Showing posts with label Game Programming. Show all posts
Showing posts with label Game Programming. Show all posts

Friday, August 2, 2013

Turncoat Dev Diary: Finding a Smaller Game in the Backstory

After investing a lot of time into Turncoat, we started pre-production, with our first task being to figure out just what it was going to take to make the series of games we had envisioned. We didn't go too far down that road before we realized it was going to take an awful lot of work and resources. Too much work and too many resources: far more than we could swing without outside funding.

That's not exactly the kind of realization you enjoy having, but we were happy to have realized it before we actually started sinking money into development. At this point, we had really only invested our time, and since we had enjoyed the process, it couldn't really be considered a loss. So, we decided to put the larger Turncoat story on the back burner, but use the universe we had created for it as the setting for another game of smaller scope. The tricky part here was that Turncoat was designed as a mystery with a complex backstory, most of which exists to support that mystery. Any number of facts from the existing story could spoil Turncoat for players if and when we're finally able to revisit the original concept.

We started investigating ideas for both 2D sprite-based games and full 3D games. We came up with several ideas, and decided to actually run with two of them. One is a take on a traditional 2D platformer that we're going to use the new SpriteKit framework for. The other is a stealth-based 3D game. It's the latter that we've already started working on and which I'm writing this dev diary for.

In this game, you have to escape from a jail-like facility using a combination of stealth and problem solving with maybe an occasional spot of violence. It will have things in common with several existing stealth-based first- and third-person shooters, but the focus will not be on combat. If you get in a firefight, you've probably already failed. Funny thing about jails; they're harder to escape from if the guards know you're trying to escape.

The game will take place about a hundred years before the original Turncoat story, during the "Last Great War" — the war that led to the creation of a single Earth government. During that war, several of the nation states created internment facilities and rounded up a certain class of people. There were no mass killings or attempts at genocide like in the Holocaust, but the treatment was degrading and often violent and the inmates were treated as less than human. Though there were no systematic executions, many inmates were killed for one reason or another.

Exactly who these inmates are and why they were imprisoned won't be revealed at first, but we'll drop some hints throughout the game, both in regular dialogue and in hidden easter eggs that will give the player pieces of the game's puzzle. We'll also throw in few small hints about the mysteries of the larger Turncoat Universe. The important thing that we'll convey to the player at the start, though, is that they have been imprisoned unfairly, that they are being treated poorly, and that they really need to get the hell out. That's all they really need to know to get started, but we want them to be able to discover more about why they've been imprisoned and more about the world they live in as they play the game.

Once we had decided on a basic concept, next up was figuring out what we need to do to actually build it, keeping an eye on creating something polished and professional while keeping the scope of the game reasonable. Here's the initial, high-level list I came up with of things that need to get done, in no particular order:
  1. Level Design. We need a place to escape from. To keep scope down, we're going to limit ourselves to a single level for this project, though we're going to leave the possibility for additional levels in the future if the game is well received. To increase re-playability for the one level, however, there will be multiple starting points and multiple ways to get out. Some options will always be available, others may only be available from a certain starting point or using a character with certain attributes.
  2. Script Writing. We're still trying to tell a story, even if it is a much smaller story than our original vision, and to tell that story, we need dialogue. We'll need an opening cinematic to set up the game's scenario and make sure the players knows what they need to do. We'll need to figure out what the guards and other people in the facility say if the player gets near them. There are going to be hints about the world that will be dropped through dialogue in certain places. When a player escapes, there will be another ending cinematic to tease possible future levels and to reward them for their accomplishment, and it will probably be a different cinematic for each possible exit. All of that dialogue needs to be written.
  3. Overall Aesthetic. We needed to figure out, stylistically, how everything will look. Will we try and make it realistic, or will it be somehow stylized? Will we favor bright colors or muted ones, or will that vary depending on some factor. 
  4. Environment Design. Once we have a level, we have make it feel like a real place by layering textures and lighting to create an environment that is believable and immersive. 
  5. Character Design. A story means people, so we need to figure out who the people in our story are — both the protagonist and antagonists. We need to know why they're in the facility, what they're going to look like, and at least a little bit about their background.
  6. Character Modeling. Once we know what characters are going to look like, their models have to be created. For some characters, we'll need both high resolution models for cinematics and low-resolution models for game play. For others, we'll only need the game-resolution models.
  7. Game Mechanics. We need to figure out how the player maneuvers around the level and what tasks they have to accomplish to get out. 
  8. Sound Design and Foley. An environment won't feel real if it's dead silent. Even games set in the vacuum of space (which, in reality, should be silent) don't feel right without some kind of sound. 
  9. Music. Just like with movies, games need music to set the mood. Music, like other sounds, can also be used to give the player feedback. We might have a different musical theme playing, for example, when the player is heard by guards, arousing their suspicion and putting them on alert.
  10. Animation. Although we can use stock animations from companies like Mixamo for some of the character and enemy movements, there will likely be some game-specific motions that we're not going to be able to buy, so we'll need to animate them or use motion capture to create them.
  11. "Finding the Fun". This is a term that a friend of mine who has worked in the game industry uses. It describes the process of iterating over the basic game mechanic until you find something that's enjoyable to play. Unfortunately, you can't "find the fun" until some of the other work has been at done. You don't have to have a fully polished game to start, but you need something. If you can't find the fun, the game should be abandoned or drastically overhauled, so it's best if you can start this process early.
  12. Voice Acting and Direction. Dialogue means voice acting, so we're going to need to find voice actors and we're going to need to direct them to make sure they say lines the way they were intended.
  13. Branding and Marketing: Even a free product is a product and it does no good if people don't find out about it.
  14. Testing, Testing, Testing: Just like any other kind of software, games need to be tested extensively before they can be shipped. Fortunately, it's often easier to find people willing to try out an unfinished game than, say, an unfinished productivity tool.
Yikes.

I know I've probably missed a few things, but I think that covers the bulk of the tasks at a very high level. I'm not sure about you, but to me, that's a pretty intimidating list, but also one with a lot of potentially fun, cool tasks. It's also not nearly as intimidating as it would be for an individual developer.  Fortunately, we have a team and resources to hire freelancers to handle those tasks we can't handle in-house.

Although many of these things can be done in parallel by different people, some of the tasks have to happen before others can be started. You can't really begin character modeling until you've got character designs, for example, and you can't really begin working on game mechanics or "finding the fun" until you have at least part of a level to maneuver around. None of these things happen in a vacuum, though, and none can be considered completely done until the game has shipped. Characters might get redesigned, for example and the level will almost certainly need to be tweaked as we test. As with any software development, the process will be one of iteration, so we can't get too married to anything.

Before we can begin even the first task, though, we need to decide what platforms we're targeting and what tools or libraries we're going to use to build the game.

Friday, June 3, 2011

Thoughts on Unity3D

As I stated in my previous post on 3D engines, I'm going to do four blog posts giving my thoughts on each of the four engines that I looked into using for a project recently. Those four engines are Unity3D, Sio2, Ogre3D, and Cocos3D. I'm starting with Unity3D, which we selected for one of our recent projects.

Now, let me state up front, that all four of these are competent engines and I could see situations where I would recommend three of the four engines for client projects and could easily imagine situations where all four of them would be good choices.These four do not make an exhaustive list; there are other engines out there, including some really good ones, but these were the four that we looked at for this specific project. As much as I like the UDK, for example, I don't like it enough to spend quality time in Windows, so that one is off the table for me until the fine folks at Epic decide to port their dev and content tools to the Mac.

Unity Overview

Unity3D actually predates the iPhone, and of the four engines, it's the one that feels the most mature and has the most robust developer tools. It also has one of the most active developer communities. Unity3D is a closed-source commercial product that you must pay for, which might be a turn-off for some, but it is worth every penny of the license fee.

Unity Pros

Unity is actually fairly easy to learn, yet has a feature set that is compares favorably to most other engines. Unity's asset pipeline is really robust and their tools give you the ability to very quickly make changes and test those changes.

One of the best things about Unity3D is the fact that it supports both Windows and Mac OS equally as development platforms. Regardless of which platform you develop on, you can generate games that runs on every platform Unity supports (assuming you're licensed for it). You can even have part of your team developing on Macs and the other part on Windows with no problems.

At the time I'm writing this, it is possible to generate games from Unity that run on Mac OS X and Windows (both native apps as well as games playable through a web plug-in), iOS, Android, Wii, Xbox 360, and PS3. The Unity folks are also actively working on adding Linux support. Console licenses are negotiated on an individual basis and are likely quite expensive, but it's nice to have the option to take a successful game to so many platforms without having to do a full port each time.

Having had to port OpenGL ES apps from iOS to Android more than once (which is no fun), I can honestly state that the Android support should be a huge selling point you're giving any thought to supporting both iOS and Android.

Unity Cons

The downsides to Unity3D are relatively few, actually.It is the most expensive of the engines I looked at, and the costs are completely front-loaded. You pay a flat per-developer license per platform up front, but then you can create as many games as you want for the platforms you're licensed for. For the basic iOS license, it's $400 per seat (one developer using up to two machines), for the Pro license, you're looking at $3,000 (because the $1,500 iOS Pro requires the $1,500 Unity Pro), which might sound like a lot of money, but it's really a pittance compared to the amount of development time it can save you. The "Basic" version of Unity, which allows you to generate Mac, Windows, and Web games (though excludes some of the more advanced features) is available completely free of charge.

The other potential downside in some situations is that the underlying C++ source code is not available. You work primarily in either JavaScript or C# (MonoScript) and at a higher level of abstraction. Unity supports a few other languages besides Javascript and C#, but only those two languages work for mobile development.

After about two weeks of spending my evenings with Unity, I actually came to the conclusion that not having access to the source isn't really much of a drawback, and for many developers, working this way will be better than working in C++. The engine takes care of almost all the low-level stuff you'd need to do, but even if it doesn't, Unity has a shader language that lets you write code that runs on the GPU and anything that needs to run on the CPU can be done by scripting inside Unity.

Although the programming in Unity3D is done with scripting languages, the scripts you write are actually compiled, so there's not a huge performance overhead to using them. In the exceedingly rare situation where C# or Javascript isn't sufficient, it is possible to send messages into and out of Unity from your application's C or Objective-C code.

Learning Curve

I found Unity surprisingly easy to learn. There are some really good resources out there, including lots of tutorials and instructional videos. I actually had a game functioning after about two hours of playing. It was ugly and the game mechanics were simple, but it was playable. Unity also has a fairly active developer community forum where you can go and get help when you get stuck.

If you don't already know something about graphics programming, you still don't need to be too scared or intimidated. Most of the gnarly stuff is squirreled away where you won't see it until you need it, and you can do a surprising amount by just configuring things in the development GUI. You can create, for example, a fairly full-featured physics simulations without ever writing a line of code. Want to stack up a bunch of crates and roll a ball into them and watch them all fall? You can do it without ever opening a text editor. Heck, you can even do that without opening a 3D program.

Complexity

I was scared of one thing going into learning Unity: I was concerned that because it was so easy (at least I had heard it was), that it was going to be a dumbed down game maker that sacrificed more advanced features for the sake of lowering the obstacles to entry. My fears were completely misplaced, though. That's not the case at all. The Unity folks have done a really great job of making their tools easy to use while still giving you the ability to do most anything you'd ever need to do. It's even possible (though the process is a bit convoluted) to integrate UIKit and Unity3D within the same application.

Asset Pipeline

The thing that actually impressed me most about Unity is what they call their "asset pipeline", which is the process by which you get 3d models, textures, and other assets into your game. If you've ever developed a game or game mod for the UDK, a Valve Source game, or other commercial engine, usually there's kind of a convoluted process you have to go through to get your game assets including characters, textures, props, and environments, into the game. You usually have to use separate applications to specify shaders and physics options, sometimes write a compile script or other text document to define certain trains, and then compile the object and package it all up into some kind of bundle or package. While developing a single mod, you typically iterate through this process many, many times. It can be a bit tedious and hard to learn and usually requires the use of multiple tools and lots of trial and error.

Unity bypasses almost all of this tedium. When you save your assets from your 3D program or Photoshop, you simply save them in your Unity project's Assets folder. When you launch Unity, or navigate back to it if it's already open, Unity detects the new file, or any changes you've made to an existing file. It imports it and adds it to the list of available assets.Anything you need to do that can't be done in your 3D program, such as specify a shader or identify the physics engine properties for the object, you do right in Unity, and most of that can be done without writing code (though everything you can configure without code can also be changed from code).

Which 3D program do you need to use? Pretty much any one you're comfortable with. Unity3D has direct import support for the native file formats from several programs including Blender , but any package that can export to Autodesk FBX or Collada can be used with full support for all features like bones, textures, animations, etc.It also supports native Photoshop files (.psd) for textures, flattening layers in a non-destructive manner when you build your app.Assets can even be given different characteristics for different platforms. You could have, for example, a 2048x2048 texture asset for the desktop version of your game but tell Unity to use a 1024x1024 version for game consoles and a 512x512 version on iOS and Android.

The Bottom Line

As I stated earlier, there are situations where I could see any of the four engines I looked at being a good choice, as could many of the other engines I didn't look at. But, honestly, if I had to make an engine decision without detailed information, Unity3D would be my first recommendation. The tools are solid, the company and community support is awesome, it supports many platforms, and getting assets into your game couldn't be easier. It's relatively easy to start using for both experienced developers and those who aren't.

A good, experienced graphics programmer working in mobile right now can easily ask $200 per hour or more because the demand far outstrips the supply. Figure it out. Unity's full iOS license is basically the equivalent of 15 hours of a graphics programmer's time. Yet, Unity will easily cut five times that many hours off of any decent size software game project's schedule, probably a lot more.

I'm giving Unity3D two big thumbs up. I'm using it on a project now and hope to use it on many more in the future because it's fun to use and removes much of the tedium associated with 3D programming without removing power.


1 Many of the more advanced features require the more expensive "Pro" license, however, and really cutting edge features from the latest games generally take a little while to show up in the tools

Thursday, January 27, 2011

Garage Games

I noticed that Garage Games, the makers of the Torque game engine have recently had a near-death experience. As of the end of last year, it looked like they were shutting down operations. However, they appear to be in the midst of a phoenix-like return to life with, perhaps, some changes in focus and priority. The bad news for iOS folks, is that they've removed the mobile version of their 3D engine from their product list. I don't know if this means it's abandoned, or that they're just not ready to announce/release it. They are actively hiring developers and designers, and from the job descriptions they've posted, it sounds to me like they've got their sights set firmly on mobile.

To celebrate their revival, they're having a sale on all their products - you can get any of their engines, including a full source license for $99.

Now, I honestly don't know how Torque compares to, say, Unity, Sio2, or the UDK in terms of features or ease of development, but there have been a lot of very solid games created with Torque over the years and the demos show the engine is versatile and fairly powerful.

What I do know that $99 is a hell of a price for a source license to a game engine of this size and complexity. For me, it's worth that much money to get to peek around their code. There's a lot to be learned from looking at other people's code.

No word on how long the sale is for, but you can check it out here.

Note: I had an e-mail conversation with Garage Games' community manager about iTorque 3D. Unfortunately, right now the official word is that the product is off their roadmap. They have no announced plans to release it, so if you're targeting the iPhone or mobile devices in general, you're out of luck for now and should probably look at another engine.

That being said, they didn't rule out the possibility of re-introducing iTorque 3D at some future point. Frankly, if you're interested in writing games, I still think it's well worth dropping $99 for a license to be able to see the choices they've made in designing their engine as well as how they've implemented them. It's a pretty good example of a complex cross-platform project.

I have to say, I like the new public face of Garage Games. Their responses to my questions were prompt and candid. I think the new management knows exactly what they want to do and I'm looking forward to seeing where they take things.