The Stranger in Kilstow

Sorry I missed out on the post last week. I didn’t have work for Labor Day, and that threw me off schedule, and I just forget. Never you worry though, I’ve got you covered today. Aside from some general housekeeping and refactoring, I’ve really focused on two major aspects of the game in the past two weeks: physics and rooms.

Relaxing the Bodies

When I initially set out to learn how to make a platformer in Unity, I tapped into my experience from working with Box2D on both In Vivo and my Ludum Dare 29 entry. I had it in my head that there was a right way to use a physics engine for platforming, despite all of the advice to not use a physics engine and just handle the collisions yourself. This started out really well. I had a collider for the body, to handle actually running into things, and some trigger colliders for detecting various states. There was a trigger beneath the main collider to determine if the player was standing on something, and was able to jump. Implementing ledge grabs introduced two more detectors, one for actually hitting the wall, and one above it so it could tell the difference between a ledge and a wall. As I went on to things like wall jumping, stalling, and various other acrobatic skills, the number of detectors ballooned. On top of that, there was a lot going on that I wasn’t happy with in regards to the general way it was handling movement. I needed a different approach.

So many triggers, and I hadn't even added the tentacle detectors. It is a Lovecraft game...

So many triggers, and I hadn’t even added the tentacle detectors. It is a Lovecraft game…

After reading as many articles as I could find about platformers in Unity, I decided it was time to bite the bullet and actually roll my own physics code. Thankfully Unity makes this nice and easy on me, with things like ray and box casting to do the brunt of the math. Essentially, I let Unity handle detecting collisions, and then I step in and deal with responding to them. This also gives me a lot greater control over the way movement is handled, which means I don’t have to figure out the right mass ratios of my objects, or relative friction between entities and the floor. I don’t need that level of detail from my physics, I just need a guy to walk around. I have done collision detection and response in the past, and even written a physics platformer from scratch just to see if I could. This was a walk in the park by comparison.

A Place to Play

I talked a little bit about the map generation in my initial announcement post, but for those that don’t remember, it’s going to stitch together a map from a bank of possible room layout. I have done procedural level generation in the past, and I have a good understanding of how to make a map that can be completed with the ability gates that are inherent to this type of game. I haven’t started on that algorithm quite yet, but I have laid out the design, and I know I’m going to need a lot of rooms and a way to load them. I’m using the Tiled map editor to create my levels. I used it for In Vivo and for one my Ludum Dare entries, and I’m pretty comfortable with its ins and outs. I threw together a basic room layout using the shape layers and set to getting it into the game.

I know it looks really exciting like that. It will look nothing like that in the finished game...unfortunately?

I know it looks really exciting like that. Unfortunately it will look nothing like that in the finished game…

This is obviously just a bare-bones outline of what the levels will look like, and it’s missing things like item caches, secrets, hiding spots and doors, but it’s enough to test out the concept of actually loading levels. Up until this point I hadn’t attempted to get anything actually loading from an external resource that wasn’t a graphic. It wasn’t that difficult, though I did run into some file format issues. I used to build web apps, and I know the pain of the xml overhead all too well, so I had taken to the habit of exporting my levels in JSON format. It turns out that neither C# nor Unity have built-in JSON parsers, so instead of doing the obvious thing and using XML, I tried to find a good open source JSON library. After spending far too much time doing that, I snapped out of it, switched everything to XML and got the levels loading. Sure they were upside down and nothing lined up, but it was a start. After a few hours working out all of the bugs and making everything speak the same language, I had the level loading in game, and I was able to walk around in it. Success!

But What About…?

Previous to my foot injury, I had been working mostly on graphics, and that has come to a standstill. I’m very interested in using the Sprite Lamp tool to enhance my visuals from my shoddy attempts at 2D lighting, and I’m still trying to decide if I should go for it. In the mean time, I wanted to get something that people could actually play out sooner rather than later. It has been months since the announcement, and I don’t have anything playable yet. I’m hoping to get the fundamental platforming mechanics up and running and out to you all as soon as possible, so I can get the feel of movement just right. I would like for that release to also look pretty, but if I have to release it with a flat character and red squares for the ground, I will.

Red on purple is such a nice color scheme.

Red on purple is such a nice color scheme.

I’m hoping to make a decision on Sprite Lamp soon. It looks really nice on their site, and it can be used to great effect, like in Hive Jump (shameless plug: you should go pre-order the game, it looks very promising and I want the extra guns). As soon as I know if it will work with Spine in Unity I’ll have my decision, but since it changes the workflow I have to hold off on making things pretty for now. I’m pushing for a five-room demo, with all of the graphics, basic gameplay elements, and some sound within the coming month. It seems a bit ambitious, but now that I can actually focus on the project instead of the tools and framework, I’m hoping I can power through and start turning this crazy idea into a game.

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.

“I can’t say for sure what it is, but something isn’t right here. I can’t turn back now, not knowing what it is that puts me off so, but I fear that its discovery will undoubtedly end in tragedy.”

Project Dunwich

What is Project Dunwich?

Project Dunwich is the new game in development by Electric Horse Software. Inspired by the works of H. P. Lovecraft, Project Dunwich is a horror game in the metroidvania style, with elements of stealth filling the role of conflict resolution, instead of the traditional forms of combat. You will take on the role of an investigative reporter, hired to look into the disappearance of a small child last seen near a remote town just outside of city limits. While its inhabitants swear they’ve never seen the child, there is much more going on in the desolate town than meets the eye. Explore a town filled with hostile inhabitants, sneak past mobs of unsettling villagers and try to discover what happened to the lost child, without succumbing to the same fate yourself. Project Dunwich will not be the final name of the game, it’s simply a placeholder to reference the project until a suitable name is selected.


How Will it Play?

The core idea of the game comes from the chase scene in The Shadow Over Innsmouth. I wanted to recreate the feeling of running for your life from a horde of terrifying inhuman creatures bent on apprehending you for some unknown yet undoubtedly sinister purpose. Running for your life makes for a great story, but is hardly as compelling as a game. I want to create the feeling of terror and helplessness that story conveys, but to do so in a game that is also fun to play requires some adjustments. A single chase scene doesn’t provide enough engagement to make an entire game. Instead, you will be running headlong into danger and then attempting to escape again. The best way to do this while retaining the feeling of being lost and alone, is with lots of exploration and backtracking. This is where the metroidvania style comes in.

With most metroidvania games, your progress is hindered by countless minor enemies. You can happily mow these creatures down, providing a bit of challenge to add engagement to the act of exploring, without turning the focus toward combat. Since this is a horror game, feeling powerful and slaughtering countless easy-to-kill enemies doesn’t fit. This is where the stealth aspect comes in. Instead of blasting your way through screen after screen of bats that go down in one hit, you will be sneaking and dodging your way through a town filled with creatures that don’t want you around. To keep this interesting you will have a slew of abilities that increase your stealth capability, but defeating your antagonists is not on the table.

Running away seems to fit pretty nicely as the main mechanic in a horror game, and while you will get better at it as you progress through the story, the threat around you will never diminish. As you backtrack, things will be easier, but only in that you can move through the map a bit better, or you may have some new tools to distract or mislead your enemies. The penalty for being caught will never diminish. Death would be too harsh, and would really break the feeling of the game, so with another nod to The Shadow Over Innsmouth you will instead be dumped on the outskirts of the town (or somewhere else equally inconvenient depending on where you were caught). This may be disorienting at times, as you won’t always know where you are when you wake, and it may not always be somewhere you’ve been, but that only adds to the feel.


Where Will it Take Place?

One of the biggest pitfalls of the horror genre, and of exploration games, is that there is very little replay value. Once you know what creepy things are around what corners, they lose much of their impact. Similarly, once you know all of the hidden nooks and crannies of a map, exploring it loses its thrill and becomes a chore. To counteract this, I will make sparing use of procedural content generation. The map rooms will all be crafted by hand, to ensure they are interesting and present the right kinds of challenges. Each room will also have a myriad of hidden passages, storage areas, and other secrets to discover, but they won’t all be active during any given playthrough. From the bank of rooms, a map will be put together, and just enough secrets will be enabled to hide all of the items you can find in that run. This means that subsequent plays will not only put you through rooms you might not have seen, and in ways you most certainly haven’t, but the same room will have different hidden compartments to keep you on your toes.

In addition to randomizing the map, elements of the story will be different each time through. The main theme is always the same, the town is run by a secretive cult that seems to have taken the child, and you have to investigate what they are doing. What eldritch horror the cult worships, what creatures they interact with, how they are structured, and what rituals and rites they perform will all be pulled from a pool. There won’t be limitless scenarios, but each one should provide a unique and engaging experience. Each creature and horror will confer its own unique gift to its followers, which means each run will provide you with at least a few new tricks to master as you discover what twisted ways this cult defiles the natural order. Some of the creatures and horrors will be pulled directly from the stories of H. P. Lovecraft, while the rest new creations based on those works. The town and the cult are largely based on Innsmouth and The Esoteric Order Of Dagon, but due to the variable nature of the game will not be direct recreations.

As I have a background in linguistics and have always been interested in languages, I will be creating a written language to go along with this world. Unlike the cipher I used in my last game, this one will be a fair bit more complex. Drawing from frequent references to hieroglyphs in the source literature, I have decided to create my own set of logograms to add to the atmosphere and frankly because it sounds like a fun thing to do. These will be used for decoration to add depth to the locations in the game, and will also act as keys when engraved onto stones like the images you see here. They will be another one of the many things that will have you trekking back and forth across the map to uncover secrets in new areas you couldn’t access before.


When Can I Play It?

The idea for this game came from the concept I used in the 29th Ludum Dare competition. While not a direct follow-on, and indeed written in a different language, I intend to use that project as a baseline for this one during the early stages. I don’t know exactly how long this will take, but I intend to make this as open and transparent of a development process as possible. Every Sunday night I will let you know what has happened with development in the past week, every day on twitter you can see what progress I’m making, and I’m always here if you have any questions about what’s going on. As soon as I have a stable playable build, I will upload it here and update it each week.

Bear in mind that this a side-project for me. I have a day job that is unrelated, and during the week I won’t always get a ton of time to work on this. The last game I released took me roughly six months from conception to release. I also moved across an ocean and lost access to my code in the middle of that, so really I got about four good months of work on it. This project is a little bit bigger, though the focus is on content creation instead of mechanics and puzzle design. I haven’t made a game like this before, so I can’t say what challenges it will present and how that will affect the timeline, but based on my previous work, I’m going with a ballpark estimate of six months. As I get closer, that will undoubtedly change, but for now that’s what I’m going with.

If you’re still reading at this point, then clearly your interest has been piqued. Stick around and join me on the crazy journey that is game development. It won’t always be pretty, and it won’t always be fun, but it will always be interesting, and at the end a game comes out that will hopefully be entertaining, and will definitely be like nothing you’ve played before.