Doctor! We need YOUR help! Protect the body’s immune system from invaders by placing and upgrading towers to fight back against infection. Use your intuition and skill to race against the clock and protect the host. It’s up to YOU to save our patient… time is ticking…
Immune System Defense is a fun and engaging game for children aged 9-14 - accessible to beginners but also providing a challenge for those more experienced. Based upon the classic style of Tower-Defense games, it combines strategy and action with a link to the human body and some of its defence mechanisms. Players buy and place towers which attempt to attack, or slow down invaders. Make it to the end of the rounds without losing all your lives to win.
Click here to watch Immune System Defense: The Trailer.
- Team
- Immune System Defence
- Introduction
- Requirements
- Design
- Implementation
- Evaluation
- Process
- Kanban Board | Photo Album
- Conclusion
- Acknowledgements
[ Figure 1: Group 8 Photo ]
| Name | |
|---|---|
| Arielle Thijssen | cc20357@bristol.ac.uk |
| Julia Alvarado Rubio | if19426@bristol.ac.uk |
| Kai Chun Cheung | xz23031@bristol.ac.uk |
| Vincent Yaoyang Xu | uv23869@bristol.ac.uk |
| Alexander Robinson | xk23756@bristol.ac.uk |
Select the map and the difficulty!
|
Place them strategically to defeat the enemies!
|
| Explore the different towers and their properties! |
|---|
 |
Immune System Defense builds upon the classic style of Tower-Defense games, combining invader-germs with the quirks of the human body and its complex defence mechanisms that fight infection. As a team, we enjoyed exploring the parallels that could be drawn between the two and developed the game as a concept which is semi-educational, being somewhat informative about germ theory whilst remaining fun and fresh to the player.
Each environment (the brain, heart, lungs and kidney) features a different map and different environmental conditions. For example, within the heart the blood viscosity is varied from high to low as the game progresses, increasing the speed at which the viruses travel - making them much more difficult to kill. In the brain, the threat of an aneurysm leaves the player exposed to an explosive end to gameplay .
The player takes the opposing side: their goal is to kill the invaders before they make it to the end of their route (and therefore ‘enter’ into the rest of the body). By purchasing towers and placing them in optimal locations, a defensive map is built up. Provided with a limited amount of money (which only increases when enemies are killed), the player needs to form a strategy and optimise their approach for the best results.
[ Figure 5: Overview of map variants ]
Do they buy more towers for greater coverage of the map, upgrade existing ones for greater attributes, or save up to buy something even more powerful in the next round? From the winding pathways of the circulatory system to the confined spaces in the lungs - each scenario presents a different gameplay and as such requires strategic adaptation, becoming more and more of a challenge as the game progresses. Adapting to follow feedback during development, we feel the game is pitched at the right level for most of our target audience - winning is achievable with proper thought and consideration.
In the early stages of “Immune System Defense”, the group spent time researching what already exists (and playing a good number of different games). We became interested in developing a game with an educational concept - one that could be light-hearted, but still inform and help children develop understanding of important concepts.
As outlined in detail in our DesignOptions document, we created two proposals with a prototype of each game.
-
A Tower Defense game (in the style of Bloons ) where the player journeys through the Human Body and protects it from invading germs. Prototype 1
-
An Arcade side-scroller where the player travels through time from the dawn of humanity to the modern day. Prototype 2
[ Figure 6 - Protype 1 "Human Body Defense" ]
We took time to think about the direction we wanted to explore. Ultimately, after discussing our ideas and having our peers simulate ‘playing’ the paper-prototypes, we decided as a team to develop a tower defence game centred around the human body. The idea was further refined to align with our goals and the needs of our stakeholders, until we arrived at our final concept for ‘Immune System Defense’.
The educational objective of the game is to explain the overarching concepts of the Germ Theory of Disease.
By modelling infectious diseases as ‘germs’ who are independant life-forms that invade the body, we are teaching the notion that pathogens are agents of disease - and not going into too much detail so as to spoil the fun aspects of the game.
In crafting the early stages design for "Human Body Tower Defence," we utilised a comprehensive approach that incorporated use case diagrams and user stories to guide our ideation process.
User stories play a crucial role in the game development process. They act as a bridge between stakeholders' needs and the implementation of game features. In the context of our game, user stories helped us to develop with a wide range of stakeholders in mind. As we chose to develop our game for children aged 9-14, reminding ourselves to regularly think as though we were those stakeholders helped to inform our game design.
If the game is to be effective, it will need to be popular among school-age children. It will need to strike the right balance between educational, but boring and fun, but without the opportunity to learn.
Whilst exploring our prototype game, we asked a number of participants to think in the minds of their younger-selves and speak aloud their thoughts. Several useful comments have helped shape the functionality of the game, changing our approach.
As the developer, I want to make an educational game that is popular among students, so that my game could have more exposure to the younger generation and I could earn more reputation in game industry.
As the player, I want to play a tower defence game with another user, so that I can have a competition with my friends and have some fun.
As the investor, I want to invest in the game development industry by developing an innovative game to attract more players, so that I can start earning money from that game.
As the teachers, I want to influence my students to play an educational game, so that the student can learn more about the effect of germs on different organ on a human,
As the project manager, I want to ensure the game developed is meeting all the requirements, so that the project can be successful.
Many of these stories are interconnected. The developer's goal of creating an educational game aligns with the teacher's objective of influencing students to engage with educational content, while the investor's desire for innovative gameplay ties into the player's interest in competitive multiplayer experiences.
[ Figure 7 - An example Use-case Diagram created at the start of development ]
Use-case diagrams provide a visual framework for understanding the player's journey through the game. In Figure 7, the gameplay sequence begins with the player starting the game and selecting a map, a choice which will alter many features of the game-play (e.g. environmental conditions, type of enemy and general look and feel). Four different maps are available to choose: journeys through the brain, lungs, heart, and kidneys. These parts of the human body are not only crucial for our functioning but also offer various aspects that we could include in our game, such as depicting smoke emanating from the lungs. Read about this Use-case in more depth.
Each level progresses dynamically as the system generates new challenges, with enemies spawning and traversing the screen. The player strategically places defensive units to attack the enemy, with the objective of maximising damage with minimal expenditure.
[ Figure 8 - A use-case diagram showing UML with include and extend relationships ]
Throughout this process, the system presents options for tower types and locations, guided by the player's decisions and resource management mechanics. This iterative cycle continues until the level's objectives are met or the player's lives are expended. These user interactions and system responses (Figure 8) are essential in understanding the flow of gameplay and ensuring that the game development aligns with stakeholder objectives and user expectations.
System architecture describes how we use our software to achieve our goal of a playable game. In this section we discuss the underlying base code of our game and provide detail on several important classes and methods, along with their specific uses.
Our design process was primarily collaborative. Through discussion, we created an initial class diagram on paper, which then took over a near-by whiteboard. It was useful to talk though this process as a team - creating a visual representation of these elements, and discussing/debating how relationships, attributes, and behaviours should be interrelated.
[ Figure 9 : Initial class diagram. Developing our game structure collaboratively ]
The class diagram in Figure 9 outlines the key classes and entities required in “Immune System Defense”, including Towers, Enemies, and Maps, among others. Each class encapsulated specific functionalities and attributes crucial for their respective roles within the game.
For instance, the Towers class served as a base class from which different tower types were inherited. These tower types, such as Tower A or Tower B, inherited common functionalities while introducing unique characteristics. Attributes of the Towers class included cost, damage, projectile type, and attack range, defining their behaviour and effectiveness in combat.
Similarly, the Enemies class encompassed various enemy types, each with distinct behaviours and attributes tailored to challenge players in different scenarios. For example, enemies in the Heart level exhibit varying speeds to simulate blood flow, with enemies travelling faster through thinner blood as the body becomes weaker - providing an additional challenge as players progress.
Additionally, our class diagram accounted for the dynamic nature of game environments by including Maps as a fundamental component. Maps encapsulated terrain features, obstacles, and environmental effects that influenced gameplay dynamics and strategic decisions. For instance, in the Lung level, a unique twist was introduced where the screen gradually darkened to simulate the invasion of fog into the lungs, adding an extra layer of challenge and immersion for players.
Upon starting the coding part of a game, we also developed a comunication diagram that would help us visualize the interactions between objects and the different classes we may could want to develop later on. By mapping these interactions, we were able to understand what type of actions each element, such as towers and enemies, needed.
Important classes and methods
GameMap class
GameMap initialises and provides the ‘map’, the specific path on which the sprites will travel.
Round class with RunningGame class
These govern the ‘running’ of the specific level and the overall game. Between the two, a number of instance-specific variables govern how the round will run. RunningGame sits above Round, which combined with Round, keeps track of the user’s success (and failure) through the entire process.
in MapSelection, handleMapSelection (PImage mapImage, int x, int y, int outlineSize, GameState state, GameMap map){ …
This command illustrates how the program passes information back and forth between classes. GameState and GameMap are enumerated types, passing just the information of what "type" the selection is, not the entire data.
Heart, Lung, Kidney... class extends GameMap.
Specifics for each map are contained within child classes of GameMap. This avoids any kind of ‘config’ file that would be separate to the program. All initial game-state data is saved within Processing classes.
Germ class with GermSprite class
This is the parent class for all instances of pathogen invader. Its constructor method is the superclass called when they are instantiated. GermSprite contains the image-handling logic for displaying the correct picture and its orientation for each instance.
Cell class
With attribute ‘isPath’ and ‘buildable’. The cells divide the playable screen into a grid - which the user can select to place towers on. Its constructor method assigns it cartesian coordinates (x,y).
DefenceTower abstract class
The parent class for all of the towers. This provides the underlying functionality that can be extended for the specific cases.
TowerA extends ShootingTower
Here is an example of how inheritance of classes has helped the flexibility of the program.
protected TowerA(int x, int y, int sprite){
super(x, y, sprite, "Basic Antibody", 0);
// Array to hold the properties of an instance of TowerA, throught it's upgrade stages:
this.properties = new int[][] {{ 75, 125, 200, 450 }, // Cost from intial to Upgrade 3
{ 0, 0, 0, 2 }, // Projectile type
{ 2, 2, 5, 7 }, // Damage Capability
{ 1, 1, 1, 3 }, // Shots fired per second
{ 2, 3, 3, 3 } // Range
};
assignIntialProperties();
}
A generic tower DefenceTower is extended to form different objects for the user to place. One of these ‘ShootingTower’ emits projectiles which are aimed towards the enemies. Each projectile is a seperate instance of the Projectile class.
Class Projectile {
float posX;
float posY;
int speed;
PImage image;
int damageCapability;
Germ target;
boolean onScreen = true;
boolean targetAlive = true;
...
Some modelling is required for the projectile motion - both the sprite it is targeting and the projectile are moving - so their collision needs to be realistic, timely and accurate if it is to positively affect the game play.
In Heart class, method decreaseBloodViscosity() is a good example of how using inherited classes for each of the levels allows specific physical properties to be substantially altered without disrupting the normal function of the parent class. There are similar adaptations across the other levels.
Assets have come from a wide variety of places - some are retrieved from internet searches, others created by the team.
Developing the logic of "Human Body Tower Defence" presented several challenges, particularly in integrating the rules of tower defense games with educational elements related to human anatomy and defense mechanisms.
Once we had an idea, we started developing the game. We were encouraged to use Processing, which is a very good tool for designing a visual program where coders can develop things that would appear on screen. However, Processing uses a version of the Java language, something we were not that familiar when we started with this project.
One of the primary hurdles was making ourselves comfortable with the Processing environment and its unique syntax. Transitioning to a new programming language and development environment required adapting our coding style and acquiring familiarity with Processing's syntax conventions. This involved grasping concepts such as defining classes, manipulating variables and functions, and discovering and using built-in libraries for graphical rendering and user interaction, all while simultaneously learning Java from scratch.
Furthermore, integrating complex functionalities like button animation, screen transitions, and dynamic element rendering introduced additional challenges. Despite these obstacles, we navigated the learning curve and very often revisited our previous code to make changes.
One of the first challenges we were presented with was deciding what parts of the human body presented enough interesting aspects that we could incorporate into our game later on as twists. For example, by incorporating the lung map we realised we could develop a teaching element about the concerns of smoking. We thought that the twist could be that the screen would be filled with smoke, making it harder to see the maps and the germs coming in.
Besides implementing twists, we also had to consider which organs had suitable environmental conditions we could enhance in our maps to maintain the user's interest. Another example concerns the viscosity of blood, which we could adjust by slowing down the movement of germs.
After a day or so of thinking and each of us developing ideas; we ended up reuniting and choosing which four core organs would be interesting to implement and have an organ-related twist. These four were the heart; with a blood clot, the brain; with a brain stroke, the kidneys; with the kidney stone, and the lungs, with smoke filling up the lungs.
One of the challenges we encountered was developing the collision detection system. We aimed for it to simulate reality, rather than merely having static towers firing projectiles in a predetermined direction. Our development team then were faced with the task of enabling towers to track the direction of germs, thereby adjusting the firing direction of the towers accordingly. The solution we arrived at involved assigning each tower a specific range. Upon detecting nearby germs, the tower adjusts its firing direction to intersect with the approaching enemy, thus implementing collision detection effectively.
Moreover, designing different types of enemies was another challenging task to think about. We aimed to avoid repetitive enemy encounters throughout the game, as we believed it would lessen player engagement. We thought about a variety of enemy characters, each requiring distinct towers for defeat. In our design approach, we aimed to offer players a wide range of enemies throughout their gaming experience. This not only kept the gameplay fresh but also encouraged players to use their money wisely and strategize continuously so they could defeat the strongest enemies.
Another important aspect of our game was the visual and auditory elements of it. We recognized the critical role these elements play in immersing players in the gaming experience. With the goal of designing a visually aesthetic and captivating map, we spent considerable time designing organ maps and their corresponding paths for the germs, programming the placement parameters for towers (and making sure it was clear and easy to understand), and designing map-specific introduction and tutorial screens to guide players through the game mechanics. Furthermore, as the game progressed in development, we decided to add auditory elements to enrich the player’s experience. We strategically incorporated sound effects to evoke feelings of achievement, such as the sound of a germ being defeated or the satisfying ring when purchasing a tower. These auditory cues were instrumental in heightening player engagement and cultivating a sense of accomplishment throughout the game.
The ‘think aloud’ test was great in that users were not restrained in answering only what we wanted to ask them. Initial plans for the game included an idea for multiplayer - where perhaps one player fought for, and another against, the body. However, when presenting this idea to testers during their gameplay, it became clear that this was unnecessary and could even reduce their enjoyment. Our participants made it clear to us that they would prefer to see more developed levels with complex challenges than a multiplayer concept.
Through these discussions, we recorded observations including:
- “Why can’t towers be used to block germs by placing on their path?”
- “This is really fun!”
- On some occasions, button presses are not always registered - or register with one aspect of the game and not the other (e.g. taking money to buy a tower, but not producing one to place on the board). Users get very frustrated when this happens.
- After selecting difficulty, the game progresses straight into gameplay. A buffer would be preferred.
- Some participants didn't realise that they needed to press 'BUY' before they could place a tower.
[ Figure 13: One of our participants completing a Think Aloud Evaluation ]
Click here to see a summary of the output from our Heuristic Evaluation.
The Qualitative Evaluations provided a number of easily-identifiable fixes that we explored as a team before attempting to tackle. We found it really interesting as a number of comments came up across the board that we hadn’t considered.
As a response to qualitative evaluations, we:
- Added the JavaFX library -> to make the gameplay smoother and less glitch-y
- Added holding screens before each level -> providing more context to the game the user is about to play.
- Enabled placing and upgrading towers during gameplay -> to reduce the amount of time the user is waiting.
- Updated tutorial page -> explicitly telling users that they need to press BUY every time they purchase a tower.
We found, generally, that users are happy to wait for an action in game, when they know that something is happening in the background - but become very frustrated when it is not clear how long they need to wait - optimising the visibility of system status was an important outcome from this process.
Whilst conducting quantitative evaluations, we used a Microsoft Form to capture information digitally - enabling participant scores to be automatically collated.
[ Figure 14: SUS test undertaken on two game modes. ]
We undertook a Wilcoxon signed-rank test on the SUS data, showing clear significance. Click here to see the raw data.
For a set of 10 participants, a W test statistic of 3 was calculated. Using the chart of known values, this shows that a significance level of 0.01 was achieved, or 99% certainty that there is a real difference between the ‘easy’ and ‘hard’ selections.
This is helpful to us to see that there is a clear difference between the two modes - when looking at the mean of the values (Easy: 66.75, Hard: 78.6), we can see the jump between the two, but are provided with no statistical information about how reliable the data is.
Development of the game was largely informed by testing. As the basic structure of the game came together quite rapidly, it was playable from an early stage and therefore could be tested even throughout the beginning stages.
We undertook two forms of testing:
- Player-led, where the game model is tested until normal (and some unusual) game play causes a terminal error message, or unexpected outcome.
- Developer-led, where white- and black-box testing is undertaken to confirm that functions behave as expected and exceptions/ errors are avoided throughout.
- This involved creating a number of ‘partitions’ where we varied input data to floor/ceiling values and checked for erroneous responses.
We used a plugin to run Processing within the IDE IntelliJ, in order to create J-Unit tests which we were able to use in testing the robustness of our code. As issues emerged, the codebase was updated and refined - we have managed to avoid any serious issues and now only minor bugs remain that we have rebranded as ‘features’.
A number of our testers have told us they want to keep playing and have pulled the software from the repo themselves to play in their own time. We are pleased with the reception our game has had from testers as the responses have been overwhelmingly positive. The feedback that we have received has helped clear up a few areas and added value to the program.
The process to develop the game was fairly intuitive. At the outset, all members of the group came together to brainstorm and think carefully about our ideas. We discussed a whole range of project ideas that the team welcomed and encouraged. Working with interested and passionate people was great - the project was propelled along as exciting ideas were discussed and then attempts were made to implement quickly after.
Whilst roles were not initially formally assigned, they developed as we all followed a path-of-least-resistance. Kai Chun got the group up and running with an underlying structure for the base-code. Once this had been established, Arielle and Vincent joined him in developing the code structure and creating the start of a working prototype. Julia and Alex took on roles as researchers and in creating documentation. Julia added start pages and audio to the game, as well as editing and finalizing the tutorial page, Alex developed the video portion and both developed the overall report.
[ Figure 15: Developing our KanBan board in the lab. ]
As a structure, this worked well although the work-load was not always even distributed. It was found that once one person had started working on the code development, it was difficult to share this out without creating more complexities than were required. We found that these clearly delineated roles worked out best and allowed us each to take an element of the project as our own.
If repeating this project with the knowledge that we now have, it might be wise to establish right from the beginning these roles - rather than from a few weeks in. Now that we have the understanding of each others’ talents and abilities, processes could be better run concurrently.
The kanban board (Figure 16) was useful. It was great for establishing the initial ideas and concepts of the game. However, our development process meant that new ideas were often thought up and developed in a single motion - meaning that on occasion, a proposal was made and coded without being added to the board. If it wasn’t possible to develop into a neat solution, this addition was discarded. Additional items on the kanban board could have been useful here, but for our development process this wasn’t the case. If undertaken again, with better understanding of the Processing/Java development process, greater optimisation could be achieved using the board to its full potential.
[ Figure 16: Our KanBan board in March, during the development process. ]
In our project development, we primarily utilized Processing as our coding platform, which provided robust tools for visual rendering and interaction design. However, we encountered challenges with Processing, particularly in the initial weeks of our project, as we familiarized ourselves with its syntax, libraries, and debugging processes. Nonetheless, as we gained proficiency, Processing became indispensable for implementing game mechanics and visual elements. For visual design, Adobe Photoshop served as our main tool, offering a versatile platform for creating characters, environments, and user interface elements with precision and detail. We sourced audio resources from royalty-free websites to enhance the immersive experience of the game, selecting sound effects.
Through an iterative development process, we continuously refined and optimised our code, visual assets, and audio elements based on feedback and testing results. Detailed documentation of coding practices, visual design guidelines, and audio specifications ensured consistency and facilitated knowledge sharing among team members.
Initially, we decided on meetings a couple of times a week during the early stages of our project. As our project progressed, we continued to meet regularly as a team, even further into the later stages of development. However, we also found that we maintained high levels of productivity when working independently at times. This approach allowed us to accommodate everyone's unique schedules and preferences while ensuring progress on the project. Our team's adeptness at balancing collaborative meetings with individual work sessions relied heavily on our exceptional communication skills.
Overall, our balanced blend of collaborative meetings and individual work sessions, supported by strong communication, contributed to the success and efficiency of our project development process.
| Name | Contribution Weighting |
|---|---|
| Arielle Thijssen | 1.0 |
| Julia Alvarado Rubio | 1.0 |
| Kai Chun Cheung | 1.0 |
| Vincent Yaoyang Xu | 1.0 |
| Alexander Robinson | 1.0 |
In reflecting on the entirety of our project, "Immune System Defense," we definitely feel proud of achieving something that we initially thought would be unattainable. When we were first presented with the task of developing a game, we all thought we were going to really struggle not only in developing the coding mechanics of it, but also in coming up with an idea that even we would like to play in our free time.
Furthermore, delving into the theory behind agile project development enabled us to simulate a real-life scenario we may encounter in the near future: collaborative teamwork. This practical experience added depth to our learning journey and made us see first-hand how software developers work day to day.
We acknowledge that we were fortunate enough that our team got along well from the very beginning, and that gave us a big advantage. We were easygoing and open to knowing each other’s ideas and suggestions. A comfortable environment and workspace undoubtedly contributed to making the entire process more enjoyable and fulfilling.
As we progressed, we encountered adjustments in our game structure, as some initial ideas proved to be overly ambitious given our time constraints. This realization prompted us to adopt a more realistic approach to scheduling and game development, highlighting an area for improvement in future projects.
The challenges we were presented with - learning new software, the development process of our game - offered valuable insights into our growth and development as a team. If additional time and resources were available for further game development, we would like to implement a multiplayer mode. This would allow players to collaborate or compete with each other in defending the human body against invading germs. We would also be interested in developing a mobile version of the game, so that more people would be able to play where and when they wanted to.