Additional challenges in the component based model

October 6th, 2010| Posted by Andy Korth
Categories: Uncategorized | Tags:

So these problems are kind of the bane of my existence. As a problem, it doesn’t really show up until the halfway point of the project. Appeasing unexpected client requests, feature additions well into development, and code added for performance optimization purposes are major suspects.

It becomes further complicated when you end up with asynchronous loading in the mix. In our last project, we had a “dress-up” style room where meshes and textures were loaded asynchronously as the player scrolled through different sorts of clothing. It also featured streaming music that had to buffer for a bit before the UI was notified that the track has begun playing. It’s fairly straightforward to use listeners or delegate notifications here, but it’s just more complexity that spreads through the app and poorly interfaces with Start/init logic of components.

I wouldn’t imagine working on a game project where you couldn’t launch the game into any gamestate. Bypassing title animations and menus to test a simple gameplay feature is essential to my sanity. In Unity, it’s easy to do this- gamestates are called scenes, and you push the conspicuous play button when a scene is open. There are two problems here. The first how state (saved information like score and which character was selected) is passed between two scenes in a completely component based system. The second is recognizing if the scene you are loading is the first scene since the game has started, or if previous scenes have already run.

In Unity, loading a new scene destroys all entities within the current scene to load the new one. To pass information to the next scene, you must mark certain objects as “Don’t destroy on load”. For a game of any magnitude, you’l need your own framework for keeping track of your persistent entities, being able to find them if they are present, or create new ones if they are missing. Of course, this happens within code where you don’t really have control over the order of your initialization methods.

Comments are closed.