You know, I often get asked questions like “What the hell are you doing over there, typing into your weird Notepad-looking thing with strange text highlights and brackets all over the place?” In answer to those queries, and because I’ll spend a bit of time explaining what I’m working on at the moment.

What I’ve been doing over the past month or so since the direction shift has been modifying the engine and game code for the new style of game. While I first thought there wouldn’t be all that much to do, I quickly found that if I wanted to do it properly, it would have to be a bit more involved. If you’re curious about the process of converting a tower defense game to an action-oriented isometric shooter with physics and collision, then this is for you!

Refocusing Input

---

Initially the input was focused on building, with character movement and control being secondary – naturally that needed to change with the new focus, and so the first thing I did was to refocus the input and player system to be character movement- and control-centric. I took this opportunity to make the player’s controls work off a state machine, which allows the input code to be a lot more modular and self contained.

Universe Get!

---

While polishing off the new player input, I spent a lot of time changing around the layout of the engine to allow for multiple levels. This was a fundamental and wide-reaching change to the engine, as the majority of classes assumed that only one level existed – I think I touched at least every single class in order to fully make this change.

It’s interesting – the evolution to the new paradigm (a WorldManager has a list of Worlds, each of which has a CollisionLevel, which that World’s objects are attached to) took a few iterations, as I started working on a paradigm and then realised that I wanted to make the system more modular and portable. That’s a big reason why this element took a lot of time, but I believe it’s worth it, as now potentially we can have as many levels or worlds as the iPhone’s RAM allows; I’m not promising this feature will make it into the current game though, as it all depends on the time we have to make resources and the effect that multiple underground areas would have on game flow.

Scaling the Engine

---

I thought I was home free and ready to work on the new collision/physics systems, but a little snag popped up along the way – previously all of the movement in the game was static, and mostly happened in graphics space – a pixel on the screen was a “unit” or meter in the game world. Of course, I didn’t want my characters to be thirty two meters wide, and for them to have to run at a hundred kilometers per hour to get from one side of the screen to the other in a decent amount of time, so I decided to separate the game’s scale from the render scale.

I won’t bore you with the details, but this was another icky problem where a lot of objects assumed that things were happening on the screen – some of which should (UI objects and etc), the rest of which shouldn’t. Needless to say, this took over a week of part-time work to resolve, and there are still a few issues hanging around.

Collidomatron

---

Finally, last weekend I was actually ready to start work on the collision system – the foundation that the new gameplay would rely on. I decided to roll my own as opposed to using Chipmunk or whatever because I’ve got a decent amount of experience with collision and physics systems, and I don’t intend to do anything too difficult (springs, complex shapes, etc). It took a relatively short amount of time to get the core physics up and running, and then during the Sunday workLAN I got both rudimentary object-to-object collision (so people don’t walk through each other) and object-to-world collision (so people don’t walk through walls) working, both of which came together with surprisingly few hiccups.

Tada!

---

So that’s where I’m at right now. The next thing on my list code-wise are the two checks we need for the characters to be able to shoot – LineInObject (which will cast a ray into the world and see what it collides with) and DoSphereTest (do a sphere check in a position with a radius and return all mobs that are within that sphere). The former will be used for pistol- and sniper-type weapons, and the latter I’ll be using for shotgun-type weapons. I also need to do some more work on player movement – at the moment it feels a bit sluggish and slidey, but I think I’ve figured out the forces to apply for it to feel right.

- Jason

One of the important elements of the new design focus is your base of operations – the Wright Mobile Labs. It’s a custom aeroplane, designed to fit somewhere between a jet and a spacecraft, and  it is the characters safe haven against the dangers outside. It was in the original tower defense design mostly just as a story element, but now it will be fully playable and explorable, and will serve an important function as the part of the game where you upgrade your equipment and research new technology.

However, in order for the base to be explorable, it needs some collision made up for it, so that the characters can walk around without walking through walls or other obstacles (or outside the ship).

To show how incredibly high tech and not quickly-thrown-together our systems are, here’s a screenshot of me mapping the collision file that gets exported into the game to a diagram of the ship.

You may need to click through to see the parity between the two images.

Warning: the next paragraph may contain technobabble.

The “x”s in the table on the left are grid positions that are “blocked” – the characters can’t walk to them or through them, and the “o”s are traversable terrain. Once you’ve seen the similarity between the two, you may note that the diagram is upside down – this is because the iPhone (or cocos2d, I’m not really sure which) sets up its grid +x right +y up, instead of the more common +x right +y down. Therefore, if I want the table to read from bottom to top, it needs to be reversed, as does the diagram!

Anyway, once the file on the left is exported and compiled into the engine, it will read each entry in the table and set the collision node to blocked or unblocked depending on what’s in that cell. And voila! A world* is born.

That’s it for this peek into the development of Shadow Field – I’ll be back with more as I tweak the systems for the new gameplay!

Cheers,

- Jason

* or at least the inside of a plane…