I am learning Unity

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

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.

What exactly goes into a DataJack level? And version updates

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”:

level

 

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:

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!

background

 

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

shadows

 

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.

 

 

objects

 

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.

patrol

 

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.

footmap

 

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!

Content is Done!!!

After roughing out the plot with my friend and fellow game designer Sofy, I realized that I have all of the missions I need, so the content of the game is basically done. I also now have the three main story arcs and all the concepts for the flavor text.

So right now my work is focused on writing the mission prompts and other flavor text, bug testing, mission finalizing, and then playtest and balancing. I did not expect to be this close to finished with this game after such a long development cycle.

Stay tuned for exciting updates!

Creating a New Robot

Page from my notebook outlining the AI plan. It actually worked as intended on first try!

Page from my notebook outlining the AI plan. It actually worked as intended on first try!

A bit of a detour this week, to create a new robot enemy. I decided I needed something that would stop at nothing to kill you with rockets. This could be a new way to make use of the destructible terrain.

This also reminds me that I had no idea how complex an isometric game was going to be before I started. I don’t think my next game will be isometric like this. I love the aesthetic and certainly I’m not done with it, but it it introduces complications at every step of the process, from deciding draw order on the screen, to (most importantly) coding A.I.

I also realized that for most of this project I’d been laboring under a misconception about the “fundamental angles” in an isometric projection. Properly, the four directions lie at 26.6, 153.4, 206.6 and 333.4 degrees on the unit circle. Somehow I had gotten this wrong early in my dev process, but it hasn’t screwed up anything major.

Example of part of the MMF code that's going into this new robot. Things have gotten messy.

Example of part of the MMF code that’s going into this new robot. Things have gotten messy.

Things are wrapping up on this level, and then it’s on to the three final missions. Things are really on the home stretch. I anticipate that DataJack will be out this year. Thanks for sticking with it. I can’t wait to start on a new project!

Need ideas for final missions

It’s getting to that point where I need to wrap up the missions, which means I need three different final mission sets which will wrap up the story arcs for the three factions… Which means I need story arcs for the main factions. Haha.

cyborgAll in all, I’m happy with how the project is turning out. It certainly underwent some dramatic overhauls, which just means there were things I should have implemented / done differently from the start. Unfortunately it’s really hard to see such things in advance and instead you learn them from experience, as I have done here.

There are still missions to be made, so I’m going to put down the blog and get back to this latest level…

Progress

I haven’t posted recently, but this is not a bad thing. It’s because everything is pretty much as it was last time: I’m still making levels, still haven’t figured out the magical video codec combination to make youtube like my videos, and progress is steady as always.

Latest level in development

Latest level in development

I got some solid feedback from a play tester and have been sharpening my level designs. They’re getting bigger and more difficult, which is good, and I think they’re all still pretty different from one another. I’m up to 17 missions now which is really close to where I want to be.

Balancing everything after the fact is going to be another matter entirely.

So, fear not, gentle reader, DataJack will be out this year. I just need to play a little less Nethack, Dwarf Fortress, and Rollercoaster Tycoon 2, if I can help it.

Buuuuuuuug Fixin’

Before I get wrapped up in the last handful of missions, I needed to make sure the existing ones were more or less ready to go. I replayed them all and they’re pretty much to my satisfaction- there are a handful of things to fix here and there, but nothing show-stopping. This is really good news, because it means the code overhaul went through without a hitch.

invstill can’t figure out how to record, encode and upload video to youtube such that it doesn’t come out looking like crap. This is annoying because I used to have a system that worked, evidenced by my last round of gameplay trailers, but the recent test footage I upped looks terrible. I think it’s mostly the encoding- it’s youtube’s black box processing that screws it up. It’s tricky to get an HD 640×480 video out there.

So basically things are moving along as expected. The game plays better than ever and I’m super excited to get it out. I still want to try a webcast of the dev process, but that will be when I’m ready to start on these last few missions.

Overhaul is complete

new_level

A part of a new mission.

I did manage the line-of-sight calculation overhaul on top of everything else, so now there’s dramatically less slowdown in addition to the much smarter A.I. I couldn’t be more pleased with the way it’s turned out.

So I’m back to working on missions pretty much. I would love to get some new gameplay footage but I still haven’t figured that out. Soon, though.
I’m also thinking about trying some sort of live webcast wherein I would demonstrate what goes into making one of these missions.

I also need to do a quick play-through to test for any remaining hiccups that might be left over from the code overhaul.

The AI overhaul has been a big success

The AI testing arena

The AI testing arena

I should have coded the AI this way all along, of course. The new guard AI is such a vast improvement over how it was before, and they now behave much like you think they should. This changes the difficulty of the existing levels for the better and puts to rest a long-standing reservation I had about this game.

I got around the lack of full pathfinding by having guards intelligently navigate around obstacles of arbitrary sizes… It essentially hinges on the fact that if you’re in a maze, taking every right hand turn you come across will eventually get you out.

Of course, switching code in mid-stream is not easy with MMF2. I’ve experimentally transitioned to the new AI code in a few previous missions and it all seems to work out fine.

The process of doing this has also made me consider touching up the line-of-sight calculation that all the AIs use. As it stands, it’s a very complex calculation that uses the same code as my bullets. It’s much more computationally intensive than it needs to be, and if I can pull off the refactoring I have in mind, it will dramatically improve framerates.