Hello Everybody, Earth Otherwise here to continue our journey into the book Game Programming in C++: Start to Finish by Eric Yuzwa. In chapter two the book will introduce some common software design methods, introduce software reusability techniques, introduce the Unified Modeling Language, describe and cover basic game phases, and describe and develop a design document using the Agile design process.
Sounds like quite a bit, but really it's just mostly going over how to set up the design for making your game. In reality, so long as you actually end up with a game at the end of it there's no wrong way to design a game. There are better and worse ways to go about it though, in a general sense.
If you're here then you probably already know what game design is. There's literally hundreds of videos and posts on it. What game design comes down to is the central idea of your game. A core that you can come back to if you're unsure if you should pursue a certain path. Want to add a double jump? Depends on the design. If your design is about freedom or having cool abilities, then sure. If your design is about realistically simulating life or building an oppressive atmosphere for a horror game, then probably not.
There are two main ways that the books talks about when it comes to design. Waterfall Design and Iterative Design. Waterfall design is an older form of design that follows a simple principal. You plan things out, get all the details on paper, code it up, fix the bugs, and ship the product. It's the faster of the two design principals. It has a fatal drawback though, particularly when it comes to game design.
Game designers rarely know the full scope of their game before they start work on it. Nor do they know if a certain part of the design is flawed or simply won't feel right to play in the final game. With waterfall design by the time you're testing your game it's far to late to find out that one of the main mechanics simply isn't very fun to play. Instead Game Designers rely on the slower and more testing heavy Iterative Design.
Iterative design is simple. You essentially take the waterfall design principals and instead of making the entire game all at once you start with a core concept and build the game out from there, much like the layers of a jaw breaker, an onion, or an ogre.
Of course you'll have a general idea of what your game is going to be and you'll also have deadlines to meet. You will set milestones for yourself to let yourself know if you're taking to long to get part of the game up and running. Each milestone should have a subset of goals that should keep you on track from week to week and even day to day. At each milestone you'll want to consider what parts of the previous work took more or less time than expected and adjust your next set of sub-goals accordingly.
Agile design methodologies were created due to the lack of flexibility in software design and they inform the iterative design process so that we may have more concrete rules for designing software, though these rules are still quite vague. Some methods, like Scrum, have taken this a step further and made very concrete methods, if you need step by step instructions for using the design process. Essentially you have several types of maps to use for finding your way to a destination of your choice, each map give you a more or less specific route to take to your destination, a video game in this instance.
Agile has a few guidelines to follow.
Minimize project risk by developing the software in short iterations, here called timeboxes, which last from one to four weeks.
Each timebox is itself to be treated as a full project and contains all the tasks needed for releasing a full update to the main project. You make a new plan, look at the old requirements and update them, gather any data from the last timebox, code, implement, and update the documentation. At the end of each timebox you should have code that, if you released it right now, would run properly and do the things you want it to do. It doesn't need to be something that you would ship, only something that you COULD ship, if you had to.
The Agile method focuses on personal communication, including direct meetings with your team and with the client. It also stresses that anything you and your client decide overshadows the written documentation. If they originally wanted red and now they want orange then it's orange. Obviously, when talking with them, if they ask for something you can't do, then mention that what they're asking isn't possible without extreme delays.
The way Agile defines the Client, however, isn't the way you or I might define the client. You or I might think of the client as the gamers that we're making our game for. Not so in the context of the Agile design process. The Client is simply the person who defined the project to begin with. In the situation we as indie developers find ourselves, We are actually the client. What this means is when you are planning out your next timebox you should go with your gut and not be afraid to change things so long as they don't put undue strain on your work load.
It's also important to note that in 2017 much of game development is multinational. Your artist might be in India or Taiwan, and so face to face meetings might not be possible. However, with programs like Discord and Skype it's easy to have written and voice communication with your team.
Along with this there's Git and GitHub that I'm using. It makes it simple and easy for a disparate team to add to the main project while under the eye of the team lead, likely yourself.
Agile design principal 4. The progress of an Agile project is measured by the amount of functioning code at the end of every timebox. Makes sense, though you might also want to keep an eye on your assets. You can have a completely functional game but if all your art assets are crap then it doesn't much matter how good your game is. Programmer art is most certainly not what most players want to see. You can really only get away with that if you lean into it and go full ASCII or something.
Finally, Agile welcome requirement changes by the client, even late in the project, in order for the client to maximize any competitive advantage. Essentially, if you're making a game, like, say, Battleborn, and goddamn Overwatch just came out, you might want to consider delaying your game and doing at the very least an image overhall.
If you don't, well, most of you probably don't even know that a game called Battleborn even exists and came out around the same time as Overwatch, do you?
Essentially, the Agile process is specifically designed for you to have a running, shippable game at nearly every turn that you can easily and quickly change if something unexpected happens, like if your sound guy dies in a car crash.
There is another part of Agile. A testing framework to automatically test your software for bugs and crashes. It is outside the scope of the book, but it might be something that we want to invest some time in at some point, as with such a small team and likely no one but friends, family, and the team itself to test our game we need all the automated help we can get.
Obviously Agile has a few flaws. The bigger your team the harder it will be to turn on a dime and start making a new feature that you didn't anticipate. The Agile Alliance recommends that you use Agile only if your team is 10 people or fewer. Essentially, if you need middle managers then you'll probably want a more concrete design strategy. Perhaps a mix of multiple design strategies even. That, too, is outside the scope of this book though.
That's it for Part 1. Next time we'll look at the Unified modeling language and software reusability. Until then, this is Earth Otherwise, signing off.
