- Game concept: How and why did your game concept change from initial concept to what you implemented?
Our game concept ended up being more simple than our initial concept. It is easy during the initial planning to come with all kinds of fun and cool features, but when it comes down to implementation and actual gameplay lots of things had to be cut not only to make sure that we could finish most of them in a reasonable time frame, but also to keep gameplay focused and fun given the demo environment. More advanced features like using units to settle new planets, separating the solar system more, and having a more complex upgrading system (among other features) all sounded great during initial planning, but as we prioritized features they were deemed less important, in part because they all slow the game pace and we needed the game to be pretty quick to stay interesting throughout the demo.
- Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
For all of the features that we ended up implementing, it has stayed pretty aligned with our initial design. The design of the networking code has stayed largely unchanged from initial design through to our final version. The strategies that we came up with for handling objects across the server and all of the clients has also remained largely the same. One difference for the game objects is that we initially wanted to have very basic identifying graphical information associated with the game objects across both the server and clients that the server would choose to ignore so that they could all share the same library of classes and sending typed objects over the network would be easy and no dynamic casting would be required. We ran into quite a few problems with this, mostly involving storing additional or optional graphical information, and so had to change this design which impacted how we wrote clientside code quite a bit, but left the server unchanged. One design that was changed almost completely was how the client would store the scene. We initially wanted to use a scene graph mostly just because that was how the week 1 miniature demo was written. When we started adding the network code and designing the core game object library we realized that it would be much easier to just store the matrices related to each object’s position, especially because all movement and animation was going to be done on the server side anyways.
- 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 final schedule lined up pretty well with the projected schedule for everything but the client work. Our projected schedule relied pretty heavily on the scene graph implementation and the expected visual work corresponding to our initial game concept and our planned features. We ended up going a very different direction with the client logic and we ended up cutting quite a few features and adding others that we didn’t foresee needing (such as coloring based on player, icon view, etc). This caused our actual schedule to deviate heavily. For gameplay logic the major differences ended up being features that we didn’t get to or decided to cut. For example we originally slated tech tree development to finish up during week 8, but we didn’t finalize it until the final week as it wasn’t prioritized over other features we still had left.
- What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
Our development workflow (github branch and pull request) ended up working extremely well. We could keep development going very consistently, no code was introduced without at least a little review, and everyone could see roughly what everyone was working on and what features were being added (meetings where we summarized our week and planned the next also helped quite a bit with this). One problem we consistently had with this was that during busy weeks, pull requests would build up quite a bit, but our mandatory team meetings would always remedy the situation. The weekly team meetings were always our most productive day of the week, and if not for scheduling conflicts I would have even liked to have a second because of the productivity it would add. Using slack also worked out quite well because everyone was generally quick to respond and helped prevent blocks. At a deeper level, separating the codebase into client, server, core library, and network code was hugely successful. People working on different parts of the code very rarely stepped on each other’s toes, and really helped push people to work together with whoever else was working on the same component that week. Merging was typically much easier as a result, and it also helped reinforce good style and design by mandating the separations we wanted between the different areas.
- Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
[Pereira] Fixing graphics bugs was the most difficult aspect of implementation in my experience. Getting a basic or nearly correct version was always easy, but fixing those last few bugs that sometimes were only happening on specific machines and not others was quite difficult and stretched my debugging abilities on more than one occasion. The lack of debugging support for shader code exacerbated the issue as well. Something that ended up being far easier than I expected was adding the UI. We went with the NanoGUI library and it was simple enough that UI development was extremely quick and relatively painless.
[Li] Since I have been mostly working on server end, it was astonishing to me how separate the client and server logics are. It was hard for me to find an efficient way to store and send information to the client to trigger the animation and delete the objects correctly. In order to make sure the game goes smoothly, we were trying to cut down the data volume, which required us to redesign the way we handle animation logics on both ends. It was also my first time using start pointers, which are immensely useful and sometimes a pain to manage.
[JJ] animation was definitely more difficult than I expected. I’ve done solely client side only animation, and it was quite simple to achieve, but incorporating the server logic introduced so many issues. Rotation should not take that long to implement.
- Which aspects of the project are you particularly proud of? Why?
[Pereira] I am particularly proud of the spatial data structure and the optimizations that go along with it. I implemented the octree, view frustum culling, ray tracing, etc at the beginning of the project in a pretty generic and extensible way, and it has served us well with very few problems throughout the quarter giving us a lot of extra optimization and utility as we implement new features and add more and more to the game world.
[Li] I am the most proud of the rotation, shooting and death animations for the units. Over a long process of developing for three weeks and multiple teammates’ effort, the unit attack look so cool and accurate. With the help of sound effects, the game felt real and playable.
[JJ] I am proud of the exploding spaceship and tracking icons simply because I never worked with geometry shaders before. To be honest, when Ethan first suggested it, I doubted the need for icons because it seemed like it would occlude the player’s view and be overkill. To resolve this, I had it as a toggle option, but still questioned it until I played the game with it and realized that it was quite helpful. I’m also proud of my teammates because they’re often and I swear that at least half of them are 10x programmers. I, on the other hand, am a -10x programmer.
- What was the most difficult software problem you faced, and how did you overcome it (if you did)?
[Pereira] Complete object selection using ray tracing was probably the most difficult single feature (excluding trying to work on stuff while sick). I have implemented ray tracing many times in the past, but never with this environment and version of opengl and so I ran into some oddities that caused me quite a bit of time lost searching for errors in the wrong places. I overcame it through extensive debugging to determine that code that I assumed was correct because it worked elsewhere turned out to be slightly off.
[Li] The most difficult problem I faced was communicating between server and client on signaling death animation when a unit dies. We also wanted to avoid sending a whole quaternion through the network each time a unit rotates. Our final solution was to keep the same copy of quaternion on both sides and made sure to update it with a rotational angle simultaneously. In order to make sure a death animation is signaled before a unit is set to idle state, we gave unit itself the power to input updates to queue on server end. This way the unit manager does not have to be overwhelmed with handling animation after an attack. It also gives us sufficient range to handle units through cities and much more.
[JJ ] Integrating with server code and knowing what to update. In addition, trajectory planning with collision detection. I noticed pretty much all the other groups implemented collision detection except ours, but our collision detection would have had to work differently. Rather than just stopping the model, or applying a simple force to it, you need to alter the path but allow the spaceship to continue to its final destination. It was not able to be overcome unfortunately. We got close (maybe 80-90%) there, but there were various issues.
- 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?
N/A
- 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.
Values found using “find [code files] | xargs wc -l” in bash
Client – 7,478 (6,879 C++, 581 GLSL)
Core – 4964
Server – 878
SunNet – 1831
Total – 15,151
- 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?
We cheated our way out of this as much as possible. The meshes in our game are either downloaded from a free online repository of models or generated directly in our code. As for workflow, for the code generated meshes we just used math to create the shapes that we wanted. As for loading models, we used the assimp nuget package (v3.0.0) and ran into relatively few issues because it directly supports the filetypes of the models and meshes that we had downloaded.
- Would you have rather started with a game engine or would you still prefer to work from scratch?
[Pereira] I personally prefer working from scratch. It’s very satisfying to complete a game after starting with nothing, and it forces you to learn a lot that using an engine would let you pass over. Part of me wishes we could have used an engine just so that our final product would likely be more complex / look nicer, but I think that the learning and satisfaction that comes with working from scratch outweighs that by quite a bit.
[Li] With a team of 6, working from scratch is viable and crucial towards the learning process. Even if we did not implement every fun feature that we wanted, I gained so much fun and satisfaction just by knowing that our system is quite robust and capable of expansion.
- For those who used a networking library (e.g., RakNet or Boost), a physics library (e.g., Bullet), or a GUI library, 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?
We used NanoGUI, which is an opengl UI library. If we had to start over, I believe we would absolutely use it again. It greatly simplified doing all of our UI work and let us very rapidly add features into the UI as we needed. A lesson that took a while to learn was that not using the form helper utility classes that are included ends up being a lot nicer because you have much more direct control and it is way simpler to create special windows by using the NanoGUI classes directly. However, for just standard windows the form helper stuff worked out just fine.
- 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?
There will be disagreements, from high level game concepts down to specific implementation approaches. However, as long as everyone is focused on making the game as fun and good as possible then compromises and resolutions will always be found through discussion. An important lesson is also that not everyone works at the same times. At a daily level or a weekly level, people are on different schedules and have different assignments due at different times and things aren’t always going to line up. It’s important to make small bits of time to review code, answer questions, and otherwise be available even at times that aren’t optimal for you to help keep the team moving along and make sure not to block anyone.
[Li] On the other hand, teammates are also your best teachers. I have probably learnt a lot more from my teammates than some of my CSE courses (partially because I have not taken some of the core upper-division classes).
[JJ] Group culture/ambience (I am forgetting the English word I’m looking for again) is important. Being part of two group projects this quarter, I definitely felt a lot more of a bond with my CSE125 group, which motivated me more. My teammates all got along and I never felt any hostility, which definitely results in a healthier and more productive work environment.
- Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
[Pereira] Looking back, I wish we had had more group meetups to work, even if not everyone could come. We were far more productive working together in person, so even if only 3 or 4 people could make it, having more regularly scheduled meetups would have helped us develop quite a bit. I wouldn’t change our workflow one bit, I really liked how it worked out for us. I also wouldn’t change our game concept much at all. Though difficult and complex, the RTS genre was a great goal that really helped me learn some cool things and also develop a greater appreciation for game development, especially large scale games.
[Li] Around Week 7, we started having “Super Days” where we just sat together and marathoned codes from morning to night. Those days were the most productive that we have ever been, partly because team members got stuck easily on their own. There could be blockages by other member’s features, or codes that were not understood. By sitting together in the lab, we communicated much more efficiently. I think we could have cut the long hours of meetings where we planned too much details, and instead code together more often.
[JJ] After seeing other team’s games I wished that we had focused more on the art aspect. I guess that for our games we had different needs, but I saw how much a difference having an artist was. Each team seemed to have either an artist or someone who volunteered to learn blender. We wouldn’t have had the luxury to do that since we were always time crunched as it is, but if our group had some additional members, it would be nice to have an artist. I would do the Thursday dev days again, because that encouraged me to actually focus on the project and allowed me to get help directly from my teammates.
- Which courses at UCSD do you think best prepared you for CSE 125?
[Pereira] I think that CSE 190 (Demo programming with Shacham) helped prepare me the most. It was a similar environment where you develop a complete game with a team, albeit a smaller game and a smaller team. The class is also much more focused on the specifics of the ZX Spectrums and hacks and optimizations for it, but the workflow with the team is similar and the amount of work you have to put in consistently throughout the quarter in order to have a fleshed out game at the end also prepared me quite a bit for the marathon of 125.
[JJ] CSE 167 – 169 gave me a graphics foundation for the class and CSE 110 helped me with understanding concepts of software engineering such as refactoring, class design, and agile development as well as working in teams. It’s a bit post-class since I just finished 112 this same quarter, but knowing some of the lessons from that class would have been useful in setting up a pipelining/development process as well. For example, (for who knows what reason), I always had the assumption that a real programmer writes everything from scratch, but this quarter I realized there’s no need to waste time reinventing the wheel if there are already tools available to you. I was slightly unaware of model loading libraries but I remember getting ready to write file parsing and model loading code from scratch had Dylan not stopped me and suggested using ASSIMP.
- What were the most valuable things that you learned in the class?
[Pereira] Modern graphics development and how to more properly use opengl were the most valuable things I learned. I have taken graphics classes and worked on my own with graphical applications, but always using older versions of opengl or very specific techniques. Getting to develop for what has to be a full game helped me learn quite a bit in that regard.
[Li] How to communicate and cooperate with people when working in a group, which I never learned from taking other classes at UCSD. This is the only class that I took where it involves both huge amount of coding and massive cooperation. As we approach to the end of our development process, no one knows everything about this game, which makes good API design and documentation extremely important.
[JJ] Pretty much anything my teammates taught me. I was glad that all my team members were smarter than me so that I could learn from them. I never knew about pull requests and how they should really work so for the first week of development, I had comments from Brandon about my huge pull request. At first I felt really guilty about it because I felt I had done something wrong, but fortunately my teammates didn’t put blame on me for it. Since then, I’ve learned/been trained in good practices for developing on small feature branches and making requests for peer review. I also learned modern OpenGL thanks to Dylan’s recommendation that we use that for our project. I don’t know if I would have taken initiative for that move if he hadn’t suggested it.
- Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.
- What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?
[Raj] Although it’s important not to get too bogged down in the details of software design in this course (for the sake of time and sanity), I found that the project presented a perfect opportunity to make concrete some of the abstract concepts presented in “Design Patterns: Elements of Reusable Object-Oriented Software”. The behavioral and structural patterns are particularly useful for interactions like combat. Keeping a general C++ reference manual is also helpful. I enjoyed “The C++ Programming Language” by Bjarne Stroustrup.
- I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
- How can the course be improved for next year?
- Any other comments or feedback?
