GDB Series: Game Design Document

NOTE: This article targets small to medium sized F2P productions.

Lets start with: don’t write a painfully long document enclosing a ton of details and explanations of each and every parcel of your game. This “doc” needs to paint a broad picture of your idea, be easily searchable, updateable, understandable, referenceable – that’s all!

To achieve such feat, i would suggest using a tool such as Confluence and avoid standalone docs (wherever possible).

As a structure, i would segment into:

Main target and idea
What’s the target audience, what’s the fantasy, why should i play the game, how is your game standing out from the crowd, what’s the one line sentence that can define the gameplay experience.

Primary and Secondary features
All games have features, some are critical to the product some not that much. Nevertheless, understanding the differences between them is of utmost importance to your game’s success.
In an ideal setup, all of these will find their place in a complex web of interdependencies, allowing the user to connect the dots and understand the relationship between them.
In short, if you manage to intersect them in such a way that using the great majority of them is linked with successful player progress, then you are surely one step closer to building a great game.

Out of that, i would further branch the “Primary and Secondary” features into relevant sectors:

Meta Loop
Simply said, what am i building / upgrading / pouring resources into at the end of my play cycle? In all F2P games you grind for some XP, resource, item or currency or you simply play over and over again to complete the level saga / map entries while spending energy. No matter the grind, you will always channel its outcome towards building your meta, be it to upgrade your heroes / cards or beautifying your garden / zoo / mansion or simply progressing stage after stage in that never-ending ladder of levels.

Core Loop
Also known as the grind, is the cyclic pattern the player needs to undertake in order to advance in the game’s meta. For simplicity’s sake, use diagram / flowchart tools to better illustrate the loop – i personally use Gliffy.
The core loop can simply be illustrated by a Play – Loot – Upgrade repetition where you will ideally replace the three elements with the previously identified Primary and Secondary features.

For instance, this would be the Core Loop for the F2P game Empires & Puzzles

Economy Loop
There’s nothing fancy and complicated about an economy loop, not at this stage at least. All you have to do is mark down the locations that grant currency/items and the ones that spend them. The main idea is to have a fair understanding of generators and spenders, so that your Progression and Balancing design properly integrates them in your loops.
You wouldn’t want to generate a need for spending resources without having a means through which you gather them, and you surely wouldn’t want the vice versa, having too many resources without introducing a purpose for using them.

Progression and Balancing
These are two of the most important areas of a F2P game and will make the difference between a successful or unsuccessful game. Make it too easy for a player and he will probably get bored after a couple of day’s play, make it too difficult and he will think twice before opening the game for a second time.

This is not something new, and anyone who has played more than a handful of games will easily understand the concept, yet this goes into a whole different ball park when it comes to free to play.

The main areas you need to look after are gameplay and economy, for which you will be interested in having a skeleton for both balancing and progression. Values will of course not need to be final, yet having this doc early on will allow you to better envision how your game will shape up.

For instance, lets say you build an RPG, you will of course need to know how much team power you need in order to win a level and what would the reward be for level 1 vs level xxx. Or maybe you have a Hidden Objects game, how will the first encounter differ from the 100th, how many items do you have on the screen, what’s the timer looking like, how much energy do you consume for playing the level, things like that.

I know it may sound like you’re doing a lot too early, yet these should not take you much time to build, you can simply sketch the “backend” of your game through a simple spreadsheet. My choice is the very powerful Google Sheet & Google Script combo.

GDB Series: Creative Design Document

NOTE: This article targets small to medium sized F2P productions.

As with the other documents, the CDD (creative design document) is meant to provide clarity to all stakeholders involved. In this part, you will detail the look and feel of your game, the setting, the environment, the story and characters, you will set your mood board and art style, in short you will need to “paint the picture” of your title.

The Story
Your game’s story will of course not need be final, as with many documents in this stage a simple sketch will do. Trace the main plot line and pin the important points, skeleton onto which you will have plenty of time to add the meat soon after. You will also need to touch on important elements such as time and location, characters, setting and environment. Having this will help the art team figure out how will everything look like, as you will of course not want to start with having a neon theme in a dark ages setting (or maybe you do :D)

Setting and Art style
Having a story backbone your art team will now be able to sketch the game’s mood board, exploring theme, environment, color palettes and overall style. In short, the way your game will look and feel. Try defining that in the simplest of ways, narrow it down until you have the key elements defining your game’s style and then build on that.
Should it help, i had a fairly decent success rate defining the game’s style by starting with three simple words, say “Vibrant, Futuristic, Clean” or “Gloomy, Gothic, 1900”. They somehow already put me in the atmosphere and help everyone start with the same base in mind.

GDB Series: Technical Design Document

NOTE: This article targets small to medium sized F2P productions.

If you’re anything like i was in the beginning, the tech details of a game are the last thing to have in mind, especially when you are so excited about the prospects of creating a new game from scratch!

With that, lets cut it short and properly highlight the importance of a TDD, underlining the value of starting such conversations in the early development stages of your game.
Doing so will not only allow you to understand the technical limitations that could fall upon your team but also provide insights on additional costs associated with engines, services or other 3rd party development tools.

Here is a list of starting questions to kickstart your list with:
– What platforms are you planning to release your game on?
– What would the tech specs look like for your game?
– Will those be compatible with the release platforms?
– What engine are you using?
– Can that engine support all features and release platforms for your game?
– Will you need servers / CDNs (content delivery networks) to run your game?
– If so, do you have your own or will you need to rely on external support?
– Will you support cloud saves and player authentication?
– Will you use a caching system?
– What would traffic look like for 1/100/1000/100000 players?
– Do you foresee the need to using Analytics?
– If so, do you have your own or will you need to rely on external support?
– Will your game support Social Media integration?
– Will you need Customer Support?
– Will you need matchmaking, leaderboards, anticheat?
– Will you need to connect external devices to you game (controllers, gadgets etc)
– How will you tackle cheaters?