[i]This week’s design diary is about an incredibly important feature in the game — its manual. I go into why the game has a manual, both from a design and player point of view. Also — this entry is the last of the scheduled run! I hope you’ve enjoyed it. I will certainly write more in the future, but only when I have enough to talk about. [/i] [img]{STEAM_CLAN_IMAGE}/43803344/848e67966771833d15badfd6fed1447c8067caf6.png[/img] [i]The manual in game [/i] You’ll laugh, but making a tutorial is surprisingly hard. Of course all of gamedev is hard, but making a tutorial stands apart in its difficulty. From a technical point of view, a tutorial is an intruder into an already messy system, demanding special exceptions and consideration, interrupting the flow of the game. From a design point of view, tutorials try to satisfy many different goals — teaching the game’s controls, systems, rules and processes; introducing the setting and world, setting expectations for the player, and so on. Tutorials will only capture most of the players starting your game — everyone has different learning styles, familiarity with genres, and moods when sitting down with a game for the first time. The problems are magnified with strategy games, with multilayered systems that don’t always present themselves well with other teaching methods used in videogames. Many layers of systems and interfaces need to be understood and readable, but generally will favor someone who understands them already over a clean entry point for introducing a player. [b]For strategy games, at the end of the day I just want a manual.[/b] I like reading manuals! I play lots of boardgames, and a well written manual is enjoyable for me to read and can greatly add to the experience of the game. Even though manuals are not strictly necessary for the operation of a videogame, they can be very useful for many situations, beyond learning the game itself, but well into the extent of playing it. Manuals can provide story and flavor, extending the game’s world beyond the interfaces the player directly interacts with. So for The Banished Vault, in addition to a small tutorial, I’ve spent a lot of time and iteration writing an extensive manual. The manual serves a lot of functions over the course of play, beyond the initial point where the player is taught the game, serving as a reference guide and containing bits of story not in the game proper. [h3]Teaching the basics[/h3] There are a few different ways the game teaches itself to you, and all are interlinked. There are introductory scenarios that show the basic structure of the game, like movement in a solar system and constructing buildings to gather resources. These are the closest to tutorials in the traditional sense, with specific step by step instructions on how to complete them. Those instructions are in the manual, laid out as it would be in a real book. There’s immediate benefits to this — one is you can read and reread the instructions as often as you like. Also with that text are diagrams and examples to accompany the instruction. On a technical level, this method is simpler than doing diagramming ‘live’ on the game’s interface, and it also shows the player a checklist and confirmation of “this is what things should look like once you’ve completed them.” The other element of the intro scenarios is hiding unnecessary interface. This is a fairly common tutorial method for strategy games, but it’s not something I see all the time and wasn’t a principle I had in place from the start. The idea is simple, for the scenario the player only sees interface elements relevant to completing it. This removes the need for trying to sort through the most important information shown to you. Many strategy games including The Banished Vault show the player a lot of information, but not all of it is necessary to know all the time. This removal can focus the player’s attention, and once new elements are brought in you will be accustomed to the ones you’ve seen before. [h3]Explore the rest[/h3] For many strategy games, wikis have replaced the reference section that is found in a manual. Each component of the game is atomized and spread out onto a page and hyperlink model. This can work well for some games and adequately for most, but I prefer having this material in game and in book form. There is a reference section in the manual that breaks down the game into small components, such as listing each outpost building’s cost and function. Additionally there are many sections simply explaining the game and how different concepts operate, such as movement, building, hazards, stasis, etc. These sections are short, written in plain language, and are a complete explanation of that game element. These explanatory sections accomplish multiple tasks, depending on the player’s situation. Firstly it’s just an explanation for the player who missed something in the introductory scenario. No tutorial will be able to fully capture every player, and so the manual reinforces what the scenarios taught. Second, for teaching game elements that the scenarios won’t be able to. Even though The Banished Vault is not an overly complex game, if a step by step tutorial walked you through every element exhaustively, it would take several hours of handholding. So I’ve opted for a middle ground where the scenarios teach you the basics, and the manual does the rest. Once the player knows what the most important elements of the game are, they can choose which sections of the manual they need to read to learn the rest. And lastly, for reminding players who come back to the game after a break. A player can much more quickly read the manual text to refresh themselves, instead of going through a tutorial that presumes they don’t know anything at all. [h3]Production[/h3] From a game production point of view, the manual has had some interesting tradeoffs. One of the primary benefits I wanted to gain was being able to start writing the manual much sooner in the production cycle than a traditional tutorial. Games take a long time to settle over the course of production, with features and systems frequently cut or added late in development. Exhaustive tutorials require the game to be in this relatively finished state, and/or need constant readjustment to account for the game, so are usually assembled very late in production to waste the least amount of work. Manuals still require adjustment late in the production process, but otherwise can be started much sooner. Since I have planned to write the manual from the beginning, the first draft was ready only a few months after the prototype started, in line with the first internal test build. The work on the manual can be done in parallel to the game, without any two-way technical implications. It has taken many iterations to get the structure right, but those iterations were important to go through and I think the manual is in a stronger place for it. It does require a lot of writing and layout work, which must be done carefully to ensure information is clear and accessible. [h3]Final Thoughts[/h3] I think the game experience is better served with a manual, because people are good at reading and referencing written material. You can read at your own leisure, dive in and try to learn at your own pace, or read as much as you want before starting to play. This kind of flexibility is hard to replicate using traditional tutorials or third party wikis. A lot of this work is experimental, but the feedback from tests is positive. I hope it’s something that bears out, and I’ll continue to iterate where I can., but I feel strongly about the benefits of this method of teaching players the game. It’s not a book that you have to read cover to cover to start playing, but a document that is a companion piece to the game, included in the game and written by myself. Ultimately, the manual is a key feature of your experience in [i]The Banished Vault.[/i] In the coming weeks, I'll be talking more about the latest version of the manual and how it integrates into the final game.