Anyway, YouTuber and Twitterer (Tweeter?) @xtomass recently uploaded a video of his play-through of version 0.0.6 of Slay the Beast and I would be remiss not to share it.

So, enjoy!

As proof, here’s a (very) early work-in-progress screenshot of my current indie game project, Slay the Beast:

Slay the Beast is a versus fighting game where one player controls a huge boss-level monster. While the other player controls a puny (but respawning) hero. The sprites are from Oryx Design Lab‘s Hifi Gothic Set and animation is done with Spine, from Esoteric Software.

The game is still at an early stage of development. Heck, I just started this project a few weeks ago! However, I plan on making WIP builds available soon. Stay tuned for more news.

EDIT:
Here are some more screenshots for your viewing pleasure:

And one more for people who’d like to see how characters look in-editor:

So, yeah.
The last few months have been pretty darn busy. Hobby-life, work-life, personal-life, everything seemed to peak right about the end of February. I’ll be honest. I’m feeling pretty tired. I may even be feeling, dare I say it: burned-out.

Well, not full-on “burned-out” I don’t think. That’s actually a pretty major state of affairs. Still, I’m starting to notice some warning signs and I’ve had trouble bringing 100% of my power to bear on any task lately, be it was work or at home.

Now, the advice I’m about to give is not based on any particular professional expertise. Indeed, I’m about as layman as they come. But, I am someone who has worked himself to the point where I had to take a stress-induced leave from work so I thought I’d share some of the signs I watch for with regards to my emotional health.

Know Your Symptoms, Know Yourself
While there are commonly accepted symptoms of burnout, I find it important to be aware of my personal quirks and behaviors and to specifically recognize certain behaviors as warning signs.

Since a lot of my job is about problem-solving (both after-the-fact and preemptively), I’m used to having lots of ideas for how I can solve a problem. When I’m at my best, I can usually come up with several potential solutions to problems at work after brief reflection. When I’m starting to burnout, that flow of ideas slows to a trickle, if not stopping all together. I don’t seem to have trouble identifying problems at that stage however. So, if I find myself identifying lots of problems without being able to provide potential solutions along with them, I have a strong sign that I’m beginning to fray.

Usually, I really like working on games. I find it energizing. Sure, there are times when the work is just tiring, but that’s the exception, not the rule. And it never happens for extended periods of time. Unless I’m starting to burn-out. If I look back over the last week of game dev and can’t think of a single instance in which I had fun while working, then I know it’s time to give myself some extra care.

One corollary to the above is that, even when I’m overall exhausted with work, crises are still “fun”, or at least temporarily energizing. Even if work is a slog and I’m running on emotional fumes, I still find it easy to gear up to deal with a sudden crisis (ex. The publisher’s build is broken! We need a bugfix quick!) But, that crisis-time energy boost is quick to dissipate and can leave me feeling just as empty, if not more so, afterwards. I generally don’t count these crisis moments as being satisfied with work since they are effectively emotional junk-food for me.

On a more physical level, I try to stay aware of signs that my body is reacting to emotional exhaustion. If I start putting on weight and developing acne, chances are I’m starting to react negatively to the current stress levels in my life. Like many, I find that my sleeping habits tend to change once I become overwhelmed. For me, my warning sign isn’t sleeplessness. I tend to sleep MORE as I become stressed but I find myself feeling LESS rested in the morning despite the extra time spent in bed.

While all of this may not pertain directly to game development per se, I think it is worthwhile to keep one’s own emotional and physical well-being in mind while engaging in an activity as engrossing as game development. People who tend towards game dev are a peculiar breed, we are truly passionate about what we do and we are prone to overdoing it if left unchecked. Being aware of how you personally react to stress and knowing when you’re getting overwhelmed are your first line of defense against burning out.

Okay, okay. I’m about two weeks late but I finally finished up my February #OneGameAMonth entry. In my defense, I did have a confluence of life and work events knock into my schedule. But, that’s neither here nor there. I said One Game a Month.

As I mentioned previously, my goal for February’s game was to capture some of that Itano Circus feel. With that in mind, I even went so far as to name the game “Itano Alpha Flight”. And now the game is available for you to play.

Itano Alpha Flight is an action game written in XNA and running on Windows. The goal of the game is to destroy enemies in rapid succession with your lock-on missiles while avoiding their projectiles. You can control the game with either the keyboard or with an Xbox Controller.

To play, you just need to download this file, unzip it, and run Itano.exe.
I’m just one guy, so I can’t really make an guarantees about the suitability of this game for any purpose but I expect it should run reasonably well on most Windows machines.

You can also see how the game turned out in these screenshots:

So, if you have a chance, give Itano Alpha Flight a try and let me know what you think. In the meantime, I’ll be plugging away on my next project.

Before that though, a few words about why I’m doing #OneGameAMonth (#1GAM for short) in the first place. Here is the mission statement from my #OneGameAMonth profile page:

My biggest hope in joining #OneGameAMonth is to use it as a chance to challenge all my assumptions about how games should be made. By holding to the seemingly impossible goal of One Game a Month, I hope to find what I need to change (and what I’m unwilling to sacrifice) in order to make more, better games. Also, making friends and becoming AWESOME!

My main goal is to challenge myself to approach game development in ways that I haven’t before. So, this is how am I doing so far:

For my first #OneGameAMonth project, I decided to start with an easy warm-up: an update of an existing game. In this case, an update for my latest XBLIG game, Robot Legions. Be sure to check it out to see how it went.

For my next trick, I’m going to try for a real challenge and make a new game.

Naturally, making a new game from scratch takes time so I’m leveraging as much of my previous projects as possible. I’m even going so far as copying my last released game’s code wholesale and then replacing the parts I need to make my new game. While I am spending some time cleaning up and excising code I don’t need, I expect this approach to pay dividends once I start having to implement menus and such. If I can get away with just re-skinning and adjusting the flow of my previous title’s menu code, I can spend that much more time focused on the gameplay itself.

The other weapon in my time-saving arsenal is an almost single-minded focus on the game’s concept. I want to do ONE THING with this game and that is replicate the feeling of an Itano Circus. The Itano Circus (or “Macross Missile Massacre”) refers to the wild flurries of missiles that occur in anime dogfights like those in Macross. Check out the video below if you want to see what I mean:

While making a game, it’s easy to have feature creep set in and blow the scope of the project. As much as possible, I’m trying to stay aware of that phenomenon and stop myself went it starts to take place. Whenever I have a new idea for the game, I ask myself: “Does this help the Itano Circus feel?” If not, I cut it. Then and there.

Here are screenshots of what I have so far.

(It’s probably not coincidental that every choice I make to bring out the Itano Circus-ness of the game seems to take it closer to Afterburner II. I imagine the creators of that game drew inspiration from many of the same sources I’m now using.)

So far, I’m managing to keep focused on my goal. Hopefully I can keep it up and finish this game this month. After all, I have a new project waiting for me next month because, well you know, #OneGameAMonth.

Each of these poor men is being totally honest in their description, but the end result ends up being divorced from reality by the limits of their own perception. The moral of the story is for one to be aware of where their limited perception (or preconceptions) may hide information from them. In more colloquial terms, it’s about learning to see the whole picture.

This lesson also applies to programming, particularly when designing code. For almost any programming problem, there are several, potentially competing, factors that play into its solutions. It’s easy to get so locked into a single mindset that you overlook important factors that you would only have noticed from a different vantage point.

When I need to design a piece of code, I try to think about it from at least the following three perspectives. Of course, these thee perspectives don’t represent the full set of potential viewpoints from which to examine a problem. These are just the three that I’ve found to be the most useful tools for my day-to-day programming work.

Class View
At this stage, I think about how I would structure my code with traditional Object-Oriented Programming techniques. I think about the data and functions that would be a part of the core “objects” in the feature I am creating. If things get hairy, I bust out some UML to track dependencies and ownership relations. This views tends to make the code most easily digestible for many game programmers because most of them have been raised on OOP principles.

Data View
This is where I look at the problem I need to solve in terms of data that needs to be processed. As opposed to thinking in terms of classes which are collections of data and functions that operate on that data, I think about data processing as a pipeline. In many cases, this sort of thought process leads me to the core update loops that will form the core of the feature I’m implementing. This view is often about making the code easily usable for the target machine. In many cases it’s about taking data that has been gathered and normalized so it can be processed in a minimally-complex fashion.

User View
I wouldn’t be a very useful programmer if I ignored my end-users. If my feature needs someone to author data for it (and almost every feature does in some way or another), I’d better make sure they can create that data in a reliable and reasonably error-proof fashion. This is especially true if they have to produce a lot of data or need to iterate on that data repeatedly.

I don’t always use the above three views in that order, but I generally make sure to ask myself if I’ve considered my design from all three of these perspectives before I start working on any significantly large feature. Sometimes the best thing I can do when programming is to stop and ask myself: “Have I seen the whole elephant?”

So, with a family and a full-time job, where do I find the time to make games on the side? The answer is: wherever I can. Here are a few of the ways I try to make the best of my limited gamedev time.

Task List
First of all, I make sure that I have a list of tasks planned out for my game project. While I’ve played with various task tracking solutions at work, for my private projects I settle for a good old text file TODO list. By writing out what I need to do, I give myself an explicit list of work that I can reference any time I have a spare moment to do some gamedev. Of course, the simple joy of crossing items off a TODO list is a powerful motivational factor.

One of my key tricks here is the granularity of my task lists. While I generally start off with coarse tasks, I quickly sub-divide tasks into smaller units as I better understand the work involved. The result is a list of small tasks, many of which are only 10-20 minutes long.

Stolen Time
This is where having such a fine-grained task list comes in handy. As a full-time employee and family-man, it’s very rare for me to have long-periods of contiguous free-time to devote to gamedev. If anything, my day is constantly split up by the toils of daily-life.

Without a consistent period of concentrated gamedev time to use, I’ve grown accustomed to using the small periods of free-time that appear over the course of a day. On a typical day, most of my indie gamedev takes place during the 20 minute bus ride to work, the 10 minutes I can actually sit on the train back (I take my son to day-care in the mornings so my routes to and from work are different), and 30 minutes or so of free-time during lunch. Other than that, my daily gamedev time depends on how much sleep I’m willing to sacrifice.

Getting anything, especially programming, done in 10 minutes seems difficult at first, but I’ve gotten better at it with practice. Before, I generally assumed I needed at least 20 minutes to rev up my mind before I could hope to program effectively. Nowadays, I’ve become rather practiced at keeping my head pre-revved so that I’m ready to go the moment my fingers hit the keyboard. Last time I was at a conference, that 10 minute break between panels proved to be the perfect time to whip out my laptop and bang out some code. Still, it took a fair bit of practice to develop this skill and there still times when I just need to sit down and concentrate for several hours straight to get something done.

Precache
With only 10-20 minutes to spare to accomplish a task, all those little bits of time lost to programs loading or closing count. Over the last year, I’ve grown very conscious of how long it takes for my most-used programs to fully load and become useful. To compensate for this, I often use the last minute or so of any development period to prep my environment for the next task. If I know what I’m going to implement, I launch Visual Studio and open up the relevant source files before I close my laptop. That way, the next time I’m able to start coding, my dev environment will be ready for me the moment I can start working.

None of these tips are particularly revolutionary or non-obvious. Still, it’s often the little things that count as they can often add up into something quite significant. For example, I made most of Robot Legions over course of five months of such bus-ride and lunch-time development. Making games is hard and time-consuming, but it doesn’t have to be impossible if don’t have gobs of free-time at your disposal.

So, in the spirit of helping out others using Unreal Engine 3 or the UDK, here are three features that I wish I had known about when I first started using Unreal.

Kismet Console Command
What’s the easiest way to call an UnrealScript function from Kismet? Write a custom sequence action? No!

Use the Console Command sequence action. Using it you can call any function marked with the exec keyword in UnrealScript. All you need to do is pass in a valid target for the sequence action (most likely a PlayerController, like in the convenient All Players kismet variable.)

Cause Event
Console Command will allow me to easily call into UnrealScript from Kismet. What if I want to go in the other direction? That’s where the Console Event node comes into play. This kismet event gets executed when the “causeevent” console command is triggered through UnrealScript. This makes it trivially easy to write code that calls out from UnrealScript into Kismet.

Having a Pawn, for example, calling “causeevent PawnHitWall” (“CE PawnHitWall” for short):

   PlayerController(Controller).ConsoleCommand("CE PawnHitWall");

Results in the following Kismet event being called with the PlayerController’s Pawn passed through as the Instigator:

ActorComponents
I’m a bit sheepish to admit it, but I jumped into Unreal without really understanding the relationship between Actors and ActorComponents. As a result, I probably created dozens more custom actor classes then I ever needed. In hindsight, the extra classes were senseless because it is so trivially easy to add new ActorComponents in the defaultproperties of a class. Spawning Emitters (a descendant of Actor) when I could have just added ParticleSystemComponents in my Pawn’s defaultproperties block was probably my worst offense.

If you only read one page on UDN, read the page on ActorComponents. (If you only read one page on UDN though, you’re probably doomed. Read a lot of UDN pages, just make sure you don’t miss the one on ActorComponents.)

For people experienced with Unreal, these tips are probably old hat, but it’s surprising how far you can get with the engine while still missing basics like ones above. Personally, knowing the above tidbits ahead of time would have probably sped up the development of my first Unreal Engine game prototypes significantly.

Here’s the thing though. While talking with some fellow game devs the other night, we got onto the topic of old 8-bit / 16-bit era chiptunes and how great we thought they are. Then, we started talking about how, despite all the iconic tunes we could remember from that era, we couldn’t think of nearly as many great examples of video game music from more recent games.

That got me wondering. Why did we have so many fond feelings for the game music of yesterday, but not nearly as much for the music of today’s games? Is it just nostalgia at work, or is there something else at play?

Well, to be honest, it could just be nostalgia, right? As a general rule, many people stop listening to new music as they leave their 20’s, forever crystalizing the songs of their teens as the apex of their musical world. As a member of a generation that grew up with the NES and Super NES, does that mean that no new game music can compete with songs of my 8-bit past?

Every piece of video game music I can remember from the 80’s and 90’s is great. But then again, that’s every piece of music I can remember. Time filters out the mediocre. That’s why very few people remember the lesser shows that came out of the previous decade of sitcoms. That’s why very few people remember the tunes from games like Amagon:

To be fair to Amagon, it has a few catchy tunes in there, But they’re not great by any measure and that’s why they’re mostly forgotten. When we compare current game soundtracks to our favorites of the past, we are often comparing both the average and the potentially great of the present against the truly great of the past.

Of course, generational bias can explain all the differences away. There are also significant technical aspects to creating game music that actually give the 8-bit era and edge in terms of creating memorable tunes. Even with specialized sound hardware like that found in the Super NES, chiptune composers were still significantly constrained in terms of the ways they could combine sounds. In many cases, they were lucky if they could play 4 voices simultaneously which meant that they had to be very efficient in where they focused their composing efforts. Without a solid, hummable melody line, a chiptune would be nothing but context-less sound. A square-wave can only really sound like a timpani if there’s a melody around helping to establish it as part of the music.

Modern games, on the other hand, have the full suite of sound available to them that had previously only been the realm of TV and movies. This works to their advantage in allowing them to create full, swelling orchestral soundtracks to go with their games but also costs them some of the more poppy, melody-driven sensibilities of the 8-bit era.

It’s also worth remembering that, as the cost of making games has gone up, so has the cost of making game music. When watching this series of videos on GameTrailers about the creation of the soundtracks for the Mass Effect series, I was struck by composer Jack Wall’s comments about how tight their production schedule was. It takes a lot of time to make good music and even a multi-year project may have trouble getting it done in time. Compounding this is the tendency of a lot of video game productions to handle audio as an afterthought relative to programming and graphics. Add to this that a lot of game devs to underestimate the time needed to make great music and it’s little surprise that a lot of game soundtracks don’t live up to their full potential.

You know, making memorable music for games is hard. It’s probably only gotten harder as game technology has become more advanced. It can be done though. That being said, it is kind of telling that the only music I remember after finishing Deus Ex: Human Revolution are the piece from the trailer and the re-hash of the original Deus Ex theme they played after the credits.

You see, there are times when designs that look “right” when viewed through an OOP lens turn out to be ill-suited to solving certain problems in game programming. One of the major causes of this is the tendency of OOP to encourage thinking of problems in terms of single data objects. Often this works because handling multiple instances of an object is a natural extension once you know how to handle a single instance. This isn’t always the case however and it’s common for OOP-oriented programmers (OOPOP?) to overlook cases in which it would be better to think of processing data as a gestalt as opposed to as lists of stand-alone objects.

To clarify this idea, I’ll share a recent experience with some code at work.

The story that follows is a familiar one. We, the programmers, had adopted a fully-featured game engine with a suitably large codebase. The engine’s 3D features were, as to be expected, top-notch. The engine’s 2D feature were not quite so developed. It mainly consisted of a set of functions to draw sprites onto a 2D HUD at particular positions, scales, rotations, etc. It had no useful UI features like buttons or other widgets nor could it handle hierarchies of sprites. This meant that any sort of menus beyond the simplest single-depth affairs would be impossibly clumsy to implement.

So, like any good programmer, one of our number set about extending the engine’s 2D HUD system with our own hierarchal sprite management system as well as some basic widgets. Throw in some runtime tools for tweaking UI layouts and we were golden. At least, we were until we started implementing some of the more complicated menus in the game.

You might not notice it at first, but most game menus actually have significant amounts of information being displayed at once. Unchecked, these menus can result in surprisingly large numbers of sprite renders. And that’s what we had in our project. Lot’s of sprites being rendered at once and our framerate tanking on our menus. Heavy menus? I thought the game itself was supposed to be the heavy part? What happened?

Well, having the hierarchal sprite system written in a scripting language didn’t help performance, but that’s a straight-forward transcription away from being solved. More to the root of the problem was the design of the hierarchal sprite system itself. You see, it was almost text-book OOP with “sprite” being the core object. Sprites were independent objects capable of rendering themselves The first thing the programmer probably did was write code to make sure a single sprite could render itself. Then, he made sure they could be connected hierarchically, deriving their absolute screen position based on their relative offset from their parent.

For the most part, that approach makes sense, until you look carefully at how sprites were actually being used. Almost every sprite we used was the child of another sprite in a multi-level child-parent hierarchy. We would render our root sprites and expect the render command to travel down to child sprites through the hierarchy. So far, so good. But, every sprite was designed to be able to calculate its own absolute screen position. To do this, each sprite would query its parent’s absolute position and add its own relative offset. These absolute position calculations therefore involved climbing back up the hierarchy to the root. This operation was performed by each child and would only become more expensive as we went deeper down the hierarchy with each depth requiring longer trips back to the root to calculate screen positions.

“Wow”, you may say. “That behavior is horrid.” And you would be right. If you’re already traveling down a hierarchy, it makes sense to calculate values like absolute screen position and propagate them downwards as you perform the traversal. But, it was surprisingly non-obvious from the OOP perspective. Had the programmer who implemented the sprite system thought in terms of how hierarchies of sprites should be rendered as opposed to how single sprites should render themselves, I imagine he would have written very different code.

Object-oriented programming has a powerful tendency to encourage thinking in terms of single objects and assuming that the handling of multiple instances of said objects is a trivial extension. For a lot of high-level game logic, this is probably a correct assumption. But, in cases where you need to process large amounts of data, this sort of single-instance thinking can be debilitating. While swearing off object-oriented programming would be akin to throwing the baby out with the bathwater, it’s good practice to occasionally question your own thought process and approach problems from a different angle.