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?
Our game concept went through a dramatic change. Initially we planned to make an FPS game with a portal feature. However as our engine kept evolving, we thought that using the new features implemented such as skeleton animation, particle system, PBR shader, etc, we could make something more visually appealing. Since some of our team members were huge fans of the new game Elden Ring, we decided to make a game with similar gameplay mechanics and magic.
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
In the initial design of the magic game, we planned to add 4 types of magic and each type has 3 dedicated magics, so each of the 4 players of our game can choose one of the types. However, in the final project design we only kept 4 magics. This is because making good quality magic was a lot harder than we thought it would be. Instead of having 12 low quality magics, we rather have 4 high quality magics. In the initial design, we also planned to implement a lot of other cool features, such as letting players customize their character, choosing their outfits, magic combinations, allow players to block or retaliate others’ attack with a magic shield, melee magics… These features were all abandoned because we didn’t have enough time. (Zifan)
We originally planned to make a shooter game with portals, but in order to achieve advanced effects, we changed to a PVP game with a mostly magical style. (Kangming)
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 is much behind our projected schedule. One major reason was because many small features that we thought we could finish implementing in one or two days actually take up a whole week. For the large goals, we had to revise many times because the engine was evolving and our programmers were also getting better at using the features of our engine. For example, in week 5 we made the fireball magic, in week 7 we changed that magic from emitting one fireball to emitting 10 fireballs at a time, and in week 9 we were able to optimize its construction and its particle effects to boost the loading time and FPS of the game. Without the effort we put in to optimize and refactor our code, our game would be too slow to be playable. Optimization and refactoring are important, but we didn’t plan enough time for them in our initial schedule.(Zifan)
We had planned to implement the magic upgrade system, but the design of the magic class was not scalable and time was limited, so it was not implemented. For character models, we planned to have two sets of character models, but in the end we didn’t make them because we spent time on other things that were more important. The last week was supposed to be spent testing the game, but careful testing, such as unit testing, was not done because important features remained unimplemented. (Kangming)
What software methodology and group mechanics decisions worked out well, and which ones (if any) did not? Why?
We didn’t use a software methodology, we had an unclear goal and just kept working towards it. Although we gained a lot of freedom in development since It didn’t work out well because the plans we made were not detailed enough, so we often ranran behind the schedule.
Which aspects of the implementation were more difficult than you expected, and which were easier? Why?
Many aspects of the implementation were more difficult. For example, we expected to spend one week modeling the character and the map. However, we actually spent more than three weeks on them. The details of the map, the skeleton and animation of the characters takes far more time than we expected. The implementation of magic and visual effects were easier. Thanks to the powerful engine that Kelin built, we were able to make appealing visual effects and magics in a relatively short time period. (Futian)
The network module was easier to implement than expected. Because the network environment of Demo is very stable, the network implementation can not consider some complicated situations, such as TCP connection break or frame synchronization lag. Although we mainly develop in the OS system, the implementation of the cross-platform development of the network module is not particularly difficult, just adjust the use of some network interfaces. The process of setting up a project on the Windows platform was more complicated than expected. Since our development is mainly in Xcode, we need to implement cross-platform development to adapt to the environment of the Demo machine. To facilitate the rapid creation and compilation of VS projects, projects need to be converted to Cmake projects, which is a complicated process, especially writing automatic Cmake files. Also, some libraries that can be easily used in the OS system, need to be manually set up and compiled in the Windows system, especially the MD/MT Settings of the Protobuf library. In addition, designing the game flow and integrating the game flow into the network was more complicated than expected. (Kangming)
Which aspects of the project are you particularly proud of? Why?
Among all the components of the engine, the particle system is probably the most powerful one because it is capable of making almost every visual effect while being very efficient. (Kelin)
The modeling of the character, map and the visual effect of the magic. We spend a lot of time modeling and tuning them for better visualization. In the end, they appear to be visually appealing. (Futian)
I am very proud of the magic effects in the game because they are so cool. (Kangming)
I am particularly proud of the technical part of our game, we supported many advanced features such as particle system, skeleton animation, PBR shader. We also had a very detailed map and character with high resolution textures, but our game still can run in over 60 FPS even in multiplayer mode.
What was the most difficult software problem you faced, and how did you overcome it (if you did)?
There would be no problem at all if there was more time. Once again, the greatest enemies are ourselves. (Kelin)
Our game still had low FPS in the last week, which really affected the visual experience of the game. After carefully analyzing the time spent in each process of the game, we found that the rendering time and network transfer time were very unstable. For rendering, we optimized the resources, and finally greatly improved the rendering speed. For the network, we changed the client-side process so that the server-side processing of data (including network packet transfer) and client-side rendering take place simultaneously. In the end, we significantly increased the FPS of the game, making the graphics very smooth. (Kangming)
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++, but we barely used the new C++ features, such as smart Pointers. C++ is a language that requires developers to manage memory, so this can cause a lot of memory problems, but smart Pointers can help us manage memory and prevent memory leaks. We still had memory leaks at the end of the game, so we suggested that future teams use smart Pointers, a very necessary feature.
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.
Here is the data provided by the VS Code Counter plug-in. All code that we didn’t write has been removed. (Kangming)
For the KGLEngine, there are 9442 lines of code. However, if you want to include all the experiential projects, variations, and the new Vulkan engines (the depreciated Syrina Engine and the Evanescence Engine in-progress), you probably have to multiply that number by 20. For our game (including the engine), there are 26952 lines of code. If you wonder why there are so many lines, please take a look at the ImportMapHelper.cpp with almost 6000 lines of code, written by another program developed in Swift. (Kelin)
The command we used to count the number of lines of code:
find . "(" -name "*.h" -or -name "*.cpp" -or -name "*.hpp" -or -name "*.vs" -or -name "*.fs" ")" -print0 | xargs -0 wc -l
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?
We used Maya (Education Edition, free for download as students) for 3D modeling and the Assimp library for loading models. Although the Assimp library supports almost every format and is very convenient, sometimes it just doesn’t work and we have no idea why. After days of experimentation, we discovered that the DAE format always works when using MAYA’s default export options.
Maya also can edit texture and animations.
Would you have rather started with a game engine or would you still prefer to work from scratch?
Starting with a game engine will reduce the amount of work in the future. Starting directly with the game will certainly make the game more efficient because it is like making an engine just for that game. We choose the first option.
I’d like to start with the engine. Engine development is a very interesting process. Also, for our own engines, we can quickly add or modify the features of the engine based on the needs of the game. (Kangming)
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?
For the network, we use the Windows winsock2 library and the Linux socket library. Combining this basic socket library with the Protobuf library is sufficient for the development of the network module of this project, and it can help us understand and learn socket programming from scratch. Protobuf is a very convenient tool for serializing data structures and generating network package data, but requires careful reading of the development documentation.
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)?
We were not satisfied with wordpress, because the permissions were annoying, we had a hard time trying to upload images, install plugins and themes. The UX design of wordpress is also terrible, it claimed that it is customizable, but I can’t even change the background image, or the button of changing background image is just hidden in a place that normal users cannot find.If I had a choice. I would just use a markdown like platform, such as notion, or just github readme.
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?
I would definitely recommend discord. Discord is a convenient way to communicate, especially for large group projects.
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?
We learned that working together in-person in a group is much more efficient than working remotely and independently, because when we meet in-person we are less likely be distracted by things that are not relavent to the project. We can also communicate better as we can just talk face to face and share our screens to each other directly. We also had better mood and became more excited when working in-person. (Zifan)
We should have concrete goals throughout the development process. Everything should be planned ahead of time to avoid accumulating all the work at the end.
It was a great idea for all of us to program together in a room, and it made us more efficient. In addition, a clear and reasonable allocation of tasks is also necessary. Since there were only five members in our group, we clearly knew what module we were mainly responsible for, so everyone had a clear goal.(Kangming)
Looking back over the past 10 weeks, is there anything you would do differently, and what would you do again in the same situation?
I wish I could do everything again with Vulkan. It will take slightly longer to get started but will much cooler. (Kelin)
I might choose to be more involved in engine development, because game engines are the soul of games, so I’m very interested in that. (Kangming)
Which courses at UCSD do you think best prepared you for CSE 125?
Russian literature courses maybe. (Kelin)
CSE 167, 169 about graphics and animations.
The most important is CSE 167, because game development needs to have a graphics foundation, so as to properly implement or use the game engine. CG production in the game is also inseparable from CSE 167’s third project. CSE 123 is also useful for network modules. Although CSE 123 does not cover socket programming, it will help you set up TCP and recognize transport layer bugs such as unpacking and sticky packets. (Kangming)
What were the most valuable things that you learned in the class?
Experience to make video game. How to use softwares, like Maya, Unity, how to create model, texture, animation, how to write shaders, how to build gaming network, etc.
The general development process of the game, the required modules, and the corresponding implementation methods. (Kangming)
Please post four final screenshots of your game on your group pages for posterity. I will display them on the group web page.
What advice/tips/suggestions would you give students who will take the course next year?
You will eventually accumulate all the work until the very last moment. So you should always keep that in mind, be prepared, and try to avoid it.
Plan your course schedule in advance and be sure to take CSE 167 in another quarter. Plan your time wisely and identify the main content of your game early on. (Kangming)
How can the course be improved for next year?
The course is amazing. It would be even better if all groups has 7 people.