CSE 125: Space Escape

Game concept: 

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

The game concept was of a space-themed first person shooter that had puzzle solving elements. The game would consist of characters in space suits fighting each other in a space  ship-themed arena. The puzzle solving elements had to be omitted for time, but the theme of the game and the overall design remained the same.

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

The initial design of the game was as a free-for-all/team-based shooter that had a puzzle-solving element. The object of the game was to fight the other players in an arena while solving a puzzle to trigger the game win state. Killing enemy players would remove them from the game temporarily, giving you to time to solve a randomly-generated number puzzle.
The puzzle solving elements could not be implemented due to time constraints, but the basic structure of the game as an arena-based shooter remained. Item pick-ups which healed or prevented damage and gave extra ammo for a secondary grenade weapon were implemented. The puzzle was replaced by a time limit which triggered the game end. The winner is determined by the player with the highest number of kills.

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

Art: Due to lack of experience with 3d modeling tools and the need to coordinate file types with the graphics team, the schedule was made to focus on developing a single animated player model for use in the game as well as other non-animated props if time allowed. The schedule differed from the planned schedule due to difficulties in coordinating the file format as well as problems with backing up files. The COLLADA file type that we decided to use was not supported very well by 3DS Max or any ot the other programs we used. Progress on the model was was hindered by trying to figure out how to get the model exported correctly. The progress was also set back significantly when the artist lost her external hard drive containing the models and failed to back up the latest version of the animation 3DS max file on Dropbox (Argh!).
In the end, all of the props and animations needed for the prototype were completed.

A lot of the milestones in our game development schedule was pushed back because of some of the difficulties due to art, modeling, and networking.

The networking got off to a slow start so we were not able to balance out the scheduling. Once we got the packets flying however, we were able to catch up to our schedule on the most part and finish the game for what it is. The problem was probably because we didn’t fully understand the networking code, but once we did, we were able to blitz through it.

The visual effects was also behind schedule, several effects would have caused us to rework how we set up the code for graphics. If we had taking that into account, we might have been able to get more effects, but to overhaul that portion of the code would have been dangerous by the time we realized it so we worked with what we had.

General Questions:

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

Having the group meet every week and work together worked out pretty well because we get to see where we are at and can help each other out as well as finding what needs to get done. If we had more time to code together then we might be able to get more out of the code. Also we had dinner after the meeting so that helped get people together as well.

The thing that didn’t really work for our group was communication, and finding what needs to get done. There were several occasions where there was something that needed to be fixed or implemented and we didn’t know who was going to be working on that part. Having a better way to track the project might have been better. We only used the group meetings as  a way to track our project, though we were thinking of using several project tracker apps, that didn’t happen, and the meeting was not sufficient in thoroughly track the project in all cases.

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

Creating animation files was more difficult than expected and not for the reasons I thought. Actually animating the rigged model was easy, but figuring out how to produce a non-corrupted file was not. There were also other issues with scaling the model that, while funny, were not very helpful. The networking was also pretty difficult because we did not have much experience working with networking code.

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

We are all fairly proud of the graphics and the sound effects. The sound effects turned out really great. The fact that the audience enjoyed the sound effects as well as having up performed it live was a reassurance that we definitely should be proud of. We are glad that the audience found out game entertaining and that our game was fun to play.

4. What was the most difficult software problem you faced, and how did you overcome it (if you did)?
   
   For implementing the character models and graphics there were some problems with the most efficient animation file format not being fully supported by the software available. Exporting the character model sometimes led to corrupted meshes and animations. It was discovered very late in the quarter that COLLADA files do not export properly when skinning with individually weighted vertices.

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

47000 lines of code

We used C++ and wrote about 47656 lines of code collectively. The way we counted it was by running the unix command: find . -name '*.cpp' -o -name '*.h' | xargs wc -l. This counted up all the lines in the files that we wrote in the source, headers, and shader files.

We used several libraries to do the work for us as well, and that work great with C++, the problem is though, some library migrated to C++11 code which we didn’t really understand on some portions of it and it would have been so much easier to understand the code to leave it as the older version of the code.

Recommendations: Use language that the whole group knows and knows how to debug in that language as well.

6. In developing the media content for your project, you relied upon a number of tools ranging 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?
   
   

For the art, we relied on 3DS Max to texture, skin and animate the models. The model mesh itself was created in a free program Sculptris. While Sculptris is a very helpful program for making detailed models that look good, it does not allow a lot of control over the size, vertices of the model or the number of triangles, also the cross compatibility of Sculptris models with other 3D modeling programs is dubious at best. If given the option to work on it again, even though it gives a lot less ease and flexibility, I would try creating, skinning, and rigging the model all in one program. Even though it probably would have resulted in a simpler-looking model it would be easier to use a model built within the program(Maya or 3DS Max) to take advantage of all of the program’s features.

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

Working from scratch seems like a really great idea and we enjoyed that. We had some trouble deciding which library to use for certain parts, such as the sound and the networking, but by working from scratch we get to understand that specific library more. If we were to use a game engine, then most of that would be abstracted away, especially the graphics portion and we wouldn’t learn as much. Another thing is that we didn’t have to work off of someone else’s code, and if we had questions, we can’t really ask anybody about out to use the code, but by working from scratch, the coder knows what’s going on, and can provide explanation, as well as simplifying it so that we use only what we need.

8. For those who used a networking library (e.g., RakNet or Boost) or physics library (e.g., Bullet), 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 Boost Asio networking library. We would definitely use it again since it simplifies a lot of the work we have to do regarding sending network packets from computer to computer. At first it was hard to understand how the library works, but after looking at the example code and fully understand its internal workings, it was much easier to alter the code to suit our game networking needs. After setting up the network, it was relatively easy to add network data. We did encounter some issues using the library since we were pretty unfamiliar with it, such as having issues with implementing and using the data structures provided by the library, but after overcoming the issue, it was straight forward from there on.

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

We definitely enjoyed working with DirectX 11, and HLSL so that portion would probably be the same.

We would probably want to do animation differently since we had a lot of trouble with the animation format that we were using and probably the modeling software as well.

The architecture of the game was also problematic as we didn’t understand the best way to deal with server/client going too fast, and balancing the network communication aspect of the game. However, we got a better understanding and by changing the architecture, a lot of the problems we had in the games would work out better such as the synchronization. We were pretty much hoping that the updates done slow down during the demo and cause everything to hang.

10. Which courses at UCSD do you think best prepared you for CSE 125?
    
    For the art, no courses I have taken helped me be best prepared for working with 3D modeling, but a basic background in CSE made it easier to communicate with the rest of the group on what to work on. Taking a course on 3D modeling and animation at UCSD would definitely help, though.

Coding wise, if you are going to be working in graphics that at least have some basic understanding of graphics such as CSE 167, and CSE 169, animation, helps in dissecting the animation formats. Otherwise a lot of coding experience, and debugging experience really helps because there are lots of situation where you have to just trace back the problems until you find the root cause of what’s wrong, and sometimes that took us days to work it out.

11. What was the most important thing that you learned in the class?
    
    The most important thing we learned in the class was to learn to work effectively with a team. Through weekly meetings and programming sessions, we learned to seek help from one another, ask each other opinions on different aspects of the game, and pair program on the things that we were really stuck on. Somehow pair programming helped us get things done quicker, especially with things that we are not familiar with.

12. Please post four final screenshots of your game on your group pages for posterity.

Pew! Pewpewpewpepwpewpewpewpewpewpwepepwpepwepwepewpepwepepwepewpepwepwpewpepepew!

Ahhh!
ooooooh
Omnomnom!

Course Feedback:

Finally, if you wish, I would appreciate any feedback on the course (entirely optional):

1. 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?

The books that we used were from the cabinet and they were pretty useful, especially the ones that are the current version. The physics book was too complicated for our needs but may be useful for other people doing other things.

2. I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?

• Figure out what your group is capable of doing first to that it is easier to organize your efforts beforehand.

• Don’t make assumptions about the capabilities of programs you are not familiar with.

• Devote a set amount of time every week to working together with everyone. It makes things easier to build and communicate and it is much more fun.

• Camp out in the CSE basement on Week 10, because sometimes they have free food.