Wednesday, August 21, 2013
Turncoat Dev Diary: Prototyping Player Game Mechanics, Episode II
As I started working on the basics of movement, I decided that my prototyping model needed a little something extra. I want my character controller to support "physics bones", which are bones that aren't pre-animated, but instead are controlled by the physics engine. You might use physics bones if a character has a pony tail, for example, so that the pony tail moves naturally. If a character has an item hanging from their belt, you might put a physics bone on it to make the item bounce around as the character walks. You can also use physics bones to fake cloth and hair physics. The results aren't as good as you get from true physical simulations, but those are often too processor intensive to do in real time, especially on mobile devices. You can get surprisingly good results by faking more complex simulations using a number of constrained physics bones.
Monday, August 19, 2013
Turncoat Dev Diary: Prototyping Player Game Mechanics, Episode I
The first game mechanic that needs to be nailed down is player movement. This is the most important mechanic to get right because it's on the screen all the time. Up to this point, I've just been navigating the prototype map using the stock first person controller that Unity provides. It's time to move past that and figure out the actual player movement and controls for the game. I'm sure we'll be tweaking these right up until release, but we at least need to get to a good starting point created.
Thursday, August 15, 2013
Turncoat Dev Diary: Thinking About Characters
(This is part of a series. The first post in the series is here.)
The reason why our original Turncoat concept was going to cost so much to create is that the scope of
the concept was just massive. The squad of soldiers the story follows consists of thirty-four soldiers. They are stationed on an enormous starship with over eight thousand people on board and which is part of a battle group containing about fifty other ships. In addition to the squad, there are many other characters that play into the story, including the Admiral of the fleet and her staff, the ship's captain and bridge crew, the ship's chief medical officer and sick bay staff, the "regular" complement of shipboard marines, and several command officers stationed back at Earth. Then, there's the Seditionists.
There are a lot of fully developed characters required to tell that story and a lot more that would need to be on screen at times in order to make the universe feel as if it was fully populated. On board ships and on an overpopulated planet, space is tight. To convey a proper sense of claustrophobia, we need lots of characters.
Characters are expensive to create.
Characters are also really important to the type of games we want to make. A casual game relies more on the mechanics of the game to generate interest, but a cinematic game puts the story — and thus, the characters — front and center on more equal footing with the gameplay. But, a fully detailed, sculpted, rigged, and facially animatable character like the ones you see in AAA console games might take a single artist a full month to create. We toyed with several ideas for reducing the cost of creating all these characters, such as doing cut scenes with comic-book-like motion graphics instead of fully animated and lip-synched characters and using a lot of close-cropped shots but, in the end, we decided that we couldn't reduce the cost enough without hurting our vision of what the game should be.
When we decided to put the main story on the back burner and start working on the Turncoat Escape game, one of our guiding mandates was to keep the scope of the game down. Way down. That meant having only a single level at first. It also meant keeping the number of characters as small as we could while still making the game work.
That's not an easy mandate to stick to. Stories are about people. If you can get your audience to buy into your characters… to empathize with them and care about what happens to them, you can get those viewers to overlook a lot of other things. But you need that emotional attachment to the characters if your goal is to tell a story.
Or, to put it another way: "It’s the characters, stupid."
There's obviously one character in the Escape game that we just can't do without: the protagonist. The player has to be somebody in the game. There has to be somebody who needs to escape the facility.
In our earliest version of the original Turncoat story, we had one character, nicknamed "Rook", who we envisioned as a customizable character. The player would see events unfolding through this character's eyes, and the player would be able to choose what that character looked like. They could decide what Rook's real name was, whether Rook was male or female, and they could select from a range of skin tones and adjust facial and body proportions and hairstyle.
As the story evolved and grew in complexity, Rook morphed into a specific character with defined traits. I still liked the original idea, but it eventually became clear that the story needed us to know more about Rook.
I like games that let you decide what your character looks like, though. Certainly, there are times when it's important to control the narrative and specify exactly what the main character looks like. Hell, we did exactly that with Rook in order to make our original story work. But, there's also value in making a game welcoming. There's value in telling the player that they can be whoever they want to be in the game, and that whatever they want to be, is okay.
The hero of the story doesn't have to look any certain way.
While we chose to abandon the character customization idea in the larger Turncoat game, the reasons we did that don't apply to the Escape game. This story is less complex. Making the main character customizable won't interfere with our ability to tell the story.
So, that's what we're going to do.
It will add some work for us, which runs contrary to our mandate to keep scope down, but we're still going to do it. It means we need at least two base models for the protagonist - a male and a female - and we need to put some effort into allowing them to be customized. We'll want the player to be able to change the skin tone, body shape, and the facial features in addition to letting them select gender.
So, what other characters do we absolutely need to tell this story? There have to be other people in this facility. Well, I guess there doesn't have to be other people. Through both Portal games, you never see another living person, and that game works extraordinarily well. But we're not making Portal; our story and our game relies on there being more people.
We need guards and inmates. Neither the guards nor the inmates will feature prominently in any cutscenes, so we don't need to make them as detailed as the player model, but we don't want them all to look exactly the same, either. Similar to character customization, we can randomize the features of the guards and inmates to make it feel like there are many different guards and many different inmates in the facility.
We also need a Guard Supervisor. The Guard Supervisor will have a different uniform from the rest of the guards as well as a defined non-random appearance; this character will always look the same every time you play the game. Some of the ways of escaping will require you to either find or avoid the Guard Supervisor, who is more observant and generally more competent than the regular guards.
Finally, we have the "white coats". The white coats are not part of the regular game level. They're never in the cell block or the guard areas. They're only inside "the theater" - that part of the map that the player can see from some of the ventilation ducts, but can't directly interact with. Exactly what it is that the white coats are doing in this facility is one of the things the player will be able to discover if they explore. They won't need to know that information in order to escape, but they'll have a better understanding of why they need to escape and why they're in the facility in the first place if they do.
One thought I had for the white coats was that since the vents are mostly down low at floor level, we might be able to make it so you simply never see their faces. As long as the the characters aren't too far away from the vent, the angle should hide their face from view. This might add to the mystery of these characters, and will have the added bonus that we won't have to fully model or animate the white coats' faces. That should reduce the amount of modeling effort.
So, our tentative list of characters right now is:
The reason why our original Turncoat concept was going to cost so much to create is that the scope of
the concept was just massive. The squad of soldiers the story follows consists of thirty-four soldiers. They are stationed on an enormous starship with over eight thousand people on board and which is part of a battle group containing about fifty other ships. In addition to the squad, there are many other characters that play into the story, including the Admiral of the fleet and her staff, the ship's captain and bridge crew, the ship's chief medical officer and sick bay staff, the "regular" complement of shipboard marines, and several command officers stationed back at Earth. Then, there's the Seditionists.
There are a lot of fully developed characters required to tell that story and a lot more that would need to be on screen at times in order to make the universe feel as if it was fully populated. On board ships and on an overpopulated planet, space is tight. To convey a proper sense of claustrophobia, we need lots of characters.
Characters are expensive to create.
Characters are also really important to the type of games we want to make. A casual game relies more on the mechanics of the game to generate interest, but a cinematic game puts the story — and thus, the characters — front and center on more equal footing with the gameplay. But, a fully detailed, sculpted, rigged, and facially animatable character like the ones you see in AAA console games might take a single artist a full month to create. We toyed with several ideas for reducing the cost of creating all these characters, such as doing cut scenes with comic-book-like motion graphics instead of fully animated and lip-synched characters and using a lot of close-cropped shots but, in the end, we decided that we couldn't reduce the cost enough without hurting our vision of what the game should be.
When we decided to put the main story on the back burner and start working on the Turncoat Escape game, one of our guiding mandates was to keep the scope of the game down. Way down. That meant having only a single level at first. It also meant keeping the number of characters as small as we could while still making the game work.
That's not an easy mandate to stick to. Stories are about people. If you can get your audience to buy into your characters… to empathize with them and care about what happens to them, you can get those viewers to overlook a lot of other things. But you need that emotional attachment to the characters if your goal is to tell a story.
Or, to put it another way: "It’s the characters, stupid."
There's obviously one character in the Escape game that we just can't do without: the protagonist. The player has to be somebody in the game. There has to be somebody who needs to escape the facility.
In our earliest version of the original Turncoat story, we had one character, nicknamed "Rook", who we envisioned as a customizable character. The player would see events unfolding through this character's eyes, and the player would be able to choose what that character looked like. They could decide what Rook's real name was, whether Rook was male or female, and they could select from a range of skin tones and adjust facial and body proportions and hairstyle.
As the story evolved and grew in complexity, Rook morphed into a specific character with defined traits. I still liked the original idea, but it eventually became clear that the story needed us to know more about Rook.
I like games that let you decide what your character looks like, though. Certainly, there are times when it's important to control the narrative and specify exactly what the main character looks like. Hell, we did exactly that with Rook in order to make our original story work. But, there's also value in making a game welcoming. There's value in telling the player that they can be whoever they want to be in the game, and that whatever they want to be, is okay.
The hero of the story doesn't have to look any certain way.
While we chose to abandon the character customization idea in the larger Turncoat game, the reasons we did that don't apply to the Escape game. This story is less complex. Making the main character customizable won't interfere with our ability to tell the story.
So, that's what we're going to do.
It will add some work for us, which runs contrary to our mandate to keep scope down, but we're still going to do it. It means we need at least two base models for the protagonist - a male and a female - and we need to put some effort into allowing them to be customized. We'll want the player to be able to change the skin tone, body shape, and the facial features in addition to letting them select gender.
So, what other characters do we absolutely need to tell this story? There have to be other people in this facility. Well, I guess there doesn't have to be other people. Through both Portal games, you never see another living person, and that game works extraordinarily well. But we're not making Portal; our story and our game relies on there being more people.
We need guards and inmates. Neither the guards nor the inmates will feature prominently in any cutscenes, so we don't need to make them as detailed as the player model, but we don't want them all to look exactly the same, either. Similar to character customization, we can randomize the features of the guards and inmates to make it feel like there are many different guards and many different inmates in the facility.
We also need a Guard Supervisor. The Guard Supervisor will have a different uniform from the rest of the guards as well as a defined non-random appearance; this character will always look the same every time you play the game. Some of the ways of escaping will require you to either find or avoid the Guard Supervisor, who is more observant and generally more competent than the regular guards.
Finally, we have the "white coats". The white coats are not part of the regular game level. They're never in the cell block or the guard areas. They're only inside "the theater" - that part of the map that the player can see from some of the ventilation ducts, but can't directly interact with. Exactly what it is that the white coats are doing in this facility is one of the things the player will be able to discover if they explore. They won't need to know that information in order to escape, but they'll have a better understanding of why they need to escape and why they're in the facility in the first place if they do.
One thought I had for the white coats was that since the vents are mostly down low at floor level, we might be able to make it so you simply never see their faces. As long as the the characters aren't too far away from the vent, the angle should hide their face from view. This might add to the mystery of these characters, and will have the added bonus that we won't have to fully model or animate the white coats' faces. That should reduce the amount of modeling effort.
So, our tentative list of characters right now is:
- Configurable female protagonist
- Configurable male protagonist
- Randomizable female guard
- Randomizable male guard
- Guard Supervisor
- Randomizable female inmate
- Randomizable male inmate
- White Coat Male (no face rigging)
- White Coat Female (no face rigging)
That seems doable. It's, perhaps, a little longer of a list than would be idea, but as long as we don't go too crazy with the ability to customize / randomize, we should be okay, especially if we try to reüse parts, like faces and hands, between the guards, inmates, and white coats.
While we're going to create some of the characters in-house, I think we've probably got more characters than we can do without some outside help, so if you know any good character modelers with game experience looking for a little freelance work, have them drop me a line at jeff at martiancraft dot com.
Next Up: Prototyping Basic Game Mechanics Part 1
Previous: Experiments in Environment Creation
While we're going to create some of the characters in-house, I think we've probably got more characters than we can do without some outside help, so if you know any good character modelers with game experience looking for a little freelance work, have them drop me a line at jeff at martiancraft dot com.
Next Up: Prototyping Basic Game Mechanics Part 1
Previous: Experiments in Environment Creation
Monday, August 12, 2013
Turncoat Dev Diary: Experiments in Environment Creation
Today, I'm going to talk about a little side quest I took while prototyping the game: painting and lighting one of the rooms. When I initially planned the level out in Blender, I did it almost entirely with cubes. I scaled and extruded and adjusted vertices, of course, but when you come down to it, it really was just a bunch of boxes. Of course, a lot of buildings in real life are just assemblages of boxes if you look at them from far enough away, but to try and make an environment that feels real, I knew I needed more than just boxes.
Friday, August 9, 2013
Turncoat Dev Diary: Just Getting Something Running
(This is part of a series. The first post in the series is here.)
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 black area I envisioned as a somewhat standard prison cell block, although probably a little more futuristic looking than a prison you might find today, and the light blue boxes I thought of as solitary confinement cells, some of which would be used as starting points for the level. The darker blue areas would be administrative areas: the guard break room and the supervisor office. Marked in red is a series of ducts that can be used by some characters (those who aren't too big) to hide from guards and navigate around the map where the guards can't see them. The green area I think of as "the theater." The ventilation grates in those rooms don't open and the player can't actually go into them, but if you they are in the ducts and get close to the grates in any of those rooms, it will trigger in-game animation sequences (and not necessarily always the same one). These sequences will hint at additional ways of escaping the level and also fill in more background information about the universe and why the character has been imprisoned.
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.
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
Wednesday, August 7, 2013
Turncoat Dev Diary: Deciding on Tools and Frameworks
Once we knew our platform, it was time to start figuring out the toolset or frameworks that we were going to use to make the game. The essential decision we had to make was whether to build our games from scratch, essentially creating our own game engine in the process, or leveraging one of the many existing commercial or open source game engines that are available. Although the idea of creating our own game engine had some appeal, we knew that practical considerations weighed heavily in favor of using an existing one. Although there are costs associated with using many engines, and even though it makes you dependent upon somebody else's work, the cost/benefit equation really makes the decision pretty simple. We want to tell a story and create games; we don't want to reinvent the wheel, and writing a 3D game engine from scratch is very much reinventing the wheel.
It actually didn't take us very long to figure out which engine to use. We ruled out a few very quickly. Cocos2D wouldn't work because we want to create a full 3D game. Cocos3D is still a little too immature for us to be comfortable relying on it. Since we want to keep our options open for releasing on other platforms, some other engines were ruled out. Sio2, although a good mobile engine that supports both iOS and Android, doesn't have desktop or console support.
Ogre3D, a well-regarded open source game engine, just has too many rough edges for my tastes. The cost savings from the fact that it is free and open source seemed to be far more than offset by the additional time and headache involved in using it. I'm all for open source software when it's the right tool for the job — Blender is still my general purpose 3D app of choice — but the gap between Ogre3D and the commercial engines is pretty wide, not in terms of what you can achieve, but in the amount of effort it takes to achieve it.
We very easily got the list down to just three: the UDK, the Source Engine, and Unity3D. Then, two of those three got quickly crossed off the list, as well.
Although the UDK is an amazing engine, we ruled it out for one simple reason: the toolset is entirely Windows based. Although it can create iOS and Mac games, most of the work involved in creating the game has to be done on Windows. We're almost entirely a Mac shop and I, personally, am much more productive and happy when working on a Mac. Even if I didn't mind spending much of my day in Windows, I'd still have to compile, test, and upload to the App Store using a Mac, which seems a rather convoluted and inefficient process. It's probably not much overhead for a large game shop, but it's more hassle than I'd want to deal with.
The Source Engine has similar limitations. Although Valve has been promising Mac tools for a while, they have not shown up yet and there have been no recent comments from Valve about Mac support, leading me to question whether that they've dropped the plan. On top of that, Valve hasn't delivered official support for any mobile platforms yet. There are rumors of a Source 2 engine in the works that will likely address these issues, but we can't develop with something that's not out yet.
Before long, there was only one engine left standing: Unity3D. We've used Unity for a few client projects in the past and I'm, frankly, rather impressed with it. I thought that I would really hate working in C# but it turns out I don't mind it at all. I don't like it as much as Objective-C, but I don't have the kind of hatred for it that I seem to have developed for Java and C++ over the years. Like all languages, it has its quirks, but I don't feel like the language is working against me and I don't have problems context shifting between Objective-C and C# like I do with Objective-C and Java. Objective-C and C# are surprisingly compatible languages given their differences.
Although I've only got a few hundred hours of experience with Unity under my belt, it strikes me as having the right balance between ease of use and power. The development environment runs natively on the Mac (and Windows also) and it is capable of generating iOS, Android, Mac, Windows, and Linux executables. It's even possible to build your apps for the Xbox, PS3, and Wii, though doing so requires contacting Unity and negotiating separate licenses. There is, of course, some work involved to account for the various platform differences, but a surprising amount of it is handled for you.
Once we got the licenses squared away, it was time to get something built. There's one school of thought in game development that says you should try and get a prototype up and running as soon as possible. The earlier you start being able to play, the faster you'll know whether the game's going to work. So, let's get a skeleton of our level hashed out so that we can get our first rough prototype stood up.
Next Up: Just Getting Something Running
Previous: Platform Decisions
It actually didn't take us very long to figure out which engine to use. We ruled out a few very quickly. Cocos2D wouldn't work because we want to create a full 3D game. Cocos3D is still a little too immature for us to be comfortable relying on it. Since we want to keep our options open for releasing on other platforms, some other engines were ruled out. Sio2, although a good mobile engine that supports both iOS and Android, doesn't have desktop or console support.
Ogre3D, a well-regarded open source game engine, just has too many rough edges for my tastes. The cost savings from the fact that it is free and open source seemed to be far more than offset by the additional time and headache involved in using it. I'm all for open source software when it's the right tool for the job — Blender is still my general purpose 3D app of choice — but the gap between Ogre3D and the commercial engines is pretty wide, not in terms of what you can achieve, but in the amount of effort it takes to achieve it.
We very easily got the list down to just three: the UDK, the Source Engine, and Unity3D. Then, two of those three got quickly crossed off the list, as well.
Although the UDK is an amazing engine, we ruled it out for one simple reason: the toolset is entirely Windows based. Although it can create iOS and Mac games, most of the work involved in creating the game has to be done on Windows. We're almost entirely a Mac shop and I, personally, am much more productive and happy when working on a Mac. Even if I didn't mind spending much of my day in Windows, I'd still have to compile, test, and upload to the App Store using a Mac, which seems a rather convoluted and inefficient process. It's probably not much overhead for a large game shop, but it's more hassle than I'd want to deal with.
The Source Engine has similar limitations. Although Valve has been promising Mac tools for a while, they have not shown up yet and there have been no recent comments from Valve about Mac support, leading me to question whether that they've dropped the plan. On top of that, Valve hasn't delivered official support for any mobile platforms yet. There are rumors of a Source 2 engine in the works that will likely address these issues, but we can't develop with something that's not out yet.
Before long, there was only one engine left standing: Unity3D. We've used Unity for a few client projects in the past and I'm, frankly, rather impressed with it. I thought that I would really hate working in C# but it turns out I don't mind it at all. I don't like it as much as Objective-C, but I don't have the kind of hatred for it that I seem to have developed for Java and C++ over the years. Like all languages, it has its quirks, but I don't feel like the language is working against me and I don't have problems context shifting between Objective-C and C# like I do with Objective-C and Java. Objective-C and C# are surprisingly compatible languages given their differences.
Although I've only got a few hundred hours of experience with Unity under my belt, it strikes me as having the right balance between ease of use and power. The development environment runs natively on the Mac (and Windows also) and it is capable of generating iOS, Android, Mac, Windows, and Linux executables. It's even possible to build your apps for the Xbox, PS3, and Wii, though doing so requires contacting Unity and negotiating separate licenses. There is, of course, some work involved to account for the various platform differences, but a surprising amount of it is handled for you.
Once we got the licenses squared away, it was time to get something built. There's one school of thought in game development that says you should try and get a prototype up and running as soon as possible. The earlier you start being able to play, the faster you'll know whether the game's going to work. So, let's get a skeleton of our level hashed out so that we can get our first rough prototype stood up.
Next Up: Just Getting Something Running
Previous: Platform Decisions
Subscribe to:
Posts (Atom)