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.
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.
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.
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.
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.
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.