Solar Fortress Chronicles: Hours 10 – 13

Solar Fortress Chronicles: Hours 10 – 13

Note – I am rapid prototyping a retro game in my spare time and keeping a diary of what I do each hour of the project.

This another update on my latest mini retro remake, Solar
Fortress (pronounced Star Castle).

I got off to a slow start in hour 10 by somehow “fat fingering” my for-loop in such a novice manner that I spent an extra 30 minutes trying to discover my stupid error. Needless to say, you can come up with some very “Interesting” results if you substitute the counter in your for statement with the variable holding the pre-calculated length of your array:

(for var ctr:int=arraylength;arraylength >=0;arraylength );

The 2nd and 3rd arraylength references should be ctr. When I looped though my projectiles for update, only the last one shot would update and when it’s max life was exhausted, the next would move, then the next, etc. It looked cool, but really worked like ass (obviously).

My next task, after player ship projectile movement, was to test their collisions with the outer ring of the “fortress” (pronounced castle). My first idea was so simply test a circle v. circle between projectile and the the outer ring circle. That worked well at first, so I continued with a loop through the red line segments on the outer ring only if the circle v. circle was true. The outer ring segments are rotated BitmapData inside bitmaps and because of this I needed to use a standard hitTestPoint between the center of the projectile and the ring segment. I would have used BitmapData.hitTest but because the Bitmap instances do the rotation, not a matrix on the Bitmapdata, the collision would not have been valid.

This seemed to work properly until I the player shot out 10 of the red line segments. At that point, the dynamic collision circle on the outer ring went haywire and began expanding and contracting at will. Although this effect was actually pretty awesome (I’ll bank it for the later Zarjaz phase), it didn’t make collision detection work at all. I quickly replaced the dynamic circle radius calculation with a fix radius and it started to work properly.

I then added hitpoints to the ring segments, which necessitated my created a class for the segments to hold current and max hitpoints. Up to this point I had not treated the line segments as a separate class, but was using a simple Bitmap instance. In rapid prototyping games like these I have a set of questions that I ask myself before I create a class for an object. I usually have to answer yes to two of these before I create a class for an object:

1. Do I need more than one of these?
2. Do I need only one of these, but is it so specific that it would consume too much game loop (or other parent) code to manage it “in-line” and be better encapsulated as a singleton?
3. Does it exceed what a standard Flash built in class can handle – needs its own attributes, or must encapsulate other objects for ease of management?

Originally, the line segments answered 1. Yes. 2. No, 3. No., so I didn’t give them a separate class that extended Bitmap, I just used a Bitmap instance for each. Now that I needed hit points for each segment (because they don’t die at the first hit), I re-wrote all of my code to use a RingSegment class that encapsulated all of the attributes and specific functions for the RingSegments.

When the player destroys a certain number of segments in a ring, the ring grows back (this increases per level to make the game more difficult). I had been treating the 3 ring segments in my Fortress class as a set of individual attributes made up of:

1. An array of segment Bitmaps (now RingSegment objects).
2. I sprite (ringsprite) to place the rings on
3. A holder sprite to rotate the ringsprite – the ringsprite was placed at -1/2 width, -1/2 height s it would rotate properly when the holder is rotated.

I had three sets of these named with ring1_, ring2, and ring3_ prefixes, but it was now time to buckle down and decide if I needed to create a class for the actual rings:

1. Do I need more than one of these? YES
2. Do I need only one of these, but is it so specific that it would consume too much game loop code to manage it “in-line” and be better encapsulated as a singleton? NO
3. Does it exceed what a standard Flash built in class can handle – needs its own attributes, or must encapsulate other objects for ease of management? YES

It was now time to spend a couple hours fixing this up and creating the new classes. After I was complete with my new classes, I ran it, fixed the 150 errors and warnings I had created for myself, and now had a little more progress to show in my spare time retro game.

(below is the current build – arrows to move, space to fire).

0saves
If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.