Unity 2D, that is. With 4.3, Unity has added a whole new 2D toolset. This is great if you want to make a game but don’t have an army of 3D modelers and level designers to help make your game look halfway decent.

The only downside right now is that 2D tutorials are scarce because it’s so new (to be fair, this guy is doing great stuff) . However, the most important parts of the 3D stuff still apply here, which is great if you’re already familiar with Unity. If you have experience with object-oriented design patterns then a lot of it makes intuitive sense. I still need to actually make something to get a hang of it though, and since I’ve outpaced the tutorials I’ve found, I’ve been plunging headlong into a stupid throwaway project called Tanks Versus Mummies.

(If you’re an OG Epic Banana fan, you may recognize this as a playable game-within-a-game in Another Day at Work: Wednesday)

Screenshot of the in-development Tanks vs. Mummies. Right now it has mummies but no tanks.

So far Unity is great to work with, thoroughly documented, and robust. On the 2D side of things, I don’t like the lack of a snappable grid (resulting in unaligned pixels) but since the meat of Unity is in its code and not its scene editor people recommend creating level layouts in an external format and reading them in. The fact that we’re also dealing with a camera instead of a fixed resolution kind of grinds my gears but maybe I need to get with the times. Anyway these aren’t major problems, just aesthetic gripes.

I know some of you are curious, so I’ll lay it out here. DataJack was of course made with Multimedia Fusion 2. MMF can make some sweet games that don’t have to look as crappy as DataJack if you really sweat the pixel art and effects, but it does have plenty of quirks you need to know to get the most out of its scripting language. Thankfully, I’ve been working with programs in the clickteam family since I started Epic Banana in the 90s.

Let’s take a look at one of the later levels, “Third Time’s the Charm”:

It starts out as a bog-standard “break in and steal this thing” level but there’s a twist in the second act.

Now at the base of the level is the collision layer:

This mask clearly tells the game which parts of the level are obstacles, which are things you can crawl under, which are half-height obstacles that provide cover, glass, ledges, etc. Each type of terrain has a unique RGB color. The advantage of this method is that it allows me to modify the terrain on the fly, allowing for destructible walls and things. Destruction is very important!

The backdrop provides the visual background for the level, which provides the player with information about where there are loud and quiet surfaces, basically.

The shadow map serves two purposes: for one, the player can hide in the shadows and so it’s important to consider where to place them. Secondly, it adds a touch of visual variation to the scene and drawn-in shadows of buildings & etc. can add to the three-dimensional quality of the scene.

I usually start by roughly blocking-out a level here, on the main action layer. I drag & drop sprites into the scene to build up the level, and they are for the most part autonomous and know how to handle whatever situation I create. Things like computers and interactive stuff usually requires a little hand-tuned coding.

The roof graphics & the HUD layer sit on top of this, and there’s a separate mask to control where the roof should be displayed; e.g. you don’t want it displayed when the user is inside the building, or when the user has a line of sight to a window. The roof adds another layer of strategy to the game, as planning an approach to a building that you can’t see inside can be tricky.

The patrol map is the single most finnicky part of the game design and I should probably have touched up its code or gone with a different method. It sits in an invisible layer and tells the guards & robots the rough path they should follow when they’re on patrol. Each RGB color corresponds to a direction of motion which is slightly randomized, and the yellow colors tell patrolling guards to reverse their directions. Dealing with this thing could be a nightmare sometimes.

Lastly there’s a material map which encodes what sound your footsteps should make, and correspondingly how loud they are. There are a handful of materials in the world and some I never even used.

That’s the quick rundown. All of these layers sit in a photoshop document, and I perfected a streamlined workflow for the whole thing. The principal difficulty was in finding a unique layout with multiple approaches, where to place hackable items and how to direct the player through a sort of obstacle course.

Updates

So I’ve put bug fixes in place for what seem to be the major problems: the bugged final tutorial level and the way in which things like the red keycard don’t carry over from scene to scene. Also a handful of smaller fixes. I just need to test this version & then send it off to Desura and it’ll be ready in the week.

After this I’ll be implementing some new features: screen sizes intermediate between fullscreen and 640×480 and maybe possibly a keymapper. Stay tuned!