ajax loader

Final Group Report

Game concept: How and why did your game concept change from initial concept to what you implemented?

Most of our concept remained according to the original plan. The central theme was having blobs that grew larger as they ate resources. However, many of the planned features never made it into the game. An example of this would be the destruction of cities and even city structures. A large part of not reaching our objectives was due to busy schedule and difficulties we encountered due to the world being a sphere, communication, and unforeseen complications. In the end we stayed pretty true to our initial concept and although we weren’t able to implement some of the more complicated features (like destroyable buildings/cities) we were pretty satisfied with the result.

 
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?

Initially we had wanted our blobs to win the game by conquering the most territory and blobs to have lives that they could lose. In the end our design was simplified and some features were missing because, as previously mentioned, we could not coordinate our team efficiently enough to complete all our goals. A predominant theme of the project was a reduction in complexity. Over time, we ended up trying to simplify most things in the game.
A lot of the things that were initially conceived such as key bindings, character selection, player-vs-player, etc. did not end up making it into the game largely due to other aspects of the system being more important like physics or sound or hud. Initially we talked about using Bullet however, after doing some research, it seemed more difficult to appropriate Bullet for a spherical world than just to write a small physics engine ourselves. By and large the overall design of the system did not change a whole lot although some things were removed or changed because when it came time to actually implement things it just made more sense or was easier to do. An example would be events. Initially, there were different event class for player events. Eventually, it was changed to just be a 1 byte value sent to the server indicating what happened. All these “events” were just numbers in an Enum. The reason for these changes was because all the other functionality was superfluous and made the system more complicated than it needed to be as well as a lack of time.

 
Schedule: How does your final schedule compare with your projected schedule, and what are the reasons for the differences, if any? (You should be able to glean this from your status reports.)

Our early schedule was actually pretty forgiving and did not leave much room for extra features to be created. We met deadlines at the beginning but we started falling behind. Tasks were assigned to people but some Graphics deadlines were never met due to complexity. However, we did reach most of the other early deadlines, sometimes out of order, but ended up working on a lot of the core features until the morning of the demo. Our schedule also changed when we made design changes, such as adding resources, implementing physics, and creating HUD art. Looking back, our early schedule was vague because the game was not entirely planned out, and became more focused as development progressed.

 
What software methodology and group mechanics decisions worked out well, and which ones did not? Why?

What did not work well was not communicating and not making decisions as a group and propagating these decisions to everyone in the group or not communicating at all. Initially this was our biggest challenge but we started overcoming difficulties in the later stages. We addressed not being able to meet as a team by using team management software such as Trello and Slack to keep us connected and organized in our tasks. Keeping communication responsive and active was pretty important as well.

 
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?

Serialization turned out to be much easier than expected. Texture mapping was harder than we expected because of the way our rendering sequence was set up in the new versions of GLSL shaders. Dealing with four clients ended up being more work than just changing the max number of connections variable. Mostly this was related to lag and trying to make things run faster, a big challenge for us since we had so many objects in the world.

 
Which aspects of the project are you particularly proud of? Why?

We are proud of the fun features that made our game unique. For example, the spherical world because it was difficult and very different. Various NPC’s animals also made the planet more alive. Burping because it’s funny. We are also proud of the original artwork we created for our game. It was really hard to find a skybox with all six sky pictures and a high resolution texture for a whole planet with grass on it. We ended up designing our own textures since we didn’t have any artists in our group.

 
What was the most difficult software problem you faced, and how did you overcome it (if you did)?

One of the most difficult problem we faced was Implementing the sphere correctly.  We had a hard time finding the correct positional updates for each object on the sphere translating and rotating it correctly. We overcame this by working together and lots and lots of debugging.

 
If you used an implementation language other than C++, describe the environments, libraries, and tools you used to support development in that language. What issues did you run into when developing in that language? Would you recommend groups use the language in the future? If so, how would you recommend groups best proceed to make it as straightforward as possible to use the language? And what should groups avoid?

We used C++ to program game logic and network. We also used OpenGL with GLFW library for the graphics aspect of the program. Finally we used SFML for audio.  Besides that, we used JSON for configuration files.

 

How many lines of code did you write for your project? (Do not include code you did not write, such as library source.) Use any convenient mechanism for counting, but state how you counted.

Just about 9777 lines of code in /src. Total with libraries is 315163, excluding media (obj files). We used
git ls-files | xargs wc -l

 
In developing the media content for your project, you relied upon a number of tools ranging from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year can benefit from what you learned, please detail your tool chain for modeling, exporting, and loading meshes, textures, and animations. Be specific about the tools and versions, any non-obvious steps you had to take to make it work (e.g., exporting from the tool in a specific manner), and any features or operations you specifically had to avoid — in other words, imagine that you were tutoring someone on how to use the toolchain you used to make it all work. Also, for the tools you did use, what is your opinion of them? Would you use them again, or look elsewhere?

Our pipeline started in Blender, where the models were created. Any version of Blender will work, since we really only used the core functionality. We attended a Blender workshop and watched several Youtube tutorial to learn the technology. However, Blender has a limitation on OBJ files, so we used 3D Max to deal with the texture coordinates. It is advised that future groups make a low poly version of their final models, because long loading times will make testing extremely slow. In order to bring the models into the game, we exported the models from Blender as Wavefront OBJ files, and imported them into the game using tinyobjloader. This library was very robust and allowed us to handle the Blender models perfectly. In order to actually present the vertex data in our shader’s format, we implemented a standard Renderable class that all rendered objects inherited from. Each vertex was represented by 11 single-precision floating point numbers sequentially:

  • The first three values represented the position of the vertex in 3d space.
  • The second three values represented the normal in 3d space.
  • The third three values represented the color of the vertex.
  • The last two values represented the texture coordinates.

We mainly used Photoshop and a Wacom tablet to create our textures. The textures were exported as PNG and loaded into our game using SOIL, which is an old but reliable OpenGL image library that made it extremely easy to make the skybox and textured features of the game. SOIL’s functions created OpenGL texture ids that could easily be integrated into the Renderable class as well. The Renderable’s render function finally set up the texture and model matrix environment for the object before calling the shader to render the vertices. In order to differentiate between textured and untextured models in the same shader, we used a shader integer as a boolean, because shaders don’t currently support booleans (or at least they are synonyms for integers). In addition, we had two other shaders for skybox and HUD.

 
Would you have rather started with a game engine or would you still prefer to work from scratch?

We would have still prefered to work from scratch, as it gives us more freedom to design and an opportunity to learn how to create a magical game. Looking at our final product we realized that we created it all.

 
For those who used a networking library (e.g., RakNet or Boost) or physics library (e.g., Bullet), would you use it again if you were starting over knowing what you know now? Describe any lessons you learned using it (problems that you had to troubleshoot and how you addressed them) for future groups who may use it. If you did not use a library, judging from the experiences of the groups that did, would you have used it in retrospect?

Our game did not require a very complex physics or networking, so we choose to do it ourselves and not use a networking or physics library.

 
What lessons about group dynamics did you learn about working in such a large group over an extended period of time on a challenging project?

It’s important that everyone contributes, knows who is working on what, and if someone is not contributing then something needs to be done because it will impact the rest of the group.

 
Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?

Assign tasks with deadlines starting week 1 using Trello or similar service. Smaller, more specific tasks. Mandatory group meetings (not with professor). Hold people accountable for assigned tasks. Be serious about the deadlines on Trello. Implement contingency plans if some tasks are not done.

 
Which courses at UCSD do you think best prepared you for CSE 125?

CSE 110 for large software design patterns and implementation. 124 for networking. 167 for graphics. 120 for low level knowledge and system design.
What was the most important thing that you learned in the class?

Software is easy, people are difficult. A large team of people contributes a lot of great perspectives, ideas, and expertise. Sometimes personalities and opinions clash, but it’s not an option to abandon team or nothing will be completed. Team issues are very important and should not be ignored.

 
Please post four final screenshots of your game on your group pages for posterity. I will also display them on the group web page.

At the bottom of screenshot page. 

What books did you find helpful that were not on the recommended list but should be?

We didn’t really touch any books. We Googled everything.

 

What books were on the recommended list but were not useful and should be removed?

Same answer as above.

 

I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?

TCP works fine. Try to meet with people in the lab. If someone is not contributing
or there is some other problem, let them know. Be direct. Be sure to go to the dry-runs near the end of the quarter so you don’t do bad things in the presentation.

 

How can the course be improved for next year?

Meetings not so early in the day when people are not awake, especially for Computer Science students. A few members of our team slept through meetings. Place a heavier weight on people’s course load when they apply to CSE 125. Maybe promote the course a bit more and create a way to form groups before the quarter starts.

 
Any other comments or feedback?

We really enjoyed the class and thank you for all the help and advice you gave us.

 

Comments closed.