What kind of game are you planning to build?
Our game will be a variant of Capture the Flag, played on a map of islands. The map will have 4 predefined starting islands on the cardinal edges for the 4 players, and a “flag” object at the center (equidistant from the players). There will be powerups, weapons, and other interesting objects that generate on the islands, providing unique gameplay mechanics. Water will serve as a secondary “biome” that players can enter, but will move more slowly in (specifics pending).
What are the goals of the game, how do players win, how do they lose?
Each game will last 10 minutes/however much demo time is allotted. The goal of each round is to be holding the flag when the clock runs out. To incentivize players to take the flag rather than simply wait out the clock, holding the flag will confer time-based advantages; i.e the longer a player holds the flag, the more boosts to their weapons they will receive. We will make sure that the “flag boost” is substantial enough to incentivize going for the flag instead of waiting until the last second. Players will have melee and ranged weapons to attack other players or knock them off islands (Islands will be floating. Players will have a set amount of health, and will die if their health reaches zero. If a player holding the flag dies, the flag will be released at the death spot.
What are the interesting or unique aspects to your game?
There will be several mechanics of interest in this game:
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".
Must have:
Basic level generation, passable meshes, textures and shaders, countdown clock, player movement/jump logic, flag-holding benefits
Would be really nice:
Powerup system, lunar phase system, particle effects, high-quality meshes, textures, and shaders, water as a secondary biome
Cool but only if ahead of schedule:
Procedural level gen for replayability, 2v2 team mode, island theming w/ unique environments, attack/defense mechanism for weapons
What are the major roles in your group's management?
In terms of work, our group will have different teams responsible for different parts of the development. For now, we have teams for graphics/animation and systems/networks. We can create more specific teams for specific aspects of the project as needed such as physics, gameplay, controls, camera, etc. Each member can be part of multiple teams.
How will decisions be made? By leader, consensus?
Decisions will be made via a discussed consensus. Ideally, before agreeing on a major decision, instead of holding an immediate vote, everybody should be convinced as to the merit of a particular decision and find the decision acceptable. Any doubts should be brought up as soon as possible. In the event of a hard deadlock after ample discussion, we will randomly select a person to make a decision, so as not to cause delays in the development of the game.
How will you communicate and collaborate online?
Online collaboration will be done primarily via our own Discord server. Information related to the game will also be recorded on the game website and/or in documents on our Google Drive. Code comments and reviews on GitHub pull requests may also be used as an auxiliary method. We also plan on using a github project board to organize and keep track milestones, tasks & their priorities as well as status (completed, in progress, not started), deadlines, and assign tasks to group members.
How will you know when you're off schedule, and how will you deal with schedule slips?
We will know we are off schedule if our weekly report either does not meet the weekly schedule that we have set up on github projects, or does not fulfill the specific goals that we set for ourselves at the weekly meetings (and are recorded on github projects).
If this happens, we will first try to understand the reasons we have failed to keep up with the schedule. Based on our discussion, we may decide to assign more people to help work on the task we are falling behind on, redistribute some tasks if we find some took less/more time than anticipated, and if necessary cut features. We will make sure to update our milestones and schedule accordingly.
Who will produce the weekly group status reports?
Each sub-team, i.e. the systems/networks team and the graphics/animation/design team will compile a separate progress report. We will alternate between the members of the group to create a single document each week, combining the two reports and adding notes that apply to the entire group (mostly based on updates from the team meetings we had in the past week).
In addition, anybody who makes miscellaneous contributions will drop their progress in a designated section on our progress document.
When will you have your weekly group meetings (separate from the meeting with instructors)?
Possible times: Thursday Night, Friday Midday (12-4), Saturday Midday (12-4), Sunday Morning (10-12), Monday Evening (7pm after)
The list of times given are not times where everybody has to meet, but rather a set of times where we know that people are free, and can work together. Thus, these times act like open office/work hours for the game, to create as many opportunities for collaboration as possible.
Our designated all-team check in will take place on Mondays 9PM.
What are the development roles and who will handle them?
|
Graphics |
Networking |
Game Logic + Physics |
Art |
|
Sumukh Jose Elena |
Almog Steven Jungwoo |
Almog Sumukh Jose Steven |
Grace (everyone else, if needed) |
What tools will you use?
We will use C++ with OpenGL for graphics. While this is fairly standard, we believe it is sufficient for our needs.
How will you do testing?
How will you do documentation (both internal group documentation as well as external player documentation)?
Internal Documentation:
External Documentation:
Low Level Milestones
|
Week |
Art/Sound |
Graphics |
Networking |
Game Engine/Physics |
Game Logic |
|
2 |
Collect or design general multi-use models for the game |
Port over existing 169 code. |
Set up a basic TCP echo client/server |
Decide on whether to use a library or build from scratch |
Determine game logic flow from project specification |
|
3 |
Concept art for player and entities used in the game |
Asset importing, complete shadows if not complete in week 2 |
Define packet protocol structure for client/server communication |
Coordinates, positioning, movement, gravity, collision (bounding boxes), velocity |
Specify the required API methods that must be accessible through the game engine for implementing the game logic |
|
4 |
Design assets from concept art |
Integrate with network client |
Integrate with graphics client |
Object Management API, Event API |
|
|
5 |
Finalize art assets, visualize in the graphics client |
Animation + Particle system, shaders (i.e. water) |
Optimize protocol |
Map generation, player controls, NPC AI (?) |
Use Game Engine API to blueprint the gameplay, |
|
6 |
Define sound effects required for the game |
Animation + Particle system, continue shaders |
Spatial audio for sound effects |
||
|
7 |
Explore publicly available options online |
UI, complex animations |
Basic audio processing API from existing assets |
Incorporate sound effects | |
|
8 |
Finalize audio assets |
Polish Graphics |
Debugging |
Debugging |
|
|
9 |
Beta Testing |
Beta Testing |
Beta Testing |
Beta Testing |
Beta Testing |
|
10 |
Demo Final Product |
Demo Final Product |
Demo Final Product |
Demo Final Product |
Demo Final Product |
High Level Milestones