Post Categories

Hallow's Way : UDK workflow for an Indie Game.

Making games for me, is like writing short stories as I’ve said before. I can be spinning several ideas at once. Recently I changed directions and focused on a short story game, working title, Hallow’s Way. I had been hoping to get it done by Halloween, but flood waters and rebuilding have slowed progress to a grinding halt at first, but I’ve been steadily getting more time to finish the game.

The main inspiration for the game began with a familiar urban legend, the “Green Light Cemetery” in New Jersey. It’s not the first time I have visited allegedly haunted places from my childhood and won’t be the last, but the real inspiration here is the fascination and fear associated with seeing the green light in the woods above the cemetery (which I do believe my younger brother Ron, and I tried to find with our intrepid childhood friend Michael Weimer). The question is, can I capture some of that fear and fascination in game play? Additionally when I’m testing a game, I try to make actions surprising enough that I too can be surprised. If I don’t have a surprise moment, or sudden fear as something unexpected happens, then I don’t feel i’m developing the game correctly. I want to be immersed in the game myself when “writing” it.

creepy doll, from my scary game... whose details I'm keeping purposefully vague.

creepy doll, from my Hallow’s Way… whose details I’m keeping purposefully vague – except to say the original concept was inspired by a Dave McKean illustration, and although the model has changed drastically from the original inspiration, I have considered putting Dave McKean in my game in some way as an incidental character – because he’s awesome.

One reason I want to work on a very short story game, which is the way I think of Hallow’s way, is that I’m still getting used to the UDK game engine. I can put together a game level fairly quickly, but completing a game from A to Z, is a different matter. Aside from testing a game, there are menus, writing artificial intelligence, and then of course creating all the assets for the game.

Since my time is limited in my studio and working on my games, one of the things I try to do is to be pretty quick and nimble. I try to accomplish things swiftly so I can move on. The creepy-doll as seen above is only a couple hours worth of work, and then another couple hours of testing the AI and getting him to work properly in game when needed. Thankfully tools like zremesher in Zbrush allow me to cut off additional time that I have previously spent making low res models for games. I’m showing this one creature of course, but he is a small part of the game. The reason I’m vague about this is not because I’m trying to hold back on what I share, but because I want to hold back if I intend to scare.

Aside from creating a list of creatures (there are fourteen others for my game) my unfamiliarity with UDK means I’m still building up a resource library of various types of AI and many other game elements. One of the things that people like to brag about UDK is how quickly you can basically create a game using resources from UDK, like their bots, or soldiers, and their environments. Additionally, people like to use the BSP brushes in UDK to create game levels quickly. A BSP brush is a brush where you can come in, create a rectangle quickly, and essentially “model” within the game package. It’s a pretty good way to test things out, however, the problem is that these are not real models. You are generating procedural models within the game engine, and to alter them you have to add or subtract. You can’t make a complex building like the Sistine chapel, and then decide to move it ten units to the left. Most people use BSP brushes to make fighting games, or Tournament games. These are fast paced (and rather pointless) games about kill or be killed. I’m not saying people don’t do amazing things with game environments and that there isn’t a lot to learn there, but it is a direction that I prefer not to go in. It’s also a type of game that I’m not interested in creating. There are no guns in my games.

My method of working is to work with modular pieces to create environments, and to do that I have had to build up my own modular library of buildings, including trees, creatures, and effects like smoke, rain and fog.

Test area for game.

Test area for game.

When I’m working in my game testing is often one of the more labor intensive parts. There is a large game level to test, and I explore it and poke at it, and try to engage the AI. The image above is a snapshot, not of my game actually but of a test area when I’m developing tricky things in my game. The reason I work in a test area is to do fast tests. I don’t want to spend twenty minutes waiting to engage my AI all the time, I want to write code, and then get into a small test area to see if it works as expected. The game area above shows a few things that might look odd to someone who isn’t familiar with engines, or UDK. There is an overlay for instance for the NavMesh. I was testing this level to with NavMesh to see how to fluidly get AI to go up stairs, and slopes to higher places than the ground plane. In the Unity game engine, I can generate a NavMesh (which stands for navigation mesh that the AI use) and it will take in the area I have in mind in three dimensions. In UDK it is limited in how high it goes in z to about the height of the player, which is odd to me. So I test this to figure out solutions in this small space quickly and to see how my AI navigates problems that I put in it’s way.

One of the things you can see are things that look like large alphabet blocks. These are models I’ve turned into rigidBody objects, or KActors in UDK. KActors obey physics. I can program my AI to interact with the rigidbodies, and I can also scatter rigidbodies in the air, and have them become live at game play to randomly scatter their location. It’s one of the things that I do to randomize a game, which I love to do. One thing I question in games, is the locked down world that you enter. Many games people present an environment where you solve a puzzle, and the puzzle is always the same. So you try and retry the puzzle until you solve it. People often replay games, and the puzzles presented are in the same exact pacing and location, nothing changes. One of the things I try to create in my games is the sense that this world is shifting when you start a new game. Another concept I’m trying to explore is the possibility of the game shifting during gameplay, which I’m going to stay vague about so again, I can maintain the element of surprise in the future.

One note about rigidbodies is that I put rigidbodies in a different game level, that is on when game play starts, but off when I generate my NavMesh because the idea is that they will be movable. If the NavMesh generates a wall around them, the assumption is that they will stay static. When I talk about different levels, I’m talking about chunks of the game that I can turn off, not “leveling up” as it were, although this could apply too. I can have a game level, where different chunks of the level go on and off, depending on your location. This can save in how much data the engine has to crunch while you’re playing, and it allows me to also separate some things out for other reasons, like for keeping my NavMesh clean as stated. I’ll give you a solid example. I created a navMesh and forgot to turn off my rigidBody level. When my AI moved through the game, they stopped on the stairs because the random objects were in the stairwell and generated a navigation mesh that saw them as permanent obstacles.

Yes, I jump back and forth between talking about generating art and story and the technical side of games. I try to understand the technical side, yet my goal is to get the technical things out of my way so that it becomes second nature, and quick to execute. I believe that more and more as I create “small” games, the library of pieces I have should allow me to write more short story games, without the huge delay involved with creating a whole new system. I’m not saying that each game doesn’t have new elements you want to add, different AI, more involved story as you get better, but you keep building a library and refine your approach rather than re-create the entire engine you made.

I think it was Stephen King, who talks about writing stories, and how there is a perfect storm that happens with an idea. You have an idea and put it aside, and then over time. You collect those ideas and don’t necessarily force it out, you can’t. At some point though the idea comes out by itself. It could be something small that happens and creates that perfect storm and makes your idea clear. The problem with trying to come up with short story game ideas is the delay in developing games. The solution for me is to continue to build a library, so that when lightning strikes and the game idea comes, I’m ready to create something more fluidly.

Actual shot from my vague creepy indie game.

Actual shot from my vague creepy indie game.

When the technical and artistic prep work is done, the short story comes in creating the gameplay. Elements like my fog and rain effects are important to me in my game stories for creating mood and movement. The same is true for sounds and music, which of course is where my games suffer the most since I am not a musician who composes music.

All of these things though can come together as part of a composition. There are million things you can do when creating any story, and the question always is, what do you need to do to tell your tale, and what can you leave out?

Other locations from my childhood appear.

Other locations from my childhood appear as incidental characters in game.

Leave a Reply