Final Design Document

LeftField Games:

High-Level Description of Modern Warfare

Modern Warfare is a multiplayer strategy game consisting of two modes: In the strategic mode the player sees the world map and issues high-level commands, such as economic policies and military deployment. When opposing forces come into contact, the game enters a tactical mode where the player micromanages tanks, jets and other war machines to win the battle.

The rules of battle and economy are somewhat simple, similar to board games. However, these rules have been extensively play tested to ensure balance and encourage creativity.

System Components

System Requirements:

· OS: Windows 2000/XP

· Processor: AMD Athlon XP, because of differences between the floating point units between different x86 architectures we decided to target our game only for the AMD Athlon XP Processor being that is the CPU that is in the undergraduate computer lab.

· Hard Drive: 600MB

· Video Card: GeForce 3 TI or GeForce 4 TI, we require a programmable pixel and vertex pipeline 1.1 or above but have only tested with these two video cards.

· Broadband Internet Connection

· Speakers/Headphones

Software Components Used for Development

· C++, Programmed in Visual Studio .NET 2002

· DirectX 8.1 SDK

· Nuke SDK

· Royalty Free Music and Sound Effects

System Capabilities
[Provide a list and brief description of the (high-level) capabilities that your software can perform.]

· Allows up to 4 players to connect and play against each other over a high speed Internet connection

· Allows players to build Light Tanks, Heavy Tanks, Rocket Launchers, Artilleries, or Jets. Each having different capabilities similar to the paper, rock, scissors game where each unit can beat out another unit.

· Players can capture cities from other players and invest resources into improving the cities.

· Players can wage large scale tactical battles involving massive ground and air forces

· An independent 3D Graphics Engine developed from the ground up, that will be used for future projects

Coolness Factor
[In your opinion, what is especially novel, interesting, and/or cool about your system?]

What we consider most novel, interesting, and cool about our system is that it is an original game idea that has been play tested to be fun to play. Throughout the project we placed a high emphasis on making the game fun. Ultimately features were put into or left out of Modern Warfare based on if they made the game funnier to play.

We brought the game to a fully playable state three weeks early so we could hold open public beta sessions, where we had twelve to sixteen people participate by playing our game for about an hour and then talk to us about the experience. After these sessions we made changes to the game based on the feedback that we received. Public feedback was a very major part of our game design and from talking with the people that have helped us beta test the game they feel that it is a fun game to play, and that the game has improved from fun to very fun because we have listened to their feedback.

Individual Contributions

· Overhead Mode: Russ and Todd

· Battle Mode: Usit

· 3D Graphics Engine: Usit

· Input Interface: Usit

· Sound Interface: Todd

· Network Interface: Usit

· Multiplayer Support: Russ and Usit

· Chat System: Russ

· Game State Synchronization: Usit and Russ

· HUD: Todd and Usit

· Game Data Management: Todd

· Special Effects: Usit

· Tutorial: Russ

· 3D Models: Usit

· Textures: Usit

· Box Art and Quick Reference guide: Russ

· Voice Acting: Todd

· Maps: Todd

· Source Control Server Maintenance: Russ

· Web Site Maintenance: Russ

· Internal Testing: Usit, Russ, and Todd

[Percentage of time and effort contributed by each person]

We all put a tremendous amount of time and effort into this project throughout the semester however being that we are being judged relative to our other team members all we can say is: Usit 1/3, Russ 1/3, and Todd 1/3.

Accomplishments
[Are you happy with your final project? Did you get everything accomplished that you wanted to?]

We are very satisfied with our final project. Starting the first day of class we worked very hard on getting the “Base Essential” features of the project implemented. We implemented all of these features; however after we implemented multiplayer, which is a “Bells and Whistles” feature we decided to focus on multiplayer gameplay only. The issue we faced is one of maximizing fun factor with our limited development resources. We decided that having both a multiplayer element along with a single player would stretch our resources too thin.

Aside from our Base Essential features we have implemented most of our Desired Features including: Fully 3D Graphics, Particle Effects for Explosions, missile trails, debris, etc. A simple economic system, an exaggerated physics system, and a well-balanced battle system.

And we implemented many “Bells and Whistles” features including Multiple maps selectable from a config file, support for 2-8 players via local high-speed reliable network, and voice acting.

We did not set low expectations of ourselves so that after a minimal amount of work we can claim to reach all our goals and claim an A. We had ambitious goals that we achieved through a tremendous amount of hard work by all three of us. We achieved these goals because of a lot of hard work.

Lessons Learned: Working as a Team

When working on a team communication is key. It is essential to have people show up to meetings and in general communicate. So if you have a question you can just instant message them or knock on their door. Maybe it is also worth mentioning that we decided to be roommates for the sole reason of developing a video game in an environment where it is easy to communicate with each other.

This is much better than past projects we have been involved with in the past where the primary method of communication was email and it was hard to get a response in a finite amount time.

Lessons Learned: Building a Large Software System
[Discuss any lessons that you've learned from your CS4500 project about building a large software system.]

Our system is 15,191 lines of code. So for our purposes I guess we will define 15,000 lines of code as large. And say that overall we have learned that it is much easier to build a large software system when you have a good team.

We really liked using Perforce for source control management (SCM). In the past we have used CVS which is infinitely better than nothing, but we strongly prefer Perforce. The interface in Perforce for looking at code check-ins was convenient enough to use that we would look over each other’s source code submits regularly. Branching and the merging of branches is also infinitely easier to do than with CVS and as a result we used branching and merging of source trees much more in this project than we ever have in the past. A good SCM system might not be essential but it sure makes building a large software system much more pleasant and efficient.

An XP-like development style worked very well for us. But it is worth mentioning that it requires a lot of time and discipline to do major code refactoring throughout the project.

It is much nicer having full administrator control over all of our assets. Meaning it was a lot better to rely on each other to keep our PC’s and system services up and running rather than having to wait a time lag to ask for help or permission to do things from lab administrators. The biggest example here would be disk space. Developing a video game that is heavy on content creation cannot be done in less than a 500MB disk quota. Rather than going through a lengthy process of trying to be an exception to the disk quota rule it is a lot better to just do the development in an environment where we were our own sys admins and could just go out and buy another hard drive.

We kept the end goal in mind and did not get hung up on solving individual problems “perfectly.” I guess this could be considered a personal decision but we noticed a lot of other teams significantly alter the goals of there project because they would get hung up in solving a particular problem that they faced in some “perfect” way and there “perfect” solution would take them all of there effort for the rest of the semester and as a result they were not able to meet the original goals of there project. Our goal throughout the project was to meet our original goals and as a result we had to try a few different solutions to problems a couple of times to be able to meet our time goals.

Lessons Learned: Time Machine
[If a time machine could transport you back to January, what you would do differently in designing, implementing, or managing your project?]

We give a strong statement when we say that we do not have any regrets, but we really don’t. The problem with doing things differently is it will give us a different result and we are very satisfied with our project and what we have accomplished this semester. We would do things the same.