Project Specification

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.


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


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.


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.


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.

0010basic 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
0011WASD controls where the camera follows the player walking around on the planet
finish making basic models
start working on full server/client
0100win/lose mechanics with 1 tower and 1 enemy
finish modeling planet
finish full server/client
more gameplay mechanics
0101finish modeling tower
graphics + networking client integration
add gameplay to server
scaling to multiple players & enemies
0110finish modeling spaceship and enemies + projectiles
development freeze
0111polish up 3d assets
sound effects
1000 - 1010play the game all the time (i.e. test)
find bugs & fix them
more content generation and complicate gameplay