Next weekend (April 29th -> May 2nd) is the 20th iteration of the Ludum Dare 48-hour game development competition. I won’t be participating, but I did want to spend some time writing up a quick postmortem of Hero Test. Hero Test was originally developed for MiniLD 25 and also (coincidentally) the March/April Experimental Gameplay Project. If you want to check out the game, the original blog post is here. Definitely play that first (you can right in your web browser) before reading this postmortem.
Let’s get down to it!
My Attempt at a New Genre
My main goal with Hero Test was to create a game based completely around failure. I wanted to explore a new genre: the Failure genre – or alternatively, the Robo-Asshole genre. Is this an interesting space to explore? A game where you can only really fail? I’m always a fan of negating expectations/assumptions in order to try something new. Just about every game includes some sort of concept of progress/success as a fundamental building block – so why not remove that and see what happens?
The feedback I received was very positive, actually surprisingly positive. People liked Hero Test, but remember it’s only about 10 minutes long. I doubt players would put up with shenanigans like this for much longer. It would be a major stumbling block for the Failure genre if players would only put up with games that were 10 minutes long or less. On the other hand, I did get multiple messages asking for a Hero Test II – that’s always a good sign. I have some ideas, maybe I’ll try one out for a future 48-hour game.
The reaction to the Observer2000 character was, by far, my most important takeaway from Hero Test. People HATED Observer2000. HATED.
Here’s some feedback that I received:
- I wanna shoot that bitch talkin.
- My avatar has no hands, and I must punch this game in the face.
- I want to shoot that piece of crap robot.
- Who does this Robo-?$@%@$ think she is?
- … and many other variations on these themes.
People were really, honestly pissed off at this character. True emotion. The interesting thing here is that Observer2000 has none of the components that you generally think of when someone says ‘game character’. There’s no animation, no model, no textures, no stats, nothing resembling true AI, almost nothing at all. Observer2000 is literally just a handful of audio files tied to some game mechanics and triggers. None of this stopped players from thinking about, or referring to Observer2000 as a ‘she’, a ‘robot’, a ‘bitch’, a ‘piece of crap’, or a ‘Robo-?$@%@$’. That’s pretty cool.
When working on game AI, I’m always looking for ways to connect players to the virtual characters they are interacting with in a meaningful way. It’s cool to see such a lightweight success story. In a lot of ways, the super-abstract nature of Observer2000 helped players connect with the character. Make something frustrating, throw a cool robot voice effect down, and poke at the player a bit and you get a reaction. This is definitely a lesson for me in the future, at least when working on small games: consider making your character smaller and more abstract than you think it should be. People might develop a stronger connection. A lot of players experienced this idea in Portal, a game that Hero Test is heavily inspired by – obviously.
How to Introduce Total Failure?
When I first started working on Hero Test, I wrote down a whole bunch of ideas of potential ‘tests’. I only ended up using about a third of them in the game, and the first one is the ‘Test of Speed’. In this test, the player is hitting a button and trying to run through a door before it closes. There is no more classic game mechanic! It’s actually one that I almost always really hate in games, which is one reason why I wanted to make this the first test.
I thought it would be hilarious to prompt the player to “run” and do a “dive and roll” in order to make it through the door, but in reality pressing the keys does nothing. Here’s how I imagined it going down from the player’s point of view:
- Ok, let’s press this button and head through the door.
- What the Hell, I didn’t make it? I’ll try again.
- Press shift to run, ok. Why am I not going faster? Damnit, the door slammed. I’ll try again.
- Press R to dive and roll through the door? I can barely even walk, maybe something funny is going on…
I thought the concept of diving through the door would be clearly ridiculous (based on how primitive the movement and presentation of the game is) and trigger some thoughts questioning the experience… but a few players just thought that the game’s controls were broken. In retrospect I think that I probably should have used the ‘collect the orbs’ puzzle as the first level. This one doesn’t involve any control confusion, just simple movement and absurd failure. I think the ‘broken’ control trick would have been a better one to pull later on in the experience when more of the audience is in on the joke.
Playmaker and Unity
One of the main reasons I decided to develop Hero Test was to test out my friend Alex’s Playmaker plugin for Unity on a “real” project. Playmaker is a visual state machine editor, and it is awesome – highly, highly recommended. When you really get down to it, a huge percentage of game components turn out to be finite state machines – and Playmaker does a fantastic job of automating the creation, maintenance, and execution of FSMs in Unity. I have a hard time imagining working on a personal project with Unity in the future and NOT using Playmaker.
If you want to see what the workflow of developing a game with Playmaker looks like, here is a timelapse video I made of the Hero Test development.
Looking back over my project, I made the totally amateur mistake of letting my FSMs get overcomplicated. This honestly wasn’t a real problem, since the complexity never reached a level that made maintenance difficult on a project of this scale – but I know that next time around I will be able to do a much better job. There were three major things that lead to this complexity:
- I only had 48 hours, and had a bunch of other non-game-development-related stuff to do that weekend. Time crunch leads to poor decisions.
- I wasn’t feeling well at all. A hazy head leads to poor decisions.
- I didn’t realize how easy it is to communicate between FSMs in Playmaker.
The only really interesting reason in this list to talk about is the last one. If you decide to work with Playermaker (or with FSMs without Playmaker), I would recommend thinking hard about the responsibility of each FSM that you develop – should your FSM really be two separate FSMs? In Playmaker, communicating between multiple FSMs is very easy. If I had realized this earlier, than I would have pushed harder towards breaking up my FSMs more.
A good example of this in Hero Test is the Observer2000 audio triggers. For the most part, I built these cues into the same FSMs that control the level logic of the various tests. If I were to do this project over again, I would separate much (or all) of the audio cues into FSMs that are separate from the level logic. This would have made iteration easier.
Graphics and Textures
MAN do I suck at anything visual. I just have absolutely no eye or talent for making things look good. My lack of skills is the reason why there are no textures in Hero Test, just some static colors and lightmapping. At one point during the 48 hours I tried to make some textures for this game, and it was a complete disaster. I’m not talking about anything fancy here, just some basic textures for the floors and walls. What I came up with was a complete embarrassment. The texture I made for the floor was actually creating some sort of optical illusion that would make your eyes see grey lines where there weren’t any lines. Find an artist and tell them to make the worst texture they can imagine, and guaranteed I can top it.
It’s really embarrassing, and makes these 48-hour projects difficult for me since I don’t have the skills to make something that isn’t painful to look at. At some point I need to take a class or read some tutorials or something.
The level design in Hero Test was very blocky and straightforward. A lot of this was intentional, part of the ‘charm’ of a sterile, sci-fi testing environment, but honestly I couldn’t have done anything more interesting if I wanted to. Again, this is a major missing area of my game development skillset. I used to make pretty cool DOOM and DOOM2 levels, but times have changed big time.
Even without better design skills, I should have been more aggressive in making prefab rooms for Hero Test. I made pretty much everything from scratch out of primitives, and lots of the rooms were very similar. Some simple prefabs would have made developing these levels much faster. You can see this inefficiency pretty clearly if you watch the timelapse development video.
All in all, I consider Hero Test to be a success. I definitely made some poor choices, and there was plenty of room for improvement – but the concept was solid and the execution was decent enough – especially for a weekend. I think the failure concept I developed was unique in a lot of ways, and that’s one of the main reasons to work on these 48-hour projects. Try out some new stuff and see if it works. That’s fun, right? I also really liked the end, and especially the final voiceover. I thought it wrapped up the whole experience in a pretty cool way. It was also a bit of a twist, and that’s always fun.
Of course it’s always a bonus when other people like something that you made, it makes me want to develop more stuff. Here’s some feedback:
- That’s brilliant! I laughed out loud, several times!
- The best game I’ve ever played. <— Note: That dude/dudette probably hasn’t played many games.
- I was smiling through the game for the whole time, very well done.
- Hero Test II?
- This was awesome.
I will close with the most interesting piece of feedback that I received regarding Hero Test: “… kinda reminded me of my life.”
Thanks for reading!