This past weekend I participated in the 30th Ludum Dare 48-hour competition and created Fusebox, an energy management simulation game. What follows is a summary of my experiences creating it, and what I learned from doing so. I had a lot stacked against me, and while I missed some milestones that would have taken the game from mediocre to great, I think that I did really well considering the situation. Before we can assess that though, we have to start from the beginning.

Sure-footed as a Mountain Goat

One week before the Ludum Dare competition started, I was at the local rock gym with a friend of mine. They had more than just rock walls there, and in my first (and most likely last) attempt at this whole slack-lining thing, I fell and landed sideways on my foot. It instantly swelled up to the size of a potato, and I haven’t been able to walk properly since. I have made a pretty decent recovery so far, but one thing I can’t do is sit up. If my foot isn’t elevated above my head, it swells back up like a balloon and becomes incredibly painful. Since working on a computer with any amount of comfort necessitates putting your feet beneath the desk, I wasn’t sure how it would turn out.

This is what you get for hanging out with extroverted adrenaline junkies.

This is what you get for hanging out with extroverted adrenaline junkies.

Over the course of the weekend, my foot turned out to be both more and less of a problem than I expected. By lowering my chair, throwing a pillow on my desk, and leaning back, I could actually sit somewhat comfortably for more than an hour at my desk. It required me to be a bit twisted, and it probably wasn’t good for my back, but I was actually able to sit at the computer. Had this not been possible, I had a backup plan of writing a game in javascript from my laptop, since it can’t run Unity. In retrospect, I probably should have gone that route, but I really wanted to try this out with Unity, so I suffered through.

The downside to this was that I couldn’t get into a position that was ideal for either my foot or for writing code. I was at least slightly uncomfortable the entire time, and several times throughout the weekend I had to stop and move to the couch to give my foot a proper rest. This had two side effects. The first was that I lost a lot of development time to laying on the couch with my foot on the back. The second was that in order to try and take advantage of this time I brought my notepad and did as much design and planning as I could while I was away from the computer. This is probably the main reason the game is so complicated and over-engineered.

This is the first time I've taken hand-written notes in years. I had to use one of those weird scratchy tube things to scrape my thoughts in stone.

This is the first time I’ve taken hand-written notes in years. I had to use one of those weird scratchy tube things to scrape my thoughts in stone.

What is it Even Uniting?

One of the main reasons I do these competitions is to force myself to try something new. I’ve used new engines, tools, or frameworks every time, and I’ve never made a game in a genre that I’ve done before. It’s a great way to learn a lot in a very short amount of time, and when you’ve been programming for a length of time measured in decades, it’s not a stretch to try and figure something out in that time frame. Since my current game project is in Unity, and I’ve been struggling with it since day, I decided that I would force myself to figure out and use Unity for this competition. In retrospect, I’m glad that I did, but it definitely slowed me down quite a bit.

I also chose to do a very UI-intensive project this time around, for a couple of a reasons. I felt that my foot might get in the way, and I wanted something I could work on from the couch if the need arose. I also know that I hate writing interface code, mostly due to the fact that I’m not very good at designing interfaces, and I find the whole thing very tedious. I may have been setting myself up for failure here, but the goal was never to win the competition. In all of the work I’ve done on Project Dunwich, I have not even touched the interface yet. At one point I actually had to look up how to make a button. I was starting from scratch here.

So... Much... UI Code...

So… Much… UI Code…

The Thought

Despite using tools and techniques I was unfamiliar with, and dealing with Quato growing on my foot, I felt pretty good going into the competition. I had read through the list of themes, and I focused my thoughts on the highest rated candidates from the first four days of voting. This is by no means a fool-proof method of predicting the winner, and I wasn’t writing any code or committing anything to paper, just idly thinking about the design possibilities. I ran through some ideas while I went about my day, and initially I wanted to make something with more action, since my last two attempts sort of fell flat in that regard. Most of the ideas I thought of with any amount of action seemed either too obvious, or not connected enough to the theme, and UI was another focus area, so I settled for a management sim game.

Once the theme was actually announced, I was a bit relieved that the top theme won out, since it meant I already at least knew what genre of game I would make for it. The idea was simple, connect worlds together through some interface, but give those worlds multiple, intricate layers of connection. I like to make my games hit the theme in multiple ways, and that satisfied that requirement. Connecting worlds to an energy source was the obvious take on the theme, but having them be linked to each other as well added a nice extra layer of depth to the interpretation. I’m not sure any ever notices these little touches, but it makes me feel better about my interpretations.

I'm really happy with how the planet rendering turned out. It's a shame I never got a chance to make that interface actually useful though.

I’m really happy with how the planet rendering turned out. It’s a shame I never got a chance to make that interface actually useful though.

The Look

I immediately started with graphics, since I didn’t think there would be very many, and I wanted to get it out of the way. I drew up a mock interface, some icons for the planet stats, and some graphics for the planets themselves, and actually had something passable by the end of the first night. I have used Inkscape quite a bit over the past few months, but I had never done clouds or noise in it, so that was a fun little challenge to overcome. In the end, I spent less than four hours total on graphics, and I’m glad I didn’t have to fight with them at all once I got into the interface code.

With graphics in hand, I set to create the game objects and renderers that would use them to actually put the images on screen. Unity actually made this really easy, though I have no idea if the setup I used is proper for an entity-component system. Since most of the game objects were just data containers, that didn’t take very long, and well before the half-way mark, all I had left was to write the code to process the interactions on the game objects, and then do a whole lot of UI work. After a brief stint on the couch to rest my foot, I started in on the UI.

It is a damn good thing I don't have to actually draw interfaces. I drew it and I can't even tell what's going on in some spots.

It is a damn good thing I don’t have to actually draw interfaces. I drew it and I can’t even tell what’s going on in some spots.

As I mentioned earlier, I had no idea how to approach the interface. I created things using GUIText and GUITextures, I switched to converting screen coordinates to world coordinates and driving the UI with game objects, and eventually discovered the OnGUI method and settled on using that. Throughout the course of the day on Saturday I created as many interfaces as I could, to enable interaction with the game objects. I could just as easily have started by coding that all into the setup and working on the simulation, but that seemed like it would be harder to iterate on. Once I learned how to make the interfaces, it was a pretty smooth ride of create, test for usability, modify, repeat. I didn’t do things in a very efficient way, there’s a lot of copy/pasted code for UI stuff, but I just kind of zoned out and started writing.

The Logic

By the end of Saturday, I had about half of the interface done, and none of the game logic. That seemed like a bad situation to be in, so I set out to right that first thing on Sunday. Since I had spent a fair amount of couch time writing out notes on how I wanted it to work, that actually went pretty fast. The logic is pretty complicated, there are a lot of moving parts that determine how the hardware will react, and how the planets will respond to their situations. The biggest problem with all of that is that I couldn’t get the interfaces done in time to actually explain all of that to the player.

My half-baked attempt at a tutorial. The best part is that I didn't even get to implement some of the stuff I explained in here. Super useful.

My half-baked attempt at a tutorial. The best part is that I didn’t even get to implement some of the stuff I explained in here. Super useful.

The final interfaces were the ones that told you what was going to happen when you advanced the day, and the one that you manage your circuit board. You know, where you actually play the game. I knew what needed to be done, but by Sunday my foot was in open revolt against me. I spent a lot of that final day on the couch resting, and with nothing to plan, I just sat there mentally writing interface code to draw out how I wanted it to look. The funny thing about mentally writing out code, is that it’s a completely useless activity. When I felt good enough to try and implement it, everything fell apart on me. I had planned on whipping up those last two screens and then playtesting the game for bugs and balance. What ended up happening was a mad dash to get the interfaces working that ended about 15 minutes before the deadline.

At Least I Finished… Sort Of

I decided that I was done, and 15 minutes wasn’t enough time to get any of the last things I needed from where they were to where they needed to be to even be passable. I set to build my project and upload, and then Unity decided to remind me why I hate it so much. Apparently the method I was using to color the planets with HSV colors was only available when you ran the game through the editor. It wouldn’t even compile. Fortunately, HSV to RGB implementations are a easy to code, so I started throwing one together. In the past I’ve worked on them with hue being an angle from 0 to 360. Unity’s method had it as a float from 0 to 1. No sweat I thought, I’ll just multiply it by 255. If that doesn’t make sense to you, it’s because it shouldn’t. All of the planets turned green because I mixed up angles with rgb values, but I didn’t have time to figure out why. Up it went, and just like that it was all over.

I’m glad that I made the choices I did. I learned more about unity and its UI features in this past weekend than I have in the past four months. Sure, I could have scrapped the planet interface and focused more on good UI, and I probably would have been better off spending time on tutorials rather than tweaking button positions. Given the constraints I was working under, I’m really happy with how things turned out. I do have some ideas for how to improve next time though.

  • Simple design with good balance – I had so much time away from the computer that my end product was as overly complicated mess, and there’s really no way for the average player to figure out what’s going on. Having a more simple design with a better balance would have been a better approach. Instead of having four types of compatibility and a two-hundred line calculation for fuse load, cut it down to two stats and spend more time on making sure the numbers work out over the course of the game.
  • Interaction before eye candy – My planets look way better than they need to for a game that is mainly driven by button clicks. If I had put that off until the end, I would have been able to see that before wasting time on them, and I might have had time to implement things like a proper tutorial or a win condition.
  • Playtest as early as possible – I put the core logic off for so long, that by the time I had it finished, I was already in crunch mode. This left me no time to make sure the numbers worked out, or that the game was even fun. With a game like this there’s really no excuse, I could have had unit tests written to test out the formulas and algorithms through all 100 days by Saturday morning if I had prioritized it. Good balance is going to be my main goal for next time.

That about covers it. I had a good time, and in the end I have another game to throw on the website and say “look what I can do in a weekend.” No matter how bad I do, or how stressful it is, that sense of accomplishment will always be worth it.

I apologize for being a little late with the weekly update post this week. If you’ve been following my twitter feed at all, you would have seen that I sprained my ankle pretty bad in an accident at my local rock gym. The result was that I’ve been unable to sit at a desk properly for about a week now, and it really makes game development rather uncomfortable. It’s getting better, but it’s pretty slow going. Since I lost the entire weekend to laying on the couch with my foot in the air, I really only got about two hours of development time since the last post, so there’s not a lot to update.

On a brighter note, Ludum Dare #30 is happening this weekend, and I’m going to attempt to participate. Since my foot is still pretty tender, it’s going to be a bit dicey, and my scope will have to be reduced to accommodate the reduction in development time. This will be my first attempt at using unity and spine to actually put a product out, so we’ll see how things go. I’m also going to attempt to stream the process, since the new computer can actually handle it. That all starts tomorrow, and I’m as ready as I’m going to be, so I’ll be back then with some updates.


I would like to start this post by saying that I’m moving the weekly posts from Sunday to Monday. It’s easier with my current schedule to do it that way, and really with as late as I was posting the Sunday stuff, it might as well have been Monday anyway. On to the good stuff.

Moving and Shaking

One of the biggest challenges for me on this project is the animation system I’ve chosen. I’ve done a lot of pixel art over the years, and I’m fairly familiar with animating frame by frame. I’ve done enough paper sketching that picking up the hand-drawn, cleaned-up vector art wasn’t a huge hurdle. What I’ve never even attempted before was skeletal animation. To put it bluntly, I have no idea what I’m doing. I move some bones around to try and approximate what I think walking should look like, and end up with something would grant my character immediate access to Monty Python’s Ministry of Silly Walks. Add on to that the fact that I’m using free-form deformation, so getting my joints to bend without everything looking awkward is taxing. I’m getting there, but it’s slow going. As of right now, I have a decent, albeit excessively deep, walk animation, an incredibly awkward jumping animation, and something that is supposed to be for grabbing ledges, but looks more like a creepy robotic pitching machine. Progress.

I have no idea why I thought this would look good. I can't even make my arms do that...

I have no idea why I thought this would look good. I can’t even make my arms do that…

That doesn’t seem like a lot of progress, especially since it’s been a few months that I’ve been working on this. That’s an entirely fair assessment, but there’s more going on here. One of the biggest benefits to skeletal animations is the ability to blend between keyframes of different animations. When the characters are standing still, rather than having to creating transition animations, or having them start immediately and relying on the low fidelity of pixel art to make it not seem so jumpy, I can simply blend. Since it’s all just bones with keyframes, the spine runtimes gradually transition from wherever the bones are now, to where they should be for the new animation. It looks amazing, when it works.

Undocumented Features

Another one of the biggest challenges I’ve faced on this project is that I’m learning a lot of new skills at once, and many of them aren’t well documented. I’m used to libraries and utilities from big companies, with massive libraries of documentation aimed at software engineers. I’m accustomed to being able to find the exact requirements of any given piece of functionality, with common pitfalls laid out. If you mess something up, it’s because you weren’t paying attention. The set of tools I use now don’t have this level of detail. The internet is awash with video tutorials, and for Unity in specific it seems to be the preferred means of information conveyance. This bothers me. I’m used to reading technical documentation, I can chew through technet, msdn articles, or javadocs with ease. I know how to find what I’m looking for. When you present me an hour-long, rambling video that more showcases than informs, I get a little irritable.

I guess the animation suite wasn't expecting me to not have animations. I stand completely motionless all the time, so I don't see why that's a problem.

I guess the animation suite wasn’t expecting me to not have animations. I stand completely motionless all the time, so I don’t see why that’s a problem.

Unity is not the only offender here. I ran into an issue with spine, where my animations weren’t transitioning properly. I downloaded the examples and compared code, everything looked good. I checked the internet for common issues, and since there isn’t a stack exchange for spine, I mostly ended up on the same few threads on spine support forums. None of the proposed solutions helped me at all; I was completely stuck. In the end, I opened the runtime source code and tracked down the cause of the issue, which was that my idle animation had a 0-length duration. I double checked the documentation to see if I just missed it, but I couldn’t find it. At least it gave me a good reminder of why it’s important to be able to read other people’s code.

Which Leaves Us…

After fighting with animations and runtimes all week, I feel like I haven’t accomplished a whole lot. There’s very little to show, since it was mostly tracking down bug fixes and making animations that nobody would be proud of. On that front, it seems the Sprite Lamp update with Spine integration is coming out very soon. Once I can try that out and see if it works with my game, I can actually start working on production-quality animations to replace my grey-man placeholder. Hopefully then the screenshots will be a little more interesting.

What, your pants don't do that? I guess there's still some more work to do on those.

What, your pants don’t do that? I guess there’s still some more work to do on those.

In the coming week, my goal is to focus on getting the sprite skinning and attachment done, so I can put pants on my character. This will let me build out a town’s worth of characters that don’t all look the same, and then I can start on some of the more involved gameplay mechanics. It’s really hard to sneak past anyone when you aren’t wearing pants, so I guess I have to do that first.

One of my favorite aspects of programming is solving new problems. This is part of why I spent so much time making prototypes without ever finishing anything. Once the initial problem was solved, I didn’t really care about the rest, I just needed a new problem. The reason I bring this up is that in creating this new project I set myself a lot of learning goals. Accomplishing these goals was an important step in getting this project off the ground, and the main reason I haven’t made any blog posts lately. There isn’t enough material in a given week of doing research to make for something interesting. Since I am, for the most part, past that phase now, regular blog updates should be returning.

Project Dunwich

I’m using this as an unofficial logo. Seems appropriate to have one to go with the unofficial name.

Uniting development

I have this notion in my head that at some point I want to target consoles with my games, and the code libraries I’ve used in the past don’t support that. The Unity game engine does. It offers a number of other benefits, chief among them being the fact that I can work in C#, which is what I use at my day job. I find it’s easier to focus on one language at a time, so that’s a huge plus for Unity. Between those two features, and the almost ubiquitous acceptance it has in the indie scene, it felt like a good choice.

I’ve written a lot of code in a lot of different languages in my day; code is where I thrive. Unity differs from most of what I’ve worked on in the past, in that it’s largely driven by the editor interface. I don’t really care for drag and drop interfaces, or attaching disparate pieces of code to objects in a scene through some GUI. I just want to write code. I’ve figured out how to drive everything through code with unity, but it was not as straightforward of a task as I had initially expected. It doesn’t help that this is my first foray into the entity-component-system structure that Unity uses. It also doesn’t help that I am vehemently opposed to watching video tutorials for programming, and the vast majority of unity tutorials are in video form. In the end, I have things working in code instead of through the interface, and I’m happy with it, but I spent a lot of time stumbling through that problem.

Pictures of code are boring, but this is what I can produce in a short amount of time through code in unity. Mostly naked men.

Pictures of code are boring, but this is what I can produce in a short amount of time through code in unity. Mostly naked men.

After getting Unity set up to work more like a software library and less like a tool, I set to work implementing the most basic parts of the game system. Setting up a platformer was easy. Most of that stuff is handled automatically, I just have to tweak the numbers to make a physics engine run a platformer that feels right. After getting that up and running, with just basic movement, collision, and jumping, I started in on the game’s upgrade mechanics. Implementing ledge-hanging was so simple, it surprised me. I was expecting it to be much more work, but Unity makes a lot of that stuff really easy. With a very rough gameplay prototype in hand, I feel confident in being able to implement the rest of the gameplay without too much trouble, at least from a programming standpoint.

Lighting the way forward

Since this is a horror game, mood and atmosphere are incredibly important. I knew I wanted to move away from pixel art with this game and move to something a bit more realistic looking. I opted for vector art initially, rendered out to standard images, since basically no 3d graphics library supports vector rendering. The art style was something akin to a comic book, with hand-drawn shadows and lighting across the vector images. I have only dabbled in vector art in the past, so my initial attempts were pretty terrible, but I persisted. In the end, it looked pretty good, but it lacked reaction. For a game with a lot of emphasis on mood, having the game world not react to the different lighting effects seemed less than ideal.

Some cultist hoods in the original style. Way too clean to be horrifying.

Some cultist hoods in the original style. Way too clean to be horrifying.

I haven’t worked on a 3d game since I was in high school. The concepts of lighting in a 3d environment are completely foreign to me. In light of that, I thought it would be a good idea to try and apply 3d lighting concepts to my 2d game. By applying normal maps to my 2d images, I get that reactivity that I wanted. My shadows aren’t hand-drawn onto every image, the lighting system takes care of that. This system worked great; I was able to put lights under faces and create that foreboding camp-fire storyteller feel. I was able to get a group of robed cultists to have long shadows cast over their faces to hide them without resorting to blacking out the front of the hood. It looked awesome, at least when everything was sitting still.

A world in motion

Once animation came into the mix, everything kind of fell apart. I was using skeletal animation with my vector images to make my character walk. Normally skeletal animation is very easy with vector graphics, but when you add in lighting, everything gets a little weird. The standard method of overlapping the joints to allow for rotation without breaking the shape just doesn’t work. Since each part is rotated independently, they get different values from the lighting system, so it becomes really obvious that the two parts are just sitting on top of each other. It looks bad when joints are rotated just standing still. It is incredibly distracted when parts starts to move. I tweaked this for a few days and was able to get the base male body to animate with only minor lighting issues, and was, for the most part, pleased with the results. Then came the pants.

This looks pretty good for a horror game, but then you have...

This looks pretty good for a horror game, but then you have…

For as bad as this looks now, it looks significantly worse in motion.

This. Which, for as bad as this looks now, it looks significantly worse in motion.

One of the biggest issues with using the overlapping shapes method of animation, is that you can’t have patterns on the parts that rotate. Without thinking, I drew up some pants to put on my naked man, and I drew a seam down the leg. As soon as I started cutting it apart I noticed my error, but I decided to run with it to see what it would look like. It was awful. The line down the side just broke at every joint, and in the worst spots it created new seams perpendicular to the main seam as rotated parts started overlapping. This was a deal breaker. I didn’t want generic, single-tone pants, and that restriction would have applied to everything. I needed a better way.

This is where Spine comes in. Spine is a 2d skeletal animation tool that lets me do some really advanced animation techniques. One in particular caught my eye, called free-form deformation. This allowed me to set polygons under the images, and set each vertex to be weighted to different bones. This let me cut the pants into a few pieces and rotate the vertices between the different bones. With this, my pant seams simply crumpled up in the polygons at the hip of the pant, just like they would in real life. I wrote the check for the software after about two days of playing with the demo, and the results are already looking pretty amazing.

This was an early attempt at using spine, so ignore the fact that it looks awful. At least the seam isn't broken.

This was an early attempt at using spine, so ignore the fact that it looks awful. At least the seam isn’t broken.

The last bit is to get these Spine animation to work with the lighting system I had used earlier. My initial attempts had some quirks that need to be worked out, but I’ve decided to put that part of the project on hold for a little while. The reason being that the SpriteLamp tool seems to solve this issue for me, as well as making my awful attempts at normal-mapped sprites easier to create and look better. They don’t have a release that includes this Unity shader for Spine yet, so I’m going to keep an eye out for that. In the meantime, I still have good animations with flat lighting, so it will have to do for now.

A goal in sight

Now that I have the most important aspects of the game that I initially had no idea how to handle at least conceptually figured out, I can start turning this into a game. It’s still a long ways off, and my initial estimate is probably going to be pretty wrong, since I didn’t anticipate spending this much time just learning techniques. At least now I can start actually making the game. This also means I should have a lot more to write about every week, so I guess this is where the crazy roller coaster that is game development really starts. Buckle up, it’s probably going to be a bumpy one.

I have been hard at working these past few months learning all sorts of new ways to make games. The up side to this is that it’s going to make a big difference in the quality of my next project, the down side is that there hasn’t been any real, sharable progress on the new game yet. That should all change very soon, as I now have all of the skills I need to start putting together playable, animated builds, so thank you for your patience while I’ve silently toiled away, honing my craft.

As a sort of apology for not keeping the website up to date for a while, In Vivo is 50% off through Desura all weekend long. I’m going to start back up with the weekly blog posts starting this Sunday, so remember to check back, or sign up for the newsletter and I’ll send the updates right to your inbox.