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.
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:
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.
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.
(Note, only gameplay features are listed here currently)
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.
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.
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.
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.
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.
| 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 |