Infiltrator Part 39 - Tedious Baselines and Reworkings

Aside from the hustle and bustle of the other parts of my life this session has also gone slowly because it was mostly design work. There are some changes that can be expressed via screenshot though, and there is plenty to talk about.

I started out by dumping the old warrior art because it was too small. I ended up completely reinterpreting it, but am fairly satisfied with the design of the result. Now that it is a larger enemy however, there is more room for detail that I have yet to fill in. As far as intelligence goes, it has none. It is sentient, not sapient. It just kind of sits around and gets in the way until you get annoyed and blow it up.

That wasn't the center of this session however. The fifth weapon has been out of commission for redesign and re-implementation for awhile now and I figured it was time to stop being lazy and get it out of the way. The current design document explains the fifth weapon, called the swarmers, as a bunch of tiny rapid firing missiles that home in on enemies. The rapid firing was easy. The homing in on a target was easy. The whole bunch of tiny missiles was easy. Choosing an enemy to target and home in on is what ate up most of the time of this session.

You see, before the homing missiles can even target an enemy, they have to be able to see the enemies in the first place.  This becomes interesting because of the way my program is designed. It is made of a bunch of small pieces called objects. Each object owns and controls certain parts of the game. These objects are constructed like a tree. Each object belongs to(is part of) an object closer to the trunk. Objects can only see and talk to other objects that it owns, belong to its owner, or are by extension its owner. This can get messy when you have an object in the tree that needs to know about an object that is on a different branch. Case in point: the swarmers belong to the player which belongs to the level, but the enemies belong to the level and thus the swarmers cannot see or communicate with them. Cases like this occur all the time, which is why I constructed a game state that contains information such as the location of the player and enemies.  Then, anytime an object needs data like that from a different branch, the branch below it merely shows it the game state. This gets really annoying really fast though, and only now am I at the point where I see that rather than passing the game state around all over the place I should just tie a string between each branch and the game state so that they can all access it. This is a major redesign, which I am still in the middle of. The end result will be an awesome weapon though, not to mention how much easier this will make a number of things later on, so I think it's worth it.

(And now, the last paragraph in programmer terms: This is an object oriented program in which the level object owns the enemy objects and the player. The player owns the swarmers, which need to see the enemies. I had been solving problems like this by passing a game state object around by reference which contained data like enemy and player placement, but that got to the point where everything everywhere had to have a game state passed to it. I have decided that I will replace this system by having each object store a pointer to the universal game state object.)

      --LazerBlade