School House Scuffle
We worked this project towards the goal: Win the Business Professionals of America Software Engineering Team National Competition (BPA SET Competition).
...and we were successful!
...and we were successful!
The start: Project Requirements
We got the rubric and requirements on September 20th, 2012:
- BitBlit Interactive, a digital entertainment media publisher based in Austin, TX, has contracted your development team for a new interactive game project. Building on the success of their recent retro-inspired "Project Wayback" branding initiative, BitBlit wants to continue to capitalize on the surge of popularity in simple, 8-bit-style games by producing a turn-based strategy title. Your contract manager at BitBlit has referred you to Hero Academy (Robot Entertainment), Fire Emblem (Intelligent Systems), Civilization (Microprose/Firaxis Games), and Battle for Wesnoth (David White, et al.) as examples of successful titles in the genre.
- Project Wayback titles must display publishing and development credits upon startup, followed by a title screen. The publisher credit for BitBlit Interactivemust display first, followed by credit to your development team; be creative! The title screen should display the name of the game and present the player with options to begin playing, adjust options (if any), view instructions, or quit the application.
- Gameplay screens should consist of a scrolling world map built of tiled sprites or textures, atop which sprites for a player-controlled avatar, and both moveable and immovable environmental objects should be placed. The gameplay perspective should be “top-down,” wherein the player viewpoint is above the world looking down upon their avatar and the action that surrounds them.
- Project Wayback titles should feature original sounds for various actions such as selecting a menu option, attacking an enemy, receiving damage, or player death. These sounds can be as simple as square-wave beeps in various pitches, but BBI encourages developers to be inventive and inspired in coming up with unique and compelling audio effects.
- During gameplay, players should be able to access a menu screen. The contents of this menu should be contextual to the game your team creates, but at minimum the menu should allow the player to save the game (for loading and continuation of play later), exit to the title screen, and exit the application.
- Players should be able to interact with the world around them in meaningful ways, including conversing with peaceful NPCs and collecting items from the environment. Combat must be turn-based, with play controlled entities alternating in a sequential or interleaved manner with AI controlled entities in tactical or strategic combat. Such interaction should happen via a well-designed menu system.
- The gameplay user interface of the game should not only provide a player with a viewport into the game world, but it should also display vital information to the player. Data such as the amount of health or hit points remaining, items equipped, gold acquired, or lives remaining should be presented in a clear, useful manner. However, information overload is to be avoided. Only display information that is immediately useful and necessary for a user to play and enjoy the game with a minimum of confusion.
|
|
Project Plan
Purpose
The purpose of the project is to create a retro-inspired 8-bit turn based strategy game. The project is being sponsored by BlitBit Interactive, a digital entertainment media publisher based in Austin, TX. BlitBit is sponsoring the project as part of their retro-inspired “Project Wayback” branding initiative. A component of our game is the creation of the character, enemy, and weapon classes in order to keep track of items and units on the map.
Project Overview/Requirements
In order to meet most, if not all, the requirements, we will make sure we create classes such as character, enemy, weapon in order to keep track of items and units on the map. This is the basis of our game and needs to be one of the first things to be completed to produce a fully functional 8-bit strategy game. Creation of these classes will be aided through the production of a detailed UML Class diagram. Careful diagramming and organization of our code will help facilitate the creation of these classes. Graphics in 8 bit style are another one of the key things that must be completed. In addition, we would include original music to aid in the aesthetic elements of the game. Lastly, a data base would be created to store game saves, username, passwords, and high scores.
Team Organization
The people ensuring success will be Alan Chen, Daniel He, Isaac Chang, and Amanda Zhao. Their job titles are team leader, lead programmer, graphics designer, and documentation manager respectively. Over view of job responsibilities for each title:
Team Leader
Quality Management
Coordination between the graphics designer and the lead programmer will ensure cohesion between the necessary graphics and music elements with the code that utilizes such resources. This will help prevent glitches and other unanticipated mistakes in the game code. In the final production of the game, the visible images of the map, task bar, and the player view will be reviewed along with the appropriate sounds and background music by the entire team to ensure a variety of opinions to reach a consensus on the optimal state of the game.
It is essential to track changes in documentation and code in order to ensure we are keeping up with our deadlines and track the level of completion of various tasks assigned to team members. This will be achieved by dating all items in the code with the time at which they were completed in the commenting, which also aids in communication and allows other team members to stay up to date with the times at which various components of the game have been completed and when they should be completed. Also, changes will be communicated through email and through the creation of multiple updated drafts of items like timeline and title pages, where new changes will be detailed through comments and notes. All drafts will be stored in our project folder in our Google Documents drive where all versions (updated versions and drafts) will be stored and accessible in order to see changes.
Communications Management
Proper communications are essential to a functional team project. A project folder was created by our team leader where we can share all our team files, allowing all of us to edit our project work simultaneously. This project folder is accessible to all team members and contains separate sections where we can share code, game function descriptions, timeline drafts, and other essential documentation necessary for proper communication between our group members. Most of our team is also in the independent study computer science class, where they are able to confer and work on different aspects together in order to keep everyone on the same page, help each other complete tasks, and distribute duties completed by each team member. All team members frequently meet after school to work on documentation, coding, and other necessary items for the project, which allows every team member to stay up to date with changes in code and progress of the game. Team members also stay in contact with emails, meeting during classes, meeting afterschool to staying in contact. This ensures the smooth functioning of our team.
Detailed Functions
An accident occurred in the chemistry lab: Everyone in the school is evacuated except the player. The player is trapped inside. There are chemistry monsters everywhere; the player needs to get out as soon as possible.
The primary goal of the game is to get out of the school without dying. While in the process of getting out of the school, there are different tasks to do. First, the player needs to go to the electricity control center to turn on the lights in the whole school. Next then the player will need to find possible weapons as shown on the map to fight different chemistry monsters because they’re guarding paths to possible exits. Once the player successfully exits with a key without dying, the player has completed the game.
The game would begin with a dialog asking the user to login or to create new user. Each selection reflects what it says. Once the user has logged in with a username and password, the user will be brought to the title screen. In the title screen, the user has the choice of starting over, starting from last saved, controls/info/tutorial, high score, or logout. If the user pressed the “logout” button, he or she will be brought to the login screen again. If the user clicks the “high score” button, he or she would be brought to the list of people who have completed the game listed in the order of high scores. If the user clicks the “controls/info/tutorial” button, he or she would be brought to another screen with choices of looking at controls, info about the game, or tutorial. If the user clicks the “starting from last saved”, he or she would be brought to the position and the situation last time he or she played. If the user pressed the “start over” button, playing the game again, starting over.
Different objects and enemies are in the game. Most, if not all, enemies are chemistry monsters. They damage the player if the player touches the enemy or its weapons. Chemistry monsters’ weapons could be anything—flying particles, moving structures extended from the main body etc. Other than enemies, there are also weapons for the player to pick up along the way of his/her adventure—tennis rackets, staplers… etc. These weapons damage the chemistry monsters if the weapon touches the monster. There is also a key to open the front exit after you have beaten the “boss” of the game.
The player can lose health if an enemy successfully attacked the player. But the player can gain points (or score) if the player successfully defeated the enemy. Some areas of the map might be blocked off until the player’s score reaches a certain value or a certain task is performed. The player may only exit if all the tasks are performed. Each different area is considered a new level of the game.
A player is awarded points if the player successfully kills an enemy or if the player successfully completes a task. Points and tasks completed could lead you do new rooms and hallways.
Schoolhouse Scuffle has two or three different windows in the actual game play. One window is the map, where the player roams and has his or her adventure. The second window is a map for the player map—so the player can know exactly where he or she is in the actual map. The third window is the task bar—it shows all the tasks need to be completed before exiting.
The game is completed, if the player successfully gets out of the schoolhouse without losing all of his or her health. But the player will die and needs to start over if he or she loses all of his or her health. The game should be completed as fast as possible while obtaining as many points as possible.
The purpose of the project is to create a retro-inspired 8-bit turn based strategy game. The project is being sponsored by BlitBit Interactive, a digital entertainment media publisher based in Austin, TX. BlitBit is sponsoring the project as part of their retro-inspired “Project Wayback” branding initiative. A component of our game is the creation of the character, enemy, and weapon classes in order to keep track of items and units on the map.
Project Overview/Requirements
In order to meet most, if not all, the requirements, we will make sure we create classes such as character, enemy, weapon in order to keep track of items and units on the map. This is the basis of our game and needs to be one of the first things to be completed to produce a fully functional 8-bit strategy game. Creation of these classes will be aided through the production of a detailed UML Class diagram. Careful diagramming and organization of our code will help facilitate the creation of these classes. Graphics in 8 bit style are another one of the key things that must be completed. In addition, we would include original music to aid in the aesthetic elements of the game. Lastly, a data base would be created to store game saves, username, passwords, and high scores.
Team Organization
The people ensuring success will be Alan Chen, Daniel He, Isaac Chang, and Amanda Zhao. Their job titles are team leader, lead programmer, graphics designer, and documentation manager respectively. Over view of job responsibilities for each title:
Team Leader
- Organize meetings
- Delegate tasks
- Verify that program specifications are met
- Review the documentation
- Help the lead programmer
- Design the code for the game
- Maintain the game code
- Check for glitches in the program along with integrating graphics.
- Create the audio and graphic effects for the game
- Ensure quality of all aesthetic elements of the game.
- Review all presentation materials to ensure they are of the highest quality
- Create project diagrams, API documentation.
Quality Management
Coordination between the graphics designer and the lead programmer will ensure cohesion between the necessary graphics and music elements with the code that utilizes such resources. This will help prevent glitches and other unanticipated mistakes in the game code. In the final production of the game, the visible images of the map, task bar, and the player view will be reviewed along with the appropriate sounds and background music by the entire team to ensure a variety of opinions to reach a consensus on the optimal state of the game.
It is essential to track changes in documentation and code in order to ensure we are keeping up with our deadlines and track the level of completion of various tasks assigned to team members. This will be achieved by dating all items in the code with the time at which they were completed in the commenting, which also aids in communication and allows other team members to stay up to date with the times at which various components of the game have been completed and when they should be completed. Also, changes will be communicated through email and through the creation of multiple updated drafts of items like timeline and title pages, where new changes will be detailed through comments and notes. All drafts will be stored in our project folder in our Google Documents drive where all versions (updated versions and drafts) will be stored and accessible in order to see changes.
Communications Management
Proper communications are essential to a functional team project. A project folder was created by our team leader where we can share all our team files, allowing all of us to edit our project work simultaneously. This project folder is accessible to all team members and contains separate sections where we can share code, game function descriptions, timeline drafts, and other essential documentation necessary for proper communication between our group members. Most of our team is also in the independent study computer science class, where they are able to confer and work on different aspects together in order to keep everyone on the same page, help each other complete tasks, and distribute duties completed by each team member. All team members frequently meet after school to work on documentation, coding, and other necessary items for the project, which allows every team member to stay up to date with changes in code and progress of the game. Team members also stay in contact with emails, meeting during classes, meeting afterschool to staying in contact. This ensures the smooth functioning of our team.
Detailed Functions
An accident occurred in the chemistry lab: Everyone in the school is evacuated except the player. The player is trapped inside. There are chemistry monsters everywhere; the player needs to get out as soon as possible.
The primary goal of the game is to get out of the school without dying. While in the process of getting out of the school, there are different tasks to do. First, the player needs to go to the electricity control center to turn on the lights in the whole school. Next then the player will need to find possible weapons as shown on the map to fight different chemistry monsters because they’re guarding paths to possible exits. Once the player successfully exits with a key without dying, the player has completed the game.
The game would begin with a dialog asking the user to login or to create new user. Each selection reflects what it says. Once the user has logged in with a username and password, the user will be brought to the title screen. In the title screen, the user has the choice of starting over, starting from last saved, controls/info/tutorial, high score, or logout. If the user pressed the “logout” button, he or she will be brought to the login screen again. If the user clicks the “high score” button, he or she would be brought to the list of people who have completed the game listed in the order of high scores. If the user clicks the “controls/info/tutorial” button, he or she would be brought to another screen with choices of looking at controls, info about the game, or tutorial. If the user clicks the “starting from last saved”, he or she would be brought to the position and the situation last time he or she played. If the user pressed the “start over” button, playing the game again, starting over.
Different objects and enemies are in the game. Most, if not all, enemies are chemistry monsters. They damage the player if the player touches the enemy or its weapons. Chemistry monsters’ weapons could be anything—flying particles, moving structures extended from the main body etc. Other than enemies, there are also weapons for the player to pick up along the way of his/her adventure—tennis rackets, staplers… etc. These weapons damage the chemistry monsters if the weapon touches the monster. There is also a key to open the front exit after you have beaten the “boss” of the game.
The player can lose health if an enemy successfully attacked the player. But the player can gain points (or score) if the player successfully defeated the enemy. Some areas of the map might be blocked off until the player’s score reaches a certain value or a certain task is performed. The player may only exit if all the tasks are performed. Each different area is considered a new level of the game.
A player is awarded points if the player successfully kills an enemy or if the player successfully completes a task. Points and tasks completed could lead you do new rooms and hallways.
Schoolhouse Scuffle has two or three different windows in the actual game play. One window is the map, where the player roams and has his or her adventure. The second window is a map for the player map—so the player can know exactly where he or she is in the actual map. The third window is the task bar—it shows all the tasks need to be completed before exiting.
The game is completed, if the player successfully gets out of the schoolhouse without losing all of his or her health. But the player will die and needs to start over if he or she loses all of his or her health. The game should be completed as fast as possible while obtaining as many points as possible.
Project Timeline
As part of the project plan, we came up with a schedule of deadlines for major checkpoints for our project. This ensured that we use our time efficiently and that we are able to finish the entire project in time for submission.
Timeline for documentation:
Timeline for documentation:
Timeline for game:
System Life Cycle
Also as part of the project plan, we chose the water fall cycle because it closely fits the project we are required to do. It gave us the freedom to edit or modify any part of the cycle if there is a change in the requirement or design.
- System requirements—Name the components for building the system:
- hardware requirements
- software tools
- other necessary components.
- Examples include decisions on hardware, such as plug-in boards (number of channels, acquisition speed, and so on), and decisions on external pieces of software, such as databases or libraries.
- Software requirements—Establishes the expectations for software functionality and identifies which system requirements the software affects.
- Requirements analysis includes determining interaction needed with other applications and databases,
- performance requirements,
- user interface requirements.
- Architectural design—Determines the software framework of a system to meet the specified requirements.
- The design defines the major components and the interaction of those components, but the design does not define the structure of each component.
- Detailed design—Examines the software components defined in the architectural design stage and produce a specific design of what the project might, and will be. .
- Coding—Implements the detailed design specification.
- Testing—Determines whether the software meets the specified requirements and finds any errors that might be in the code.
- Maintenance—Addresses problems and enhancement requests after the software releases.
Storyboard
Based on the "detailed functions" in our project plan, we created a short story line for the game and sketched a storyboard. The story goes like this:
- There is a spill in the chemistry lab!
- Everyone evacuated the premise immediately (except you, because you're napping in the library).
- 20 minutes later...
- ...This is you.
- You wake up in the library. It is pitch dark and there're strange noises surrounding you.
- You have a map and a flashlight.
- You must first turn on the lights. You make your way to the electrical control panel.
- Since you turned on the light, you make your way towards the exit.
- You find a water-gun* along the way.
- You encounter chemistry slime monsters along the way.
- Once you made it to the exit, you find the exit door locked. (A cat then hints that a monster in the chemistry lab stole the key)
- In the chemistry lab, you find a hideous creature.
- You fight him with your water gun* and defeat him.
- You get the key from him.
- You successfully make your way to the exit and escape!
Data Flow Diagram
This should be self explanatory.
Art and Sprites
The first thing we drew is actually the title screen, and all the rest of the sprites are based on that. Here are some "rare, previously unreleased" versions of the title screen:
Notice how the final version of the title screen is almost the exact negative of the first colored version. The first colored version was actually meant to be the title screen for a while, but I discovered midway through the project that the negative actually gives the image "glowy" feel that I liked. This explains why all the slimes in the game are green, because they were meant to be that way originally. To make the game colors actually match the title screen, we made the final boss purple, and changed our "cat/mouse" to blue.
The next thing we did was the map! We chose to hand draw our entire map so we can put details in that we cannot hope to include using a code generated one like Coffee Wars. The map started out simple, but we added more details as we moved on:
The next thing we did was the map! We chose to hand draw our entire map so we can put details in that we cannot hope to include using a code generated one like Coffee Wars. The map started out simple, but we added more details as we moved on:
You may be wondering, if the map is hand-drawn, how did we make the sprites interact with the map? We had an easy solution: make the game tile based, and make a copy of the map using a 2D array. The way we send the 2D array data into the program is by a text file:
Main sprites from the game:
The player and the slime sprites have 8 different directions each. In addition, the player has 3 separate different sprites: one for holding a flashlight, another for a weapon, and finally one holding nothing.
Sprite palette coming soon
Sprite palette coming soon
Game Music
I wrote the game play music myself. The cues are originally for full orchestra, but switching it to 8-bit sounding instruments, I got it to fit fit the mood of an 8-bit game.
sound bytes coming soon
sound bytes coming soon
Coding the game
Coding went very smoothly because of all the preparation beforehand (everything you see above). I'd say the most interesting part to code was sprite collision with other sprites and with the map. Coding to spot a collision is an easy task especially when all the sprites are square and the same size; however, limiting their movement because of collisions became a rather complicated task...
For example: In the game, all enemies will chase the player through the path of least resistance (move towards the direction of the player...etc.), so if there're multiple enemies on screen at once around the same area, they'll almost certainly end up being exactly on top of each other when they comes near the player. This is especially problematic whenever there're large amount of enemies on screen, because they eventually end up looking like one sprite, but really there might be 10 on top of each other.
There is an incredibly easy fix to this: making the enemy movements random. The drawback to this is the enemies would become "less smart", since now they'll almost certainly just move and jiggle randomly on the screen.
I eventually coded collision between all the sprites, while keeping the chasing algorithm. This is not as easy to do, because you'd have to check for all possible combinations of each pair of sprites that might collide. Stopping when they collide is trivial, but for them to be able to get themselves unstuck after colliding is not so trivial anymore... Eventually I did get it working, by "cheating" (you'll see what I mean below). Anyway, here's an early screenshot of the game showing enemy collision in the early stages:
For example: In the game, all enemies will chase the player through the path of least resistance (move towards the direction of the player...etc.), so if there're multiple enemies on screen at once around the same area, they'll almost certainly end up being exactly on top of each other when they comes near the player. This is especially problematic whenever there're large amount of enemies on screen, because they eventually end up looking like one sprite, but really there might be 10 on top of each other.
There is an incredibly easy fix to this: making the enemy movements random. The drawback to this is the enemies would become "less smart", since now they'll almost certainly just move and jiggle randomly on the screen.
I eventually coded collision between all the sprites, while keeping the chasing algorithm. This is not as easy to do, because you'd have to check for all possible combinations of each pair of sprites that might collide. Stopping when they collide is trivial, but for them to be able to get themselves unstuck after colliding is not so trivial anymore... Eventually I did get it working, by "cheating" (you'll see what I mean below). Anyway, here's an early screenshot of the game showing enemy collision in the early stages:
By "cheating" I mean instead of checking collision between every single sprite, I only checked collisions between half of them at random. There're two advantages to this:
I won't spend too much time dedicated to how I coded this, I'm sure seeing the actual game in action is more interesting.
- Game becomes less predictable
- Sprites no longer become stuck on top of each other
I won't spend too much time dedicated to how I coded this, I'm sure seeing the actual game in action is more interesting.
Game Demo
Here is basically a watered-down version of our presentation for the game:
After the program passes through the login screen, it imports a JPEG file to create the main menu title screen. There’re a couple of options you can pick in the main menu. Play, Tutorial, High Score, and Logout. If a user clicks “logout”, then all the frame closes, and you’re asked if you want to login with another username.
|
If a user clicks Play, a dialog box would appear asking the user if he/she want to load previously saved games if saved data for the user exists. Once all the data is loaded, the game screen appears, as shown. The screen contains the game-play area (point), score, health bar, status/task bar, and a small guide map which shows you where your character is currently on the map.
Now let’s get into the actual game. Here is a list of tasks the player has to accomplish before completing and eventually winning the game. These tasks are given to you by friendly cat NPC when you come in contact with it.
Here we have the two attack modes. First we have the single shot, which is a long range, precise damaging attack. Now we have the spray attack, it’s a short range, but wider and less damaging attack. Both have their advantages and disadvantages.
- You must find the electric box and turn on the lights.
- You must find a weapon.
- You must learn a second attack.
- You must find the front door.
- You must kill the boss (who has the key).
- You must take the key and unlock the front door.
Here we have the two attack modes. First we have the single shot, which is a long range, precise damaging attack. Now we have the spray attack, it’s a short range, but wider and less damaging attack. Both have their advantages and disadvantages.
The enemies, mostly slimes, spawn randomly in a frequency around the player depending on the level; they follow the player around the screen, then shoot in the direction of the player, as long as they are within a 200 pixel area around the player.
The boss is found only in the chemistry lab, and he has the key. He has higher health and unrestricted movement. He can attack the player in addition to being able to reproduce slimes around him.
The boss is found only in the chemistry lab, and he has the key. He has higher health and unrestricted movement. He can attack the player in addition to being able to reproduce slimes around him.
Once you beat the boss and move to the front door, you’ve beaten the game. Once the game is beaten, I can enter my name and store my achievement in the high score list.
But if your health reaches zero and die along the way.....
Download to Play!
Google Drive Link: https://drive.google.com/open?id=0B8-c46xOqA9NczBId0tJYy0xeGs