Final report
A. In the project review document, start by addressing these main questions:Game concept: How and why did your game concept change from initial concept to what you implemented?
After much deliberation during our first meeting, we agreed on an RPG styled game, but perhaps due to confusion or miscommunication, a few of us left the first meeting feeling overwhelmed and thinking that we were making a MMORPG. Perhaps another problem was that two of us never extensively played MMORPGs, so we weren't actually sure as to what the project entailed. We had a second meeting where most of the specifics were narrowed down in AI, game logic, and we were reassured that there was definitely not going to be an MMORPG. (This ended up being a very good thing, because even as a simple RPG, we were scraping for every fps we could get).
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
The end result of our project was actually very close to what we originally wanted to implement. It was still an RPG, it parodied various games in style and the origination of whom the characters were and it retained a GUI style similar to a lot of RPGs out there. The Player Characters were still the same as the ones we discussed in the very beginning. The play was also still the same. However, there were some minor changes due to time constraints and software constraints. For example, in animation, we would have like to have had the characters change their weapons and not actually hold them while running, but this proved to be too difficult of a task with 3ds max. Some of our NPC ideas changed, but that was because Vivien found the original ones to be too similar to NPCs in other games, so we went with slightly more eccentric route. The AI was probably simpler than Mooneer would have liked, but we were very desperate for fps at the end, so a lot of the better algorithms he originally had were pulled out.
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.)
We fell behind schedule significantly, moreso than any other group, in the beginning it wasn't too bad, we'd only be 2 or 3 days behind, but then during the two weeks of integration, we realized it was nearly impossible to get people together in the lab at the same time. In addition, Guy and Kim's apartment burnt down and they had to take care of legal issues and finding a place to sleep for the next 1 and a half week. We were able to cover some things as people started to fill in small parts of Guy and Kim's roles, but we were definitely far behind all the other groups. During the time we were supposed to be testing, we were still coding, even on the day we were supposed to "code freeze", we were still putting in new things. Unfortunately, we never had much thorough testing, even in the last few days we had left.
B. Then address these more general questions:
What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
Meeting on Wednesdays for dinner worked out quite well, because it was time away from a computer and we could communicate our ideas more coherently instead of just coding away and not really listen to each other.The part that did not work out was that not a lot of people came in to work in the lab, which made things difficult during integration. There is no doubt that everyone worked a lot on this game, but our problem was that we didn't really work cohesively.
What aspects of the implementation were more difficult than you expected, and which were easier? Why?
The process of making a usable character was difficult in that it definitely took longer than expected, because the exporter was finicky about everything, a lot of time was wasted trying to figure out how to export a model without having it break apart in DirectX. Moreover, the fps issue didn't really register until near the end, so the same model was remade/optimized multiple times in attempts to get the fps up to a reasonable rate. Dealing with the models, making them, texturing things each alone wasn't hard, but put together and remade over and over again was difficult because some of the things were already plotted out in the world, so any changes you made, you had to consider where they were being placed in the world and you had to keep that same confined area so it wouldn't affect any of the other models. Implementing a GUI from scratch is much more difficult than the tutorials Chris read early on would have made it seem. As a result, the GUI took much more time than it really needed to and it put limitations on the other group members in terms of what kind of widgets they had access to for displaying and accessing information. In retrospect, it would have been much better to strip out the dependencies in the DXUT library and use its GUI toolset instead.
In implementing your project, you relied upon a number of tools, from the DirectX libraries to modeling software. Do you see the opportunity and need for new libraries and/or tools that would make project development easier?
Vivien would have loved to work with Maya since it has more industry use, its tool set is much bigger, and perhaps the exporter for it might have been better. A good exporter would have been nice, except the cost is excessively steep. Also, maybe relying more on things we already know (such as OpenGL instead of DirectX) might have helped reduce the amount of time we were behind by.
Looking back, would you have rather started with a game engine like Ogre or would you still prefer to work from scratch?
There's two ways to look at this. For Guy, who really wanted to make the graphics engine, he was definitely happy about learning all the things you needed in order to make the game from scratch. However, for Vivien, the exporter from 3ds Max to Ogre was nicer and she might not have had to simplify her characters and models so much. The world definitely would have looked much prettier because Ogre already has so much premade stuff by programmers that had more than 10 weeks to work on the graphics engine. In the end, we probably learned a lot more by starting from scratch but without a well documented game engine that does a lot of the setup work for us, we were significantly impaired in what we could accomplish in the given time frame. In Chris' opinion, not using Ogre was well worth the trade off in knowledge gained.
For those who used RakNet, 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 RakNet, judging from the experiences of the groups that did, would you have used it in retrospect?
I (Erik) am glad I used RakNet. It's a useful and very powerful tool. One must realize, though, that most of the "networking" work, if you do, is going to be learning how RakNet works, and the interface it uses. One note: don't assume the replicator will cache changes for you and send them at the desired rate. You'll have to cache your own changes and SendSerializeNeeded() once per server update time.
Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
We might have changed up a few of the tasks, maybe asked Chris to be second graphics and asked Kym to use DirectX's premade gui library, and allowed her to spend most of her time on sound, which is what she really wanted to work on since the beginning. And even if Chris stayed on GUI, he would definitely use the DXUT GUI library. No more of this starting from scratch stuff.
Which courses at UCSD do you think best prepared you for CSE 125?
Compilers (A and B), in terms of lack of sleep, how hectic the end of it can be, and how you needed to start planning it out ahead of time so you wouldn't kill yourself near the end of the project. Also, in Chris' experience, Compilers is the class closest to this one in terms of having a quarter long project that is the focus of the class and requires dedication and teamwork from both partners. CSE 111 helped a lot in keeping a good object-oriented hierarchy and using patterns. For graphics, CSE 167 and 169 both helped immensely in not only understanding the concepts but also in implementing new ones.
What was the most important thing that you learned in the class?
Working in a team, I think perhaps this is quite close to what it's like out in the workplace when you work with a team, the ups and downs, and the conflicts. Also, working on a large team project in C++ in the Microsoft Visual Studio IDE is as close to industry experience as we can get in a class; this is particularly valuable because few, if any, other CSE courses offer such practical and useful experience. Working with terrible, terrible APIs was another skill we learned - DirectX has pretty much the worst documentation we've seen, Google and the SDK (which is very poorly written) are pretty much the only sources of information on it.
C. Finally, if you wish, I would like you to provide optional feedback on the course:
What books did you find helpful that were not on the recommended list but should be? What books were on the recommended list but were not useful and should be removed?
There were books on the recommended list? Anyways, it would have been nice to play with 3ds max ahead of time, so it could have reduced some of the learning curve. Most of our resources for DirectX was from the internet most of the time. As long as that resource doesn't go down, I think next year's students will be okay.
One word: Toymaker
I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
People have no idea how much gets done when everyone on the team is in the lab. People may think it's trivial in the beginning, but our group was able to churn out so much in those last 3 days when everyone was working together in the lab. Imagine, what we could have accomplished if we had all been in the lab consistently for 10 weeks instead of just 4 or 5 days out of the entire quarter. Communication is key. Unless everyone keeps everyone else updated on what they're doing, people are going to step on eachother's toes. Also, AIM is in no way a substitute for face to face communication.
How can the course be improved for next year?
a) When considering people for the class, instead of asking people just what classes they are taking next quarter, you should also ask them to submit a google calendar of their schedule.
b) Maybe set up a bookmarks repository for the whole class? In the end, we realized we were pretty much using all the same links and resources online and I think everyone was perfectly fine with sharing information with each other because we all wanted all the groups to be able to finish their game.
In addition: CSE168 and CSE125 definitely don't mix, moreso than Compilers and CSE125, because CSE168's end goal is a competition to make the best rendering so you can go to the SIGGRAPH conference. (Guy and Vivien dropped that class before the second assignment was due, so we know.) If people take CSE168 and CSE125 at the same time, they are definitely going to be MIA during the important last weeks of CSE125; whereas in Compilers, you can grovel to your partner and beg them to take some of the heavier load in the class.