Sunday, December 2, 2012

New Approach to Particle Systems

As a combination web and game developer, the HTML5 canvas is something that really interests me. I had dabbled a little in programming for the canvas with Javascript, but it wasn't until I read a fantastic article about common optimizations for the canvas that I really felt inspired to write a small framework for HTML5 games. The engine has some cool features, including a tile-based collisions/physics, animation sprites, input handling, and timing. Future functionality includes sound, resource management, and possibly a AJAX server/client interaction wrapper. This is all implemented using a message based architecture. The engine is a WIP, and the feature I'd like to talk about today is the particle system. I set out to get away from the classic model of particle systems and try something new.

The Classic Model 

Generally, a particle system consists of three parts:

Particle Collection Collection
This contains a list of emitters to be drawn or updated. Also may have any adding/removing emitter logic. Sometimes this component is non existant, like in a highly object oriented architecture, where each object would control its own emitter. Even so, if an object had multiple emitters, it would have to control a list of them like this.

Particle Emitter
This spawns and controls a list of particles.  The emitter has a specified position and time to live. Because it is in charge of spawning particles, it must store the initial state of particles. The emitter must also have the constraints on particle speed, direction, and generation rate.

This is the final, smallest part of the particle system. It renders itself and also has a time to live. Updating the particle means doing any physics calculations on its position.

The Problems 

The problems with this system is that there is a lot of information passing from component to component that is largely the same. Particles themselves have a lot of data associated with them: position, velocity, acceleration, fade boolean, fade rate, gravity boolean, lifespan, image/animation. The emitter must generate all of this from: range of angle to spawn direction, jitter, and most of the elements listed above. What this usually results in is large constructor and function calls with about 10 parameters each. There are solutions to the classic model, such as using a convention over configuration approach or storing particle information in script files. These are perfectly valid solutions, and I've used the CoC solution in other projects.

My Solution

What I did was eliminate the emitter component. The particles are stored directly in a list, contain their own initial state, constraints, and data. In addition, they have a maxGeneration number and a unique ID. Every time a particle is copied, the new particle's generation is one more than the particle that spawned it, and its ID is the same as the particle that spawned it. If its generation is maxGeneration, it does not copy itself. Essentially, to start a new emitter, you just add a particle configuration object to the list. The particle collection does the rest using a queue and set. Here is some pseudo code:
for each particle in list:
    add (,particle.initial_params) to set
    update particle
    draw particle
for each tuple in set:
    if(tuple.params.generation < tuple.params.maxGeneration)
        make new particle(,tuple.params,
A particle object is basically a Javascript object that specifies the behavior of the particle. It relies on resonable defaults, so it can be as big or small as you like: 
var particle1 = { 
  initialState : {x:134,y:575,v:.2,a:0}, 
  ttl : 25, 
  maxGen : 10, 
  image : "particle_red_img", 
  gravity : 0, 
  copy_per_frame : 15, 


I think in a Javascript environment, my scheme eliminates a lot of redundant code, which is good for reducing loading times and keeping with JS coding convention. For a language like C with no built in support for sets and variable sized arrays, it is probably best to stick with the classic model. A negative to my new system is that there is some added logic in copying particles and using the set. Like anything else, it all comes down to what makes you a more efficient programmer and what is the best fit for your project.

I would love to hear other solutions or comments about how you handle particle systems.

Thursday, November 8, 2012

In The News

My recent work with the city of Augusta,, was featured in an article that appeared on the Northern Kentucky University home page.  You can read the article here.

Saturday, November 3, 2012

Content Management Systems: 4 Pros, 4 Cons

Content Management Systems (CMS) fascinate me as a web developer, so much in fact that they were the topic of my senior paper for my undergraduate degree. CMS is a polarizing topic among web developers; many dread their usage in anyway, but others use them exclusively for web development projects. Like anything else, there are pros and cons to using a CMS, and the choice to use one depends on many factors, including your skill level as a web developer, the development environment you are in, and what the overall purpose of the site is. I have experience developing in Drupal and Joomla as well as custom solutions, so I sat down with a critical eye and listed the four best and worst aspects of CMS.

The Cons 


#4. Modules
Web projects by nature are very diverse, meaning accommodating for the needs of everyone with a single monolithic framework would be impossible. To solve this, both Joomla and Drupal have a plugin system, where small collections of scripts (a Module in Drupal, Extension in Joomla) interact with a core API to give unique functionality to the site. This is slightly annoying for a developer, especially in Drupal, where the core is so bare bones and the most basic functional aspects of a website require the installation and configuration of a module. The problem with this architecture is that it introduces a slew of new problems to the CMS via third party developers. Individual modules tend to bring bugs of their own, which may never be resolved, especially if developed by an inactive open source community. Also, because the development is managed by a third party, so is the documentation for the module, which is generally spotty or non-existent. Some companies build proprietary modules and support them, but it usually comes at a price, so your free CMS is suddenly not so free anymore. The biggest problem third party module developers introduce is security holes. Every time you install a module, you essentially have to trust that whoever wrote the module took the necessary precautions to ensure the integrity of the sites security remains intact. The most common way CMS sites get hacked is through vulnerable modules, and although both Drupal and Joomla do their best to ensure modules maintain a level of security, there are always some that slip through the cracks.

#3. Bloated Code
By their nature, CMS sites produce bloated code. At the end of the day, when the CMS core, a handful of themes and dozens of modules are used in your site, you end up with a ton of resources, and if not managed correctly, can become a code bloat nightmare. The primary sources of code bloat in CMS is a result of the level of fine tuning regarding the display of your site. Poorly written theme templates output unnecessary markup and sloppy use of inline CSS, replicated a couple hundred times, can greatly increase your code bloat. Code bloat can also arise in the form of poorly written modules that do not take full advantage of what the core already has in place. Code bloat causes numerous problems. Debugging bloated and poorly written code makes debugging web development projects, which is already an arduous task, even more difficult. Poorly structured markup can also interfere with your site's SEO, as crawlers like Google and Yahoo respond better to cleaner code. Finally, bloated code takes longer to load, which means a slower site all around.

#2. Versioning
CMS versioning is the single greatest irritation for me as a developer of a CMS site, without question. CMS are constantly under development to fix bugs and close security holes. In the past five years, Drupal has gone through four major versions, and Joomla three. This averages a little over a year before a version update, which can create major problems for the site developer. The rapid change of major releases means that the documentation and third party developers are constantly trying to catch up with the core development. In the case of Drupal, it is common to find three sets of documentation (for 6,7, and 8) interwoven in the same page. This makes the documentation difficult to navigate and extremely confusing to new developers. Modules, too, must be updated for each version of Drupal, which means that modules exist for some versions but not others. There is nothing more frustrating as a developer than finding the perfect module, only to realize it has not yet been updated to the version of Drupal you have installed. In the end, what these factors mean is that you are left with two choices. First, you can keep your site in its current version and live with the deficiencies, or you can upgrade your site every year and go through the painful site migration process, which if done incorrectly, can damage your site beyond recognition. CMS means you are at the mercy of the speed of core development, which for Drupal and Joomla is rather quick, while hundreds more CMS develop too slowly to meet the growing needs of web developers.

#1. Speed 
This is more of a culmination of the previous points. While you may see an decrease in development time from the use of modules and templates, the learning curve and the time it takes to look up information in the docs is considerably more than a custom solution. Code bloat and poorly configured sites will preform slowly, which can cost you big time. Another speed disadvantage comes from being reliant on the provided user interface to make changes to the site. When using the overlay administration in Drupal, you'll be forced to wait a few seconds while each dialog loads. Joomla seems to have a more responsive user interface than Drupal, but it has its fair share of usability issues that can slow your development process.

The Pros  


 #4. Modules 
If you've read up to this point, this header should be familiar to you. Modules do accomplish a lot of good in the plugin architecture that many CMS employ. Although there are a lot of problems with having major third party development, it means that you won't have to write very complex modules yourself. For example, both Joomla and Drupal have a full fledged e-commerce module that takes payments, sets up a shopping cart, and can manage site subscriptions. For large tasks like these, a module will move your project along much faster despite whatever documentation/versioning issues there are. Another obvious benefit of modules is that it encourages writing re-useable code, which is something I strive for in every project I do. By allowing the user to write custom modules, they are able to create unique functionality that is applicable to a product, and most likely, a family of similar products made by the same developer. Drupal and Joomla modules are very portable and easy to transfer from product to product, unlike code from custom built solutions.

#3. Themes 
Most internet users can look at a site and give the approximate date it was designed. Really bad sites get the "wow that looks like 1997 all over again" whereas some that don't pop as much as modern sites are denoted as "slightly outdated" or "2005ish". The reason for this is that web design is a trendy business and over the years we have seen blocks of traits that define an era in web design. What this means for a developer is that if you're designing a site today, you generally want to look around and pull elements from modern designs into your design. This essentially means that many sites made around the same period will have the same basic layout: Logo top left, horizontal navigation (drop down optional), large banner image, grid based layout, and a footer with contact information. We already know this is the general layout of our site, so why should we code it every time? Themes allow users to reuse and share designs, which means that the majority of those "common traits" I mentioned above will exist in hundreds of themes. Theme developers keep up with web trends, so all you have to do most of the time is swap out colors and images and occasionally re-position stuff. Some might see that as an "easy way out" or being uncreative, but I see it as another chance to avoid NIH syndrome.

#2. Team Based Development 
If you are working with a group of developers and copywriters, especially those that are non-local, using a CMS can greatly streamline workflow. By assigning different roles and permissions, a CMS can manage what each developer is able to do with the content. By default, Joomla has permissions set up for Author, Editor, and Publisher, which allow a user to compose, revise, and post content, respectively. Because this functionality is built into the system, you can organize your work roles and enforce them on the project. CMS typically will have an internal log on what the users are doing, so its easier to oversee development and generate work reports. Joomla also has a built in change control mechanism, so that if a user is editing an article, it will be checked out and no one else can edit it until it is checked in. To me, this seems like a valuable tool to ensure changes are correctly made. It should be noted that in both Drupal and Joomla, a change control system like SVN could be effectively employed to protect changes made to modules or theme files.

#1.  User-Centeric Websites 
I usually classify websites into three categories, static websites, data-centric websites, and user-centric websites. Static websites function as merely billboards that are rarely changed. Data centric sites are dynamic, but may pull data from other online sources or be updated by me, the developer (If needed, I'll write a simple script with a database, like the schedule for TG Entertainment). User-centric sites are those that focus exclusively on user content; reviews, rankings, comments, blogs, etc. Any CMS worth using will offer functionality ranging from user blogs to full fledged social networking. Writing some of these aspects from scratch would be possible, but very difficult. The key here is to pinpoint exactly what the site needs and whether it is truly user-centric or just data-centric. My distinction is like this; if the site owner is the only one updating the site, its probably more on the data-centric side and can be made with a few simple scripts or third party libraries. If the end users are making frequent updates in addition to the site owner, it is probably more user-centric, and a CMS could be effectively utilized.



In closing, there is a definite place for CMS solutions, but it is a constantly evolving place as CMS continue to grow and advance. When it comes down to it, choosing to use a CMS or not largely depends on you, the developer, and the project you're building.

Saturday, September 1, 2012

First Post

This is the first post for my new blog. My goal for this blog is for it to be an outlet to which I can give back to the web design community. I want to be able to provide solutions and resources that I find useful to my work, and hopefully, someone else may benefit from them too. A lot of what I've absorbed about productivity, web frameworks, inspiration, CSS techniques, and PHP tips have come from blogs, forums, or other forms of shared user experience.