Group Final Report: Week 10

Game Concept: How and why did your game concept change from initial concept to what you implemented?

Our game concept stayed steady through the entire quarter actually. This was the only thing that stayed steady through the quarter. This can probably be attributed to the fact that we got together as a group and all agreed on the game concept but not much else. There were of course features that were brain stormed up that were not implemented (either because they were too hard or there just wasn't time), but we all had the same basic vision in our heads while coding. We wanted a fairly simple (low-content) fast paced action game that was possible to pick up and play quickly. Game mechanics such as win conditions changed along with other balance issues, but the battlecube still remained. RIP The smart tetris block generator thingy that was going to sit in the middle of the world.


Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?

Design... what design?

We never really had all that much of a design to begin with, other than some simple diagrams Martin made that nobody paid attention to after the first week (sorry Martin). Our eagerness to get a jump start on what we felt was a cool game idea led us to do some well-meant (albeit unused, ex. Visio document) stuff, but mostly we just wanted to code up something that was playable as soon as possible.

We planned from the start to have basically two layers to the project: game engine, and game application. Almost everything except physics, game logic, and game object management lived in the game engine. This means that we could, in theory change the game application to a wholly different game without having to change too much of the underlying engine code. The main difference would be that there was much more cross over between the two layers than originally anticipated. Making the application a little too tied into the engine code.


Schedule: How does your final schedule compare with your projected schedule, what are the reasons for the differences?

The original schedule was terribly optimistic, calling for a finalized game by the end of 7th week, using the last couple of weeks for testing and tweaking game feel. While we did have a networked functioning game pretty early on, we were missing milestones left and right. We were working up to the last minute putting in content and balance changes.

One of the problems was our list of absolutely necessary items was entirely too conservative. When we had these implemented (poorly in some cases) we moved on to the more fun features. This was a mistake, as the core features either never got fixed or were fixed very late in the game. I think our schedule didn't really reflect the way we coded, so we ignored it completely. Some things on the schedule never got implemented, while other features not on the schedule were added because it was easy at that point in the code.


Methodology: What software methodology and group mechanics decisions worked out well, and which ones did not? Why?

As far as decisions about the game, the good ol' simple make everyone think your way worked out quite well. We were lucky that there was usually a consensus on game play issues. This allowed us to split up the project into smaller pieces that teams of 2 could handle. These mini-teams could then quickly make design decisions about their specific module while keeping in mind the decisions about the game in mind.

Breaking up the game into modules and working on them separately was definitely a huge help, and to be honest I don't know if we could have done it any other way. Working in the lab together a lot was nice too because it allowed us to quickly ask questions about each others code if necessary, rather than spend hours trying to figure out how it worked ourselves.

Our methodology kind of broke down when we stopped communicating what we were doing and each module started to just grow without input from the group as a whole. In a way, it showed how the modules were fairly separated (good), but it also showed that our group meetings were non-existent and everyone was just adding stuff on their own (bad).


Implementation: What aspects of the implementation were more difficult than you expected, and which were easier? Why?

Physics turned out to be a lot harder than anticipated. We had expected this part of the game to go decently smoothly considering our game was fairly small. However, we ended up with only one person working on physics and that turned out to be insufficient for the task. Some of the mathematical complexities with the three-dimensionality of the project where unforeseen and took considerable brain power/time to resolve.

Getting the initial networking set up and working was easier than expected, due to RakNet's helpful tutorials and nice, clean API. But, figuring out exactly what to send, when, and how in order to keep the server and clients running smooth was tougher than originally thought. Adding extra features like powerups wasn't too bad, due in part because of the fairly well organized system we had in place already. <ED: multipliers, we need more multipliers!!>


Tools: What other tools or libraries would you have seen to be useful?


Caught in a RakNet: Would you use RakNet as a networking library again? Why/WhyNot? ?

Patrick, our networking gawd says:
Using RakNet from the beginning allowed us to get networking up and running quickly, because RakNet provides a clean, easy to use API that for the most part does not require the programmer to deal with the low-level issues. As a result, our networking was integrated into the main project early, and from that point onward the code was written with the client/server relationship in mind. This was very beneficial over, say, trying to insert multiplayer capabilities into a game that was previously developed for single player.

Another beneficial aspect of RakNet is all the statistical data that it provides. The stats are easy to get to, easy to use, and can come in really handy when debugging a network issue.

We did have a few problems and those took quite a while to resolve. Our networking wasn't working smoothly with 4 players until the end of 9th week when we finally found out there was something within RakNet that needed to be adjusted (see below for more details).

So, RakNet wasn't all fun and games - it definitely had its frustrations, as I imagine any networking library would. All in all, though, I think the pros outweighed the cons, and I would probably choose to use it again. The only reason I would use something else like Winsock would be to get more experience with lower level networking, which would be cool, but then we probably wouldn't have been able to get as many networking features into the game.

Lessons learned from using it and advice for future groups

Keeping things simple is probably the best way to go, at least for the purposes of this class. Just throttle the server to update 30-40 times/second - subtract the difference of your server update execution time from your target update period and sleep for that long, making sure it's at least 15 ms or so to give your network thread enough time to send everything it needs to. You can send all the normal updates in one big packet (you shouldn't need to worry about MTU size) and use separate packets for the less frequent updates.

Here's where I describe some problems we had with RakNet and how we overcame them. Originally, we tried to use a system that RakNet provides called the Replica Manager. This allows for "replicated objects", which are automatically serialized/deserialized through RakNet. However, we soon found that this system was creating lots of network traffic, which would fill up the server's send buffer and cause lag. To fix this, we ended up rewriting a large chunk of our network code to still use RakNet, but only the basic capabilities (not the Replica Manager system), so we handled all the sending/serialization stuff ourselves. This helped reduce the amount of data we were sending by about an order of magnitude.

We also had a send rate problem with RakNet. Basically, RakNet was waiting too long between sending packets, so they weren't all being sent in the time allotted to the network thread. We fixed this by adjusting a variable within RakNet that controlled the maximum time to wait between sending packets. Here is a RakNet forum thread on this topic. In case that link is broken, I changed MAX_TIME_BETWEEN_PACKETS in ReliabilityLayer.cpp from 100000 to 1000. By the way, I would definitely recommend utilizing the forums. There are lots of helpful people there, including the author of RakNet.

I would advise using UNRELIABLE_SEQUENCED priority for messages that are sent every update, and RELIABLE for the more occasional ones. This is exactly how we did it (eventually). If you're having issues with lag, look at the send buffers first (available via RakNet statistics), and see if they're filling up. If they are, you're probably sending too much too fast.


Engine: Would you have rather used a game engine, or work from scratch

Those who support creating a game engine from scratch say 'yay'. Yay! Yay! Yay! Yay! Yay! Yay!
All who oppose it, say 'nay'. *crickets chirping*

By a unanimous vote, we all say it was worth it creating our own game engine. Yes, it would have been easier to build something from the Source engine or Ogre, and it would have looked much nicer than our game, and it probably would have played better because we would have more time to focus on game play... All that aside, the whole point of this class is building a systems and integrating them. Our game wouldn't have the look and feel it does if it weren't for some of the quirks in the engine.


Time Travel: What would you have done differently, what would stay the same

Most of us wouldn't change much (because we are Team Awesome, and have obviously made no mistakes at all). Apart from the fact we all wish we could have worked just a little bit harder during the early bit of the quarter when time was abundant, I think we would have changed our organization a little. If the allocation of work units was handled properly, everyone would have had a task to do at all times. This, coupled with group meetings and some kind of reporting of work would have brought everyone closer to understanding every bit of the project.

We should have decided much, much earlier how we wanted the look-and-feel of the game. We didn't really know how our game would actually look until less than 24 hours before the demo, which didn't give us much time to tweak and play around with it.

On the side of things we wouldn't have changed, our goal of integration as soon as possible.


Preparation: Which classes best prepared you for CSE 125


Lessons: What was the most important thing you learned?


Books: What books were helpful but were not recommended? What books were not helpful that were recommended?


Advice: Tips for next years students


Course Improvements: What should be done differently next year?


Notes