The first version of Enlightenment Vision was made over a year ago. It took so long to finish because I was jumping from project to project learning new aspects of Objective-C and experimenting with other game ideas. Since then I’ve improved tremendously and have been thinking about how I would code EV today.
When I started EV, I didn’t know how to use arrays, so I turned that limitation into a challenge for innovation by deciding that each game element would have a unique relationship to the other. I ended up adding in the blue corners for a scoring section, which are the only copied objects. Now, instead of writing the Life, Death, Obstacle and Enlightenment movement code separately, I would create a class of objects with properties that determine how they behave.
One property would be “collides with”. Could do multiple “collides with” properties for each object “type” (I think this is OK if you only have a few), or a string / array with a series of numbers referencing each object. Another property would define the “effect” for each kind of collision. Effects would include “strike”, “bounce”, “damage”, “kill”. Strike would function as Life and the Obstacles do now, bounce would have both objects affected by the momentum.
Another property would be “movement type” (along with the various acceleration / turning / top-speed values that Life and Death currently use). In Enlightenment Vision, Life pursues Understanding with a separate X and Y velocity while Death follows a smoother curve. There would be four properties for pursuit: one for type, one for current object, one for rules of starting pursuit and a variable to be used when determining starting pursuit (eg. modifying the % pursuit begins, or a distance the two objects must be closer than). Not necessary for Enlightenment Vision, but essential for making the system reusable. In a different game, an object could be defined as pursuing “type 1″, with a null current target, pursuit type “1″ (which would find the closest object of that kind and pursue). So when this object ticks (how often an object ticks could be another property) it will scan the game object array for “type 1″s. If it finds any, it will call checkPursuit:(1) to see if it should begin pursuit using the “begin pursuit” property of value 1, which calls for “begin pursuit immediately”. The object would set its target, and then its movement type and variables would determine how it follows.
Properties for determining the end of a pursuit (target is too far, target is dead, target has changed targets) would be useful, as would properties to define additional movement behavior like dodging incoming attackers, or weighing diverting pursuit to avoid proximity to a corner or collect a power-up, or evade if the target has recently used a weapon, or speed up if the target has recently used a technique that will slow them down / cause them to be defenseless.
A createObject function would call for an integer to determine what type, and possibly a CGPoint for location, or an integer for use in a spawningRules lookup by the createObject function, which would received the integer for what type of object, as well.
I have done something similar when creating kinds of ships in SHMUP engines, but just for determining varying stats when most of the behavior is the same. This design allows for differing behavior, dynamically generated so you can change a few parameters of an object type instead of the inefficient “change how type 1 behaves in the move function, change how type 2 behaves in the fire function”, properties for each type are assigned, so you can have more properties than you need and just switch them out during development.
Have a few projects in sight at the moment, I expect I’ll make something of this though.
