A little Tanty about Tanty…

Chances you haven’t yet heard about a game called ‘Tanty’, and that may be either a good thing or a bad thing, it’s hard to tell really. Tanty is a small-scale physics based game made in Unity3D. The game puts you in the shoes of a toddler throwing a tantrum (fit/outburst) in a dentist’s office and for reasons, you have some psychic powers.

Tanty is available on itch.io HERE ~~ By the way, for whatever reason we were named ‘Team Brando’. The team consisted of me (Alex Bryant), ‘Harrison Metcalfe’, ‘Tylah Kapa’,’ Jacob Blanch’ and ‘Hanoch Yanuary’.

Tanty is the result of a four-week miniature game dev project for a piece of assessment at my university course. The rules of this assessment were relatively simple with the main rule being ‘No Complex Bipeds Allowed’ (No human models, especially animated), which was also the name of this task. For simplicity’s sake (not quite), groups were assigned and we were only allowed to keep the game small, in one area, and limit ourselves to a colour pallet of 5 unique colours (Not including black & White).

This blog is going to be somewhat reminiscent of a post-mortem but with a slightly different, less formal spin than what I normally do. As briefly as I can without losing detail, I will discuss what went well and what went wrong with the 3rd task of the trimester, or in other words, Tanty.

Before you ask, yes I did make my MassPickup script for this game although it was later removed due to its lack of chaos.

Alrighty then, let’s start at the beginning, planning.

The Original Idea
Originally, Tanty had a slightly different premise, our first plan for the game was to have the player stuck in a dentist chair or a singular confined room simply trying to fend off the dentist. Because we had to make the game run for no more than ten minutes, we also planned to have aliens come rescue the child if they avoided the danger for long enough. Why? Because reasons…. Reasons being we didn’t think up a reason, that’s all.

As you’d expect, when it came time to pitch the group was blasted with a whole lot of negative feedback. Because of this, we sat there upset for a little and then did something about it. It took a couple more iterations until we got the plan to where it is now and it was well worth the effort. Pitching to a live audience is an extremely important part of a project even if it’s just to a couple of close family members. Everyone always thinks highly of their first few ideas, but with an honest audience we can come to realize that there is always room for improvement, so improve we did.

Planning & Documentation

GDD (Game Design Document)
A GDD is a highly detailed document containing basic information on all individual elements of a game including descriptions, map design, story/plot, and the wider range of assets (3D/2D & Audio). A good GDD should include every type of asset needed, how many variations of it are needed and what assets link to each other.

For Tanty we had a 15-page document containing all of the information we needed to complete the game according to out original scope. In place of a razor statement, we had a short paragraph explaining the base concept. Following this, we had a section for detailing the ‘Mechanics & Dynamics’ and the goal. Having these two helps us remember and share what we are trying to achieve without going into too much detail. Next, we covered the use of the game which includes what platform the game will be made for, who the target audience is and what experience we hoped to give the user. All of these had briefly mentioned examples of other games to help with visualizing the concepts.

Next came ‘physical’ assets, this section of the document spanned over about seven pages and included both a list of all planned models, UI and the floor-plan of the game. After initially laying out the assets in an indented tree style we created a large table that included example images, links to the source of the image, and if the object would be able to be grabbed/thrown or not. While we definitely missed a large number of the objects on this list, it helped us to remember what was needed and constantly keep that image in our heads of what the game would look like.

Further on in the document, we included the Audio Assets. This list included all character voice lines, menu interaction sounds, ambient noise/background music, how many variations of each type we needed (and what for to allow an easier time preparing for it), and collision sounds (and what objects need them). Then came the UI assets and this mostly included links to examples of existing games we would want to take inspiration from. Finally, we included a Game-Flow-Diagram and a more detailed version of the ‘Level Layout’, how we plan to get players to explore without forcing them to and a change log at the bottom to note all changes to the document.

While the GDD was fairly good for the scale of our project it definitely could’ve included a lot more detail in terms of imagery and asset linking. A lack of detail on changes was also apparent and we only noted one change to the document after the initial release to the team. I would have also liked to do some more work on this myself and it was mainly completed by the designers and one of the programmers. Adding more detail and how we plan to implement them (briefly) would have increased the quality of the document and given all team members a better understanding of what was to be achieved, and how to do it. Obviously, Designers are better suited to the GDD development as that is a heavy part of their field, but that doesn’t mean programmers and other team members should just neglect the document as I did. All members should provide input, this would not only increase the amount of detail in the document but would also rule out inconsistencies and incompatibilities.

Because team input and refinement was the missing factor in creating an even better GDD, in the future I plan to communicate better with all members of the team by emailing and messaging members when something needs to be added and even assigning tasks to everyone to look at and adjust the document while writing down every change they made. Every time the document gets adjusted all members will be required to take another look to ensure everyone is happy with the content of the document and direction of the game.

A couple of great articles on a GDD can be found HERE and HERE

HCD (High Concept Document)
A ‘High Concept Document’ is a relatively short document (roughly 2-5 pages) that essentially grabs some of the important details out of the GDD and expands on them to give more detail. HCD’s can also be used a what is known as a ‘Pitch Document’ and be spoken aloud when pitching the game to either the team, investors, or just to curious individuals. A ‘HCD’ should try to portray what a team is trying to create in such a way that anyone reading/listening to the document can understand both what is going to happen and what the advantages/disadvantages are (Using their own interpretations).

While Team Brando did in-fact have a HCD, it was rather lackluster at meeting all the standards and only contained a singular page containing an explanation of the game’s concept/story and a detailed section of how & why we would use a controller for the only input method.

Again I didn’t input to this document so that didn’t help but if we were to revise it and start up the game again there are a large number of things I feel are necessary for a document of this nature. The most important item we left out was a feature list. A feature list should detail every single action the player can do, what areas they can & can’t access, how the game communicates to the player and what restrictions/limitations the player has. We should have also included what competition there would be for this game and how we were going to make it different, or at the very least how we were going to market it differently. Of course, this was just a free game created for an assessment piece, but considering aspects such as selling points is important and can provide practice and also get the development team into the mindset that a game is a product that can be sold (As well as how it can be).

Another thing to add would be a more detailed description of the target customer and what motivation they have to actually play the game. No one really wants to play a game without motivation, so why would they have any motivation if the developers don’t even know what/who to build the game for. Lastly, the HCD should contain a section detailing the ‘Design Goals’ of the game. Design Goals are not just simply ‘Make Money’ or ‘Get publicity’, they are marketing goals (which should also be in selling points). Design goals should include what the developers want the player to do and be able to do in the real world such as ‘We are making this game for the enjoyment of the player, laughing is a must so the game must include humour in some form’ or even ‘We want the player to experience freedom of movement and feel like they are actually picking up objects, the use of a controller allows this feeling’. This document should mostly be created by designers and some form of marketing team (possibly even the story writers) so that when it is used to pitch, the game doesn’t go misunderstood.

Most of these features were missing due to both poor communication and a lack of effort my my behalf. In the future all teams I work with will do research both before working on a HCD and after purely to ensure we didn’t miss anything. A HCD also relies on revisions and adjustments throughout the project alongside the game so changing the document is a necessary adjustment I will have to undertake.

Some more articles for you, but this time for HCD’s! yay!

TDD (Technical Design Document)
Tanty didn’t use a technical design document but an example of an extremely high-level TDD can be found HERE, and a slightly less detailed but still very good TDD can be found HERE. It is very unfortunate that we did not have a TDD as it is extremely useful in planning out what script/asset requires what to run. With a TDD we can know what to make in advance instead of editing scripts to be compatible. In the future I plan to make a TDD working with all the programmers using diagrams and even scheduling tasks to do so.

I will also be writing a separate blog describing a TDD and the benefits they bring, this blog will be linked here upon completion.
Check Out My TDD Blog Here

Art Bible
An art bible is a document created towards the start of a development process usually by the Art Director although collaboration with the main designers and project leads helps with its creation. In simple terms, the art bible is essentially a guide to be used throughout the entire development and it should detail what colours are being used, what visual style the game is to fit in, examples of similar concepts, and examples created especially for the bible.

All art bibles should be created with the thought of a new team member joining so that all members working on visuals know what is expected of them. This helps the team work in unison and minimizes confusion about the direction of the game’s art. Due to the small team ‘Team Brando’ had, the small game we were making and the lack of extra artists, our Art Bible was relatively short.

Content within our Art Bible included our colour pallet, our visual style (low poly), how we planned to use our five colours effectively, and two examples of low-poly games. A lot of detail was also added in regards to how the player should feel with the art and why we chose this particular style for Tanty (childish simple items).

The Art Bible we produced included enough detail to get everyone understanding our direction and what we had was of high quality, although we were missing a few essential features that I plan to include in the next Art Bible I create. The first item on this list is concept art, this is where the artists create images of what the game would look like while playing. Concept art can range from a sketch all the way to a highly detailed image in photoshop. Unlike the images from external media and the photos we included in the bible, we didn’t include diagrams. We had previously developed simple diagrams to aid in interpreting our vision although we failed to implement them to the art bible during development.

More sections that would’ve helped are one such as UI, LODs, Camera vision, Character Art, Atmosphere Feel, and what file types/programs where to be used.

In the future I will be (and recommend to all) to plan out an Art bible and every single item it requires before even working on it. Essentially I will be building a template and then filling out every section in collaboration with other team members. After this to ensure it meet the criteria of updating a newcomer I will show it to multiple people outside of the loop to see if they understand completely what the game will look like in the future.

Scheduling & Task Allocation
In order to keep a project on the right track and make sure everything gets done it is essential to employ some form of scheduling whether that’s something as simple as writing down a plan and emailing reminders or even using a more advanced program/website such as Trello. For Tanty we used a website currently in beta going by the name HacknPlan.


HacknPlan is a website developed with the sole intention of creating an efficient scheduling system specifically for game developers. This site allows users to create tasks, categorise them, assign members to them, set specific time requirements and even set dependencies for task to be unlocked upon completion of another task. For this particular project all members of our team were signed up on HacknPlan and were using it actively whenever someone completed a task. We had set up multiple Milestones which needed to be completed before moving onto the next, this allowed us to focus on current tasks without getting distracted on ‘the next cool thing’ we wanted too add in.

Tom improve on our use of this we could have narrowed down more tasks to complete. This would’ve allowed us to have a more detailed report on how quickly we were progressing and if we had to change any plans to accommodate. We also often ignored the estimated and completed time portions of the tasks so the numbers we saw couldn’t be trusted, therefore we didn’t know how fast everyone was working and couldn’t properly assign tasks to team members using time estimations. Although on a more positive note, HacknPlan allowed us to easily work with out Audio Student collaborator ‘Andrew Thorley’.

Time Management – How I can do better
Yet again this was another project where my time management was extremely poor and that affected the quality of the overall product. Even though we used HacknPlan and added a lot of tasks for everyone they were never really small enough or specific enough. A lot of time management problems with me stem from my inability to actually work on tasks earlier than needed. I recently had a meeting with my uni facilitators about this and we discussed the very issue at hand. What I need to do (and is good practice for everyone) is to work around this rather than trying to fix it. Instead of trying to commit myself to work on a task earlier I need to break up a bigger task into a lot of smaller tasks and set a sooner deadline for them. This is where Trello/HacknPlan shine, in the future I will use these to assign a large number of small tasks which unlock the next task as soon as one is completed. I will also use the estimated time to complete in a way that inspires me to get it done within that time. What I mean by this is that if I set a task to take 2 hours to complete then I should think of the deadline as two hours away even if it’s not needed for another week..

Audio is a large part of a game as it helps to keep players both engaged and entertained while playing. Working together with Andrew we were able to come up with what sounds we would require and what style we wanted them in. he was able to produce 2-3 dozen audio files for us at short notice including background music, interaction noises, menu music and character dialogue.

Here’s an example of our Menu Music, Enjoy!

Overall the audio quality was great and well put together. While we didn’t end up implementing all of it, most of it was added into the game through Unity and our own custom made mini-AudioManager script. All audio would be played upon certain conditions being met in the game or upon objects colliding with each other as can be seen in the downloadable copy of Tanty. The audio we included in our game aimed to give players the feeling that they were playing from a child’s point of view, to achieve this we ensured that all audio was slightly upbeat and comedic to keep it childish. We didn’t sacrifice everything for this though, we kept some audio slightly darker such as when the dentist is nearing the player and when time is running out.

Thanks for reading that big rant-thing of a Post-Mortem I made! I know it was long but I wanted to squeeze out a lot of detail, see you next blog!


One thought on “A little Tanty about Tanty…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s