Posted on

Raj’s Week 4 Update

What were your concrete goals for the week?

My goals for this week was to interface with Brandon, Sylvia, and Ethan to get some movement going on the server, then communicating that movement to the client. We aspired to have done the ability for clients to select an arbitrary unit and its destination.

What goals were you able to accomplish?

This week, Sylvia and I finished movement on the server and mocked up an example that illustrates updating movement propagates correctly from server-to-client. To get this done, we put together a Mediator on the server side that abstracts away how Units are updated (for movement, combat, etc.), set up two dummy units, set their destinations on the server side, then served updates of those units’ position to the client. We assured that the client received the correct updates through logging the differences. Also, we had the clients move two spheres, representing the units, to provide some visual assurance.

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

We haven’t finished Unit Selection on the client-side, but the graphics team got the core of this set up yesterday, so integrating this with unit movement should be done by today (Tuesday), given we have assured that unit movement updates are being communicated correctly between the server and client.

What are your specific goals for the next week?

My immediate goal for next week is to get unit selection done, working with the graphics team. Also, Ethan has set up the client-to-server updates (which we call “commands”), so the next thing after unit selection will be unit creation, where the client issues a “Create Unit” command and the server responds by creating the unit and sending confirmation to the client. Then, I will work with Sylvia to integrate combat into the server side, using the Mediator we set up for the movement updates. So, by the end of this week, we will hopefully have unit creation, movement and combat examples up.

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

I learned that my Windows VM doesn’t have access to my Graphic Card 🙁 — I think I have a solution to fix this, so I can develop from home again, but for now I’ll be spending a lot more time in the lab this week.

What is your individual morale?

My moral is high still. I’m excited that we have communication between the server and client (in that direction) working for unit movement. Looking at the team’s progress this week, I feel like much of the foundation has been set and much of the work for this week will be integration!

Posted on

Brandon’s Update: Week 4 (02 May 2017)

Concrete Goals

My concrete goals for this week weren’t super concrete. For this week, I told the team I would “fill in where needed”. When I said this, I meant that I would help review teammates’ code, help them in problem points, implement features we needed that no-one was working on, and fix any glaring issues with our game.

Accomplished Goals

Since I was working to “fill in”, the things I accomplished this week seem a bit scattered. Most of my work, as usual, went into networking and server/client communication. Fortunately, I believe that the networking layer is servicable for the rest of our game’s development. The only major remaining logic left is automatic reconnects.. but that can wait until a later time to implement.

I helped plan and implement some server/client integration and offered a lot of advice and feedback on the unit movement system. I think we have a well-functioning system for handling and issuing client updates.

I also helped develop some new features this week. Pending review, I added client support for holding down keys, properly mapping specific textures to specific planets, and adding connection-time player ID assignment.

Also, all of my features from last week that were pending review have been merged in! That means players can now send a PAUSE signal to the server – An early form of server/client interaction

Clean Client/Server disconnect was also merged in!

 

Unmet Goals

Since my concrete goals were, erm, not so concrete, I can’t say that I didn’t meet any goals. However, I really wanted to have the ability to select units done this week (Just click a unit and they will move in a random direction). That remains uncompleted. I feel like a lot of the infrastructure is now in place and selection/movement will only take a few days to finish, but I still think it could have been completed.

Next Week’s Goals

Next week, I really want to start making the game come together.  The infrastructure is in place, and it’s time to get implementing. There is a lot of work going on in the unit selection, movement, and combat space, so I’d like to work on something no one else is. I’ll work on city slots, founding cities, and spawning units from cities. I’m hoping that all of this will be networked and ready to go by the end of next week. I also want to work on keeping the team focused on incremental, visible, intractable improvements.

This Week’s Learnings

From a technical perspective, I didn’t learn all that much this week. I learned a bit more about how to use Visual Studio to accomplish exactly what I want.. but that’s about it.

Again, most learnings had to do with the team and interacting with them. I tried very hard this week to help move things along quickly, and I learned that the more we push to “move forward”, “merge”, and “prioritize iteration over a full initial product”, the more we can get done.

Individual Morale

I’d say my morale is at “normal” levels. It has dropped steadily from week 1 to be considered normal. I was satisfied with the progress we made this week; satisfied with my own progress; and satisfied with how we function as a team. I’m not particularly excited about anything, though. Once our game becomes more interactive and results become visible, I know my morale will become higher.

Posted on

Brandon’s Update: Week 3 (25 April 2017)

Concrete Goals

This week, my concrete goals were a little less concrete than they were last week, but that’s OK. My primary goal was to create a working model of how the server and client would communicate, as well as a “demo” of them communicating. Of course, this also involved creating the server skeleton as well as cleaning-house, ensuring that the shared server/client classes were setup appropriately.

Accomplished Goals

As advertised, I completed my primary concrete goal and created a demo of networked server-client communication.

This involved a lot more work than I expected. There were a lot of small kinks in the networking code that had to be worked out. There were also some design issues in the client and shared libraries that had to be ironed out.. but it all worked out in the end, and I’m happy with the result!

Unaccomplished Goals

I was hoping to accomplish even more server/client interaction, especially concerning clients clicking or pressing keys. However, there was simply so much groundwork that needed to be laid.

Next Week’s Goals

I’m confident that the necessary groundwork has been laid and that we can really start working on our game functionality. Next week, I’m planning on helping out with the client to help get things moving as far as actually creating the game goes. I’d like to create a demo program where players connect to the server, a player can press a key to “spawn” a unit, the unit “spawn” is broadcasted to all other players, and perhaps the unit may begin moving.

I’d also like to work with another teammate to try and lay the groundwork for the user-interface, so that we have plenty of time to solve any problems that might arise.

Learnings

On a technical level, I learned a lot about the different strategies for doing client/server design as well as some of the problems that could arise when working with multi-threaded servers. (I believe all the kinks are worked out, though!)

Much like last week, my biggest learning was again with the team. I realize that I am very passionate about my ideas and would love to have them implemented quickly. However, I need to remain patient and allow the ideas to propagate throughout the group, grow, evolve, iterate, and eventually come to fruition.

Morale

My morale this week is much lower than my morale last week, but still high. I feel that our group did not accomplish as much as we could have this week. At the time of writing, there are 13 outstanding pull-requests, the majority of which have been sitting for several days. I feel that we are very slow to iterate and make significant progress.

I feel a lot of this is due to our group’s focus on “perfection”. A lot of time in PRs is spent debating over rather-small design decisions. We need to get back to the basics and focus on how to move the entirety of our game forward.

I recently brought this up with the team, and they felt receptive. I feel that we can improve!

Posted on

Dylan’s Update: Week 3 (25 April 2017)

1) What were your concrete goals for the week?

A failure of mine was actually in defining my concrete goals. I left them very abstract this week. One concrete goal was definitely to push the long list of PRs through that we started the week with, being mostly concerned with the huge ones with lots of conflicts. Other concrete goals for me were to finish the octree implementation that we would be using for unit selection so I could start testing UI and control schemes better.

2) What goals were you able to accomplish?

I was definitely able to help get the PRs pushed through. I was also able to complete a much needed refactor of our client code. At the beginning of the week, we were still using the poorly organized code that I used to throw the initial demo together and we were starting to feel some pains involved with managing everything on the graphical side. The client code was split up between the main function and a massive static only Client class. I initially used this setup to play nicely with GLFW, our openGL wrapper, since it is strictly a C-style API and doesn’t like member functions at all. This week I changed this to make Client a regular class and add a static GLFW handler class to handle setting up and keeping track of callbacks. I’ve also done some further abstraction to move code out of Client, such as making a generic Camera class to handle view and perspective information that can be passed around. Though this was not in my initial goals for the week it was a lot of much needed changes that I’m glad I completed.

I additionally completed the Octree implementation. It is a little inefficient in that each frame it must be reconstructed instead of doing more efficient object sized updates to move things around in the data structure as their positions update in world space. Due to the nature of our game, almost all objects will be moving each frame and doing a full update every frame won’t be too far from what the updates would be anyways, so I’m choosing to use my development time now for more important, pressing matters.

I started on a simple UI, but was unable to complete my goals of a rough implementation this week. I will continue this as a priority next week.

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

My failure to complete the basic UI was entirely a result of a busier than expected schedule this week for me. Poor planning of my other assignments as well as some prior engagements reduced the number of hours I was able to put in this week. I expect to work quite a bit more than usual to catch up, if not get ahead, next week.

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

Next week’s goals are to work much more on the graphical UI. I want to have a smooth UI that is easy to add to as we move forward, that is capable of displaying the basic UI information that we are anticipating thus far.

Another goal of mine is unit selection. Now that we have some client server communication going, I want to be able to create units on the server and select them on the client using ray testing with the spatial data structure we now have, and then issue commands related to the selected unit back to the server. We should also update the UI with information about the selected unit.

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

I learned that UI in openGL is not as easy as anticipated! There are a lot of options and I’ve spent a bit too long trying out various options. Otherwise everything I’ve been learni

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

My morale is still very high, though a bit lower than last week, mostly due to me being a slacker this week! I feel excited about my work for next week, though, and am looking forward to see our game progress!

Posted on

Jessica’s Update: Week 3 (20170424)

The goals for the week changed a bit after talking to the team, so for this week, I had set out to implement a skybox and particle system.

The skybox is pretty simple, so I had completed that, but I ran into obstacles with the particle system. I have one in place, that can be rendered but it’s not the beautiful or complete particle system that I was envisioning.

  1. As of writing this post, billboarding is not working for the particles. I am using flat squares and am trying to make them face the camera at all times, but there is something wrong with my math calculations.
  2. I wanted a nice shader and shape for my particle system to represent thrusters so that it would look like real fire. I’ve attempted things such as using textures and noise sampling, but nothing looked quite right yet, so i’m just using colored squares.

Hopefully for next week, I will be able to start implementing user selection and input with our graphical interface.

What I learned this week is that I really need to brush up on some of my math. I should also try and ask my teammates early on for help. No one has really been asking me for help yet, so I’ve been working kind of individually on my side, but I feel like I should try and integrate more with the team.

 

The team still seems pretty excited. It was neat when Brandon sent me a screen shot of his success hooking up networking with graphics. He had been sending position coordinates and updating the position of our Earth model with it.

Posted on

Week 3 (24 April 2017): Team & Individual Reports

Team Report

Overall Status

All team members were actively developing for the past week, and our effort has resulted in the following accomplishments:

The networking part of the game is going well, especially with the server. We added logging functions to SunNet for debug purposes. Network channels were added to the client with the ability to subscribe. We also finished our very first demo that shows server/client interaction (yay) by making two planets orbit. Furthermore, a universe mapping system is added so that the client can load the planet positions from the server. A basic tick timer is added so that the server can update every 30 frames per second.

For the game hierarchy, the underlying infrastructure is slowly and steadily growing. We added the functionality for (1) player to create and remove a singular unit (and multiple units), (2) unit to unit combat logic and (3) upgradable system. The configuration parser is also done. It can read multiple files, throw exceptions when there is an error, and return the read values with a get function. We drafted up player scenarios that are good reference for the developers. There are some issues for different parts of the games to sync, because we were unaware of what the server or client need from the structure. Hopefully, by looking at each other’s pull requests and actually pulling down the branches (and play with them), we can help each other point out the things lacking. We aim to finish these scenarios by the end of the week.

On the graphics end, we have made some concrete progress on loading the models, making the skybox, writing shaders and so on. Particles are on their way of development. More importantly, we revamped Client from static to a normal class, with glfw handling calls in a separate utility class. This really simplifies and organizes the code, as well as making it more readable. Unfortunately, we were not able to get to our stretch goals, including the HDR and blooming. Hopefully we can find time for them once the client and server are more stabilized.

Group Morale

Our group morale is consistently high. We finish most of the features on track, although not the stretch goal. Everyone puts their effort in communication and contribution in pull requests, and actively help others to improve. We hope to this spirit can continue along the weeks.

Individual Report

Brandon’s Update

Dylan’s Update

Ethan’s Update

Jessica’s Update

Raj’s Update

Sylvia’s Update

Posted on

Raj’s Update: Week 3

What were your concrete goals for the week?

My goals this week were to set up the foundation of the game’s combat logic. This includes handling how units engage in combat with both cities and other units. Further, I aimed to better understand how we will be sending updates between the server and client

What goals were you able to accomplish?

This week, I implemented the unit-to-unit combat logic and am set up to complete the unit-to-city combat logic. Through development, I became more familiar with the Visual Studio development environment and developed a few tests for the combat logic using Microsoft’s C++ Unit Test Framework.

Regarding the overall design of the combat system, we maintain an interface that implements the foundation of combat (i.e., check if a target is in within your range; if so, attack, otherwise respond appropriately). Then, subclasses may implement interesting combat logic using one of the hooks that the interface provides. For example, there is a hook for being out of range to attack, which our Unit class overrides to tell itself to move closer to its target. These hooks allow us to handle special needs without rewriting the common logic.

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

I haven’t finished the unit-to-city combat logic yet. However, with the hooks I’ve implemented in the combat interface, extending combat to cities shouldn’t take much time. For example, by overriding the hook to handle defeat within the City class, I can tell the city to transfer ownership to the victorious player.

What are your specific goals for the next week?

My first goal for next week is to complete the Unit-to-City combat. Then, I will interface with Brandon and Ethan to hopefully get some combat going on the client by the end of the week. Further, I will be working with Sylvia to clarify aspects of the core game logic that are still ambiguous, then from there, we can set up a priority queue of tasks to finish on that end.

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

I learned a lot about developing in Visual Studio, being that I had worked predominantly on a Mac prior to this quarter.

What is your individual morale?

Overall, my moral is high still. Looking at the team’s progress this week, I feel like we’re getting close to seeing some (very minimal) game action going on the client, which will hopefully happen this week.

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

Ethan’s Update: Week 3

1) What were your concrete goals for the week?

My goal was to implement a timer that allows the server to process updates every 30 ms, as well as processing all incoming updates from clients. Code reviewing will also be a big part for this week, as I didn’t do as much last week.

2) What goals were you able to accomplish?

I finished the basic logic for the server to run indefinitely in a loop, processing every certain amount of time, as defined my user, and showed how to create a separate thread to terminate server correctly. I also reviewed most of the codes submitted on Github, including some from last week that I did not review, which helped me understand what’s going on in other parts of this game.

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

I was not able to finish handling client updates because we did not clearly define how would clients send updates/commands to the server. I have the basic logic down in server, but my full implementation was pretty much blocked until we have some further discussion on server-client communication.

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

Since we assign work during Thursday meetings, these are just my personal expectation. I expect to be working on further developing the basic infrastructures for server-client communication. Probably work on the game launcher or the lobby system as well, which was planned to be done by week 4.

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

The most thing I learned is how important code reviewing and documentation is. All of us have been working a lot since the very first week, and it’s quite hard to keep track of what other people are doing. It took me quite a while to get how exactly the networking library (aka. SunNet built by Brandon, which was definitely a fantastic job) works. Having detailed documentation would significantly decrease the time people have to spend learning other people’s code.

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

Again, our morale is pretty high at the moment. I can see all our team members have been putting lots of effort into this game. We seem to be assigning lots of work for this week in our original plan, but since we got ahead of plan last week, we were able to keep up with it for this week. We haven’t encountered any major problem yet, but I guess we will have to deal with them at some point as the game grows.

Posted on

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

Concrete Goals

This week, my primary goal was to create and complete a networking back-end. In theory, we would then be able to use this back-end to begin linking parts of our game together.

My initial design for the networking back-end involved an OS agnostic wrapper around sockets, a Server and Client class that asynchronously intercepted messages and let the user handle them via event-handlers, and a “Channel” system, where messages were sent on “channels” (Each channel corresponds to a type and may thus be deserialized and passed directly to a handle function).

My final concrete goal was to provide the team with constructive criticism and feedback on their pull-requests and be as helpful as possible.

Accomplished Goals

I was able to create the OS-agnostic networking layer as well as the “Server”, “Client” and channel systems. I was also able to complete a small demo-programming as a proof-of-concept for the networking architecture that I designed.

Of course, not all of the things I created are in the “stable” branch of the project yet. My changes are undergoing review from my teammates and I will be implementing their feedback for the next few days.

I was also able to provide my teammates with feedback with their PRs, as well as aide them through the development process. All in all, I feel like I definitely accomplished my goals this week.

Unmet Goals

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.

Next Week’s Goals

This section of my updates will always be a little bit awkward. Our team has decided to manage tasks in week chunks, where our “review” sections are on Tuesdays. Thus, I will only be giving my personal goals, but not those fleshed out by the team.

Anyway, for next week, I am planning on accomplishing the following:

  • Development of a logging utility
  • Add comments to the networking layer (lest I forget what I did)
  • Continue to iterate on the networking-layer until it is merged into “master”
  • Integration of the networking-layer into the game layer (Create Server executable, create the concept of a “game”, allow players to join the “game”)
    • This is a large task. This will be more of a “lobby” functionality, where players are able to connect to each other and share some data (players send the server their names, server sends them their IDs. When another player is connected, that data is sent).
  • As a stretch goal, I will begin integrating the networking into other parts of the game that have already been set up.

Learnings

I am now a master of Smart Pointers in C++ and I highly encourage everyone to use them.

I’ve also become fairly fluent in most layers of the “sockets” networking stack.

My most important learning of the week, however, is that everyone has their own ideas. Without communicating our ideas to each other, we will all be working on our own “individual” versions of the game. Our bi-weekly meetings have cleared up any misunderstandings that we’ve had.

I’ve also learned how important it is to stay on-track during meetings. Everyone wants to talk about their ideas, but in order for limited-time meetings to go smoothly, there must be a clear agenda. In one of our meetings, about 45 minutes was spent discussing a design decision that was ultimately considered non-important.

Morale

My individual morale is fairly high. I am excited about our game and the progress that we’ve made. Our team is just getting started, so we hit a few rough-spots (there was some wasted time, some HUGE pull-requests that sat in review for way too long, and some development-process misunderstandings). However, I am hopeful for the next week — we are ready to make some major progress, I’d say.