Our original game concept turned out to be a bit difficult for the user to intuitively understand. Originally, the user would pick up weapons and fire off each static weapon object that would be re-inserted into the world. After many hours of gameplay we realized that this was not the funest implementation. We also began adding weapons with different projectile motions as the game progressed in order to make it more interesting than having a single projectile. Ammo pickup changed a little as well. Initially we had no ammo as only a single weapon was allowed to be fired at a time. After our weapon implementation changed we then added support for a dynamic ammo count where the user was required to have ammo in order to use the weapon.

Our overall client-server game design and interaction between each module are the same as our initial design. Our design is not perfect, but it is good enough for our game. Given the time limitation and resources, we were not able to plan a superior design that would have allowed us to implement more of the features we would have liked in our game. We feel that our original design was put into place in a hurry in order to keep the project from gating further development. Our original plan was to load all static game objects into the world using an importer. The idea was to allow the configuration file to contain all the world details without having any hardcoded references to a single map. However, in the end we found it easier to provide collision detection support by hardcoding each static object into the world. Since we don't know a lot of stuff about game design and how does it works, our final implementation design is much different from our intital design.

Our final schedule is different from our projected schedule in the sense that we created our original schedule based on templates from made by groups from previous years. We truly had no idea how much time to expect to spend on each module given the lack of game development experience in our group. Firstly , there are many things we didn't consider in our initial schedule such as multiple game states, Menu System, HUD, etc. Secondly, we didn't know how long the implementation of each module will take ahead. It is really hard to keep up with our projected schedule, but we managed to finish on each week deadline and achieve our weekly goals. Our weekly goals changes as we understand more about the game design and its implementation. As weeks goes by, we adapted our projected schedule to fit our goals. As is the case in any real world project development cycle, some modules were completed sooner then expected as well as some taking longer. In the end we were very pleased with the number of items we had accomplished to implement.

We kind of follow the path of water fall software development model. In the beginning of the quarter, our game design is far from complete. As our implementation progressed, our design changed. For instance, member variables of the game objects kept changing until the last two weeks. We were given advice to manage integration wisely and we made a weekly priority in order to assure the integrity of the overall project as the weeks progressed. This way no major changes effected other modules from progressing each week. However, we do wish we could have used a better integration scheme. We often spent a lot of time copying not only the changed files but stale copies of files that never changed. We did not use a versioning system and perhaps this would have saved us a lot of time. We intended to use a versioning system however the learning began to take too much time away from development. Another successly methodology we used was to work in pairs of two and sometimes even three people on a module. Having pairs of individuals work on modules allowed for more time flexibility as well as debugging knowledge later down the development cycle. Anytime team members needed more help or support this grouping methodology allowed for other team members to relocate their current module development priority. Weekly meeting is the most effective way to communicate with our group members. It is more effective than any other group mechanics decision. Messenger is great way to keep in touch outside of the lab. Forums are ok, but we don't get around using it at all since we are always in the lab. Email is just bad especially when it doesn't reach to all the game members

Definitely, sound module. Sound module seemed to be easy but we ended up finishing implementation sound and 3d sound on the last week. Playing a single sound in a buffer on client side is easy but synchronizing 3D sound through server and multiple sound buffer management can be tiresome. Another thing is that there are many thing we didn't expected to implement in our original design. It is a pain to add modules when we didn't expect to implement. Our gamestate manager ended up being something we had no original plans for but turned out to be a crucial element in the game. Clientside implemenation did not provide anywhere near as many problems as serverside implementation did. Many hours of sleep were lost due to this fact. Probably the most difficult element to implement was the collision detection. Simple collision detection took a few weeks however this ignored the fact that the terrain was not flat. Since Ogre generated the terrain information on the client-side and the collision detection module was located on the server, we needed to find a way to represent the terrain on the server in order to successfully model the terrain in our collision detection world. This took over a month and ended up being a last minute implementation. Our backup plan was to eliminate elements from the world that required the terrain be generated on the server however everything worked out in the end. Since we used Ogre as our game engine, anytime we wanted to implement a new graphics feature we needed to invest research time on the Ogre webboards and discussion forums in order to figure out how to build everything. This included building the Maya model exporter that would allow our modules to be added to our game as well as the CEGUI system that we used for our pre-game GUI

We ended up using all Microsoft API's for the development of our game features. This included DirectSound, DirectInput, DirectPlay and of course DirectX via the Ogre game engine. MSDN provided a lot of documentation and support for all of these interfaces so we do not see a need for any other core API tools. However there are many more API's that exist that we could have used so in now way would I see the course being restricted to using strictly this set of API's. We feel that an API or at least an SDK for a loader library would have saved a lot of time that we ended up spending getting the models from Maya into our game. I'm sure if there is any better GUI's for versioning system out there but we found that WinCVS was unable to meet our needs due to the non-intuitive learning curve. In the end, Visual Studio and MSDN was all we needed to implement the core features of the game.

First of all, using game engine is not a bad thing. We learned a lot while getting familiar with Ogre such as what are the essential components and how they should work together, etc. We felt that the purpose of the course was to design a significantly large software project and implement it, not to re-invent the wheel so to speak in terms of a game engine. Using Ogre allowed us to focus on the important aspects of the game that needed to be implemented. Had we not used Ogre, we would have needed to implement elements that we did not feel were important to do from scratch if the software was available for use. If any of our group members would have been stronger in terms of graphics rendering then we would not have been opposed to implementing the support that Ogre provided. However, due to the complexity and amount of research time that would have been added to the already grusome schedule we felt this was unecessary for the overall goal of the project

We would have spent more time on the overall design of the game prior to jumping into the initial implementation. Looking back, we realize that there exists better designs for each module. We also would have utilized these better design patterns as well as concentrated more on efficiency instead of simply making it work. In terms of networking, we would have design a much better model for the communication packets between the client and server. We definitely would have implemented support for dynamic packet sizes as well as restrict the amount of details included in each packet to the bare minimum necessary. The reason our game design did not include this type of support is because of our inexperience with this type of project. Originally, we had no idea what information would be needed by each module and so we simply added support for everything we felt each module might need. We would have liked to implement support for a client side physics engine to compliment the server physics engine. We feel this might have sped up the pace of the server as well as created faster transitions between frames.
Janvier: "First, I would definitely use OpenGL instead of Ogre or other graphics engine. Second, I would prioritize having a simple character on the simple terrain in the beginning to better plan most of the important aspects in the game."

Brandon: ICAM 120, CSE12
Frank: CSE 100, CSE 101, CSE 105
Isaac: CSE 12, CSE131A/B, CSE167
Janvier: CSE 100, 131A, 131B.
Justin: CSE 111, CSE 120, CSE 169
Kevin: CSE120, CSE111, CSE123A
Simon: cse12, cse100, cse131a, cse131b

We have learned a great deal about teamwork and understanding group members. None of us had any experience with any of the API's used during the development of our game. We needed to research each API and in order to implement what we needed it required the understand and knowledge about each individual API. Overall we learned a great deal how Microsoft API's are structured. We also learned a great deal about consequences of design flaws. We often found ourselves debugging the simplest problems for hours and sometimes days when a better design could have prevented each problem. We learned how to maintain ourselves individually as well as within the group during the gruesome 10 weeks. We learned how the whole game works from a high level. Considering we had no idea where to start to make a game, it was not bad at all.

Game Programming Gem Vol 1 & 3 were very useful in terms of game design knowledge. The books that were provided to each student at the beginning of the course were great . for tissue paper that is. We appreciated the free books however we found them to be of absolutely no help whatsoever. Most of the information we collected was online or through MSDN so as it turns out we did not invest much time in books.

1. Learn how to utilize good design patterns such as singleton, factory, façade, and state pattern. It will help you a lot.
2. Don't hesitate to help your team members to keep up with their schedules
3. Keep up with your schedules
4. Please TEST your game with at least 4 players before the demo.
5. Make sure everyone likes the game and everyone is happy with what their doing or they wouldn't contribute.
Janvier: "Never use any graphics engine. Use OpenGL and build your graphics module from scratch. If you want to make a very fancy game and therefore need a graphics engine, you are in the wrong direction. The point of this class is to learn things behind the scene, not learn how to use some certain engine, which what you will be doing if you are using them. Keep in your mind, SIMPLE and FUN."

There should be more working machines in the lab. During the final week, the lab was super crowded and a lot of the groups didn't get to test multi player with 4 people. Also, we could have known better driver installtion process such as for gamepad.

7/7 votes. X-Box is not a distraction