1. Besides concepts we came up with in week one, not much. We completed all of our necessary features along with most of our nice to have features — and didn’t add or remove anything in between. Initially there was some vagueness in many of our ideas, as well conflicting interpretations of those ideas. For example, some of the group members did not expect 3D movement or realistic physics. Player movement went through about 3 major versions as we attempted to balance the physics of movement in space with controls that weren’t too unwieldy.
2. The first few weeks were very dynamic, but the design was quite solid and thus was not changed too much. Some things, like switching from UDP to TCP resulted from suggestions from the professor. Others, like sending game state changes instead of the entire game state came about through testing the game and seeing how things worked.
3. We were ahead of schedule in the first half of the quarter — about a full week. However, we did vary somewhat as the second half progressed, not sticking to our alpha or beta schedules (and adding features into the last week). Part of this could be attributed to fatigue, as our group worked pretty hard in the first few weeks.
1. Pair programming was not effective – it was used once. Most of our group worked from home and didn’t spend much time in the labs, and so it was difficult to organize peer programming sessions. Git was our VCS, and it worked quite well. The lab computers did not work very well. Git needed to be reinstalled every login, and for the first few weeks we weren’t able to determine where to save our projects so that they’d remain after logout, and that forced us to set up our project every time we logged in. There were also problems with the reliability of the data we saved, and at least one of us experienced multiple instances of data loss. Eventually most of us gave up trying to work on the lab computers.
2. Shaders and network packet deltas were much more difficult than they should have been. Switching from sending entire game states to sending deltas introduced lots of problems that took a lot of time to debug. Speakers were a major limitation on testing sound, but the implementation was relatively trivial. Physics and collisions were quite difficult, and underwent multiple total redesigns. Part of the problem with collision detection specifically was the lack of documentation on the specific model we chose (i.e. capsular).
3. The entire project. Every person is quite proud of each aspect – particularly the art, graphics, networking, sound, physics, and gameplay. The fact that the game was fun to play was very rewarding, along with how it was received by the demo viewers. In particular, it was enjoyable to see different players employ different strategies, including ones we had not completely anticipated, and more so to see those strategies work.
4. Controller vibration while being tractor beamed. This did not end up in the final release. Debugging the network. The lab software was difficult to use, and one group member lost all his work due to a problem with one of the computers. They didn’t appear very stable, and it became a big hassle to work on them. Installing VS 2010 also proved to be problematic for one of us.
5. Lines of code: ~16000 (wc on all git tracked files). We used C++, and while some of us wanted to use Java or C# instead, in the end C++ served us well.
6. Modeling: Blender. Textures and images: GIMP (Textures compressed to dds). Loading: D3D native loading. Texture loading: D3D native.
7. If we were making a game as a standalone project, we’d probably have used an existing engine like Unity. But building the entire engine was a great learning experience that is invaluable compared to the benefits that would have come from using a pre-existing engine. Some of us wished the class emphasized industry standards a little more.
8. Despite the networking code being difficult to debug, the network coding was a good experience and definitely worth it.
9. We should have play-tested sooner and more often, but most of the quarter went smoothly. We wouldn’t have changed much, aside from perhaps working closer together. Since everyone worked on separate parts of the game, we ended up working almost in isolation sometimes. Also: Andrew wanted HDR.
10. CSE: 120, 100, 131, 167, 160.
11. We learned a lot about debugging, and most of us developed some good debugging techniques. DirectX was completely new to our group, so using that was a great learning experience for our graphics programmer. We also learned a lot about physics and collision engines, and how to integrate a project with so many disparate parts, as well as how to keep code synchronized and updated amongst all of us. Also, the power of love.
1. Most of us used Google as our primary resource. Real Time Collision Detection was invaluable, and Game Engine Architecture was useful for explaining basic concepts too.
2. Plan early and realistically, work hard early and get ahead so that you can fix things later. And focus on fun (in the game and in the process). Don’t be too ambitious, and make sure you get a playable version of your game out as soon as possible.
3. More guest lectures, more overview on games and the industry.