Posted on

Ethan’s Update: Week 2

1) What were your concrete goals for the week?

My goal was to implement classes for basic in-game objects, including different types of units, and base classes for them. I also proposed to add a utility class where we can put all shared utility functions such as debug logging. Aside from those I planned to keep working on game design, which I started from week 1, and help with building networking infrastructure.

2) What goals were you able to accomplish?

Sylvia and I designed and implemented a hierarchy for all game objects, and I finished the implementation for a base Unit class as well as a sample concrete unit class derived from base Unit class that represents an in-game unit. I also added a Lib class that contains two basic utility functions useful for all projects.

In terms of game design, I decided to put that on hold after some detailed discussion about combat system, as we have the basic game design drafted already, and the detail of all game design aspects won’t matter until we finish the baseline for the game.

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

I didn’t manage to help with basic networking infrastructure because implementing classes took longer than I expected.

4) What are your specific goals for the next week?

My goal for next week is to keep working on debug logger and other utility functions, while start to help with finishing networking layer, and start building the server.

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

Not much that I learned programming-wise, but I did learn how to use Pull Request on Github, which I pretty much have never used before. It turns out to be really useful for code reviewing and communication throughout a group development process.

6) What is your individual morale (which might be different from the
overall group morale)?

My morale is pretty high. I’m very excited about this game. All our teammates worked very hard in the past week as well, and we are sticking to our plan at the moment.

Posted on

Sylvia’s Update Week 2 (4/17/2017)

 What I Planned

For this week, my main goal is to get an overall idea of the main components that structure a multi-player game and find my position within the team. I quickly invested my interest in creating the main architecture. Our plan is to design a class structure that is object-oriented and capture the basic functionalities for things like units, cities, planets, and so on. We also want to make a separate class for player that handle gamer activities, such as claiming slots on planets and establishing cities.

What I Have Accomplished

Ethan and I formed a team of two on the task of architecture implementation. It includes an abstract class called GameObject that serves as the base for other derived classes. The four main classes are units, planets, cities and slots (I wrote the latter three as well as the superclass). Furthermore, we decide to extend units and cities from another class called Attackable, based on their similar qualities such as attack, armor and health.

For the player class, I decide to maintain all owned assets by making a vector that stores GameObjects. A lot of decisions were made to ensure that our design is as polymorphic and object-oriented as possible.

I wrote some test cases for the basic functionalities of all the classes. By creating pull requests, I was able to get some concrete feedback from my teammates on how to write code more efficiently and cautiously. I also learnt to maintain good coding style and to push frequently so that everyone is closely updated.

The Unexpected Factors

Originally, I planned to work on whatever the team is lacking the most on. However, I quickly came to the realization that networking is an unknown topic for me, and thus I could hardly offer help on the subject. When I read someone else’s pull requests, it was hard for me to offer constructive and useful feedback because I don’t immediately see catastrophic drawbacks. From reading other people’s comments on my code, I realize that suggestions can be subtle and purely for the reason of efficiency. Therefore, in the following weeks, I’d like to try harder to offer my opinions on pull requests and be up-to-date with the team’s codes overall.

On the other hand, designing an object-oriented class architecture can get very complicated. I quickly realize that many design decisions were yet to be made for functions that involve multiple class objects. I wasn’t able to make any destrcutor or consider memory leak issues.

For the Future…

We still yet to discuss our new team goal during the next weekly meeting. However, I envisioned some as below:

  1. Think about the complication of a chain reaction, how are other objects affected during a player’s action? This will require more complex architecture that keeps track of a series of objects, as well as linking object fields with one another.
  2. Write destructors for classes, which is what I’m afraid of the most (memory leaks). In order to better manage the memory, I must de-allocate objects properly and in order.
  3. Add other neccessary derived classes for individual units, such as a spaceship, trading cargos, and so on.
  4. Consider how the server process data and readjust the class functions as appropriate.

What I Gained

I’ve learnt that my teammates are also my teachers. During the past week, I received a lot of surprising and useful feedback from every member on the team, because each of them specializes in a different area. Interacting with team members during the meeting was also fun, because everyone has their own input and inspire the rest.

In terms of coding, I realize that designing any architecture starts out easy but can get incredibly complicated and confusing. It is also good to discuss with teammates before any sort of implementation, because all components will eventually be linked. None of the designs is permanent, because there will always be edge cases that have not been considered and require further revision of the structure. By writing test cases and scenarios for players, I was able to find loopholes in my architecture.

How I Felt

I am very happy with our team’s progress in the first week and also the results (in the form of pull requests) even though it has not been visualized much yet. It is always exciting to imagine when the architecture fully works with the graphics and networking (putting aside all potential errors that could occur). Team meetings pump me up when I know that there are people out there who are as passionate about games and graphics as me (or even more!). This factor really drives me to work as hard as I can. It is also satisfying to know that your teammates can back you up when you run into serious implementation issues. I hope to keep this enthusiasm up during the following seven weeks.

Posted on

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

Posted on

Dylan’s Update: Week 2 (18 April 2017)

1) What were your concrete goals for the week?

My concrete goals for this week were to add some abstract classes to the Core library that was being developed that the Client would make use of to render as the server sent updates, and also to set up the groundwork for handling network updates.

2) What goals were you able to accomplish?

I set up a lot of basic classes with half implementations so that I could start connecting everything properly, even if not all the data or functionality we would eventually want was there. I added Update classes that the server would be using to push updates to the client, added a very basic implementation of unique ID generation for both the server and client, added basic interface for the client to render game objects that wouldn’t interfere or slow down the server’s processing (however, it will have a minor impact on memory usage).

After writing a bunch of these classes I changed the visual studio project and solution settings such that our shared libraries, Core and SunNet, would output static libraries instead of executables, and our two application projects, Client and Server, would link with the header and library files of these projects so that their code can properly be used.

After linking everything together I had hoped that a couple of PRs would be fleshed out and merged, but they were still under review and being changed. That is, the model rendering and loading that Jessica was implementing which added a lot of great changes that I would want to make use of in the Drawable interfaces I added, and the Core libraries that I had pulled into my code to make use of despite not being merged with master from Ethan and Sylvia. So my code is currently waiting behind those two to get fixed up and merged in once those changes are finalized.

This meant that I was blocked on finishing this changeset and so I looked for something else to do and decided to jump ahead a bit and work on implementing the Octree that we planned to use for both rendering efficiently, and doing unit selection in the client. I completed my initial, fairly inefficient implementation and just need to more thoroughly test it now.

3) if there were goals you were unable to meet, what were the reasons?

Although I completed basic implementations for linking things together, I was unable to thoroughly flesh out the graphical interfaces to sync up and draw on the Client with by the end of the week. This was both due to time and a failure on my part to talk more with Jessica about her changes and maybe pull them in ahead of them being merged. I was unable to complete an Octree implementation that successfully updates over time, and in its current state must be completely rebuilt each frame. This may or may not be sufficient since so many of the objects in our game will be moving so much anyways.

4) What are your specific goals for the next week?

My specific goals for next week are to finish the implementations of the Update classes so that they work properly with Brandon’s network code and to fully implement the update handler’s on the client. Additionally this means syncing with Jessica’s changes in order to finish the Drawable interface and then writing the code on the Client’s display loop to start drawing everything we are getting from the server. Additionally, finalize the Octree implementation and implement unit selection with the mouse, and along with that the orbital camera movement mode.

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

I learned quite a bit about implementing spatial data structures during the octree implementation. Though tricky, I think I found a good middle ground between performance and design complexity. I can always go back later and update it if we find it isn’t meeting our demands.
Additionally I learned that group coordination is not easy, and slacking a little on PR review is a great way to really slow the whole group down, and I plan to stay more on top of that in the coming weeks.

6) what is your individual morale (which might be different from the
overall group morale)?

My morale is very high at the moment! We made some great progress this week, and everyone is showing great enthusiasm for not only the game, but the development process. On the client side of things specifically, Jessica churned out some massive, high quality changes this week that I really look forward to using in my planned work for this next week!
There have been some growing pains with the development process of the group, but things are starting to move more smoothly and I’m very optimistic!

Posted on

Jessica’s Update: Week 2 (20170417)

My main goals  this week were to get model loading done, as well as to rearrange the graphics base that Dylan setup to organize it better.

I managed to get model loading up and going, along with its color and texture properties. There are also some functions that allow you to manipulate the model matrix. I also refactored the graphics code, which is still under review

I think I accomplished most of the goals set out for the week, but I was actually hoping to get more accomplished or start on the next iteration since I thought that model loading would be a simple task. However, I had to try to understand and adjust to the newer version of OpenGl as well as understand how to use the Assimp library, and I’m a bit slower at picking up new things than other people. In addition, there were some cases where I was testing model loading and it didn’t seem to work so I wasted a long time trying to debug. Later, I found upon inspection, that it wasn’t necessarily my code that was wrong, rather the model file info was different than what I was expecting. (One of my models had no color, but it was because blender had not exported the colors I painted on it, so all of the information was gray. Another model had purely color materials and no textures, but at that time I was using a shader that only handled texture information.)

There are also some issues still with the shader giving a pinkish tint to my models, and the lights passed to the shader should be organized in a better fashion.

I also spent more time than I thought on thinking how I would refactor the code since the Sphere code Dylan had was very similar to calls I would use to draw or create a mesh.

 

My goals for next week are:

  • Planet/ solar system animation
  • Having a skybox

Stretch goals:

  • Bloom shader
  • Particle system

 

This week I learned that if something working, I should try other cases instead of being fixated on that one case to try to narrow down what is wrong. I have a bad habit of obsessing/ being focused solely on one thing.

In addition, I made the mistake of waiting to make a huge pull request with lots of changes. I don’t like to show people things that aren’t done or that have imperfections (not that my code is perfect now, but it was definitely more of a mess as I was refactoring one class at a time). I realized this puts a negative impact on my teammates who have an overload or things to review. Note to self: try and get over the insecurity of having other people look at your code because your teammates would like to know what is going on.
In general, I don’t really express much excitement  or have a strong opinion for anything because that’s my personality, and I tend to put up a barrier when I’m still uncomfortable with people. Once I warm up to people I might be more enthusiastic. The rest of the group seems really excited for the project and are always spitting ideas back and forth. Dylan and Brandon are really proactive. Sylvia says that she can’t wait until she can see a ship shoot down another ship. Raj and Ethan are always ready to jump in and contribute ideas.

 

One of the model loading screenshots**:

** note that the ship is not to scale

Posted on

Raj’s Update: Week 2 (18 April 2017)

What were your concrete goals for the week?

I had two goals this week: help Brandon on networking and define an INI configuration parser.

What goals were you able to accomplish?

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.)

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

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!

What are your specific goals for the next week?

I aim to set up the server-side communication logic using the `SunNet` package and assist in core game logic development and design.

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

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.

What is your individual morale?

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.

Posted on

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)