The Saga of MepWars*

Ok for like a year now I've been talking about how MepWars is "in the works". (Here's the promo-toon if you haven't seen).

So where's the game? Umm...Well... I finally have to and fess up.... It's sort of hit a snagstall.

Here's the story:

A while ago a student named Ryan from University of Ottawa got in touch telling me he's in school for nerdly geek stuff and he and his "team" have year-long assignment to develop a working multiplayer game. The whole team would work on the game together. He wanted to know if I had any ideas for a game to be developed... for free! I was like, 'Do I?!' And MepWars came to mind. I was psyched because I really have no idea (zero) how to program a game. It involves alot of math. I know that. Nuff said there.

Anyway, Ryan ran the idea for MepWars by his professor and he thought it was cool so we got started. For the next few weeks, I had a bunch of online IM chatroom meetings with the group of canadian students. We talked about what would be cool and told them to check out the other games on my site etc. They were totally into it and smart. It was fun chatting it up with a bunch of students about this stuff too! It was like being back in school or whatever.

The first part of their job was to kind of spell out the step by step process of how MepWars would function. This went on for a few months and the students kept sending me updates and we kept having our chatroom meetings every week or two. And I started blabbing about it.

Here's just SOME of the documentation they did: (which I had to sign off on. lol. it was ok with them for me to post it here. scroll away!)

--------------------------------------------------------

UML Diagrams

State based UML diagram (part 1) ---- client

Part 2 ---- server

Class diagrams part 1 ---- the game

Class diagrams part 1 ---- Networking

Test Plan

1. Summary

This documentation is to present a formal testing plan that will be performed on our project: MepWars(2D on-line game).

We will apply:

• Black Box Testing to test most of the classes and methods.
• State based Grey Box Testing to achieve N+ coverage.
• Bottom-Up strategy for integration testing.

2. Description of the software to be tested.

The software being tested is a MepWars a 2D multiplayer game with the following functionalities.

2.1 Functionalities

1.1: Opening movie

1.1.1: There is an optional movie (video introducing the alien races) at the beginning of the game.

1.2: User interface

1.2.1: A window (pre-game UI window) will prompt a user to choose from “server” and “client”.

1.2.2: Once a user starts a server, the client perspective window will be disabled.

1.2.3: If a customer acts as a client (ie, joins a server), the server perspective will be disabled.

1.3: Server option (a player who starts a server can…)

1.3.1: The server can choose the game style (eg, classic).

1.3.2: The server can choose the number of points to win the game.

1.3.3: The server can launch the game by clicking the launch button.

1.4: Client option

1.4.1: A client can type in the server IP address.

1.4.2: A client can enter the server’s port number.

1.4.3: A client can connect to the server.

1.5: Input support

1.5.1: A player can play the game using mouse.

1.5.2: A player can play the game using keyboard.

1.6: Game play

1.6.1: A ball will bounce around the game screen.

1.6.2: If the ball comes into contact with the force field surrounding a planet it will remove a portion of the field.

1.6.3: If the ball touches a planet, it explodes and the player whose planet has exploded is removed from the game until the next round.

1.6.4: The ball is deflected by the players paddle/shield.

1.6.5: If the ball touches a power-up, the power-up is given to the last person who hit the ball with the paddle.

1.6.6: The last person to be left alive without having their planet explode wins the round.

1.6.7: When a person wins enough rounds equal to the number of points required for a match(set by server) they win the war and the game ends.

1.7: Power-ups

1.7.1: Speedup ball

The ball speeds up after hit the paddle with this power.

1.7.2: Sticky shield

The player will be able to hold the ball when it touches their shield, and redirect it at will.

1.7.3: Photon Torpedo

The player is able to shoot out a laser beam that will directly take out a portion of another’s shield.

1.7.4: Super Ray gun

If this power-up is collected the user automatically wins the match, this power-up shows itself rarely.

1.7.5: Sticky paddle

Once the ball hits the paddle, it sticks on it. The player left clicks to release the ball.

(Power-up explanation: Power-ups flow around in the “universe” the last player to hit the ball and it touches the target will be granted a particular power. The power-up disappears as soon as the ball touches it. If the player hit the ball and it touches another power-up, the latter power-up is overridden.)

1.8: Other requirements

1.8.1: The game supports as many as 4 players.

1.8.2: There a will be a game over video with the winner doing a happy dance.

1.8.3: The game will include a chat window that allows users to chat to their opponents once they connected to the server.

1.8.4: The game will be able to play music and sound effects during both the intro movie, and while the game is in motion.

2.2 Fundamental Classes

Note: Our project currently contains 27 packages. Eleven of them are the engines of the game (ie, interface), and thus they will not be listed below. The classes shown here are the most important ones to the game. There are too many classes to list them all. Also note that the classes that are in italics indicate that they are empty at the moment but will be eventually implemented.

2.2.1 MepWars: The main type of the game. It creates the game objects.

2.2.2 Bot: (act as a player, controlled by a computer.)

2.2.3 Ball: defines the velocity and position of the ball

2.2.4 BallManager: Initiates a ball object (its velocity, location, etc).

2.2.5 ClientGameManager: The most import class. Generates the main frame. Creates all the manager objects.

2.2.6 ClientNetWorkManager: Starts the client, connects to the port and host specified

2.2.7 Idle: One of the states classes. Handles events and updates the states.

2.2.8 ChatWindow: initiates the chatting window frame (layout, style, etc).

Status Report

Team AUNA

Project:

  MepWars (2D on-line game)

Iteration:

  This status report is for iteration four.

Implementation Status

At this stage, we are able to show the following to the customer:

• The chat UI is now fancier (there is an icon for each letter).
• The server can now chose the game style and points of the game.
• The four players can all move their paddle without crashing.
• There is an actual shield surrounds the planet and when the ball hits the shield it diminishes.
• The scores are displayed during the game.
• 90% of the required concrete classes have been written.

The diagram above shows the situation that two players are playing the game.

Highlights

• The server on longer crashes when all four players move their paddle at the same time.
• The paddle now blocks the ball.
• When the ball hits the shield, that part of the shield disappears.
• The chat part of the game is almost done.

 At this stage, we are right on schedule.

Risks or Issues List

Tasks in Progress or Completed This Iteration:

Tasks to be worked on next Iteration:

Features to be tested

The following list describes the features that will be tested in the project:

Functionalities:

All the functionalities listed in section 2.1 will be tested.

Classes will be tested:

All the classes that are crucial to the successful running of the game will be tested.

Test Design Specification:

• Functionality testing (Black box testing)
• N+ testing (Grey box testing)
• Branch testing (White Box testing)

5. Features not to be tested.

The following list describes the features that will not be tested in the VCR Module:

Functionalities:

None (all will be tested)

Classes will NOT be tested:

We decided not to test the User Interface and the entity portion (ball, paddle, planet, etc.) of the system independently. Because they can be tested incorporate with the other classes. While testing more essential classes, we can call the methods in the UI and entity classes to see if they function correctly.

6. Approach

We decide to use a variety of techniques to perform the required testing on MepWars. We will be using three main testing approaches they are:

• Black Box
• Grey Box
• White Box

The following are the testing constraints we will meet:

• 100% functionality coverage
• N+ Coverage
• As many branch coverage as possible

For integration testing we will be considering all classes as a single cluster and we will be using the Big-Bang approach for both intra-class and cluster integration.

The following tools will be used to test the software:

JUnit

• Eclipse for debugging

- Tracers for branch coverage

7. Item pass/fail criteria blanket statement

The test results must exactly math the customer’s requirements. We will not tolerance any miss matches. So a test fails if the actual behavior are different from the descriptions bellow.

We will verify:

1.1: Opening movie.

The movie should start playing after a user clicks on the “Intro Movie” button. When the movie finishes, the user should be prompted back to the main window.

1.2: Server and client perspectives

A user should be able to choose to be either a server or a client by clicking on the “start server” or “start client” button respectively. Once the choice has been made, he/she will only see the corresponding UI (server or client) which means he/she can’t choose both.

1.3: Server options.

A server should be able to choose game style and the number of points that are required to win the game. The server should also be able to launch the game.

1.4: Client options

A client should be able to type in the server’s IP address and port number and then connect to it.

1.5: Input support

A player should be able to play the game by both keyboard and mouse.

1.6: Game play requirements

Please refer to functionality 1.6 in 2.1.

1.7: Power-ups

Different power-ups should appear at various frequencies. The image of the power-ups should match their effects. The person whose ball touches a power-up will be granted its corresponding power, and this power-up vanishes. The effect of a power-up will last a certain amount of time.

8. Suspension/Resumption criteria

For classes testing, we will be writing test cases for some of the classes and then test them individually. So we don’t even need to run the actual game to perform this part of the testing.

However, when it comes to performance testing, we will have to run the game from start to completion. The timing values are meaningless if the tests are delayed, interrupted or abandoned.

9. Test deliverables

We will provide a Test Report in our next milestone which contains:

• The results of the tests (with screenshots)
• Testing data
• JUnit test cases
• Any diagrams constructed

10. Testing tasks and environmental needs

So far, we have only run our game in Windows systems. Since the game is programmed in Java, we assume that it will run successfully in any other operating systems. Yet at this stage, we will manage to test it in other OSs like Macintosh. Our test manager Jad will provide the testing environment.

11. Responsibilities

The following people will be performing the tests:

12. Reference

SEG4111 professor S Some.

Test Plan of the Inter Process Communication package for the Atlas DAQ Prototype-1 http://rd13doc.cern.ch/Notes/103/Note103-1.html

Test Plan Outline http://www.softhawkway.com/TestPlan.htm

SOFTWARE PROJECT MANAGEMENT PLAN

For

MepWars game

Document Revision: 1.0

Table of Contents

List of Figures

List of Tables

1.Project Overview

1.1. Purpose, scope and objectives

1.2. Project deliverables

1.3. Evolution of the plan

1.4. References

1.5. Definitions and Acronyms

2.Project Organization

2.1. Organizational Interfaces

2.1.1. External Interfaces

2.1.2. Internal Structure

2.2. Roles and Responsibilities

3.Managerial Process Plans

3.1. Start-up Plan

3.1.1. Estimates

3.1.2. Staffing

3.1.3. Resource Acquisition

3.1.4. Project Staff Training Plan

3.2. Work Plan

3.2.1. Work Breakdown Structure

3.2.2. Schedule Allocation

3.2.3. Resource Allocation

3.2.4. Budget Allocation

3.3. Control Plan

3.3.1. Requirements Control Plan

3.3.2. Schedule Control Plan

3.3.2.1. Team meetings

3.3.2.2. Stakeholders meetings

3.3.3. Budget Control Plan

3.3.4. Quality Control Plan

3.3.5. Reporting Plan

3.3.6. Metrics Collection Plan

3.4. Risk Management Plan

3.4.1. Risk Identification

3.4.2. Risk Analysis and Prioritization

3.4.3. Risk Plan and Monitoring

3.4.4. Risk Mitigation

3.5. Closeout Plan

4.Technical Process Plans

4.1. Process Model

4.2. Methods, Tools, and Techniques

4.3. Infrastructure Plan

4.4. Product Acceptance Plan

5 .Supporting Process Plans

5.1. Configuration Management Plan

5.2. Verification & Validation Plan

5.3. Documentation Plan

5.4. Quality Assurance Plan

5.5. Reviews and Audits

5.6. Problem Resolution Plan

5.7. Subcontractor Management Plan

5.8. Process Improvement Plan

Annex A: Work Breakdown Structure

Annex B - Project Milestones

Annex C – Organizational chart

List of Figures

Figure 1 MepWars game Gantt chart of phases .................................................................. 20

Figure 2 Standard Waterfall Model ................................................................................... 27

Figure C.1 Organizational Chart ......................................................................................... 38

List of Tables

Table 1 Acronyms ............................................................................................................. 13

Change History

Project Overview

This document provides support for the development of the MepWars game software project, which is currently being developed at the University of Ottawa. It defines the project and the environment in which it is being developed. Furthermore, it supplies a series of managerial, technical and supporting process plans to ease the control of the software project. This document will be used as a reference throughout the development of the MepWars game to measure the current progress of the project. The format of this document is adapted from the IEEE Standard for Software Project Management Plans (Std 1058-1998).

Audience:

This document is intended for the people involved in the development of the MepWars game such as, the project team members and the project customer. It will also be supplied to the SEG4913 supervising professor to evaluate the level and type of control exercised in the development of our software project. Any other person(s) wishing to monitor or understand the development of the product can refer to this document. This document will also be supplied to the professor of the SEG4913 course for grading purposes.

Companion Documents:

Companion documents are attached and should be consulted whenever a reference to them is made:

• MepWars game MS Project document
• MepWars game - Risk Management Plan
• MepWars game - Charter

Purpose, scope and objectives

The project (developed independently by us) is a 2D game that will be added to our customer website where players around the globe can compete against each others. The customer is a famous Webmaster, we think that Todd as an entrepreneur will provide us with good support. Moreover, he will teach us the keys to good business. The project that we will be working on is a game. He asked us to implement a 2D game that will be added to his website and where players around the globe can compete against each others. The customer lives in New-York, we’ll be contacting him through email and online chatting. He’s email is: oddtodd7@hotmail.com. The customer is a famous Webmaster, we think that Todd as an entrepreneur will provide us with good support. Moreover, he will teach us the keys to good business.

People are likely to search on the web for entertainment and usually games are the main target. However, nowadays games are made with such high technology that they demand very good reflexes and too much concentration from the player. Therefore, we will create an 80’s 2D game called Warlords. So Todd wanted to provide the user of his website a game that is fun and relaxing. It must be creative even though we will use an old Atari game idea. It should attract new users and should be a game played between two or more people via internet. During the year, we will always be in contact with Todd to make sure that everything is completed to his satisfaction. This project will allow us to learn a new way to implement a program through learning the java graphics API. We will divide the work between the team members and during the semesters. Also, we will gradually build the game so that it will be complete by December 2005. Also, the game we create will only be loosely based on the old game. Therefore, we will not have to worry about copyright infringement.

Project deliverables

The following deliverables are the major course requirements for SEG4913 that can be found in detail at http://www.site.uottawa.ca/~misbah/seg4913/index.html:

• 8 Monthly Status Reports
• 1 Project Proposal
• 1 Requirements Document
• 1 Design Document
• 1 Final Report
• 2 Customer Evaluations

All deliverables mentioned previously, must be sent by e-mail to the SEG4913 course supervisor. In certain circumstances, if requested by the supervisor, hard copies of a particular deliverable can be physically delivered during course hours or any other times scheduled by the supervisor and acceptable to the team members.

Evolution of the plan

The SPMP will be used on a regular basis to track the progress of the MepWars game. Each time the SPMP will be used, it will be reviewed . If necessary, it will be updated to reflect any changes that need to be implemented. Furthermore, any change in requirements will result in a SPMP review. Any changes affecting the SPMP will then be implemented.

All versions of the SPMP will be put under configuration management and any changes will be done according to the configuration management plan outlined in this document.

Every new version of the SPMP will be distributed to the project team members as soon as it has been through the CMP.

References

The following documents were used to define all the terms in the Definitions section:

• IEEE Standard Glossary of Software Engineering Terminology http://standards.ieee.org/
• Project Plan Template, Treasury Board of Canada Secretariat

http://www.tbs-sct.gc.ca/emf-cag/ppto-gtpss/projplantemplate/ppt-mpptb_e.asp

• http://www.uml.org/what_is_omg.htm
• http://www.ieee.org/about/

The following documents have been referenced in order to correctly complete the SPMP:

• Schedule of deliverables for the course SEG4913F: http://www.site.uottawa.ca/~misbah/seg4913/index.html
• SEG 4100 SPMP template provided by Professor Shervin Shirmohammadi
• MepWars game Project Charter
• MepWars game Risk Management Plan
• MepWars game Project Proposal
• MepWars game Project Requirements
• MepWars game Microsoft Project document
• MepWars game Monthly Report template

Definitions and Acronyms

The following definitions and acronyms are listed here to supply the reader with information to help fully understand the SPMP.

Customer: Entity requiring the software.

Milestone: A scheduled event used to measure progress. Examples of major milestones for software projects may include an acquirer or managerial sign-off, baselining of a specification, completion of system integration, and product delivery. Minor milestones might include baselining of a software module or completion of a chapter of the user’s manual.

Project Agreement: A document or set of documents baselined by the acquirer and the supplier that specifies the conditions under which the project will be conducted. A project agreement may include items such as the scope, objectives, assumptions, management interfaces, risks, staffing plan, resource requirements, price, schedule, resource and budget allocations, project deliverables, and acceptance criteria for the project deliverables. Documents in a project agreement may include some or all of the following: a contract, a statement of work, user requirements, system engineering specifications, software requirements specifications, a software project management plan, supporting process plans, a business plan, a project charter, or a memo of understanding.

Project Deliverable: A work product to be delivered to the acquirer. Quantities, delivery dates, and delivery locations are specified in a project agreement. Project deliverables may include the following: operational requirements, functional specifications, design documentation, source code, object code, test results, installation instructions, training aids, user’s manuals, product development tools, and maintenance documentation. Project deliverables may be self-contained or may be part of a larger system’s deliverables.

Software Project: The set of work activities, both technical and managerial, required to satisfy the terms and conditions of a project agreement. A software project should have specific starting and ending dates, well-defined objectives and constraints, established responsibilities, and a budget and schedule. A software project may be self-contained or may be part of a larger project. In some cases, a software project may span only a portion of the software development cycle. In other cases, a software project may span many years and consist of numerous subprojects, each being a well-defined and self-contained software project.

Supporting Process: A collection of work activities that span the entire duration of a software project. Examples of supporting processes include software documentation, quality assurance, configuration management, software reviews, audit processes, and problem resolution activities.

Baseline: A work product that has been formally reviewed and accepted by the involved parties. A baseline should be changed only through formal configuration management procedures. Some baselines may be project deliverables while others provide the basis for further work.

Waterfall Model: In software engineering, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back. See section for a graphic representation.

Work Activity: A collection of work tasks spanning a fixed duration within the schedule of a software project. Work activities may contain other work activities, as in a work breakdown structure. The lowest-level work activities in a hierarchy of activities are work tasks. Typical work activities include project planning, requirements specification, software design, implementation, and testing.

Work Package: A specification of the work that must be accomplished to complete a work task. A work package should have a unique name and identifier, preconditions for initiating the work, staffing requirements, other needed resources, work products to be generated, estimated duration, risks factors, predecessor and successor work tasks, any special considerations for the work, and the completion criteria for the work package—including quality criteria for the work products to be generated.

Work Product: Any tangible item produced during the process of developing or modifying software. Examples of work products include the project plan, supporting process requirements, design documentation, source code, test plans, meeting minutes, schedules, budgets, and problem reports. Some subset of the work products will be baselined and some will form the set of project deliverables.

Work Task: The smallest unit of work subject to management accountability. A work task must be small enough to allow adequate planning and control of a software project, but large enough to avoid micro-management. The specification of work to be accomplished in completing a work task should be documented in a work package. Related work tasks should be grouped to form supporting processes and work activities.

Table 1: Acronyms

Project Organization

Organizational Interfaces

External Interfaces

All deliverables will be delivered to both the course supervisor for SEG4913 and the project customer. The course supervisor will use the deliverables to evaluate the team members’ final grades. The project team members may also at times, consult with the customer to obtain information related to the development of the MepWars game .

The complete organizational chart is described in Annex C.

Internal Structure

This project consists of five team members: Ryan , Simohamed , Yibo , Bachir and Jad . Yibo acts as project manager. But all major decisions are done jointly, between the five members. The other roles and responsibilities are divided between the five team members and are defined in the next section.

The project customer, Odd Todd, provides the tools (requirements) and resources (video and sound components) used in developing the MepWars game.

See Annex C for the complete organizational chart, which identifies all internal interfaces.

Roles and Responsibilities

There are five members working on this project. All the major work activities will be split between the five. The WBS in Annex A describes all the tasks and the person responsible for each task.

Here are some other roles that will be filled by the team members

• Project Manager: Yibo
• Configuration Control Manager: Bachir
• Quality Assurance Manager: Simohamed
• Primary Coder: Ryan
• Primary Tester: Jad
• Primary technical writer: Yibo

Managerial Process Plans

Start-up Plan

Estimates

The schedules and respective costs associated with the project are outlined in the WBS in Annex A. The total amount of time required to develop the project is estimated at 213 hours. The total estimated cost of the project is $1,0650 since all team members receive a salary of $50 per hour.

The schedules for each major work activity have been estimated by taking into consideration several factors:

Managerial Process Plans

Start-up Plan

Estimates

The schedules for each major work activity have been estimated by taking into consideration several factors:

• Required time implemented by each team member
• Team members’ availability
• Deadlines for deliverables
• Process model to be used (Waterfall model)
• Previous experience with similar work activities
• Workload of the activity

Most of the work activities outlined in Annex A are familiar to the team members. The estimates for these activities have been done by simply looking at the workload of the activity and by estimating the time for that activity by taking into account previous encounters with a similar activity. For each work activity, all team members individually estimated the time and cost for that activity. If the difference between each estimate isn’t significant, the average of all estimated is taken as the final estimate for that activity. If the difference is significant, further analysis of the work activity is done until a final acceptable estimate can be produced. Due to the familiarity the team members have with these activities, our confidence level for these estimates are high. Our confidence level is 90%.

However, this is a first time project for most of team members; thus, some of the work activities are new and have never been done previously by either member. They are as follows:

• Quality assessment
• Comparison to original proposal
• Lessons learned
• Project plan

In these cases, best judgement was used to estimate the time and cost associated with a work activity. Some inquiries will be made upon individuals who have had experience in these areas such as, previous students who had taken this course or had done a similar project before, to help with our estimates. Again, all team members individually estimated the time and cost, and the average of all estimates is taken. In these special cases where no previous experience with the activity exists, our confidence level is about 65%. Even though we do not have previous experience, we are able to know what needs to be done and use best judgement to obtain this confidence level.

Throughout the project, the initial estimates will be compared with the actual cost and times for work activities. If discrepancies occur, the current estimates will be re-evaluated and updated to reflect any changes.

Staffing

Five team members are assigned to the project. These team members are students at the University of Ottawa currently enrolled in the SEG4913 course. These team members will remain as the only staffers for the lifetime of the project.

Either or all team members must have all the skills needed for the successful completion of each phase of the project. If any skills are missing, the team members must acquire these skills at their own time and expense.

Resource Acquisition

The University of Ottawa supplies all team members for the project. The project customer and the University of Ottawa supplies all resources needed by the project team. There is no budget for other resources that are needed by the team members. If extra resources are needed, the project team must supply the cost. In this case, all team members must discuss the need for the extra resource and split the cost if they decide to purchase it. Extra resources could include:

• Printing costs
• Office supplies
• Other minor costs

Project Staff Training Plan

This section is not relevant to our project since no training sessions will be offered to the team members. The developers for the project have already met all the skills needed.

Work Plan

Work Breakdown Structure

The WBS for the project is outlined in detail in Annex A. All work activities have been identified as well as the associated time and cost needed to complete them.

Milestones are defined in Annex B.

Schedule Allocation

All work activities have all been scheduled in a manner to produce the necessary deliverables for the project at their specified deadlines outlined in the course requirements for SEG4913.

There are five team members on the project, each one works part time on the project. The availability and the time required to be implemented by each member, was taken into consideration to create an appropriate work schedule. The average time required by the team is about 7 hours a week.

The following Gantt chart associated with the WBS of the project defines the 5 main tasks and their deadlines. It also shows all concurrent development that can be done.

Figure 1: MepWars game Gantt chart of phases

The MS project document for the MepWars game attached with this document details the work activities, their schedules and the full Gantt chart associated with all the activities.

Resource Allocation

The only resources that have an associated cost is the staff’s time. The cost and associated staff for each activity is given in the WBS. The customer and the University of Ottawa provide all other resources free of charge. These resources include the necessary facilities (laboratories and classrooms) and tools (computers and software) needed for each work activity. The team members can use these resources at times allowed by the customer and the University. Any further resources will be distributed to the team member who dispenses the cost of that resource.

Budget Allocation

The WBS contains the budget for each activity. The team members provide the cost for any other expenses.

Control Plan

Requirements Control Plan

Once the requirements are completed, they will be baselined and put under configuration management as defined in this document. Since this project is to be done primarily for academic purposes and the timeline of the project is fixed, changes to the requirements must be carefully analyzed and accepted by the change control board. For each proposed change, the change control board must:

• Assess the effect on the size and scope of the project
• Assess the effect on the project schedule
• Compare the skills needed for the change to the team members’ skills
• Assess the need for the change

Once these have been done, a decision must be made whether to accept or refuse the change. If accepted, all documents and work activities that are affected by the requirements must be reassessed.

Schedule Control Plan

Team meetings

A formal meeting will be held every week to bring all team members up to date on the status of the project and plan the next work activity. Any obstacles encountered will also be discussed.

At the end of each work activity, the current status of the project will be compared to the estimated schedule and corrective actions will be taken if the two are not aligned.

The project manager is responsible to schedule the weekly meetings and has to inform the rest of the team of the time, date and place of the meeting.

Stakeholders meetings

An online meeting with the customer will be held at each prototype release to inform the later on the status of the project . An informal review by the customer is needed in order to confirm the project is on target.

Other meetings will be scheduled by the professor responsible of the software project course (SEG 4913) for educational evaluation purposes and to verify the status of the project.

A team member will be assigned to act as “meeting secretary”, responsible to write a report summarizing the topics discussed. A status report will be presented to all stakeholders at the end of each work activity. If needed , all team members and stakeholders may request to schedule additional meetings.

Budget Control Plan

As stated above, an EVA will be done to create new estimates if needed. The associated cost with each new estimate will then replace the old estimated costs. The budget will vary depending of these new estimates.

Quality Control Plan

Quality control will be done according to the Quality Assurance Plan outlined in this document. The main indicators of quality will be the grades received for each deliverable as well as the two customer evaluations. If the results of these indicators show an undesirable level of quality, changes to the Quality Assurance Plan will be made to increase the quality level of our project.

Reporting Plan

Monthly status reports will be used to report all the work done on the project by the team members. The status report is divided into different sections, which include:

• The report ID
• The project name
• The month for which it applies
• The highlights of the month
• A list of risks and issues
• A table containing:
• The tasks started that month
• The description of that task
• The staff for the task
• The progress of each task (% completed)
• A list of the task scheduled for next month

These monthly reports are filled out at the end of each month in a Word document and are sent electronically to the supervisor of the SEG4913 course.

Metrics Collection Plan

The main metrics that will be collected for our project are the completion times for each work activity as well as the actual time invested into each activity. Every time a work activity is completed, the metrics associated with it will be collected by the team members and inserted into a MS Project document. This document will be put under CM and updated regularly. It will be used at times for progress evaluation and other inquiries.

Risk Management Plan

This section identifies various risks related to the Victory e-learning and describes the tracking activities and contingency plans.

Risk Identification

Contractual Risks

R001 The customer may decide to break the contract

Intermediate System Risks

R002 Network failure could cause stop of game.

Requirement Changes

R003 Requirement changes will affect the timing.

Technological Risks

R004 The chosen technology (java) that will be used to implement the MepWars Game may create limitations to some functionality.

R005 Changes in technology may require hardware or software changes on either the client or the server side.

Risk Analysis and Prioritization

Likelihood (0 = impossible; 1 = sure) Consequence (0 = none; 1 = very important) Severity (Likelihood x Consequence)

Risk Plan and Monitoring

A detailed risk plan will be created and communicated to the team and management. A first draft of the plan will be provided after requirement sign-off. During the duration of the project, the project manager will track the most important risks and apply their corresponding steps and approaches.

Risk Mitigation

This section describes what will be done to reduce the probability of the risk in a proactive manner.

R001: A prototype will be provided to the client describing the features and advantages that this product would bring to his clients.

R003: A prototype will allow reviewing the requirements with the client and users at the beginning of the project and reduce the risk of major changes in later parts of the project.

R004: Design the code so that additional features can be included with less complexity.

R005: Follow the specifications of the MepWars software when including it into the product to make it easier to adjust when there is a newer version of the MepWars Game.

R002: A more reliable network connection would cost more. When the network is unavailable, the automated process will become manual. This means that the user will need to call the restaurant in order to make a reservation.

Closeout Plan

The project must be completed by the final deliverable date. Complete or not, all deliverables must be submitted to the supervisor. All milestones must also be provided to the customer.

The team members are students and therefore, will not be reassigned after the project is done. Continuing work on this project or other related project could be possible if the customer hires the team members. He will then assume administration responsibilities for the team members.

If any stakeholders desire an archive of all produced documents and items, they will receive the items and will be responsible for archiving them. However, an archive of the project is not mandatory.

A final presentation of the product will be given to the SEG4913 course supervisor and students. Furthermore, a final report will be done for the project and given to the course supervisor. This report consists of:

• All documents completed
• Final system demonstration
• Evaluation report
• Quality assessment
• Comparison to original proposal
• Lessons learned
• Member contributions

Once completed all team members will receive a grade for their project. If they are given a passing grade then the course and the project will be complete.

Technical Process Plans

Process Model

This project has very fixed deadlines that must be met. These deadlines form a basic sequential development process. Therefore, the model used to develop the product will be a slightly derived version of the basic waterfall model. The following figure shows the basic waterfall model.

Figure 2: Basic Waterfall Model

Our project starts with the requirement phase, which consists of both the requirements and analysis displayed above. Following, the design phase, the coding phase and the testing phase occurs. However, some of the work activities from the coding and testing phases are done concurrently. The documentation phase is done in parallel to all other phases. It contains the first work activity (Project Proposal) and the last work activity (Final Report) to be done. All these phases and their associated work activities are in the WBS in Annex A. Finally there will be no maintenance phase since this project has a fixed lifetime and cannot supply the resources for it.

All other processes done in parallel to development are defined in this document and carried out by all members.

Methods, Tools, and Techniques

The following must be adhered to in order to successfully complete work activities for the project:

• Submitted documents will be done in MS Word
• Formatting of the submitted documents will be done according to the SEG4913 requirements
• The WBS and task tracking will be done using MS Project
• Functional requirements will be defined using use cases according to UML.
• Design specifications will be done according to UML
• Code must be done in Java and compiled on Windows workstations
• Presentations will be done in MS PowerPoint
• Submissions will be done through e-mail
• Work products will be put under CM

Infrastructure Plan

All work is done either in the Site building lab or in team members’ homes. No specific hardware is needed for the project. Some software is needed to efficiently complete the tasks of the project.

• MS Office
• MS Word
• MS Project
• MS Powerpoint
• QuickTime
• Rational Rose
• Java 5.0

Product Acceptance Plan

All work products will be reviewed and then accepted by the project team. These work products include project deliverables, project milestones (defined in Annex B), presentations and other produced items. Many work products will be compared against the requirements for approval.

Next, the customer will review all completed work products and if accepted, they will be signed off. Signoff requires the customer to sign a physical document related to the work product. If no such document exists, such as in the case of code, one will be produced for signature purposes. They will then be delivered to the SEG4913 course supervisor for a final grade. Once these steps have been completed the work products will be baselined and put under CM.

Once all deliverables have been accepted and baselined, and the project successfully completed according to the project closeout plan, the MepWars game will be complete and, therefore, considered acceptable.

Supporting Process Plans

Configuration Management Plan

Please refer to the MepWars game Configuration Management Plan document attached with this document.

Verification & Validation Plan

Verification and validation will be done through reviews mentioned in the Review and Audits in section 6.5. Comments and feedback from these reviews will be used to verify and validate the project’s work products.

Verification and validation of the code components of our project will be done through test cases. For each component, a test case will be performed and the results will be analyzed to identify any operational discrepancies. Changes will be done to satisfy the initial requirements and to produce correct operational results. Once the results are satisfactory, the code component will be validated.

Documentation Plan

All documents required for this project, including their times and costs, are defined in the WBS in Annex A. The schedule for each of these documents will be followed.

Quality Assurance Plan

Work quality will be assured by properly following all the processes outlined in the SPMP. Every team member will be expected to know and conform to these processes. They will act as work standards for the development of the project.

Product design will be compared against the requirements to ensure proper design quality. The quality of the code will be assured through code review and by using test cases to validate it.

Results from reviews and audits performed will identify the quality of our work products. If the quality level is unsatisfactory, modifications to the processes is in order to increase the quality of our project. Also, progress tracking and analysis will be done to ensure the quality of the project schedule.

Reviews and Audits

For each deliverable, the team members will review the initial created version of that deliverable and change it if necessary. Next, the customer will review it and deem it as acceptable or not. He will also provide comments on the deliverable. Finally, the supervisor of the SEG4913 course will do the same. Comments will be given to the team members and a final version will be submitted.

A review of the project progress will also be conducted after each work activity. The project team will do this review.

Problem Resolution Plan

All team members will be responsible for identifying any problems that occur in the project. Every time a problem occurs, a report will be generated detailing the following information:

• Problem ID
• Date of occurrence
• Problem description
• Type of problem
• Cause of the problem
• Work activity that is affected
• Milestones and work products that are affected
• Severity of the problem
• Possible solution(s) to the problem
• Corrective action taken (including date and time of implementation)
• Result of corrective action
• Further corrective actions (optional)
• Further comments (optional)

Once the problem report has been completed, it is put under CM. For each problem that occurs in the project, research into other similar documented problems will be done to ease the analysis and problem solving process.

If several problems occur at the same time, then for each problem, a report will be made and the problem with the highest severity will be analyzed first. Other problems will be addressed once we have solved the more severe problem or that we have reduced their severity level.

The Verification and Validation Plan, the Quality Plan as well as Reviews and Audits are key processes to the early detection of problems that could occur in our document.

The problems identified throughout the project will be reviewed at the last stage of our project to create the lessons learned document.

Subcontractor Management Plan

This does not apply to our project. There is no subcontracting allowed.

Process Improvement Plan

After every work activity is completed, a quick EVA will be done to assess the progress of the project. If an analysis yields any negative results, corrective action will be taken and noted in a report document. Identification of improvements to any existing processes will also be noted and incorporated into the SPMP.

Other assessments will be done each time a problem is identified and handled using the Problem Resolution Plan in section 7.6. An analysis of these problems might also yield possible improvements to existing processes.

Reviews and audits can also signal minor flaws that may be analyzed to find possible improvements.

Random suggestions of improvements by team members can be taken into consideration and implemented to increase productivity.

All suggested improvements must be analyzed for impact on the project. The cost and time to incorporate the improvement, as well as, the ROI should be taken into consideration. If the improvement is deemed beneficial, it will be implemented. However, suggested improvements are not always beneficial to this particular project.

Annex A: Work Breakdown Structure

The following Gantt chart outlines all the major work activities including all their subtasks. Each subtask is identified, given duration and a cost, their predecessors identified and the person assigned to the task is given.
The MepWars game MS Project document attached to this document gives the same WBS. However, the specific schedules are identified for each task within the constraints of the academic year. This document should be consulted when the SPMP is facilitated.

Figure 1: MepWars game Gantt chart of phases

The MS project document for the MepWars game attached with this document details the work activities, their schedules and the full Gantt chart associated with all the activities.

Annex B - Project Milestones

The following milestones have been identified to help track the progress of the project. They have been identified using the project deliverables and the work breakdown structure defined in Annex A.

• 8 Monthly Status Reports
• 1 Final Project Proposal
• 1 Final Requirements Document
• 1 SPMP and all companion documents
• 1 Final Design Document
• All code components identified in the WBS
• All test cases identified in the WBS
• 1 Final Report
• 2 Customer Evaluations

Annex C – Organizational chart

The following Organizational chart identifies all stakeholders in the project. These stakeholders make up the external interfaces and internal structure of our project as defined in section 4. Dashed lines represent the external interfaces and interaction. Continuous lines represent the internal structure of the project.

Figure C.1 Organizational Chart

Quality Assurance Report

Description:

The “alpha” version, the latest version, of the system was tested. This version of the program is 70% complete, in other words, 70% of the bugs are fixed. This new build is available on our website, http://ryanhyma.servebeer.com/MepWars. The .zip file of the program with its respected freeware downloads needed for the program to run correctly is provided on the web site.

Release Tested:2.5 alphaDate Released:October 22, 2005

Requirements:

The requirements needed for the program are all found on the web site cited above. This web site contains links to the download page of each of the freeware software needed to run MepWars. Below are the instructions on how to start the game.

Installation Instructions:

• Download and Install QuickTime 7 from the link on the right side menu
• Download and Install Java 5 from the link on the right side menu
• Reboot your computer
• Click on Play MepWars link.

Non-functional requirements addressed in the making of MepWars:

Use Case Model of Functional Features of System :

User

Use Case 1:

A user (Bob) goes to the website, he clicks on the MepWars game, the usage agreement window shows up, he can either agree to continue or disagree and leave.

Requirements addressed: Non-functional requirement 3 - Target Audience

Use case 2:

Bob does not have Java 1.5 installed. On the web site, Bob clicks on the Java 1.5 link which leads him to a download screen. Once Java 1.5 is installed, Bob downloads the game and launches the chat.

Requirements addressed: Non-functional requirement 1 - Java 1.5 compatibility.

Client

Use case 3:

Bob chooses to be a client by clicking on the “client” tab. He enters the host IP address and port number and connects. He will be able to join a server and starts chatting with other players if the server is not full. Bob may also choose to leave the game.

Requirements addressed: Functional requirement 2, 4 and 6 - User Interface, Client option, and Maximum player

Server

Use case 4:

If Bob decides to be the server, he also needs to enter the name and port. Bob then starts the server and launches the game or wait for players. Once the game is launched, it starts and the user can quit at any time.

Requirements addressed: Functional requirement - User Interface, Server option, and Maximum player

Player

Use case 5:

Bob, while playing the game, can either move their paddle to avoid collision or use power-ups when needed. The players and can quit the game at any time.

Requirements addressed: Functional requirement - Input support and Game ove

Test summarization:

Bugs:

The bugs are 70% fixed. Our program is very sensible to change, thus every time we fix a bug the chances are a new one is discovered. We foresee a bug free program by the end of the courses’ term. The bugs found are not always severe or critical (all severe bugs are fixed immediately when found) in the functional sense, however they’re essentially fixed for ergonomic and better usage of the game (ex: little problems with the UI, the special alphabet symbols provided by Todd etc…).

When a new build is finished and posted, the team is asked to run it and to test all the features looking for bugs. When a bug is found, it is sent to the Test manager who then will sit down with the architectural programmer and try to fix the new problem. Thus, the whole team participates in the testing of the program.

Proof of Concept:

Conformance Requirements:

Multiplayer networked gaming is the main functional requirements for our game. Thus data needs to be sent over the network and reconstructed into game events by both the client and server. The following sequence diagram outlines the process in which data is received from the network and translated into an event and passed to the event handler and finally executed.

The process includes the following steps:

• NetworkManager receives data in the form of a ByteBuffer
• EventHandler takes the data and processes it using the prototype pattern to look through a list of possible Events. When a match is found it constructs a new event and sets the appropriate parameters.
• The EventHandler then sends the event to the EventListener
• The EventListener is actually the Controller of the state machine. It adds the event to its queue.
• When the update portion of the gameloop occurs (a method call from the HeartBeat) the event is then delegated to the particular state the game is in.
• The state then executes the event and depending on the particular state handles the event in a specific manager

The following diagram depicts the sequence of 1-3 listed above.

The following diagram depicts the sequence from 5-6. The sequence assumes that the controller is ClientGameManger and that the game is currently in the playing state.

As can be seen the HeartBeat (which is the gameloop thread) during each update loop calls the ClientGameManager and tells it to update the state of the game. The ClientGameManger then delegates this task to the state. The state then iterates through all received events since the last update and executes them.

Algorithm's Applicability:

The most significant algorithm in our system is the algorithm that is used to detect the collision and rebound of the ball off of angled moving objects. The objects the ball can bounce off of are the shield pieces and the paddle. The following algorithm is used and will be described thoroughly. The first part of the algorithm simply gets the velocity of the paddle and the ball during their last iteration it then sets the velocity of the ball relative to the paddle. This means that the calculations can then be performed as if the paddle were stationary. The paddles velocity will then be added back on after the rebound velocity has been calculated.

Paddle playerPaddle = this . paddles [ this . playerPos ];

float paddleVX = playerPaddle.getPosition(). x

- playerPaddle.getPreviousPosition(). x ;

float paddleVY = playerPaddle.getPosition(). y

- playerPaddle.getPreviousPosition(). y ;

// now the paddle is stationary as far as the ball is concerned.

float vX = ball[i].getPosition(). x

- ball[i].getPreviousPosition(). x ;

float vY = ball[i].getPosition(). y

• ball[i].getPreviousPosition(). y

// now the paddle is stationary as far as the ball is concerned.

vX -= paddleVX;

vY -= paddleVY;

The next part of the algorithm creates a rectangle using the ball position and size, the rectangle will be used later to see if it intersects with the paddle.

Rectangle2D.Float pos = new Rectangle2D.Float(

ball[i].getPosition(). x - vX, ball[i].getPosition(). y - vY,Ball. SIZE . width , Ball. SIZE . height );

The xInc and yInc variables are then set. These variables are needed because it is possible for the ball to be moving so quickly that in one update of the gameloop the increment of position may actually allow the ball to pass through the paddle. To compensate for this the actual movement is divided by a constant value and a loop is done starting with the balls old position and is incremented by xInc and yInc. During each iteration a collision detection is done. This ensures that even if the ball is moving extremely fast the collisions will still be detected. The detection is done by finding the intersection of the ball using it's old position plus the value of xInc and yInc using the position of the paddle.

float xInc = vX / COLLISION_ITERATIONS ;

float yInc = vY / COLLISION_ITERATIONS ;

The next part of the algorithm gets the lines of intersection with the ball and paddle. After that it then finds the angle of conversion depending on the line that the ball hits. If the ball hits the flat side the conversion angle would be 0 however if it hits a side wall then it will have to be adjusted by 90 degrees.

Line2D.Float intersectLine = intersectLines.get(0);

double angle = Math.toRadians(playerPaddle.getRotateAngle())

VecMath.getConvertedAngle(lines, intersectLine);

Once the angle is known the velocity vector and paddle are rotated by the angle of the paddle and the rebound velocity vector calculation is then easy because the paddle is assumed flat and the calculation is simply inverting one of the axis depending on the side hit. After the velocity is calculated it is then rotated back to get the actual angled rebound velocity.

Point2D.Float vel = VecMath.getReboundVelocity(vX, vY,

intersectLines.get(0), angle);

The paddle velocity is then added onto the final velocity this allows for transfer of energy allowing the ball to speed up if the paddle hits it hard.

vel. x += paddleVX;

vel. y += paddleVY;

After all the calculations are made the objects are updated.

ball[0].setVelocity( new Point2D.Float(vel. x *30, vel. y *30));

ball[0].setPosition( new Point2D.Float(pos. x + 2 * vel. x ,

pos. y + 2 * vel. y ));

The calculated event is then sent to the rest of the clients playing the game.

GameEvent event = new ClientBallMove( new Point2D.Float(vel. x *30,vel. y *30),

new Point2D.Float(pos. x + 2 * vel. x , pos. y + 2* vel. y ));

this . eventListener .addEvent(event);

The algorithm is a still a work in progress we are still tweaking it to model the physics of elastic collisions and rebounds.

Simulation and Modeling:

Our system cannot be simulated due to its need of connected network resources. The system does include two small state machines. These state machines are related to the systems network connectivity. The client has the following states:

Idle: This state is needed to model the situation in which the player has not yet connected to the host. In this situation the only events the Idle can receive are events that have to do with connection to the host.

ClientConnected: This state models the situation in which the user has connected to the host and is currently able to chat to the other players in the system. This state is needed to allow users to see what specific game settings are required and is also needed because all users will not simultaneously connect. At this point users are waiting for other players to join the game.

WaitingForPlayers: This state is required for game synchronization purposes. Essentially this state's sole purpose is to do all of the games pre-loading of graphics and sound and to sit idle until the server notifies it that all players are ready and to launch the game. If the state did not exist some players would get an unfair advantage if their computers are faster because their game would load quicker and they would be able to perform moves before others.

Playing: Playing is the state that models the actual playing of the game. In this state all event received are game object related events, such as the movement of the paddle or the destruction of another player.

The server is also a state machine that has the following states:

Idle: This state models the server before it has actually started running. In this state no ports have been opened and no users can connect to the host.

ServerAccepting: In the ServerAccepting state the server will allow outside clients to connect to it. This is the only state where new connections will be accepted.

WatingForSync: This state is very similar to the client state WaitingForPlayers. It essentially waits for all players to send a message stating they are ready to play. Once all messages are received it broadcasts the playGame event and the server then moves to the Playing state.

Playing: The playing state is the state in which all game events are passed through the server and broadcasted to clients. Essentially the Server is very dumb and has very little game knowledge or understanding. Most of the processing is done by the clients themselves.

As can be seen all states are required for the proper functioning of the game.

Instructions On Setting-up and Playing MepWars On-line.

(Important Note: You only need to follow steps 1 and 2 ONCE. )

1. Getting Started

The game is written in Java, and it has a short introductory movie embedded. So to run it, you will need Java 5 and QuickTime. If you are not sure whether you have those or not, you can do the following:

• Double click on My Computer icon on your desktop.
• At the upper left hand corner under System Tasks, click on Add or remove programs. A window should popup.
• In the popup window frame, scroll down and look for QuickTime and J2SE Runtime Environment 5.0.
• If you can’t find them, please read Download and install bellow. Otherwise, skip to Run the game.

2. Download and Install

2.1 QuickTime

• click this link: http://www.apple.com/quicktime/download/win.html . It will bring you to Apple website.
• uncheck all the boxes under Sign-up. Then click on Free Download Now.
• A file download window should pop-up. Choose Save. Then choose where you want to save the file. It is recommended that you save it on your desktop so you won’t forget where you save the file and also easy to delete the file after installation.
• Click on Save again. Wait for downloading. It should take from a minute to several minutes depending on your Internet speed.
• After downloading, find the file iTunesSetup.exe on your desktop and run it.
• Read the security warning window (if it pops up), make sure the publisher is Apple Computer, Inc. If it is, click run to start the installation.

2.2 Java 5

• Follow the link:https://sdlcweb2a.sun.com/ECom/EComActionServlet;jsessionid=DFF0BD19C39AF5A32C7C3EA550F721B1
• Read the stuff on the website. Choose which file to download according to your operating system. For example, if you are using Microsoft Windows, you should click on Windows Offline Installation, Multi-language. Then save the file just like what you did to the QuickTime file.
• Run the downloaded file jre-1_5_0….

Now you are good to go!

3. Run the game

• Click on MepWars

-------------------------------------------------------------------------------------

Ok enough of that!

So you can see I really wasn't bs-ing when I kept talking about how this game was "in the works". Needless to say I had no idea what they were talking about at all. I don't understand really any of that. I graduated college with a 2.27 GPA with a degree in Communication. These guys probably ain't that gonna also.

But I was psyched that this was being taken so seriously and so detailed! Canadian too! I figured this was going to be a serious game!

Long story short (you can stop here if you're bored). The game itself never got finished. Short story longer. Continue reading:

My one concern going in was going to be programmed in "Java". For those of you who don't know what Java is...umm.... you're like me. I don't know what the hell it is. I just know it's weird and foreign feeling and it loads weird. But I whatevered the java thing. Web beggers can't be choosers.

As time went on I started to see rough prototypes of the working game. That's where I started to get more involved. I'd send over buttons or some graphics and sounds and they'd get plugged into the game. But it sort of looked weird and very rough. And as the months went by I kept getting documentation (see above) but there wasn't a ton changing in the actual working game (Alot was going on behind the scenes in terms of functionality but the actual fun 'Let's add some more bloops! And booms! Race of X! Jimmers! And how do we make the planet's explode! And how's it gonna work when the space dragon comes and everyone has to fight it together! And what about the powerups!' All seemed sort of down the road a bit considering just getting the bally to go bouncy was a challenge.) But I was patient and everything I do takes forever so I understood.

I figured in the meantime I'd get another game off the ground. In the past I worked on stuff with the brilliant Geoffrey @ ae4rv.com. Unfortunately, at the time, he was too crunched to start a new game. They really do take a long time. Bummer total.

Anyway, the semester started racing to an end and I felt the team sort of breaking away from the project. It wasn't even close to done in terms of being a working game. Only the team leader, Ryan, hung in there to really pressure everyone to put the game together-- but it seemed the documentation was really the priority for the class grade. Ryan generously offered to continue working on the game by himself after school ended but there was simply a ton of work to be done. And I decided to pull it. When someone's working for free it's just not fair. But super mega-thanks to Ryan for trying to keep this afloat for as long as he did. And thanks for the other people on the team as well for their hard work.

So that was that. Big giant apologies to people who've been waiting on MepWars for so long. I was of course totally bummed that it went down a clunky road.... but I VOW that one day that game will live on this site! I will find a way! It just might not be a ragtag bunch of coolio Canadian students putting it together...

BUT THERE IS GOOD NEWS!

Now AE4RV has cleared the decks a bit and a new game is in the works! It might not be MepWars but it's gonna be way coolio and spacey! And at least you know now that when you hear me say stuff is 'in the works', I'm not just laying around all being lazy and stuff (although I am usually. just not all the time).

Of course all things take time. So please be patient.  Please stay tuned.... lots of other coolio stuff in the works too.... as always.

ok bye!
tOdd

PS. There was second game I was working on (not with AE4RV) that didn't make it thru development. It was going to be like Space Invaders with crazy weapons and powerups and games within the game. But Mep went nuts demanding all sorts of crazy weapons and the people working on it sort of fired us because Mep was being a over ambitious jerk.  He wanted freeze rays, machine guns, flame throwers, atomic weapons, and napalm for the invaders... etc.

But this is as far as it got...

PPS. Got a bunch of emails regarding developing MepWars as open source. I'm into it and checking into it totally...