Project Description
Type of game:
The game we’re making is an aliens vs humans tower defense and shooting multiplayer game. Players will be one of up to four battle spaceships protecting the planet UCSD's landmarks (Bearl, Sun God, King Triton, etc.) by flying around the planet and shooting down alien invaders. The game will test team coordination, shooting skills, and strategy in keeping UCSD safe.
The goal is to keep the overall planet’s hp (a sum of the hp of the various landmarks) from reaching zero for as long as possible. Battle ships can respawn infinitely many times, but once the enemy spaceships defeat the planet, it is game over. There’s no technical “win”, as this is a survival game, but a high score, e.g. a record number of seconds the planet was standing, can be considered a win.
Game mechanics:
The game is an infinite game, which means that you can keep playing it till you lose. The losing condition for the game is that the planet's health becomes 0. The health of the planet goes down as it is shot at by the enemies.
Unique/Intriguing aspects:
Our game will facilitate player cooperation toward a common goal--saving a planet containing priceless UCSD landmarks like Bearl. Players will be challenged to race to save each landmark under attack by enemy spaceships (maybe sent by from neighboring universities, who knows?), all the while battling limited periphery when navigating the planet. Pending stretch goals, players can vicariously experience the battlespace as different types of engineers each with a unique set of player capabilities (electrical, structural, chemical, computer science, computer engineering, and bioengineering).
List of features:
Must Have
- campus planet
- blue sphere with a green island per landmark
- landmarks on campus planet
- bearl(s)
- enemy spaceships
- target and shoot at campus landmarks
- player spaceships
- WASD controls to move to shoot at enemy spaceships
Would Be Really Nice
- campus planet
- clouds
- landmarks on campus planet
- sun god
- unique buffs or special effects are given to players per landmark
- enemy spaceships
- shoot at players in addition to the planet
- player spaceships
- roles among players in terms of health, mana, classes, and capabilities
Cool But Only If Ahead of Schedule
- campus planet
- wormholes to teleport to parts of the planet
- multiple planets
- landmarks on campus planet
- king triton, stonehenge
- enemy spaceships
- diverse enemy types in terms of health, capabilities, wave formation
Group Management
Major Roles
We don't plan on having any major group management roles (i.e. X is the leader). Individual groups will be responsible for updating their weekly tasks on the Github Project page. Democracy!
Decision Making
Small sub-team related decisions will be made at the discretion of that sub-team. Any major decisions (i.e. API changes, major tooling changes, gameplay decisions) will be discussed as a team and will be decided by simple majority consensus.
Communication
We will use messenger for urgent communication, as it is the medium that most members have notifications and alerts on. For non-urgent communication and updates, we will use discord. We will have daily stand-up updates in the “#stand-up” channel, in which each team member will post their completed tasks from the day before and their planned tasks for the day (these will be asynchronous). Team members are expected to check the discord at least once a day for important updates. We will have weekly sprint meetings, where we will discuss progress and goals for the upcoming week as a team. Google Drive will be used to store important team documents (i.e. project specifications, general documentation, useful resources).
Schedule Slips
We will know we are off schedule by comparing our current progress with our weekly milestones. When we notice the schedule slips, we will discuss solutions during the weekly sprint meeting. If we start slipping on the schedule, we may need to start cutting “nice-to-have” features.
Weekly Group Status Report
The weekly group status reports will be written by rotation, alphabetically by the first name. We have created a schedule to make it easy for members to know when their assigned week is. Individuals will be responsible for writing their own individual.
- Week 2: Alex
- Week 3: Carlos
- Week 4: Cora
- Week 5: Evan
- Week 6: Priyal
- Week 7: Alex
- Week 8: Carlos
- Week 9: Cora
- Week 10: Evan
Project Development
Development Roles:
Graphics Team:
- Evan Laufer
- Alexander Garza
Networking and Gameplay Team:
- Carlos Wirawan
- Priyal Suneja
- Alexander Garza
Art / 3D Modeling:
- Andrea Sudharta
- Cora Xing
Tools:
Our project will be developed in C++ utilizing various libraries for graphics, networking, and art. For our graphics engine, we will be utilizing OpenGL, Assimp, and GLM. On the networking side, we will be using C++'s default networking libraries. For our art and 3D models, our artist will be creating art primarily in Blender and the Adobe suite.
In addition to these specific tools, we will also be using Visual Studio for our programming environment, and Github Issues to keep track of our development tasks.
Testing:
During development, each group member will be in charge of writing their own asserts and logs to ensure the state of the game can be tracked to narrow down bugs. In addition to this, we will be writing unit tests for essential components of our game engine to be confident that during integration our code remains correct.
Separate from code testing, we will be performing a development freeze during week 6 to have the chance to focus on user testing of our MVP. From the information gathered through user testing, we aim to use the remaining weeks to polish and continue testing each iteration.
Documentation:
To keep our project documented, we will be using Doxygen. Doxygen allows each group member to be able to easily add comments to their own code which can be automatically generated into HTML for any member to read. External player documentation will be saved into our shared Google Drive accessible for everyone to view.
Project Schedule
The following is a projected plan of our weekly milestones. The bolded tasks are more high-level, long-term milestones.
| Week | Tasks |
|---|---|
| 0010 | basic rendering of obj files |
| echo server | |
| 50% basic models for objects made and concept art, including the planet, the towers, and the polygons for spaceship and enemies | |
| 0011 | WASD controls where the camera follows the player walking around on the planet |
| finish making basic models | |
| start working on full server/client | |
| 0100 | win/lose mechanics with 1 tower and 1 enemy |
| finish modeling planet | |
| finish full server/client | |
| more gameplay mechanics | |
| 0101 | finish modeling tower |
| graphics + networking client integration | |
| add gameplay to server | |
| scaling to multiple players & enemies | |
| 0110 | finish modeling spaceship and enemies + projectiles |
| development freeze | |
| testing | |
| 0111 | polish up 3d assets |
| sound effects | |
| 1000 - 1010 | play the game all the time (i.e. test) |
| find bugs & fix them | |
| more content generation and complicate gameplay |