Design work

These past 2 weeks I mostly spent on design work. That is also part of the reason that I missed last week's update, nothing much happened.

In any event, I've worked out how to, practically, work out this infrastructure. I'll end up having a single pointer array of type 'dynamic_actor' which the game will walk through every cycle. Each entry will refer to an entry in object arrays of all the derived classes, which are the actual dynamic_actors (such as Door or TurretBullet). They will inherit some basic function calls, such as query() or playercollides(), which can be called from the main loop. In addition to those they will have functions depending on how each of them functions. So a Turret gun will have a shoot() function and Door will have open() and close() functions etc.

It took a little while, but I've got some basic designs laid out on how to do all that internally (and do it well, mind you) so I'm beginning implementation in the coming week.

Some time was also spent on the next iteration of Project: SPACE. I've mostly been laying out how I want to do all the objects and how the application will be laid out entirely, and once I feel good about the general outline of the whole thing I'll start writing code. I intend to take 'Design then Build' pretty seriously for this one because I feel that it helps get everything right from the get-go, which saves me a lot of work later.

Also, my priority is still CubeWars, so it's no big deal if I get distracted because of how slow that's going.

Finally, there's now a twitter feed on the blog. Not all of my tweets are on the topic of Backyard Interactive, but it's not like I tweet that often :)

See you next week!

All my designs

The past week I've mostly spent on theoretics.

In particular, the implementation of the Dynamic_Actor class. Currently the level is created with a few pointer arrays for all the elements in it. There's an array for tiles, one for Goody type objects and one for Static_Actor objects. For Dynamic_Actors I initially thought to just add another array of that type, and have that class contain all variables and functions required for all types.

Then I thought about the things I actually wanted Dynamic_Actors to do, and all of a sudden that plan seemed overly convoluted.

You see, then I'll end up with, for instance, a 'query' function that has all these different cases for all the different types of Dynamic_Actors. The code will become hard to read (and thus manage) and I'll need this base class with a ridiculous amount of variables to accommodate the (often complex) behaviour of all the different types of Dynamic_Actors.

Instead, I've been thinking on giving the Dynamic_Actors class a very limited amount of variables and functions and create child classes of different types to accommodate each different type of Dynamic_Actor. So I'll have an "Enemy" subclass that has variables such as hitpoints, response time or whatever and another subclass called "Door" which won't have any of those, but instead will have things like waiting time or key colour required. As most of this different behaviour is handled by the class functions themselves, you technically don't *need* to know which subtype it is for it to be handled properly!

So I've been planning out how I want to do that, and looking at all the caveats for that. I've written very little code, though I have begun some optimizations because of this process. It's interesting the things you find out as you plan other, similar things.

Also, I've been watching the Alien films today and was shocked, SHOCKED to find how many games take cue from the first 2 ones. Stylistically I mean. Just look at the gunship in Aliens and tell me that doesn't look like a Halo dropship... or Command & Conquers Orca gunship... or sounds like StarCraft 2's banshee... etc. etc.

See you next week!