Collision System Revisited

After giving a lot of thought to Professor Keenan's suggestions about callbacks and the decoupling of colliding objects, I have decided to completely redesign my collision system and generalize it to the point that it could become a central part of my MHFramework game engine.

Here are the elements of the system as I am currently envisioning it:

Collidable Interface

• public boolean isColliding(Collidable);
• public CollisionGeometry getCollisionGeometry();
• public void collideWith(Collidable);
• public int getType();

CollisionPoint Class

• private Point center;
• private float radius;
• public boolean isColliding(CollisionPoint);

CollisionGeometry Class

• private ArrayList collisionPoints;
• public boolean isColliding(CollisionGeometry);
• public CollisionPoint getCourseBounds();

Shield System UML Diagrams, Iteration 1

The shield system for the Space Invaders project is somewhat hierarchical in nature; not just through inheritance, but through the system of instantiated objects as well.  The class diagram below shows the classes that make up this subsystem.

Both the shield class and the individual bricks that comprise it derive from the basic sprite class because they have similar needs -- rendering, collisions, changes in state, etc.  The shield itself maintains an array of brick objects so that each brick can have its own state and damage effects.

The damage effect is accomplished by the dynamic creation of a separate image object.  When a brick is destroyed, it generates a "damageEffect" image.  The appearance of crumbling is attained by randomly drawing ovals onto the "damageEffect" image, which is then superimposed over the normal shield brick image.  So the bricks don't actually go away.  Instead, they change state which changes their collision response (nothing counts as a collision) and their rendering behavior (the damage effect is drawn over the brick image).

Collision detection and response happens in the game's update phase.  The game screen calls to the collision processor to process all relevant collisions.  Part of that process involves checking the shields for collisions with projectiles, and another part checks for collisions with the invaders.  Here's a rough, highly generalized form of the sequence diagram.

Space Invaders Class Diagram, Iteration 2

Here's a revamp of the class diagram that more accurately reflects the actual implementation up to this point.  To keep the diagram clean and readable, not all associations are represented here.

Brainstorming a "Simple" Design Doc

I'm a little disappointed by the cancellation of the individual project, but mostly, it's a relief.  I was very concerned about my ability to devote an appropriate amount to time to it.  But Space Invaders -- now that can be done.

So now we need a game design document .  Normally, that's the first step in any game project, but in this case, a standard game design document seems almost like overkill for a game like this.  The question is, what sections would be appropriate to be in a design document for as simple a game as Space Invaders?  I'm going to brainstorm here 'cause it's a good place to keep a record of my thoughts.

• Overview
• Rules and Objectives
• Game Play Overview
• Victory/Loss Conditions
• Scoring
• User Interface and Controls
• Key Commands
• HUD Elements
• Multimedia Assets
• Graphics
• Audio

Project Proposal Site is GO!

My project proposal site is up and running at https://sites.google.com/site/ctg456/home,

The initial requirements are met on the following pages:

• Description of game (https://sites.google.com/site/ctg456/home and in the design document on https://sites.google.com/site/ctg456/file-cabinet)
• Features of game (https://sites.google.com/site/ctg456/project-definition)
• Screen mockups (https://sites.google.com/site/ctg456/home)
• Project plan/milestones/schedule (https://sites.google.com/site/ctg456/project-definition)

Debating the Project

When I first found out that we'd be doing an individual game project, I was thrilled.  It's just the excuse I've been looking for to get a small, simple game done.  My first overwhelming urge was to make the isometric platformer that I've been wanting to do ever since I added two new detail layers to my isometric tile map system.  However, the realist in me eventually spoke up with some reasonable objections:

1. With my heavy load and long hours at work right now, I don't have the time to make the assets required for such a project.  
2. With Space Invaders being written in parallel to this project, I don't want to take on something with that much uncertainty.

A few days ago, I decided that I had to think of something more feasible for the time allowed.  Then, just today, out of the blue, I was hit with a brilliant idea:  I need to remake the old CTG game that my friends and I made twelve years go.  Why?  Because:

• The first version (from 1998, in C++) was abandoned because of issues we had with the rigidity, deployment, and licensing of the wrapper on the graphics API.  It was playable, but never finished, lacking essentially EVERY feature aside from a two-player deathmatch that let the players shoot and destroy each other.
• I tried to remake the game about eight years ago in Java, but that was before I had started serious work on my game engine.  There were a lot of graphics and threading issues that were later solved with the engine itself, but I had once again abandoned the project because I didn't feel like refactoring all the work that I had just done.
• Most importantly, the art assets and sound effects are already made, saving a huge amount of time in developing this game.

So this is what I'm going to propose:  A complete redesign and rewrite of my first "major" game...which wasn't that major, but it seemed like it at the time.  If this proposal is rejected for any reason, I have a few more ideas in mind, but I'm going to assume that this'll be it...as soon as I get Space Invaders out of the way, of course.

Space Invaders Class Diagram, Iteration 1

I am beginning the Space Invaders project the same way I begin every project -- with a rough class diagram to start getting some ideas down. It needs a lot of refinement, but it's a start.  At this point, I foresee uses of the Factory, Facade, Observer, and possibly the Template Method pattern, with probably more to come.

A first attempt at a class diagram for the Space Invaders project.