Posted on

Sylvia’s Update: Week 9

What I Planned

To catch up on this week, I will dedicate all my energy to trading user interface and make sure that it works. This includes the aesthetic UI, the function set resource types and amounts to sell and buy, and the ability for player to accept and decline trade. If there are more time, I will add the function to do counter-offer.

What I Have Accomplished

  • A fully functional and displayable trading system
    • the ability to establish trade
    • select any online player (except himself or herself) as a trade partner
    • establish trading resource type and amount, both for selling and buying
    • the receiver can either accept or decline a trade
    • a player can only receive one trade at a time. If more than one offer is provided, any old offer is overwritten

The Unexpected Factors

There are not many unexpected factors this week. It took a long while to develop the trading UI due to the learning curve for nanogui, but after some read-up on the documentation, I was able to implement the feature without much issue.

For the Future…

This is the last week before the demo! Time flies by so fast… Most of us agreed to stop implementing new features and focus on making the game more robust, aesthetically pleasing and user-friendly. This will include fixing the fps lag and other bugs. If people agree on having more time, we can work on adding some icons to help users identify where their cities/units are, and adding a small guide.

What I Gained

Looking at other people’s game today made me realize on how far everyone have progressed in the past 10 weeks. All groups have done a wonderful job, and we may inevitably compare ourselves to others’ graphics or game play. However, I am very happy with how far our game has come. It ran relatively smoothly and did not break at all. The members enjoyed attacking each other’s units and found small, hilarious bugs, such as having no resources to build extra ships.Overall, we learnt a lot from the dev weeks, and I’m proud of what we have accomplished.

How I Felt

I am feeling both nervous and excited. While I was deep-diving on my own feature for the past week, I was able to enjoy our current game play on demo branch for the first time today. With some small tweaks, we believe that the game will be significantly smoother and more fun!

Posted on

Sylvia’s Update: Week 8

What I Planned

I am heading home for Memorial Day weekend, and I plan on finishing up user interface for trading system, at least on the aesthetic part. I also wish to finish integrating animation with master branch.

What I Have Accomplished

  • Getting animation up-to-date with master
  • Have a basic trading UI branch on remote

The Unexpected Factors

After bringing the animation branch up-to-date, I realize that the turning animation did not account for movement only activities. It only works when a spaceship is selected to attack. Thankfully, my teammate caught the error and remind to fix it.

For the Future…

I MUST get the animation branch merged into the master. Besides finishing the aesthetic part of the trading user interface, I want to catch up with the team on the general progress of the game before making a decision on what to work on. We are probably lacking some aesthetic elements for tech tree and scoring systems, so I can potentially work on those.

What I Gained

To be really honest, I did not dedicate enough time to the project this week due to the itinerary. My weekend was quite overwhelmed by events, and thus I was trying to finish as much feature before the trip as possible. I am really glad that my team supported me and got my back this week. For the next two weeks, I promise to put all my effort to the project to make up for the time loss.

How I Felt

I am feeling neutral this week because I did not get time to work with the team during our usual meetups. However, I am grateful that my team understands my trip and prep to take over my role when I am absent.

Posted on

Sylvia’s Update Week 7

What I Planned

For this week, I plan on wrapping up on the attack, death and orientation animation and merge it with master. I also want to get familiar with nanogui API and write up a trading user interface to integrate with the existing trading framework. This will probably take up a good chunk of time, as the API has some sort of learning curve. At last, for stretch goal, I would like to add some visualization difference between friendly and enemy units.

What I Have Accomplished

  • Make unit CORRECTLY rotate towards enemy spaceship
  • Fully link all animations, including rotation, attack and death
  • Started on designing and implementing trading user interface, but not close to a pull request yet

The Unexpected Factors

This is perhaps my slowest week yet… Hours and hours of debugging, just so we can have a perfected rotational animation. Jessica and I teamed up this week to work on animation together, however, we went on a long, long journey to perfect the rotation algorithm. In the end, it took way too much time and exhausted our energy. After multiple back-and-forth attempts, I decide to discard our half-working, pre-existing code altogether and create a simplified version. Instead of of smooth rotation around a calculated, arbitrary axis, I lowered the goal to an immediate, sharp turn around only y-axis, making it easier to achieve. Taking the TA’s advise, I started from writing basic functions that rotate only around singular axis. Subsequently, I realize that I am using function from an older opengl version, which produces an inaccurate rotational matrix… It also explains the inconsistency between radians and degrees across our opengl functions due to version differences (newest version use solely radians). The change also helps me realize that functions like acos only return positives angles range from 0 to pi (non-directional). All the small mistakes lead to hours of work and complete exhaustion.

For the Future…

I will be heading back home during Memorial Day weekend. However, before leaving, I wish to finish the majority part of trading user interface and chat with Ethan about integrating all the back-end infrastructures with it.

What I Gained

Jessica and I tried really hard to research about opengl rotation, as well as coming up with a relatively efficient way of activating animation from server to client. In the end, we had to compromise efficiency for accuracy (sending mat4 data from server to client, removing smooth rotation, and installing arbituary rotation around only y-axis). I’m glad to have communicated with the TA during lab hours, because his input gave me a good idea on how to further debug my code. Also, I had a massive loss of interest after long hours of debugging with vain. This resulted in a weekend of stagnation, wasted solely on the purpose of debugging. I should have balanced my time better, delegating more energy towars trade UI instead, which might also help on refreshing my mind.

How I Felt

Like mentioned before, this week is probably the lowest I’ve felt, due to my inability to move onto new functionalities, resulting in a state of stagnation overall. I really hope to overturn this by starting fresh on a new component of game play (trading), and regaining confidence by learning the nanogui API. This should be get interesting and allow me to use my creativity in beautifying the user interface.

Posted on

Sylvia’s Update Week 6

What I Planned

My primary goal this week is to finish some sort of battling system for the units. This part is absolutely essential towards our game play, and many other core elements, such as ordering spaceship to attack cities, adding complex animations and so on, are all dependent on its implementation. Since object selection is almost out of the oven, I can start by selecting two random spaceships (spawned by pressing F3 key) through key press. After that, we will migrate the attack logic to be triggered by clicking on two separate units. I will also be working on orienting the ship towards the destination, adding shooting animation as well as triggering explosion before death.

What I Have Accomplished

  • The first iteration of a working attack system. By pressing the F6 key, two random spaceships are selected (must be spawned from different client, thus belonging to enemy players). The client receiving the key instruction will command its own spaceship to attack the target. The ship travels to the target, and once in range will start dealing damage. The ship that reaches 0 health will be permanently removed from the server and client side.
  • A half-working rotation animation
  • Particle shooting animation incorporated when attack command is triggered
  • Death animation, though unit is not yet correctly deleted from memory

The Unexpected Factors

I started to incorporate animations after finishing the attack logic, however, it was much more complicated than I assume. Right now, our unit manager handles a list of active and idle units and dictates when to send updates. The updates are cut off once a command is finished, swapping the unit to the idle queue. Therefore, we had to send one last tail update to wrap up what unit needs to do. Also, it is extremely hard to determine the best place to handle animation. Neither server nor client could handle the animation singlehandedly, because it requires communication of an exact timing for rendering on the screen. However, we also want to regulate the amount of information sent through server. Right now, we could not help but send a while rotation matrix, which is less than ideal. There also seems to be unexpected issues from race conditions, where the objects are drawn before they receive crucial updates. We could not attach to any logics because new flaws are constantly found, and thus must be modified.

For the Future…

This week, I want to get the rotation animation perfected (probably with TA’s help). After we get all the other teammate’s pull requests into master, I will have to update the attack and animation logic. Besides that, I want to start helping out on user interface side (writing the underlying logic and design the aesthetic outlook). A stretch goal would be making the enemy spaceships look a little different (perhaps with a visual outline) for individual clients.

What I Gained

While implementing more functions, I realized that we need to constantly change the system logic to accommodate new abilities. My teammates were able to point out loopholes and brainstorm a more concrete architectural design, which is much better than me thinking about it alone.  I have been working with different teammates each week so that I get to work on every aspect of the game and also get to know the people. It has been working wonderfully.

How I Felt

I am pretty happy with our team progress this week. I was working with two to three teammates at the same time, on multiple functionalities. Raj took over unit attack logic and modified it to be more rigid and resistant. Jessica added all the particle effects for explosion and shooting under the correct class, while I helped her send the updates to notify server. We continued our super-work day which is going really well.

Posted on

Sylvia’s Update Week 5

What I Planned

In the second week of our core development, I plan to finish the major components visualizing and interacting with units. This include linking unit object with an actual spaceship model, spawning spaceships on key press, as well as making spaceships move in random directions. Having visualization on client hooked up with the server is my priority. As a stretch goal, I would like to work on animation of the spaceship, including orienting towards the direction of travel, attack and death animation.

What I Have Accomplished

  • Replace temporary sphere with an actual spaceship model
  • When pressing F3 key, player can spawn a spaceship in a random location with 1000 range in x, y, z
  • When pressing F4 key, a random spaceship is selected to move to a random location
  • Refactor Unit Manager to store unit ids as key and units as values

The Unexpected Factors

There were not many unexpected factors this week. The visualization process went on smoothly. We spent a whole day developing together, which we did for the first time. This proves very helpful because we can ask each other questions directly.

For the Future…

My next big goal is to get all the animations set up on the client. This could be challenging because of the sequencing. For example, if we want the spaceship to move from point A to point B, we would need to hold off the update call somehow for the spaceship to have a smooth orientation towards the destination. I also want to see if my teammates need any help with unit selection and unit attack visualization. At last, I will be working on a simple user interface for the client.

What I Gained

Our group usually communicates remotely and share codes through git pull requests. However, we gather for the first time solely for the purpose of writing codes together, and I thought that was very productive. We could communicate about the issues on the spot, and people come and leave when they have classes. I really wish we could have more of these sessions.

How I Felt

So far, I am pretty happy with the progress we have made. However, I am also concerned that people are starting to get busy with midterms and other homework. Sometimes communication falls through, and I become disconnected with other people’s goals. I want to help out as much as possible even when the teammates are busy.

Posted on

Sylvia’s update Week 4

What I Planned

As the Scrum master, I will be in managerial position to write the Week 3 team report, update the Trello board and hold the team meetings. We are in an important transition from abstract design to seeing actual visualization of (super early stage of) game play. With Professor’s guide, we moved many things scheduled for week 5 to be a week prior. I plan to do pair-programming with Raj on handling unit updates on the server side. We will be making a unit manager class to do all the update calculations for movement and attack.

What I Have Accomplished

  • Create a Unit Manager class which handles updates such as movement and attack
  • create unit destructors
  • visualize unit movement on the client side with dummy creation
  • got up-to-date with client and server logic through pair-programming

The Unexpected Factors

  1. Our planning started off with ambiguity because we were switching our schedules around. I felt a bit lost on how everything is going to be connected, but doing pair-programming helped counter that.
  2. I realized that there are a lot of inter-dependencies on features that other people are working on, and it partially constrains the progress we make.

For the Future…

In the next week, we will have most of the individual components for commanding and visualizing units ready. This include unit selection on graphical window, player command of unit creation, connection sockets between client and server, server side unit updates, and so on. We will be able to link all the components together and see how it works. I also hope to mock some units attacking each other, as well as getting to the concept and visualization of slot.

What I Gained

I realize that pair-programming is super efficient in terms of approaching an area of code that I am not familiar with. For example, I was concerned about understanding how the server and client work together. Ff I were to be working on this part alone, it would have taken so much longer. Working with Raj helped us nitpick each other’s errors and brainstorm the best way of implementation.

How I Felt

On one hand, I am really happy on seeing the progress of the team. We have the server-client connection established, hdr and bloom implemented on the graphics end, a full universe system in display (hopefully) and tested units flying from point A to B. However, it was also a rather messy week in terms of breaking down the tasks and keeping track of everyone’s progress. As a Scrum master, I feel little disoriented and perhaps waiting around too much for people’s progress. Even though I implemented the destructors, it was a very trivial part for the game, and I could have spent time on something more significant.

Posted on

Sylvia’s Week 3 Update

What I Planned

I wish to continue building upon the basic infrastructure that Ethan and I wrote on last week by refining the classes and adding more functions. In order to keep track of the game abilities, we plan on writing player scenarios that illustrate the events such as building a unit, allocating a slot and constructing a city. We can then refer to these scenarios, write functions and base our test cases. We want to add NUnit tests to our project in order to make sure that the basis of the game works at all times.

What I Have Accomplished

  • changed all print statements to test cases written with NUnit framework
  • refine the tests to be more efficient and accurate. Instead of comparing string outputs, we are comparing object fields and
  • planned out player scenarios and implement them into the classes
  • switch from vectors to maps because they are more efficient for pushing and popping polymorphic objects
  • design the upgradable class that can be used to upgrade units and cities by modifying their fields (such as attack, defense, health, etc.

The Unexpected Factors

There were several issues afloat. This week yields the longest pull request that I have ever experienced, mostly due to the following:

  1. Print statements and string output comparisons are bad practices for unit tests. With teammates guidance, I slowly changed my methodologies to be more conventional and up-to-date. Instead of concatenating and converting important info into strings, I use standardized NUnit framework to compare object properties and vector sizes, for example. I also broke down the testing aspects to be independent from each other.
  2. I should never accommodate the game to match data structure for convenience. I wrote a function that swap any particular key with the last key in order to pop from the back of a vector. However, the better way of doing this is simply to choose a better data structure, such as a map.
  3. Sometimes branches do not migrate gitignore correctly, and I was pushing unnecessary files and personal settings to server.

Besides the frequent iterations to get my pull request accepted, we also have infrastructure mismatch. When teammates try to link server with client and test out the game hierarchy, there were basic constructors or functions missing. All of these point out that we not only need to maintain our frequent communications, but furthermore should keep ourselves up-to-date with all aspects of the game in development.

For the Future…

In the next week, I want to finish up implementing the scenarios that I have planned, as well as syncing up with teammates on the server and client side. This will help me get a better understanding of the big picture of our game. With team work, we will ensure the function where a player enters a game and be able to perform actions. I also want to design some basic graphic user int

What I Gained

I have gained a lot from this week, not just on how to code more efficiently and clearly but also how to break a complicated system down into basic components. The strategy of listing out player scenarios was a successful approach to clear my mind and put things into order. It shows what functions should be prioritized and what can wait. However, i should also be more careful with my design in general and take into account of the needs of other parts such as client and server. How are these structures going use the class hierarchy? How can I design better for other’s needs?

I have also tried to be up-to-date with people’s pull requests. Although I was not able to comment on all of them, reading other people’s codes help me visualize what are missing from the game and what are already implemented.

How I Felt

This week has been pretty hardcore for me, but I am not discouraged. Rather, I learnt a lot from my mistakes and from teammates’ feedback. It is exciting to see that your teammates are starting to use the functions you implemented and make the game come to life.

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.