Itch.io Game Page

Game Design Document

 

Foreign Body is a single player, third person, turn-based strategy game where you play as a hostile bacteria invading a defensive immune system. As you move further into enemy territory, you must spawn bacteria, strategise and consume your way to victory!

​

​

​

 

 

 

 

 

 

​

​

Game Genres

• Third Person

• Strategy

• Single Player

• Turn Based

​

Platform

• Windows PC (Itch.io)

​

Engine

• Unity

​

Time Spent on Project

• August 15th, 2022 - December 1st, 2022 (16 weeks)

​

My Role(s)

• Producer

• Designer

• Scrummaster

​

Software I Used

• Unity

• Photoshop

• Audacity 

• Discord 

• Trello

• Google Drive

• ScreenToGif

• Diagrams.net

• Visual Studio

• Perforce

• Google Docs

• Google Sheets

• Google Forms

• Chiptone

​

Gameplay Summary

Foreign Body is a strategy game about battlefield management. You control a commander unit and an army of bacteria as they move across a hostile battlefield, filled with enemy white blood cells. The goal of this advance is to destroy the enemy commander unit, located at the far end of the board. As you progress your bacteria can absorb their enemies and passive resources to gain new abilities and clone themselves to increase their numbers. 

​

​

​

​

​

​

​

​

 

​

​

My Overview of the Project

Petri Dish Studios was a team made up of 4 designers (including myself), 3 artists (plus 1 for UI), 2 programmers and 4 sound designers. Foreign Body was a student project I completed for my second year at AIE. I had previously not worked on any strategy games before, so this was a new experience for me. Learning to plan for the way players would behave was even more prevalent in this game than it had been in others. I am very proud of this game and all the effort that myself and the team put into it! 

​

​

​

​

​

​

​

​

​

​

​

​

My Contributions

• Collaborated with the other designers and team-members to discuss and create the behaviour of the AI and all facets of design within the game. 

• Worked majorly on the Game Design Document (see document at top of page for logs of all added content).

• Acted as Producer for the project, ensuring that tasks were understood by all, and that people were clear on the direction of the game at all times. 

• Frequently held meetings with other team members, ensuring to document all decisions made for future reference.

• Ensured that I was available for any questions that team members may have had. 

• Grey-boxed both the main level of the game and the tutorial level.

• Worked with the other designers to edit and refine the layout and design of both levels. 

• Worked on the menu designs and implementation into engine (including adding functionality for most buttons).

• Created placeholder SFX and music for the game and later implemented all SFX and music from the sound designers. 

• Conducted rigorous playtesting sessions throughout the project to find and report any bugs present.

• Reviewed, edited and implemented the tooltips and tutorial text.

• Created and conducted surveys and interviews for playtesting purposes. 

• Iterated on feedback given by teachers, peers and participants in testing. 

• Created the rolling credits menu animation.

• Creation and maintenance of the Asset lists and Trello boards for project management. 

• Setup the Itch.io page and YouTube channel for the team.

• Created the developer commentary video using clips and videos sent from team-members. 

• Acted as the scrum-master, ensuring that everyone had set tasks for the day and were aware of which facets of the project were the highest priority each morning during morning standup. 

• Programmed some of the less complicated scripts and edited some as well. 

• Created a script that played the intro music of the game and then looped a second track after that for the main menu.

• Sourced and added the text fonts to the game.

• Edited audio clips to increase and decrease volumes to be more appropriate levels.

​

Design Decisions

Now this is a section of the project I could talk all day about. To save you the hassle of reading all that though I will break this section down into the top 3 biggest design changes of the game. 

​

 

 

 

 

 

The Update Phase

The update phase in Foreign Body allows to player to update their actions after any given turn. This means that the commands they set on the planning stage cannot be changed but they can change where those commands are aimed. For example, if the player decided to move in the planning stage but wanted to change where they were going to move on the next turn, they could update this information during the update phase after each turn. This mechanic was added after some playtesting in the Alpha milestone as many playtesters became frustrated with the lack of control that they had when planning 3 moves ahead and having no way to change course. Implementing this mechanic drastically changed the strategies used to beat the game and satiated the players need for more control over their units. 

​

Fog of War and a Smaller Board

During Alpha we decided to create something called fog of war. Fog of war was originally going to cover the entire board, stopping the player from detecting exactly where enemies were until they came into range of the player's units. This mechanic made sense to use on the previously larger board however during Alpha it became apparent we needed to resize the board to be smaller as players were getting bored spending so much time traversing the large space and not enough time feeling like they were interacting with the resources and enemies. As the board shrank in size, the team decided that fog of war would not add that same effect and would become almost redundant very quickly due to players almost always being in close proximity to enemies. Fog of war would also directly hinder the player on a smaller board as they would not be able to plan ahead and feel confident in their plan due to never knowing what might be around the corner. This conflicted with one of our core gameplay pillars and so we decided it was best to remove the mechanic. 

​

AI Behaviour and the Goal of the Game

Originally the goal of the game was to reach the other side of the board to "escape into the bloodstream". We later revised this idea as playtesting quickly showed that it was very easy to b-line to the other side of the board, even when the enemy AI was trying to block you. We decided we would prefer a more aggressive playstyle that focused on wiping out the enemies and their commander instead to provoke a more strategic gameplay and more rewarding payoff. We changed the theme of the game to be set inside the lungs, and so the new idea was that the enemies were white blood cells trying to protect the body from the player, being harmful bacteria. We then added in a round counter to symbolise that after a certain amount of time has passed the body would deploy enough white blood cells to kill the bacteria if they did not succeed in taking out their commander first.

 

With this large goal change came a huge overhaul of enemy behaviour. We had to rethink the AI to be more aggressive and less defensive of a location. We decided to create multiple enemy types to ensure that AI did not all feel the same, however. Some of the types were the "Commander Defender" that would guard the enemy commander, the "Attack Unit" that would focus primarily on attacking player units and then once they were all destroyed, go for the commander unit. Then we had the "Commander Homer" which would make straight for the player commander and ignore player enemies. All of these variations of the enemies were left in the game but changed slightly in their exact behaviour along the way. To further add variation to the AI, I created a roster for the enemy commander to use that would impart special abilities such as tentacle and boosted metabolism to the newly spawned in units. The intention of all of this was to create variation of movement and attack patterns that the player could feel smart predicting and combatting. I believe this worked well in achieving this goal. 

​

What I learnt

This project taught me that it can be very difficult to maintain posts about the project while also trying to work on it. I attempted to make regular posts about the project, delving into the nitty gritty decisions made, however this quickly became irregular posts as the time needed to write them was often hard to find and prioritise over other project work. In future I need to take this into account as set specific times in which posts need to be made and I need to allocate a duration of time to work on these posts. 

​

I also learnt once again the immense value of playtesting. Without others to test and break our game we would never have found so many of the bugs that plagued it. I am immensely grateful that so many people were able to help us test our game as it was developed, and it was certainly a blessing that we stuck to making sure we had a build out as often as we could for people to test. This was likely one of the biggest factors in ensuring that our game functioned the way that it was supposed to. 

​

Something else I learnt this project was a few new skills with how to program some aspects of code for the game, the functions I learnt specifically pertained to menus and sound design mostly but were very useful and I made sure to record them for future use. 

​

Highlights and Lowlights

One of the highlights of the project was definitely planning how the AI would behave and in turn (with the help of playtesting) determining what actions players could take and would take in the moment. Additionally, playtesting the game myself and logging bug reports was a very rewarding task as finding the issues in the game and then collaborating with the other members of the team to fix them was very useful to the game and a true highlight of our teamwork.

 

A lowlight of the project would be that at the beginning of the project there was a disconnect of information between specifically the designers and the programmers, this was because the design of the game was being constantly overhauled each day by the designers as we tried to narrow down exactly what mechanics we wanted the game to have and how they would work. Due to this, the programmers were often not kept in the loop on a change-by-change basis which became frustrating for them as they were trying to prototype the mechanics of the game. This communication breakdown was quickly solved however as we became aware of the issue and came up with ways to communicate the changes to the programmers through the use of a flowchart diagram. This fixed a lot of our issues and at the same time as implementing this document we made sure to inform the programmers of any changes that were made immediately, these were also written down in the meeting notes document so that a copy of the information was always available immediately even if the GDD or flowchart diagram was in the process of being updated. 

​