Final Report
A. In the project review document, start by addressing these main questions:
[Shuyuan] The overall concept of asymmetrical combat hasn’t change. For the god player it’s an RTS game. For the survivors it’s a shooting/rpg game.
[Kai Li] Our main idea didn’t change, however, we couldn’t finish all the fancy features we wanted to implement.
[Shuyuan] It changed a lot on the survivor players side, but not much for the god player. We initially planned to build a crafting system like Minecraft or Don’t Starve, and the winning condition for survivors is to build up a tower progressively to overthrow the god. Now it has become an arena-like shooting game, along with the skill system, whose concept is brought from RPGs like World of Warcraft. Now the winning condition for survivor is to destroy the obelisk/tower in the center of the map. The main reason of this change is that we don’t have enough people and time to finish an item system and a crafting system.
[Kai Li] Luckily, our software design didn’t change at all. We started with a simple implementation of the server and the client, and every time we wanted to add a new feature we just add a new function/handler to server and client class. Our initial design worked really well and there wasn’t too much refactor.
[Shuyuan] The graphic engine and animation took way longer than we expected, and that is a bottleneck for a lot of development.
[Haomin] I am not quite familiar with javascript development, so it took me some time to get familiar with the language and libraries. For the animation part, I changed among three different collada loaders and each of them converted data in a different way, so I have to change pretty much the whole animation system every time I try a new one. That also makes it hard to tell if the problem is in the loader, or is in my code.
[Lin] As expected, we were far behind the projected schedule. The projected schedule includes more features in gameplay and did not foresee the bulk of the work for animation. We deviated from the initial plan by designing and integrating our own models, animations and also changed the gameplay logic.
B. Then address these more general questions:
[Haomin] I guess one problem is that I did not have enough communications with others as I implemented the graphics and animation code. Turns out it can be hard for us to merge graphics and animations into other code some time.
[Lin] Having a product manager to guide decision making and assign tasks to group members makes the development process a lot smoother and faster. One downside of our group development process is that we don’t have a lot of formal group meetings to discuss and reflect on what each of us think and have done. We did not follow a very disciplined software development process due to lack of time and human resources.
[Kai] Unlike most other software development, we were lucky to separate tasks such that there wasn’t too much overlapping. Although we barely had time for formal group meetings, we were still able to finish our tasks efficiently and overall the project grows well.
[Shuyuan] The networking IO is easier than we expected. Since we are using JavaScript, all networking traffic can be handled with the Socket.io library, which is built upon the HTTP protocol. JSON is very easy to use with JavaScript and very efficient as well. It turns out to be a quite pleasant development experience around networking.
[Haomin] Even graphics and animation took me a lot of time, the implementation itself is actually within expected difficulty. For most of the time I was struggling with the libraries that lack document and reliability.
[Tianhui] JavaScript allows us to add properties to each object very easily. Instead of creating a separate new class that holds the extra property or passing extra params through functions, we can directly modify the objects from existing libraries as long as the change doesn’t conflict with existing functionality of library. Regarding the difficult part, there are not many detailed documentations for Cannon.js. Also it seems the author hasn’t added any updates to the repo for a long time. It becomes really difficult when I try to use shapes other than boxes in the physics engine, such as cylinder, and tweak the parameters to make the physics work as desired.
[Lin] I thought the most time consuming part of modeling would be designing and fine-tuning the looks of the model yet that did not take too much time. The more difficult task was to come up with a clean model, in which all faces and structures are positioned and angled in a necessary and minimal way. When I drew the player model, I had to connect the head with the body and there were a lot of small and disturbing faces in the neck part that could not be observable from the outside but adds more work to clean up and adjust when I tried to apply bones and animation to the model.
[Kai] UI was hard to make it look good. I spent a lot of time on it, way longer than I thought I would need.
[Shuyuan] The fact that everyone can join using just a browser. No client software is needed.
[Lin] The asymmetric design of game play, because it adds irregularity to the game and adds more fun. Making it web-based is also very cool because of its portability and light weight on the client side.
[Haomin] Three animation(collada) loaders. The first one store data in a convenient way by pre-calculating all the joints movement, made me think it is going to be easy. Then I found that this loader works pretty much only on the very collada file used in it’s sample code. The second loader seems to store data in a traditional way, but after finishing a whole system with it, I cannot make it play animation correctly. There is one section of data cannot be found in the original collada file, and I have no idea how should I use it. Eventually I go with the third loader, reimplement the animation system since it stores data in a new way, and finally make it work.
[Lin] Exporting animations as dae files from Blender. The default exporter of Blender somehow bends half of the player body in every animation so I had to search online for an alternative animation exporter.
[Shuyuan] JavaScript. We build the server upon Node.js, which is a popular web server framework. It is proven to be amazingly powerful and efficient, efficient enough to handle over 20 clients smoothly with 60Hz tick rate. (Actually we have never tested how high its limit can be. It handled a couple dozens of players, from both on-stage and public Internet, at the demo very well). The physics engine we used is Cannon.js, which is half-complete, yet still the most popular and the only choice when it comes to JavaScript physics engine.
The client is a combination of parser logic, 2D HUD, and actual 3D canvas. The parser receives data from server through Socket.io events and update objects to render. The HUD part is built with HTML, CSS, and JavaScript, which are very powerful and enough to implement astonishing visual effects. The 3D canvas is built with WebGL, which is a subset of OpenGL. All OpenGL knowledge applies here. Do notice that different browsers support WebGL differently. From our experience, Firefox has the best performance.
I definitely recommend JS. It is a whole new experience. It is a high level easy to use, very readable, and very efficient scripting language. Make good use of JS-only features like callback functions, promises, forEach, etc. Keep good moduality.
[Haomin] One thing I really like about JS is that you can console.log everything, the whole data structure will be there for you to check. This is really convenient.
[Tianhui] Compared with C++, we don’t need to handle memory allocation, although we did intentionally try to avoid large memory usage, and type definition in JavaScript. More importantly, it is single-threaded so we don’t need to write locks and create critical sections to handle multi-threaded issues.
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.
[Kai ] Roughly 2000(after all the deletion, 6000 - 4000). I didn’t commit any library codes so github’s number should be accurate
[Lin] 0
[Haomin] For model loading we used webgl-obj-loader: https://github.com/frenchtoast747/webgl-obj-loader, which works, just lack documentation. Main problem I encountered was when I load the mtl file, I recommend print out the loaded mesh to see how things are stored.
For animations, what we did was transforming collada file into json and read the json. We used: https://rmx.github.io/collada-converter/preview/examples/convert.html for this. The website has some problems when you shrink the browser, but it does play the converted animation to let you know it actually works, which is good. One problem with it is that it throws away the original keyframes and generates new ones, and the time interval between each new keyframe is very large. So to make this work you have to use the fps store in the converted json file to reset the time of each keyframe. The first keyframe should at 0 seconds and all the keyframe should be 1 / fps seconds later than the previous one. Occasionally, there are collada files it cannot convert, it there is no animation played in the preview window after conversion, do not use the converted json.
Both tools work, and there are not many tools that work for webGL, so would probably use again.
[Lin] For drawing the models and making the animations, I used Blender 2.79b. It is a powerful tool with more functionalities to explore, e.g. particle effects. It took hours to get familiar with all the keys and modeling techniques so start early.
The default collada exporter in Blender has issues with exporting animation so I installed a plug-in from https://github.com/godotengine/collada-exporter and used that to export animations from Blender to dae files.
Would you have rather started with a game engine or would you still prefer to work from scratch?
[Shuyuan] Definitely with a game engine, since I’ve been dreaming of making my own game. But still, it has been a unique experience, software-engineering-wise.
[Haomin] Let’s say we can save tons of time if we embraced the dark side and just use three.js to handle all the graphics and animations. But yeah, implementing these is always a good practice.
[Lin] I think either way has its pros and cons. Starting with a game engine enables you to focus on the gameplay and the looks while working from scratch makes the game more configurable and makes you learn everything underneath.
[Tianhui] We used socket.io for networking in JavaScript and it turns out to be a great choice. We don’t really need to define our own protocol, define the length of the buffer and write raw sockets. Socket.io handles all of the work underneath. It provides functionality to establish multiple connections, broadcast messages, and naturally uses JSON. We were able to build the networking very easily in the first two weeks and the infrastructure didn’t change henceforth.
For physics engine, Cannon.js was our choice. There are many other physics engine available, such as Ammo.js, which is a direct port of Bullet to JavaScript. We chose Cannon.js since it is light-weight, written in pure JavaScript and one academic paper ranks Cannon.js higher than all other JavaScript physics engine. It, however, hasn’t been updated by the author for nearly four years and doesn’t support features as comprehensive as Bullet. Judging from the experiences, I would use it again since the syntax and procedure to create shapes and add objects is quite straightforward.
One thing I have struggled using Cannon.js is its lack of documentation. It has a great demo page and API online, but there are not many StackOverflow posts or online websites where I could really seek help. If your group only needs to use basic bounding boxes and basic detection collision, Cannon.js is the one. However, if you need to build complicated shapes, JS physics engine that uses Bullet behind the scene may be a better choice as it supports more features and you could find more help.
[Tianhui] I am very satisfied with wordpress. The only thing I need to do each week to maintain our group web pages is copying from the weekly report on Google doc and directly pasting it to the posts created on wordpress. It also supports inserting Youtube videos and you only need to provide a url.
[Shuyuan] Please, learn Git. QAing code without Git or alternative version control is just a nightmare.
[Tianhui] Communicate often with your teammates not only when you are stuck but also when your work is overlapped with other people’s work. If you need to change other teammates’ codes either when you are reviewing or when you need to add extra features, do notify the author. Besides, make sure your local repo is updated with the remote one and use version control often.
[Lin] The importance of product manager to guide the development flow. In addition, more communication with team members.
[Kai] Without git it’s impossible to maintain a project, that’s the truth.
[Tianhui] I would suggest starting working on animations as early as possible, both the codes and modeling. Don’t underestimate the workload, as animation is the hardest system in making games but it also determines how attractive your game is on first impression. So do reserve enough time in developing it.
Do develop a robust lobby system to support multiple games at the same time if you plan to release your server ip address to the audience and let them play. Make sure that you could still demo your game and become one of the actual players when numerous enthusiastic Twitch audiences join the lobby.
[Lin] Start on modeling early so that we have more time at the end to refine and use project tracking software to make clear all the priorities and our development speed.
[Kai] I would try to squeeze more time to work for this project. I couldn’t commit a lot of time into it this quarter due to taking too many classes, and it’s just not enough time to implement more features.
[Shuyuan] CSE123, 124, 167. COGS 120/121 for JS.
[Haomin Wang] CSE167 for graphics and CSE 169 for animation.
[Tianhui] CSE 110, CSE 120, CSE 124, CSE 123 (not as useful as 124)
[Lin] CSE 110, CSE 112, CSE 167, CSE 124, CSE 134B, CSE 135
[Kai] CSE 110, CSE 123
[Tianhui] Don’t consider the project as a pure assignment or as a replication of future rigorous workspaces. Make friends, enjoy the whole experience and have fun playing your own game.
[Lin] Making art is fun, even for CS majors.
[Kai] Never underestimate the time it takes to implement new features. Even if it looks very simple, be conservative and expect to spend more time on it.
[ ]
C. Finally, if you wish, I would appreciate any feedback on the course (entirely optional):
[ ]
[Shuyuan] Be productive. Be responsive. Be responsible. Communicate. Ask for help when you are stuck. Again, learn Git.
[Tianhui] Wordpress is great!
[ ]
[ ]