Final Project Review

From Group 5
Revision as of 12:29, 14 June 2013 by Admin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
   Game concept: How and why did your game concept change from initial concept to what you implemented?

KHANH- Our game originally was focused on the idea of an asymmetric battle between 3 weaker players and 1 stronger one. That central idea remained constant although many details were lost and gained along the way. We varied powerups, weapons, and map plans until it transformed into a SWAT themed shooter, to a magic and fantasy setting. Our idea was initially very elaborate, but as the deadlines loomed closer we were cutting several components, one of which was animations for the characters.

ZHEN: Our game changed a lot as the quarter progressed. Initially we were going to make a FPS based on the MAFIA game. However, we decided to change the concept around week 3 or 4 because we could not think of a good game mechanic to separate the players. how the game is an asymmetric game of 3v1 in a dynamic map with different powerups and weapons.

Matthew C: Originally we had a mafia (in werewolf/demon theme) like fps game. The core concept of fps stayed the same as well as the asymmetric concept, however the theme and shooting mechanics changed to magic and what not, and the teams became known from the beginning. I believe we changed due to uncertainty of how fun the mafia game would be as well as lacking enthusiasm / conflict of ideas.

Alvin: Allen and I came up with the mafia Idea, but it's not so playble as we tested in other fps games. In the end, I just wanted to make a fps game.

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

KHANH- I think the core idea of the asymmetric battle was achieved. Visually, the game was not everything it could be, but we surprised ourselves in how good some aspects developed. Specifically the HUD, which was a collaboration between artist and programmers turned out very well. Player role, magic, health, weapon type, charge time, and even a radar all made the game intuitive and easy to read. The lack of fully fleshed out player animations is a shame, but the environment, skybox, and moving wall mechanics worked flawlessly during the demo. Our gameplay remained interesting, generating genuine panic and adrenaline in the guiest players who were stuck battling the “Bad Guy”.

Zhen: I agree with everything Khanh has said. The core idea of the game is accomplished and we actually have a very cool HUD and mini-map. I think we were hoping to have a more sophisticated animation system but we encountered a lot of problems along the way.

Matthew C: Our initial design was not fully fleshed out or detailed, so I think our final project design turned out better than the initial just because it is more concrete. Especially, the HUD which rapidly evolved as we were looking/playing/programming it.


Overal game play architecture is consistent. It was a good idea to spend a bit more time on figuring out the design in the beginning so we don't have to change it around so much. How the game look visually kinda just change around as we try different things out.

Bowen: I think our initial design wasn't really set in stone but we know what basic systems we should have. As the quarter progressed we came up with more features and became part of the final product.

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.)

KHANH- As far as graphics, there was many of bumps we encountered along the way. I found myself re-doing several models, animations, and riggs over and over due to technical problems either transporting the files over, and the issues with the animations reading in the code. Although the “Bad Guy” model turned out very complex, we needed extra time to animate, rigg, and translate the animations into the game. I think Alex described Khanh’s workflow the best when he said “He spent more time redoing things than actually doing” I attribute this to my lack of experience with 3DS, not modeling in a way suited to uploading into code, and my underestimation of the number of road bumps we would encounter along the way.

Zhen: I think our initial and actual schedule is way off. Everything that was listed for networking was done very early on during the quarter. Also there were many things that was off schedule. We did not anticipate how difficult graphics and collision will be. Also there was issues with the SFML’s TCP packets that caused a bit of delay toward the end of the quarter.

Matthew C: Our projected schedule was a lot more optimistic than our final schedule (hence the all nighters and long hours towards the end). I think our schedule was kind of thrown out because we changed the entire game design but never bothered to update the spec although both games were similar and the milestones should be roughly the same. We didn't really check our progress against the schedule which may have caused us to lose sight of where we were compared to our schedule.

Alvin: Week 10 = exponential development. Yeah!

Bowen: Network schedule is about the same as we expected. However we were a little bit too optimistic about the other schedules. (It's also because the original schedule weren't really well thought out. For example, we didn't include enough details for game play)

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

KHANH- 3DS MAX gave us many issues. Although it is a fine modeling program, texturing and unwrapping these models took time and was much less intuitive compared to other programs. Exporting was always a pain, and crashes became unavoidable, and counterproductive. There were also issues working in-between versions of 3DS MAX that we had in the lab and the ones we had available to download. We ended up having to export through various versions, which only added to the amount of time between graphics and coders.

Zhen: I think the weekly group meetings worked pretty well. It force everyone to try to stay on track and not be the lagger. One thing that I think did not work quite so well was when we decided something very quickly and then implement it just to find out it doesn’t work well with our game.

Matthew C: Git worked. Our group meeting without the professor did not go to well, nor did most of our designated programming sessions, this was probably because everyone's differing and busy schedules as well as lack of feeling the pressure as everyone picked it up towards the end. Our TODO on the wiki was semi successful, much better than asking for tasks.

Alvin: Tried to get everyone to buy into scrum but I failed. We are not full time developers and it's hard to find common time for meetings.

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

KHANH- Getting the model to look right in 3DS MAX is totally different than getting it to look that same way in the game. Axis rotations, bone names, animation issues, EVERY. SINGLE. THING. that could have been an issue became an issue.

Zhen: I think gameplay was a lot easier than I anticipated because once we had the basic gameplay, it was very easy to expand upon it. I think the C++ compiler and syntax gave me more trouble than anything else such as circular dependency.

Matthew C: Collisions were more difficult than expected due to lack of mathematical skill and a typo which haled my development for 2 days. The HUD as well took longer than expected especially the directional hit and switch weapon animation due to lack of mathematical skill, although they still didn't take too long. The networking was much easier than expected albeit we used the SFML packet. We were able to have a finished network after about 3 weeks (although we later had that bug which stopped development for 2/3 days)

Bowen: The network was much easier than expected despite of the bugs we encountered in the end (but it's in the SFML library and we were actually able to fix it). Getting SFML and openGL to work together was more difficult than expected, but it's also because we are using a more advanced version of openGL. We had to dig really deep to figure out how to make them work at the same time.

   Which aspects of the project are you particularly proud of? Why?

KHANH- The HUD turned out spectacularly. The magic, health, icons, aiming cursor, all worked together intuitively and shared an aesthetic that lend itself to the theme of the game.

Zhen: I think the HUD was super awesome. I think we also did a great job of making a fun game.

Matthew C: I think the game as a whole is something to be proud of, the gameplay is fun, intuitive, strategic, and interesting.

Alvin: I'm prod that we have that engineering soul. We perform the best when we are under pressure and we were a very efficient team.

Bowen: I think it's a fun game, especially for people with Counter Strike background.

   What was the most difficult software problem you faced, and how did you overcome it (if you did)?

KHANH- We never finished uploading animations into the game. Although we could, there were issues with scaling, speed, and positioning of the models. In the end there were no animations for the “Good Guys” and there were no first person animations to simulate a swing of a sword or wand.

Zhen: I think the C++ compiler is the most difficult software problem I encountered. I relied on Google, Matt and Bowen for help.

Matthew C: The SFML sending packet network bug was one of the most difficult we faced as we were unsure of what the problem initially was, nor were we able to reproduce it a will. It seemed to only be gotten on the upstairs machines, although this hypothesis later proved to be false. Luckily, we eventually figured out how to reproduce the problem and Bowen was looking through the source code and able to figure out why the bug was happening. What was happening was SFML sends the size then the packet, which can cause the server to believe the packet send was unsuccessful, while the client can receive the packet size and believe the packet was received successfully. The client and server will then go out of sync and are never able to recover. With the help of the professor we were able to overcome this issue. Another problem was a seemingly random collision problem where projectiles would stop in front of the walls, and players would be able to walk through the walls at times. Eventually I wrote a test which could reproduce the problem then I had to step through 33 collisions one line at a time to discover the problem was a typo. In my getter. getHalfWidth(){ return hh; } instead of return hw. T_T


Picking up c++ as a java/web developer is not so easy. There's a lot of convention that I don't know of.

XXXX c++. XXXX visual studio. why you crash all the time?

Bowen: The SFML bug definitely took us a lot of efforts to fix. Also it was really hard for the graphics team to load their models. In the end I believe we had to use 3ds Max 2012 to load the models in .x files to get animation to work.

   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? Finally, 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.

Zhen: We used C++ and I believe Matt said we have over 11k lines of code.

Matthew C: We used C++. We have about 60 cpp files if we say 300 lines per file is 18k lines.

Alvin: I don't like C++...

   In developing the media content for your project, you relied upon a number of tools from the DirectX/OpenGL libraries to modeling software. And you likely did some troubleshooting to make it all work. So that students next year 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?

The workflow we finally used to get animated models into the game was. 1. Animate in 3ds max 2013, 2. export as collada (.dae) (with baked animations). 3. import into 3ds max 2012 4. export as .X (with full matrix key frames) 5. Fudge the ground position in the game. We would not recommend anyone else using this workflow. We never figured out how to solve the final positioning problems, along with several of our animations exporting with bone weights set incorrectly. If we were to continue development on the game, we would probably look for an alternative to 3ds max for modeling and animating and then test several file types and export options before continuing. Also, having Y-up rather than Z-up sometimes makes things easier.

   Would you have rather started with a game engine like Ogre or would you still prefer to work from scratch?

Working from scratch is definitely more fun when it actually works and definitely deeply maddening when it doesn’t.

Zhen: I think working from scratch was definitely worth it. I learn so much by doing it ourselves.

Matthew C: I think since the goal of the class is interact with a group starting from scratch is better (you also learn more). If the goal is to make a good game then starting from an engine would be fine.

Alvin: I'm a big fan of library/plug-in. However, I did learn/benefit from implementing the system from scratch.

   For those who used a networking library (e.g., 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 a library, judging from the experiences of the groups that did, would you have used it in retrospect?

We used the network library of SFML along with its other components. SFML was very convenient for our cross platform methodology as it handled the byte order corrections for many common types. The only problem we ran into was because we used an uncommon feature of SFML, non-blocking TCP, we ran into a bug late in development that wasted 2 full days of our tenth week. Using a low level networking library is definitely a good idea but remember, all software has bugs.

   Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?

Have more than one guy on graphics for the whole quarter and have everyone on graphics work the same amount so they all understand the system and can then split the work. Make everyone in the group learn C++ (including all the pitfalls and weird corner cases) first before the quarter starts so we don’t waste time on basic stuff.\

KHANH- Lower expectations, simply designs to it’s core essentials. Details tend to get lost the closer the deadline comes to approach. DON’T ANIMATE FABRICS.

Zhen: I think it would have been great if we had a working game earlier. One problem we had was not playing the game enough. We were making modifications down to the very last minute so it was very hard to balance the game.

Matthew C: Try to solidify a schedule of meeting and mandatory coding a lot earlier so it sets a precedence early in the quarter when no one is busy. Pick a good leader, and stick to a more rigid schedule.

Alvin: I would have taken less classes along with 125.

Bowen: I think we should have a more detailed schedule. Things weren't well planned.

   Which courses at UCSD do you think best prepared you for CSE 125?

Zhen: I think CSE 100, CSE 131, and CSE 190 (android development) help prepared me the most because those classes taught me a lot about C/C++ and what it is like working on a large project.

Matthew C: No class can prepare you for 125. C++ is barely covered in any class, nor are design patterns. 110 in a way can prepare you for working in a group, and 101 can show you elegant code to strive for, 131 shows you how important good coding layout is and has you work with a partner, but all are miniscule in scale.

Alvin: CSE12.

Bowen Shu: I don't think there is a single course that best prepared me for CSE 125. It's really all the programming experiences I have gained over the course of my four-year education here. CSE 123 was helpful in terms of giving me a better understanding of the network part of the project, but I don't think it's a must since I definitely still had to read a lot.

   What was the most important thing that you learned in the class?

KHANH- Simplifying my design from the get-go and lowering expectations to what could be accomplished would have worked may have yielded a complete set of animations. I should have planned for my plans not to have worked.

Zhen: I think the most important thing I learned from this class is working in such a large team and how to delay with conflicting interests.

Matthew C: Compromise, delegation and communication are as important as good code.

Alvin: Stealing is art.

Bowen Shu: It's hard to organize a team and put everyone in the best position for the team.