Once I had made the list of tasks that had to be accomplished in order to get the game created, my brain started going in a lot of different directions all at once. I kept flitting between thinking about different tasks, trying to judge whether I could do the task, one of our existing MartianCraft developers or designers could do it, or if I'd need to go out-of-house to get it done at the level of quality and finish I wanted. A few items, like sound effects and music, I felt comfortable pushing to the back burner for now, but I felt a need to do an informal triage of many of the tasks. Some of them would require finding either freelancers or new hires and that adds time. I wanted at least some idea of what kind of outside talent I would need.
After about a half day of bouncing between the various tasks and just generally being a disorganized mess, I realized I was putting the cart in front of the horse. I need to just get something running to make sure the core idea was even worth pursuing. The greatest art and sound can't rescue a game that's not enjoyable. So, I pushed aside all my other concerns and thoughts to try and get a simple prototype up and running.
Fortunately, with Unity, that can be done pretty quickly. It took me less than day to get a prototype level built so that I could navigate it. Today's dev diary is about that process.
Unity doesn't have a level editor, per se. It has a scene editor with some basic primitives and some really good terrain tools. Levels are generally built in the scene editor using components built in an external 3D program, unless it's an outdoor environment, in which case you can often do everything right in Unity.
From the time I first thought of the escape game concept, I had some idea of how I thought the level should look and about it's overall layout. Now, that layout wasn't really driven by gameplay concerns, but rather by storytelling concerns. I had certain information I wanted to get to the player and some information that I wanted to make available to more adventurous players who explored beyond what was strictly necessary to escape. I envisioned the basic map as looking something like this:
The goal of the game is to get to the security elevator, which is outlined in gold. It looks like a straight shot up the center from the isolation cells — and it is — but that hallway is well lit and well guarded. Plus, you can never go directly to the elevator. You always have to do something first before you can go there. You might have to disable a force field, find a key, or restore power to the elevator before going to it makes any sense. Once you've done that, then you need to get past the various guards without being detected in order to escape.
Once I saw the map laid out, I realized it wasn't enough. There needed to be more than one way to get to the elevator so that we could give the game some amount of replayability and also give the player more stuff to explore. I felt that there needed to be more rooms outside of the main prison block to give the player places to hide and explore.
I came up with the idea of adding on an "Intake Processing Center". The existing entrance to the elevator would be the one that guards and other staff used, but new inmates would come in a different way. They would come in through a series of rooms where their belongings were stored, mugshots were taken, and prison clothes were issued. I added on a series of rooms to the map for this purpose, as can be seen in purple below.
I originally started trying to draw out the level map old-school style. But, it wasn't really working for me. It was keeping me from thinking in three dimensions. So, I fired up Blender and started planning the map in 3D. The maps above are actually screenshots of the top orthographic view in Blender that I added some color to using Photoshop. As you can see, it's actually a three dimensional map:
Working in 3D seemed to make sense, since the file I created can be exported right to Unity for prototyping. At least, it can if I built it right. There was only one way to find that out, though: export it from Blender and import it into Unity to try it out.
My first attempt didn't work out very well. I dropped a First Person Controller (something provided by Unity for creating first person games) onto my map so that I'd be able to navigate around the map. For the final game, I won't be able to use the provided Unity component, but it will work plenty well for letting me look around my map.
I hit play, and saw… nothing.
Oh, right. Lights! The "real" lighting for the game will be done much later in the process, but I needed some light to see anything. I could've just turned on global ambient lighting, but that wouldn't give any shadows to judge shapes or distances. Instead, I dropped a somewhat random assortment of real time point lights onto the map. Performance won't be good, but at least I'll be able to see well enough to navigate the map. Since I'm using my dev machine to navigate around the prototype level right now, I'm not overly concerned about performance issues yet.
Once I had the lights added, I hit play again. And saw… nothing. Again.
Then I swore at my computer.
Fortunately, I realized what the problem was before the swear words were even completely out of my mouth. Blender (and, I'd imagine, most 3D programs) assume that objects are going to be viewed from the outside, not from the inside. While Blender supports two-sided polygons, Unity doesn't, so when designing interior architecture, you have to make sure your objects are built, essentially, inside out - with the face normals — which mark the forward or visible direction of the polygon — pointing inwards.
You can see in the Blender screenshot below that the normals (the light blue lines) are facing outward. Most 3D objects get created this way so they can be seen from the outside when you're using one sided polygons.
Outwards, in our case, is bad. Outward pointing normals mean you can see this room from the outside, but not when you're standing inside of it. Fixing it was a simple matter of selecting each room in Blender, going into Edit mode, selecting all faces and then hitting the "Normals / Flip Direction" button in the left toolbar.
Once I fixed the normals, I re-exported, went back into Unity, waited for the level to re-import, then hit play. This time, I actually got something:
Well, yay! I've got a map and I can even walk around the level. I haven't written any code yet, but I can actually navigate from the user's perspective and get a feel for the level. I'm really liking my decision not to try and write my own game engine right now.
I found it kind of hard to maneuver, though. It is soooo white in here that it's hard for the eye to grab onto anything, especially when you're not near a point light. Even for a throwaway prototype, I needed some textures for the eye to grab onto, so I pulled down a few tileable images from CGTexture.
Using repeating textures won't cut it for the final game. That was the state of the art a decade or two ago, but not today. The human eye is just too damn good at picking out patterns for us to rely on repeating images for very much. But, for testing, getting any kind of texture on the floor and ceiling was going to make a big difference. I also made the cells a different color than the hallways, which helped quite a bit as well.
It's not going to win any awards for level design or aesthetics, but it's a starting point. I can walk around, find the more glaring problems, and get a feel for how the layout will work. The first thing I did was to make sure I could get everywhere I wanted the player to be able to go. I found a few mistakes along the way - polygons that should've been deleted to make doors and normals that didn't get flipped. I also found a few gaps between rooms that were noticeable. Those were all pretty easy to fix in Blender, which I did.
The one thing that did strike me, as I walked around the map, was that the level is too small. Probably a lot too small. At a walking speed that feels natural, you can navigate the entire map fairly quickly. Even accounting for the fact that you'll be sneaking and avoiding guards much of the time, it's still too small. I'll have to go in later and make it bigger. But this is enough for an early prototype - to test out game mechanics and bad guy AI.
Now, if I were focused, this is the point where I would start working on some actual game mechanics. I'd drop in a few bad guys with simple AI so I could start actually playing the prototype and figuring out what works, if anything. But, I'm not focused. I'm the kind of person who…
Ooh, look! A shiny object…
What was I saying? Something something, focused… oh, right. There are some tasks that I know we're going to have to go out of house for, and some that I know we can do in-house. Then, there are the ones that I'm just not sure about yet. One task that I think we can handle in-house with existing talent, but don't know for sure, is painting and lighting the environment. So, I allowed myself to be distracted from the prototype to do a quick paint-up of one room on the level. That room will probably need to get re-done at least once before we ship, but it seemed a worthy experiment and something that would be kind of fun. Plus, it would help me get familiar with some Unity functionality that I've not used before (light maps), some new 3D painting improvements in the latest version of Blender, and it will just generally help with the decisions that need to be made about the overall aesthetic feel of the game. I'm a visual person and sometimes need to see something to know if I like them, because they always look good in my imagination.
Next Up: Experiments in Environment Creation
Previous: Deciding on Tools and Frameworks
No comments:
Post a Comment