Week 2 (18 April 2017): Team & Individual Reports

Team Report

Summarize your overall status for the week

As a team, we are looking good. We accomplished all of our week 2 goals originally proposed in our spec. We had two team meetings this session (one on Tuesday and one on Thursday) and both were extremely productive.

Group Morale

As a team, our morale is high. We are making steady progress and taking our time to design things right. We are getting all of the bare-bones infrastructure out of the way and are looking forward to focusing on the “cool stuff”

 

Individual Report

What were your concrete goals for the week?

Raj: I had two goals this week: help Brandon on networking and define an INI configuration parser.
Brandon: My primary goal was to create and complete a networking back-end. As a secondary goal, I wanted to help members of the team better understand git, GitHub, workflows, and C++. (read full individual report here)
Dylan: Linking up the projects, adding Drawable and Update interfaces / classes into Core.
Sylvia: To make a basic gaming architecture of classes.

What goals were you able to accomplish?

Raj: I completed the INI configuration parser. The implementation includes an extendable base class, so defining other parsers, if ever necessary, would require minimal code. (Explicitly, descendants must define the reading logic and a getter and setter that respectively handle `string` values.)
Brandon: I was able to complete the full networking-backend (minus performance optimizations, comments, and clean-up) as well as give lots of comments on team pull-requests.
Dylan: I was able to link the projects successfully, add basic Drawable and Update classes, but not implement that as fully as I would have liked. In my extra time at the end of the week I implemented a simple Octree.
Sylvia: I was able to create a basic, object-oriented structure that contains unit, planet, city and slot. I also designed the player class that has simple manipulation of objects.

If there were goals you were unable to meet, what were the reasons?

Raj: Having minimum networking knowledge and experience, I struggled this week to fruitfully assist Brandon in developing the `heliocentric` networking package, `SunNet`. Brandon knocked out the package like a champ!
Brandon: Of course, when a programmer says they “finished” something, it isn’t entirely true. I was unable to clean up my networking code or make it more performant. I am satisfied that I decided to prioritize completion over performance, however. I may come back to performance once we learn more about how the networking-layer interacts with our game.
Dylan: I was unable to fully complete my goals, and only finish basic versions because I was blocked on a couple PRs and also didn’t plan as effectively as I should have.
Sylvia: I realize that my lack of knowledge in fields such as networking prevented me from offering constructive feedback to my teammates. Also, designing an architecture can get incredibly complicated and confusing.

What are your specific goals for the next week?

Raj: I aim to set up the server-side communication logic using the `SunNet` package and assist in core game logic development and design.
Brandon: Much like Raj, I am hoping to help with the server-side communications logic as well as establishing the concept of a “game” (Set up a lobby, players join and exchange names and IDs). I’d also like to clean up and comment my networking code (lest I forget what I did).
Dylan: Finish up my incomplete classes from this past week, fully implement the client’s update handlers that use Brandon’s network code, finalize the Octree, implement unit selection and the orbital camera.
Sylvia: Add more complex implementation of classes, create destructors and link functions with server.

What did you learn this week, if anything (and did you expect to learn it)?

Raj: Through Brandon’s thorough walkthrough of the networking package design, I learned a bunch about the low-level, OS networking API and the challenges it presents.
Brandon: I learned a lot about C++ smart pointers and sockets. I also learned that everyone has their own ideas and it is important to discuss ideas, otherwise each member of the team would work on their “vision” of the game. But most importantly, I learned that team meetings need to stay focused in order to be productive.
Dylan: I learned quite a bit about spatial data structures and also about how to better work with the team moving forward.
Sylvia: Teammates are my teacher. Also, no design decision is permanent because there are always edge cases to be considered.

What is your individual morale?

Raj: Overall, my moral is high. Looking at the team’s progress this week, I’m more optimistic than last week that this game is doable. However, I’m looking to ramp up my contribution and carry more weight.
Brandon: My morale is high – we’ve made lots of progress this week and I think we ironed out a lot of our kinks. I think if we keep our pull requests small (favoring many small PRs instead of few large ones), my morale will stay high and we will be able to iterate so fast.
Dylan: My morale is very high at the moment. We are moving along smoothly, the group is communicating effectively, and everyone seems pretty enthusiastic!
Sylvia: Group meetings really pump me up as I see that other teammates are as enthusiastic about game and graphics as me (or even more). Therefore, my morale is very high.

 

Brandon’s Update

Dylan’s Update

Ethan’s Update

Jessica’s Update

Raj’s Update

Sylvia’s Update

Initial Project Specification

Project Description

What kind of game are you planning to build?

Space-themed 4X real-time strategy game

What are the goals of the game, how do players win, how do they lose?

Grow and mature your celestial empire, be that through economic, technological, or militaristic means. The game ends when any player meets any of the following victory conditions:

TECH VICTORY

If a player successfully researches everything in the science tree, they are able to build an intergalactic ship or structure, thus expanding even beyond the solar system, winning the game

ELIMINATION VICTORY (ASSUMING COMBAT)

If a player eliminates all other players, they win

EXPANSION VICTORY

If a player controls over a certain % of the celestial bodies (potentially based on mass), they win

ECONOMIC VICTORY

If a player manages to accumulate a certain amount of currency over the course of the game, they win

In this victory condition, spending currency might not reduce your total accumulated amount, but trading it away will

TIME VICTORY

If there’s a set time limit and no player meets any of the victory conditions above, whoever gets the highest score wins.

What are the interesting or unique aspects to your game?

Create special strategy by leveraging planetary orbits and other celestial properties in 3-D, for instance, movement in the z-axis. Further, collaborate and compete with other players in combat, trade, and random events that present opportunities for scarce resources, such as a resource-rich asteroid.

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 HAVES
      1. At least one static map to play on
      2. Basic orbiting for celestial bodies
      3. 4 player support
      4. Basic research system
      5. Ability to build structures and units
      6. Ability to move units
      7. Basic combat system
      8. Basic trading system
      9. Functional Camera System
      10. Functional UI
      11. Basic sound effects
      12. Unit stats such as speed, etc.
      13. Main Menu / Lobby System
      14. Enforcement of victory conditions
      15. At least 1 random event
      WOULD BE REALLY NICE
      1. Government and policy system
      2. Diplomacy system (allies or friends etc.)
      3. Gravity simulation to replace a static orbit system
      4. Ability to annex or trade cities
      5. Storyline / Background
      6. Additional Random events that influence gameplay
      7. Additional victory conditions (maybe wonders)
      8. Variable Game Settings (resource density, etc.)
      COOL, BUT ONLY IF AHEAD OF SCHEDULE
      1. Random map generator
      2. Chat
      3. Variable game speed
      4. Multiple factions with unique properties
      5. Extra Celestial Bodies
      6. Help/documentation menu
      7. Basic A.I.

Group Management

What are the major roles in your group’s management?

GIT REPOSITORY / GITHUB MANAGEMENT:
  1. Ensure stable branch is “stable”
  2. Ensure queue of PRs never get too large
WEEKLEY STATUS REPORT MANAGEMENT
  1. Ensure individual status reports are submitted
  2. Group status report compiled, submitted
“SCRUM LEADER” (AGILE!)
  1. Leads creation, assignment of weekly goals
  2. Reminds people to update cards, est. time of completion.

How will decisions be made? By leader, consensus?

Consensus.

How will you communicate? Email, meetings in the lab, discussion board?

Slack, in-person meetings.

How will you know when you’re off schedule, and how will you deal with schedule slips?

  1. Maintain a list of tasks/due dates on Trello.
  2. Schedule slips will be announced on Slack and tasks will be re-prioritized based on week’s end-goal.

Who will produce the weekly group status report?

We will rotate every week in the order listed below.

Project Development

What are the development roles and who will handle them?

  • Brandon
    1. Networking
    2. Website
  • Dylan
    1. Graphics
  • Ethan
    1. UI
    2. Algorithms
  • Jessica
    1. Graphics
    2. Website
  • Raj
    1. Network
    2. Sound
  • Sylvia
    1. Networking
    2. UI
    3. Art

What tools will you use?

  • Git (with GitHub for remotes)
  • Trello
  • Slack
  • OpenGL 4.0
  • C++

How will you do testing?

  1. User testing
  2. When writing code, each developer is in charge of their own tests.

How will you do documentation (both internal group documentation as well as external player documentation)?

  1. Internal group documentation done via comments. Other documentation generated by doxygen.
  2. At the end, we will write a small “user manual”.

Project Schedule

Define a set of milestones with a specific definition of what each milestone is, what it means to complete each milestone, and when you expect to complete them. Define the milestones at two scales, a high-level set of key milestones like integration and design freeze, and a low-level set of weekly milestones.

WEEK

(ends on Monday morning)

WE SHOULD HAVE DONE… STRETCH
1 Game concept, Project Spec, Game/Team name, Roles, establishment of Slack, Trello, Github repo Graphics foundation
2 Systems Architecture; loading models, rendering models with light, basic camera controls; server, client creation and reliable sending of bytes. Creation of a “working mode” static map
3 Initial classes for players, units, buildings, planets, resources; scene graph hierarchy mostly complete with orbiting, rotation, simple celestial movement animations and skybox; establishment and definition of network “ticks”, game “turns”, player “actions” HDR / Bloom
4 Robust scene graph implementation; complete camera controls; menu UI, lobby system where players join a common game; Ability to launch game from menu
5 Displaying unit and structure models and handling unit movement; planets have “city slots”, player can interact with them to establish a city, communicated across networks; player can create units and move them (communicated across networks).
6 Basic in game UI displayed; Finalize unit production, unit movement, city creation, city upgrades (all with player interaction and network support); Basic combat systems (And creation of types of military units), trade systems
7 Particle systems, surface effects on planets, basic combat animations / visuals; Finalize combat systems (for all existing types of units) and trade systems.
8 Finish combat visuals; Finish in game UI; Establish concept of winning, losing; establish victory conditions; implement “random event”; implement tech tree Add some sound
9 Worrying about animations and making things look less bad; Finalize sound (ambient sound prioritized); have every single member play the game 24/7
10 DEMO WEEK — Prepare for demo (keep playtesting, establish demo procedure)