Bob & Robob's Crazy Space Adventure
7 members
4 weeks
Unity
Concept
Bob & Robob's Crazy Space Adventure is a chaotic couch co-op spaceship defense game for 2 players. You and your friend play as:
-
Bob, the human engineer who can throw objects across rooms and over walls!
-
Robob, the robotic sidekick who can put out fires but requires a charged battery to operate at full capacity!
Bob & Robob are under attack by pirates who are trying to destroy their spaceship for scrap. They must work together to fend off the attack, craft the necessary ammunition to defend against the different incoming missiles, repair any damage the ship has taken, and charge their cannon to destroy the pirates!
Contribution
Game Design
Lead designer, core systems and game loop design, mechanics design, UI design
C# Scripting
Systems prototyping and implementation, UI scripting
VFX & Art
VFX creation and implementation, asset creation, level dressing, animations
Turrets and Ammo
Collecting ammo and ingredients, combining them together, and delivering the special ammo to the defense turrets makes up our core game loop. Successfully performing these tasks will prevent your ship from taking damage.
The type of ammo you need to craft corresponds to the type of enemy missile that is flying towards your ship. There are 4 different missiles that can impact your ship in different ways:
-
Normal Missile: Destroys 1 wall on impact
-
Green Missile: Destroys 2 walls on impact
-
Red Missile: Destroys 1 wall and starts 3 fires on impact
-
Blue Missile: Destroys 1 wall, drains Robob's battery, and partially drains the cannon's charge
Each ammo type is crafted by combining a specific ingredient + the basic ammo inside the crafting station located in the center of the ship. The basic ammo can be found at the back of the ship, and the different ingredients are located in different areas on the ship. Both defense turrets are located at the front of the ship.
Damage and Repair
When the players fail a task, a missile will impact the ship creating a breach in 1 of 4 places. While these breaches exist, the ship's oxygen level will drop until the breaches have been repaired with the repair tool.
Every so often, the enemy pirates will fire lasers at random pre-placed spots on your ship that will start fires. The fires act as walls that block player movement until extinguished. These play a major part in the disruptiveness of the core loop, and because they can only be extinguished by Robob, the players will have to communicate and cooperate to succeed.
The Repair Tool is an item that always exists on the ship and needs to be picked up and brought to breaches in the hull to be used. Players have to be wary of where they leave the tool after they're done with it as it will remain where they last placed it!
Symbiotic Design
We wanted our two characters to play differently and to need to rely on the other to succeed. We went though several ideas before deciding that:
-
Bob will be able to throw items, but is unable to put out fires that block the path.
-
Robob will be able to put out the fires, but needs Bob to replace his battery to function at full speed.
As crafting the ammo was such a central mechanic for our game, we ended up requiring both players to activate the crafting bench simultaneously to get the crafted item. This pulled both players to the center of the map very frequently to progress forward, creating a central point to balance around.
To strengthen our third game loop, both players are also required to fire the cannon to progress the difficulty and score multipliers. The buttons are located on opposite ends of the ship, providing a contrast to the central pull of the crafting bench. As an added incentive to defeat the enemies, firing the cannon also automatically completes both turret tasks.
UI and UX
I designed and created all the UI in the game and scripted the functionality for the main menu and game scene. I also worked on UX improvements to make the game more clear to the player.
When the player picks up the correct ammo type, the turret consoles will have a bright flashing outline with a moving arrow above them to make it clear where the player needs to bring the ammo.
Each of the items the players can grab are labeled with an icon, and each of the rooms are also color coded to increase clarity. Play testers were very happy with this addition when we added it.
The oxygen and the cannon charge meter are both very crucial to the game, so I thought it was important that it was big and centered on the top of the screen so that it is easy to see.
I added cinematic animations to the main menu to create a nice first impression when starting the game. I felt it added a lot to the experience, even if it was a little thing.
Scripting
I prototyped several systems that I designed to ensure they would fit the game before passing them over to our programmers for a full implementation. These systems included the hull damage system, the oxygen system, Robob's battery system, and the cannon system.
The oxygen manager handles how quickly the oxygen depletes, as the depletion is multiplied by the amount of breaches in the hull. It will also call the game over event if the oxygen level reaches zero.
It also contains a function that will shake the oxygen UI element as the level drops to give a sense of urgency to the players.
RobotInteractable is a script located on Robob that controls his battery level and reduces his movement speed if the level hits zero. It also allows Robob to be interacted with when holding a battery to be able to refill the battery level.
It also contains the ReduceBattery function that is called when the Blue Missile hits the ship.
VFX & Art
We had limited time and limited resources in terms of VFX and art, so I filled in when I had time to create a more polished and refined visual experience.
Documentation
I created this diagram to visually describe all the systems at work, showing how each of the game loops fit into place and work together. I also color coded each section to be able to clearly show which actions the player can take and how the game reacts to those actions. As the enemy is the driving force of the game systems, I also displayed what happens when each enemy event occurs.
I put together a game design document very early into the development process which acted as a point of clarity for all the team members for all parts of the game. This was a living document that changed each week as we re-evaluated our scope and features. Most of the information is already described above, but please look below if you are curious!
Please get in touch!
© 2023 by Seth Marrison. All Rights Reserved.