Introducing Our Development Environment
Before you can begin prototyping in earnest, you first need to become familiar with Unity, our chosen development environment. Unity itself can really be thought of as a synthesis program; while you will be bringing all the elements of your game prototypes together in Unity, the actual production of the assets will largely be done in other programs. You will program in MonoDevelop; model and texture in a 3D modeling program like Maya, Autodesk 3ds Max, or Blender; edit images in a photo editor such as Photoshop or GIMP; and edit sound in an audio program such as Pro Tools or Audacity. Because a large section of this book is about programming and learning to program in C# (pronounced “see-sharp”), you’ll be spending most of the time with tutorials using MonoDevelop, but it’s still critically important to understand how to use Unity and how to effectively set up your Unity environment.
Why Choose Unity?
There are many game development engines out there, but we’ve chosen to focus on Unity for several reasons:
Unity is free: With the free version of Unity, you can create and sell games that run on OS X, PC, the Web, Linux, iOS, Android, BlackBerry, Windows Phone, Windows Store, and more. While the Pro version of Unity includes a few additional useful features, for a game designer just learning to prototype, the free version is really all that you need. The Pro version normally costs $1,500 (or $75/month), but if you’re a student, a one-year license for Unity Pro is about ten times less!
- Write once, deploy anywhere: The free version of Unity can build applications for OS X, PC, the Web, Linux, iOS, Android, BlackBerry, Windows Phone, Windows Store, and more, all from the same code and files. This kind of flexibility is at the core of Unity; in fact, it’s what the product and company are named for. There are also paid extensions to Unity Pro that professionals can use to create games for the PlayStation 3, Xbox 360, and several other game consoles.
- Great support: In addition to excellent documentation, Unity has an incredibly active and supportive development community. Hundreds of thousands of developers are using Unity, and many of them contribute to the discussions on Unity forums across the web.
- It’s awesome!: My students and I have joked that Unity has a “make awesome” button. Although this is not strictly true, there are several phenomenal features built in to Unity that will make your games both play and look better by simply checking an option box. Unity engineers have already handled a lot of the difficult game programming tasks for you. Collision detection, physics simulation, pathfinding, particle systems, draw call batching, shaders, the game loop, and many other tough coding issues are all included. All you need to do is make a game that takes advantage of them!
Why Choose C#?
Within Unity, you have the choice to use any of three programming languages: UnityScript, C#, or Boo. Very, very few people actually use Boo, so you’re really left with two choices.
C# was developed in 2000 as Microsoft’s response to Java. They took a lot of the modern coding features of Java and put them into a syntax that was much more familiar to and comfortable for traditional C++ developers. This means that C# has all the capabilities of a modern language. For you experienced programmers, these features include function virtualization and delegates, dynamic binding, operator overloading, lambda expressions, and the powerful Language INtegrated Query (LINQ) query library among many others. For those of you new to programming, all you really need to know is that working in C# from the beginning will make you a better programmer and prototyper in the long run. In my prototyping class at the University of Southern California, I taught using both UnityScript and C# in different semesters, and I found that students who were taught C# consistently produced better game prototypes, exhibited stronger coding practices, and felt more confident about their programming abilities than their peers who had been taught UnityScript in prior semesters of the class.
On the Daunting Nature of Learning a Language
There’s no way around it, learning a new language is tough. I’m sure that’s one of the reasons that you bought this book rather than just trying to tackle things on your own. Just like Spanish, Korean, Mandarin, French, or any other human language, there are going to be things in C# that don’t make any sense at first, and there are places that I’m going to tell you to write something that you don’t immediately understand. There will also probably be a point where you are just starting to understand some things about the language but feel utterly confused by the language as a whole (which is the exact same feeling you’d have if you took one semester of Spanish class and then tried to watch soap operas on Telemundo). This feeling comes for almost all of my students about halfway through the semester, and by the end of the semester, every one of them feels much more confident and comfortable with both C# and game prototyping.
Rest assured, this book is here for you, and if you read it in its entirety, you will emerge with not only a working understanding of C# but also several simple game prototypes that you can use as foundations on which to build your own projects. The approach that I take in this book comes from many semesters of experience teaching “nonprogrammers” how to find the hidden coder within themselves and, more broadly, how to convert their game ideas into working prototypes. As you’ll see throughout this book, that approach is composed of three steps:
- Concept introduction: Before asking you to code anything for each project, I’ll tell you what we’re doing and why. This general concept of what you’re working toward in each tutorial will give you a framework on which to hang the various coding elements that are introduced in the chapter.
- Guided tutorial: You’ll be guided step by step through a tutorial that will demonstrate these concepts in the form of a playable game. Unlike some other approaches, we will be compiling and testing the game throughout the process so that you can identify and repair bugs (problems in the code) as you go, rather than trying to fix all of them at the end. Additionally, I’ll even guide you to create some bugs so that you can see the errors they cause and become familiar with them; this will make it easier when you encounter your own bugs later.
- Lather, rinse, repeat: In many tutorials, you’ll be asked to repeat something. For instance, in a top-down shooter game like Galaga, the tutorial would guide you through the process of making one single enemy type, and then it would ask you to create three others on your own. Don’t skip this part! This repetition will really drive the concept home, and it will help your understanding solidify later.
Earlier, I mentioned that most of my students feel confused and daunted by C# at about the midway point of the semester, and it’s at exactly that time that I assign them the Classic Games Project. They are asked to faithfully recreate the mechanics and game feel of a classic game over the course of four weeks. Some great examples have included Super Mario Bros., Metroid, Castlevania, Pokemon, and even the original Legend of Zelda. By being forced to work things out on their own, to schedule their own time, and to dig deeply into the inner workings of these seemingly simple games, the students come to realize that they understand much more C# than they thought, and that is the time that everything really falls into place. The key component here is that the thought process changes from “I’m following this tutorial” to “I want to do this...now how do I make it happen?” At the end of this book, you will be prepared to tackle your own game projects (or your own Classic Game Project, if you want). The tutorials in this book can be a fantastic starting point on which to build your own games.