Final Report

A. In the project review document, start by addressing these main questions:

Game concept: To what extent did your game concept change from initial concept to what you implemented? If it did change, how did it change and why?
1. Our game concept stayed relatively the same from the initial concept, and we even had lot more than original idea. There were only a few things that changed like the win condition, player perspectives, and bribing NPCs. Our initial idea for winning was the first player to make a certain amount of money would win, but this ended up being who had the most amount of money at the end of the 12 minutes; we thought this would be a better game design choice for players to make comebacks. The intended perspective was originally going to be primarily top down, but this eventually evolved into allowing the player to move their camera around more freely. We also didn’t end up implementing NPC bribing, but instead focused adding more sabotage items. – Leon
2. There were also other ideas in the beginning that were considered but were ultimately forgone in order to focus on farming and sabotage. The idea of an economy and playing with supply and demand was tossed around (the Market in Farmer’s Market), where the vegetable buying and selling prices would have been adjusted depending on how popular an item is being bought/sold. There’s a little bit of old concept art somewhere that had to do with the proposed basket/inventory UI for when the player would be carrying more than one item. And there was some brief discussion on plant genetics, mixing different crops and selling them at certain prices, but that would have been a whole other layer of complexity! – Cher
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
1. We initially decided to make a farming game like Stardew Valley and animal crossing so we can add pretty scenes and models to the game. The sabotaging functions were putted as additional nice to have features to increase interactions between player but we somehow ended up making a sabotaging game instead of farming game. I think the reasons are: first it is difficult to make our game-play unique if we focus on farming because there are already a lot of good farming games and also human nature make us want to mess around with other instead of producing. – Jennie
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.)
1. We actually got way more done than we expected. We initially had our “must haves”, “nice to have”, and “reach” goals and we implemented all of them. We made our project very scalable so our MVP was done by week 6, and our actual game was done by week 8. After that, it was all debugging and polishing which was very nice! We were always ahead of schedule! I think the reason we were so far ahead is because we planned out our project thoroughly before starting to implement, so adding features was very easy. That, plus because everyone was super hard working, some people literally coding until 4AM or waking up at 5AM to code- Danica

B. Then address these more general questions:

What software methodology and group mechanics decisions worked out well, and which ones (if any) did not? Why?
1. Git rebasing instead of git merging is especially nice, since we can easily trace back the person who made the change (git blame) and ask whether our new code will conflict with their changes. – Nick
2. Voting and group consensus definitely helped everyone feel like it’s the group’s decision as a whole. – Nick
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
1. I initially thought the networking will be more difficult like it will just randomly not working as we add new things but it didn’t. Maybe it is because Nick has just covered all the edge cases ahead of time. Loading models and animation are much more difficult than I expected, I spend several hour just to read the code of model loading to make the loading bar and it seems impossible to to multiple thread without refactor half of the code ( but Nick did it!! All Hail Our Frat King) . – Jennie
2. I really expected the physics engine to be extremely easy, since we were able to get circle-to-circle collision detection and resolution for non-static colliders done very quickly. However, after needing to expand our engine we found problems with AABB colliders that we still weren’t able to fix perfectly by the time of the demo, and the static circle colliders were a lot less smooth than I would have preferred. – Jakob
Which aspects of the project are you particularly proud of? Why?
1. I loved our characters and UI. They add a personal touch to our game that can’t really be replaced! – Danica
2. The network API I exposed to the rest of the project. I made the network method take in a function for the game logic, so I can completely separate game logic with networking code and no one other than me has to touch the sockets part ever – Nick.
  - I agree with this, working on game logic was very easy due to the fact that sending new messages back and forth between the client and the server was trivial due to the functions Nick made for serializing and deserializing packets. Would be incredibly versatile for any type of game we wanted to make! – Jakob
3. I’m really proud of how the sabotage items turned out! It ended up being our main mechanic and was really fun to play around with. – Leon
4. The day and night phase – Cynthia (and Nick too even though I didn’t work on it)
5. The character models and store UI! Also the sabotage tools mechanism. – Jennie
6. Definitely the UI – Cher
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
1. Loading in the animations initially was pretty hard. We didn’t know if it was Maya or Assimp causing the problems, it was a lot of back and forth, reexporting and bug fixing without knowing exactly where the bug was. – Danica
2. Installing library and use visual studio in general. I just real all the post and document I can found and somehow it works. – Jennie
3. Visual Studio was sometimes being difficult since I think some of us at the beginning were using different versions. There was also a glfw3 dependency issue that was acting really weird with the project file (thanks Alex). – Leon
4. Visual. Studio. Is. Fiddly. – Nick (p.s. I have no idea how IntelliJ’s IDE is so much nicer to use than VS)
5. I still can’t get my head completely around how to get C++ libraries to work sometimes, it feels like sometimes they magically work for some reason, and sometimes they magically don’t. Nuget is a life-saver since it does a lot of stuff automatically for you, and progress significantly sped up once we got all of our libraries in place – Jakob
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?
1. We used C++. (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.
1. We used a tool called scc to count our lines of code (https://github.com/boyter/scc/) excluding libraries and any other files that weren’t our .h, .cpp, and glsl files.

Language	Files	Blanks	Comments	Code
C/C++ Header	47	10302	1463	7551
C++	36	999	490	4549
GLSL	25	276	194	1000
Total	108	17810	2147	13100

Lines of Code

In developing the media content for your project, you relied upon a number of tools ranging from the underlying graphics libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students in future years 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? Are there any tools that you used but, looking back, you would avoid?
1. We used Maya to make models and animations, and Assimp to load them into our game. We also used Blender as an inbetween modelling software. Making models and animations in Maya was very easy and fun for me but it’s likely because I had experience with it. When exporting models in maya, always delete the history (to reduce file size) and freeze transformations (because Assimp doesn’t like it when transformations arent frozen). Exporting it with the game exporting function allows you to export multiple animations in one FBX file. If assimp has trouble loading in models/animations, load the FBX file into blender and then reexport it from blender. You may need to reassign textures when moving models into your github repo. I definitely recommend using Maya to make models + animations, the only thing that can limit your creations is imagination! – Danica
2. Going more into detail about loading the models and animations, (note we used 5.2.3) .dae files work fine if they are exported in Maya, and .fbx files work fine if they are exported in Blender. BUT .dae files do not work when exported in Blender and .fbx files do not work fine if they are exported in Maya. assimp had a newer release about 27 days ago as I write this, so maybe that is now fixed. We also used the stbi library to load the textures. Though I would recommend Blender as opposed to Maya because it has more resources online and it is free, unless someone in your group is already experienced in Maya (Danica in our case). This also prevents you having to export in Blender after exporting in Maya (I still do not know how I even figured this out, my brain just told me to export Danica’s models in Blender and kaboom it worked). Also, technically you can still export multiple animations in Blender with just one file, you just have to make use of NLA Action tracks. Writing code for animations and loading meshes was very experimental working with different libraries and stuff, so for whoever is working on it just make sure communication is strong with whoever is doing the 3D modeling. – Cynthia
Would you have rather started with a game engine or would you still prefer to work from scratch?
1. Building the game engine from scratch is a once in a life time experience that can’t be replaced by making a game in Unity or Unreal. Being able to design exactly how everything works and interacts to fit our needs was really challenging and fun – Danica
2. Having had experience in Unity, I still believe that this class benefits from having to build the game from scratch. It taught me a lot, and gave a lot of insight on what actually goes on when working in a game engine. I think implementing these systems ourselves gave us a lot of experience for the future, even if we decide to work in a engine. – Leon
3. We might be able to make the game more fancy if we started with a game engine but building the game from scratch allow us learn much more in the progress and there are more freedom in design. So if we use an game engine in the future we actually know what’s going on underneath.
4. Adding on to the three excellent points above, I think building our game from scratch also allows us to practice design patterns and really see the implications of our design (both good choices and bad choices). – Nick
5. I agree that building a game from scratch was very good practice for having to come up with solutions to problems that you wouldn’t have to deal with in a game-engine. How should we send information from the server to the client on what to render, how should we figure out how to send inputs to the server, how do we update our game with these inputs, how is sound going to run, etc. For future projects, now that these are problems I’ve already encountered, I would prefer to work with more libraries that solve these problems better than we’ve solved them (a higher level networking library that provides less lag over wifi, an input library that works with controller input, a higher level graphics library like The Forge) so that we could focus more on gameplay. – Jakob
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?
1. We used winsock2 for network. I personally think winsock2 is pretty good? It has all the basic function we need and gives a lot of freedom in network system design. Since we are relying on short network latency time of local connection, it might be better to use a different library if we want to optimize the network connection under wifi. But winsock2 should be good enough for the demo. -Jennie
2. We used Winsock2 for windows, which is basically the built-in sockets library. I was fine using winsock because I knew how sockets work and we didn’t really know the exact networking requirements going into the project, so we wanted to take the most flexible path. But I don’t think using raw sockets are particularly hard, but maybe that’s just because I haven’t used a networking library that makes a huge difference yet. – Nick
3. We used Imgui for GUI. I never use other GUI library before so I don’t know if other library will be better but Imgui is really not made for building a complex 3d game ui. The good side is that imgui is real time and pretty fast as it just use the same buffer as the 3d model but on the other hand it is very difficult to style with imgui. I didn’t want to re-install another library/environment so I made it work but with very bad coding style as no-one else is gonna touch it besides me. – Jennie
For your group web pages, we used wordpress. Were you satisfied with wordpress, or would you rather have used some other system for maintaining your group web pages? If you had a choice, is there another system would you have preferred to use (or even just doing everything on your own using HTML, CSS, and JavaScript)?
1. WordPress was alright. I’d much rather use wordpress than write all of the HTML, CSS, and JS from scratch just because it’d be a lot of extra work on top of the project. I’d be interested in other website making options though – Danica
2. I’m satisfied with WordPress. It will be fun if we can customize our website more though. – Jennie
3. WordPress is much better than raw HTML + CSS, since we can easily customize the look without having to actually maintain an entire website. However, I do think the list numberings are sometimes a little buggy. – Nick
4. WordPress was ok for the type of site that we were doing, however, I’d imagine there are much more lightweight systems that also allow for multiple people editing the same post at the same time. Even .md files with a custom theme wouldn’t have been too bad!
This is the second year we’ve used a discord server for the class. Would you recommend that we continue using discord in the future?
1. Yes!! We used Discord for our group and it made everything extremely convenient (probably because we’re gamers) – Danica
2. Yes x 2 !! – Jennie
3. Yes x3 – Leon
4. YES x4 – Cher
5. Yes x5 -Jakob
6. Yup, it also made collaboration easy since people can just hop in and out of the voice channel without having to set up an entirely separate call – Nick
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?
1. Ask for help when you need it. Everyone in our group was super kind and helpful, so getting help from each other increased communication and made development much easier. Just talking each other and planning together allowed us to get more done too. I think our group dynamic was amazing. A sign of a great team is the creation of long lasting friendships that we’ll likely reflect upon with “back in my day” stories. – Danica
2. Communication. I really enjoy working and just hang out with our group. Communicating over 125 and no-125 related topics built trust and friendship among us and it just make work much more efficient. – Jennie
3. I have to agree with the points above. Everyone in the group was super understanding and helpful when it came to development. Overtime, our group got a lot closer and trusted each other. I think initial planning and meeting often allowed us to get everything done on time. – Leon
4. Communication and team-working skills. I tend to be a bit more on the reserved side and do work alone, so I thought I could get away with just doing my own thing since I was the only one on graphics but I was wrong (thankfully). My team was really nice, and getting comfortable with them made me not feel anxious about communicating. – Cynthia
5. How strong an open and receptive team can be. It’s been really nice to be able to bounce ideas off each other and knowing how to work with one another as someone who tends to struggle with communication, and this team has been one of the most welcoming I’ve ever been in. – Cher
6. I think we really lucked out with our superpowered little team. We were super well balanced in terms of areas of expertise (Cynthia with OpenGL, Cher with 2D art, Danica with 3d Art, etc.) but more importantly than that, the friendships that we made with each other allowed for us to have a more open environment in which communicating was easier, and in my case I felt much more motivated to be a reliable and accountable group member.
Looking back over the past 10 weeks, is there anything you would do differently, and what would you do again in the same situation?
1. Refactor the code as I wrote it and not procrastinate like ” I will just refactor everything all together after I am done” because you will just procrastinate until the end of the world. – Jennie
2. Looking back at this quarter, I definitely wish I had a smaller workload in terms of other classes, personal project responsibilities, and work so I could’ve gotten a healthier sleep schedule. But everything worked out in the end! – Leon
3. Use ECS game logic instead of object oriented design! I would have been a cool thing to explore, would have given us way less problems, and could have sped up the development a bit, allowing for a more polished game
Which courses at UCSD do you think best prepared you for CSE 125?
1. CSE 167, 168 and 169 for graphics. CSE 123 and 124 for networking (@nick). MGT 172 for project management ? I know business majors have a bad rep, but knowing both the software aspect and the how to plan and assign tasks accordingly was pretty helpful. – Danica
2. CSE 110 and 124 – Jennie
3. CSE 167 and CSE 110
4. CSE 110 (design patterns), CSE 123 (fundamental networks), CSE 124 (sockets), CSE 120 (multithreading)
5. CSE 123, 167, and 169 seem to have the most use of designing the game, and CSE 110 was good for having previous experience working as a team with source control.
What were the most valuable things that you learned in the class?
1. How to work as a team! Turnout the most important part of good team working is hotpot and milk-tea and not what we learn in the cse110 lol. – Jennie
Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.

C. Entirely optional, I would appreciate any feedback on the course:

What advice/tips/suggestions would you give students who will take the course next year?
1. Get to know your team. The better your team dynamic, the more you’ll get done, and make sure there is psychological safety. Also, don’t be afraid to start coding. Get the ball moving early because seeing things get accomplished motivates everyone to get working. – Danica
2. Enjoying the time with your team as much as possible! The sad part of taking this class in Spring quarter is that we just get to be best friends and then we have to say goodbye because everyone’s graduating QAQ. – Jennie
3. Take the time to really enjoy the class because time goes by really fast! Get to know everyone on your team early and establish a workflow. – Leon
4. Friendship is magic – Jakob
How can the course be improved for next year?
1. Make the class last for 20 weeks (2 quarters) 😀 – Danica
  - Even if this is a joke this would be a great idea. I know the Music department’s ICAM major has a senior project class that lasts for 2 quarters, and it gives them a lot of time to develop some amazing content before they graduate. There’s a lot I would go back and do differently having the knowledge we have now, and having the extra opportunity to take another shot at it would have been amazing – Jakob
Any other comments or feedback?
1. WE’LL SEE YOU AT THE 2023 DEMO PROFESSOR VOELKER ?
2. REUNION AT DISNEY LAND NEXT YEAR!!

Leave a Reply Cancel reply