Game concept: How and why did your game concept change from initial concept to what you implemented?
Herein, we will refer to concepts and design as a single entity, with features as a separate entity.
Firstly, The how: The general concept of the game stayed the same. It remained a 2-D in a 3-D world defense type of game, in which the main goal of the creeps was to get to the portal, the main goal of the players was to stop them. We implemented both of those fully. However, our initial design implied we would have different roles inside of the game. This was not implemented fully, but we did manage to input a turret functionality, which was going to be the basis of some sort of “engineer” class.
Secondly, The why: Since the above are general core concepts, we considered them necessary to achieve the group vision that we had for our game. Before we would sacrifice any of the above concepts, we would go ahead and remove features from the game. All other features, including the class based design, were not allowed to be put in because of time.
Design: How does your final project design compare to the initial design, and what are the reasons for the differences, if any?
From the “Must-Have” Category: All goals were met.
From the “Would be Really Nice” Category: We implemented three weapons, so we did in fact have objects that took advantage of the terrain, as well as multiple weapons. We did not implement any obstacles, though we have a level provide a kind of obstacle...
From the “Cool but Only Ahead of Schedule” Category: It was difficult enough to get a single level in the game. Adding a level was a pretty involved process, but it was (of course) a time issue. Classes were not added either, there was not enough time. A class based system could fit in, but not in the original intention that we were thinking. In keeping with our inspiration, though, we were unable to create a class-based system through the game system. We did implement varying sound effects, with a 3 dimensional sound engine. Originally, we also would have liked to do a little more graphically as well however were limited because of time.
As time went on, we started to narrow down our game with many, many playthrough tests, and a general motto of keeping it simple, and keeping it fun.
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.)
In General: We were behind on all fronts, though by at most a week. In specific though, there were lots of changes.
Sound:
Physics: Jumping was scrapped, collision detection didn't even come together until week 8.
Network: Client/server echo was up and running by Week 2. We were behind on server send and receives from week 2. We managed to create a flexible message packet structure by Week 4, and then stopped development after that, as it was a mostly complete system.
Input: Input was done according to plan in the beginning, but issues in tying together input with the server caused us lots of problems in the Week 6, when we finally had a server movement system all patched together.
GUI: GUI underwent changes until the very end, and it wasn't even really started until Week 7 or so, which made things lots of fun.
Graphics: Scene Graph was scrapped, and lots of other systems in the game were abandoned in order to keep our rendering engine simple, and working.
More General Questions:
What software methodology and group mechanics decisions worked out well, and which ones did not? Why?
Being able to reliably split up the work was a large issue. As long as that could be filled, then we could all make decent progress. This might have been alleviated by spending more time in the lab together. I also think that we got an actual running copy of the game up and running way too late, which we could have spent actually playing and then going back to the drawing board a lot quicker. We spent a lot of time talking strongly and not actually making decisions.
What aspects of the implementation were more difficult than you expected, and which were easier? Why?
Trying to implement any sort of concept features were very difficult to refine. Not from an artists point of view, but just the fact that someone was actually implementing something was “good enough” for us, whereas in retrospect, we wish that we had a little bit more time to refine and meet as a group to go ahead and do that.
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? Are there any tools that you used but, looking back, you would avoid?
Everything that was done was done efficiently was thanks to Visual Studio and subversion. Looking back, we probably wouldn't have used any different tools out of the whole situation.
Looking back, would you have rather started with a game engine like Ogre or would you still prefer to work from scratch?
As a group, we are undecided on the answer to this question.
It would have made for a prettier, more feature-filled game, but it would not have been as original. [Rivera, Ranatunga].
I would have started again from scratch, rather than simply learn a game engine API that wouldn't help when I have to potentially deal with a proprietary system, if you were to get when you actually work at a game company. [Green]
I also liked the idea of starting from scratch. It made it more something that we owned. [Cheng]
Looking back over the past 10 weeks, how would you do things differently, and what would you do again in the same situation?
We wouldn't do things differently, we would just try to be quicker in what we did. We don't really feel like we prioritized wrong, just could have been faster.
We could have planned and designed things out better in the beginning instead of just going at everything and then trying to hack it all together later. [Cheng]
Which courses at UCSD do you think best prepared you for CSE 125?
Compilers and 141L, simply because of work ethic. In terms of technology, definitely 167 and 169, in terms of graphics.
What was the most important thing that you learned in the class?
Was to involve everyone in the modulation, ideally much before this modules were run. Sometimes we didn't end up with a properly executed idea that could have been avoided.
Visual Studio [Ranatunga]
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?
Gamedev.net, MSDN, Tutorials for the DirectX SDK. None of us used a lot of the books.
I will be teaching this course next Spring. What advice/tips/suggestions would you give students who will take the course next year?
I would have more demonstrations and speakers, there were a very good thing. Perhaps a later classtime. [Rivera, Ranatunga] Start Early, Work Hard [Rivera]. You should be prepared for this class and what it's going to do to you before you even walk in [Green]. Plan out and design what you're going to do and then do it. [Cheng]
