Project Description
What kind of game are you planning to build?
We are planning to build a cooperative space simulator game. The game will involve up to 4 players piloting spacecraft in a semi-realistic zero gravity environment, and performing tasks to restore functionality to a mothership crashing towards a planet.
What are the goals of the game, how do players win, how do they lose?
The mothership has suffered an accident and is on a trajectory towards crashing into a planet. To save the ship, players must dispatch small support ships and perform various tasks, such as:
- Repairing mothership exterior hull and engines
- Gathering and refining fuel from nearby asteroids
- Salvaging equipment from nearby abandoned space stations
- Defending the mothership from asteroid impacts (and potentially enemies)
- Supporting your teammates by resupplying them and repairing when things go wrong
The bulk of the gameplay will be planning out tasks among teammates and navigating in space, whereas the tasks to perform would be relatively straightforward once players are in the right place.
The players win if they are able to complete all necessary tasks to restore the mothership within the time limit, and escape the planet.
The player loses when the timer runs out. There may or may not be penalties when players damage their individual ships, but it will not end the game.
What are the interesting or unique aspects to your game?
The game will feature a zero-gravity movement and physics system found in a few other space games (e.g. Kerbal Space Program, Space Engineers), while combining a cooperative aspect by making players divide their tasks, which makes the gameplay loop hard to learn but very satisfying to master.
The degree of realism (e.g. speed limits in space, fuel constraints) will be balanced according to development time and how accessible we want the game to be.
Initially, we will implement piloting controls similar to various other space games, where players control translational thrust and orientation via yaw, pitch, roll controls. Later we may implement some autopilot functionality to make learning the controls more accessible.
Beyond the novelty of the movement system, the game will test the players' teamwork to set up "supply chains" among the various points of interest in the surrounding space, and the ability to divide roles and adapt to changing conditions.
What are the list of features of your game? Prioritize them into at least three categories: "Must Have", "Would Be Really Nice", and "Cool But Only If Ahead Of Schedule".
(Note, only gameplay features are listed here currently)
- Must Have:
- Space physics and navigation system
- Asteroid and structure generation
- Very basic tasks (e.g. pick up fuel from a space station and deliver back home)
- Simple collision physics
- Win condition and timer
- Multiplayer support
- Would Be Really Nice:
- More complex tasks, e.g. repair interactions, fuel transfer
- Better collision and damage models, crashing does not immediately kill your ship
- Specialized ship roles (repair, logistics, exploration, etc)
- Cool But Only If Ahead Of Schedule
- Light combat mechanics to shoot down asteroids and potentially enemies
- Autopilot systems
- More game phases before victory (e.g. phase 1: fix critical damage on ship, phase 2: gather fuel, phase 3: start engines)
Group Management
What are the major roles in your group's management?
In terms of development, our group will be divided into teams responsible for different aspects of the game. Currently, our teams include: Graphics team, Artists team, Networking team, Systems & Engine Architecture team, and Game Design team. Each member can join any team depending on their preference and need for the development of the week; importantly, each team should have at least one member if that aspect of the game is being worked on during the week. Furthermore, more specific subteams can be formed as needed.
In terms of group management, we also would like to have extra roles to improve our development. This includes note-taker(s) during each week's meetings, and someone to contact the professor when the group has a question.
How will decisions be made? By leader, consensus?
Decisions will be made via consensus. More specifically, we will base our decisions via a discussion where a large majority of the group members must be present to hear all sides, and then each can vote, and the plurality will be the decision chosen. Said discussion will be used to make compromises and make sure all the members feel at least fine with all of the choices. Voting will be done via Discord polling tool.
How will you communicate and collaborate online?
- Discord (for communication and feedback gathering)
- Zoom (for online / hybrid meetings if needed)
- Google Drive and Docs (for internal documentation)
- Game Website (for formal documentation)
- Github Comments / Issues (for additional developmental communication, along with Discord)
How will you know when you're off schedule, and how will you deal with schedule slips?
We will know that we're off schedule if our end-of-the-week reports are significantly behind the project schedule detailed below, or the agreed-upon weekly goals set during the project meeting.
In this case, we will first discuss whether the delayed feature can be finished in just a couple of extra days. If so, and it's not yet the end of the quarter, the progress on it will be continued and the milestones will be updated accordingly. However, if not, we will discuss the possible alternatives or if it has to be cut if necessary. If the delayed feature is very crucial to the game, we will discuss if we can assign more people to help work on that feature whilst rebalancing the other teams workloads (and possibility of those other teams having contents be cut instead). In either case, we will adjust the schedule and milestone deadline plans accordingly.
Who will produce the weekly group status reports?
As of now, we are going to assign a week's status report to a singular group member. If needed, we can switch this to working on as a group and individually take a section. Later on, each sub-team will also make a report for what they work on during the week.
When will you have your weekly group meetings (separate from the meeting with instructors)?
Group meetings will be every Monday 2-3 PM, just before the meeting with the professor, so this time can also be used to collect questions for the professor.
Project Development
What are the development roles and who will handle them?
- Graphics
- Alex
- Artists
- Sofia
- Bernico
- Networking
- Bernico
- Nora
- Zoe
- Kane
- Systems & Engine Architecture
- Jacky
- Bernico
- Kane
- Game Design
- Jacky
- Nora
What tools will you use?
- C++ (Notably, no physics library since our game has unique zero-gravity physics)
- OpenGL
- Git
How will you do testing?
We will test our game using a combination of unit testing, scenario testing, user testing, and full gameplay testing to ensure technical correctness and overall user experience quality. Unit tests will be used to verify core systems such as physics, resource management, and game state logic. Scenario tests will simulate specific in-game situations, such as collecting fuel, docking the mothership, and completing repairs. Because this is multiplayer, we will conduct frequent playthroughs with multiple players to test synchronization and game flow. User tests with players outside of the development team will help evaluate clarity of objectives.
How will you do documentation (both internal group documentation as well as external player documentation)?
- Internal documentation:
- Shared google drive folder to organize documents
- README for project overview, setup, and build instructions
- External documentation (for players):
- Public README, included on the group webpage
Project Schedule
Low Level Milestones
| Week | Graphics | Artist | Networking | Systems & Engine Architecture | Game Design |
|---|---|---|---|---|---|
| 1 | Spec finished | Spec finished | Spec finished | Spec finished | Spec finished |
| 2 | After Tue: Write program that takes in list of objects (coordinate, face direction, path/to/model.something), player (coordinate, face direction, path/to/model.something) and outputs static render (Assuming this will be 3rd-person game) After Thu: Extend program to take in dynamic mouse input to look around After weekend: If client/server functionality is implemented, implement movement |
Finalize core game art direction Figure out art software (output file type) |
Basic server-client for arbitrary IP Address (have different machine be able to connect to the server) Integration with the graphics to do basic box movements Determine initial data to send between client and server |
Initial position, velocity, acceleration physics; movement Determine repository file structure |
Determine game theme |
| 3 | Object animation | UI Components | Define and implement the lists of client inputs and server reactions | Collision detection with the wall boundaries | Implement the basic core gameplay (the tasks to fix the mothership) Determine the game tasks |
| 4 | Ray tracing (depending on art direction) | An incredibly simple model for everything | Define additional client and server inputs-reactions if needed | Collision detection with asteroids | Implement the full core gameplay (start to end) Determine initial menu and how players join |
| 5 | Optimizations | 1/2 of all finalized models complete | Extension for the server to handle more than one player | Collision detection with other ships | Design teamwork goals |
| 6 | Help out with other tasks / more work | All finalized models complete | Optimizations | Physics for other tasks | Iterate on must have game tasks |
| 7 | Integrated game UI | Multiplayer testing | Must have mechanics | Design nice to have game tasks | |
| 8 | Sound effects | Nice to have mechanics | Polishing overall game design | ||
| 9 | Beta testing | Beta testing | Beta testing | Beta testing | Beta testing |
| 10 | Additional fixes, testing, and demo | Additional fixes, testing, and demo | Additional fixes, testing, and demo | Additional fixes, testing, and demo | Additional fixes, testing, and demo |
| Final | Report | Report | Report | Report | Report |
High Level Milestones
- week 1-2: basic client server integration (simple graphics and basic player input-echo functionality), finalize core game art direction, start modeling
- week 3: movement and physics, basic UI components, playable basic game
- week 4: key game art finished & integrated (mother ship, 4 player characters, basic environment), test game that complete with theme and functionality for one player
- week 5-6: extend client/server model to 4 players, (optional) more complicated graphics, vfx, environments
- week 7-8: nice-to-have (and up) mechanics / level development, multiplayer testing, debugging
- week 9-10 (polishing): (optional) add music, testing, debugging, get ready for demo