Mechaius Technical Design

[Monolith]

I don't remember what or how much was planned before, but as something to get restarted on the technical design, I was sketching out some of the architecture through some of the classes/components I think will be needed. This is not complete, but it is something to start with.

(Bleh, sorry for the poor formatting. I could just do things in Word documents or something so it looks nicer.)

Program
Purpose
Holds everything for the program
Single instance
Contains
Game
Menus
Form
Render Device

Game
Purpose
For everything in the actual game (as in part of the gameplay), and nothing else.
Single instance
Contains
Level
Player collection

Level
Purpose
For everything in a single level.
Single instance
Contains
Map
Object collection

Player
Purpose
Everything related to the player in the game
Multiple instances
Contains
Controlled object

Map
Purpose
Contains the arrangement of tiles that make up the level.
Single instance
Contains
Tileset

Tileset
Purpose
Contains a full tileset.
Single instance
Contains
Managed tile collection

Object
Purpose
Abstract base class for all dynamic objects in the game.
Multiple instances

Renderable Object
Purpose
An object that can be rendered
Contains
Reference to a Graphic Resource through the Resource Manager

Resource Manager
Purpose
Stores, loads, and otherwise manages all resources.

Resource
Purpose
Abstract base class for all resources (such as graphics, sounds, etc.).
Multiple instances

Graphic Resource
Derives from Resource
Purpose
Contains a graphical resource

Menus
Purpose
For a system of menus.
Contains
Menu collection

Menu
Purpose
The stuff for a single menu screen.

Form
Purpose
Just the standard empty form there to be used for drawing. Doesn't really contain anything.

Render Device
Purpose
Interfaces with the graphics library for all the rendering.
Contains
All stuff needed for the graphics library
Reference to the form to draw to

[Hareoic]

...Can anybody tell me what that is?

[Onag]

This is a great start! I made few adjustments and (hopefully) clarifications. I'm assuming we use some kind of Singleton class, but I haven't yet figured out a clean way to do this with C#.

<b>class Application : Singleton</b>
<table><tr><th valign="top">Purpose:</th><td>Holds everything for the program</td></tr><tr><th valign="top">Contents:</th><td>Main program entry point
Game object
Menus collection
Form object
Render Device</td></tr></table>

<b>class Game : Singleton</b>
<table><tr><th valign="top">Purpose:</th><td>For everything in the actual game (as in part of the gameplay), and nothing else.</td></tr><tr><th valign="top">Contents:</th><td>Level object
Player collection</td></tr></table>

<b>class Level : Singleton</b>
<table><tr><th valign="top">Purpose:</th><td>For everything in a single level.</td></tr><tr><th valign="top">Contents:</th><td>Tileset collection
Layer collection
Object collection</td></tr></table>

<b>class Player : IControllableObject</b>
<table><tr><th valign="top">Purpose:</th><td>Everything related to the player in the game</td></tr></table>

<b>class Layer</b>
<table><tr><th valign="top">Purpose:</th><td>Contains the arrangement of tiles that make up the level.</td></tr><tr><th valign="top">Contents</th><td>Tile collection</td></tr></table>

<b>class Tile</b>
<table><tr><th valign="top">Purpose:</th><td>Represents a single tile on a single layer</td></tr><tr><th valign="top">Contents:</th><td>Tileset index
Tile index</td></tr></table>

<b>class Tileset</b>
<table><tr><th valign="top">Purpose:</th><td>Contains a full tileset.</td></tr><tr><th valign="top">Contents:</th><td>Tile collection</td></tr></table>

<b>interface IGameObject</b>
<table><tr><th valign="top">Purpose:</th><td>Abstract base class for all dynamic objects in the game.</td></tr></table>

<b>interface IRenderableObject</b>
<table><tr><th valign="top">Purpose:</th><td>An object that can be rendered</td></tr><tr><th valign="top">Contents:</th><td>Reference to a Graphic Resource through the Resource Manager</td></tr></table>

<b>class ResourceManager : Singleton</b>
<table><tr><th valign="top">Purpose:</th><td>Stores, loads, and otherwise manages all resources.</td></tr></table>

<b>interface IResource</b>
<table><tr><th valign="top">Purpose:</th><td>Abstract base class for all resources (such as graphics, sounds, etc.).</td></tr></table>

<b>class GraphicResource : IResource</b>
<table><tr><th valign="top">Purpose:</th><td>Contains a graphical resource</td></tr></table>

<b>class Menus</b>
<table><tr><th valign="top">Purpose:</th><td>For a system of menus.</td></tr><tr><th valign="top">Contents:</th><td>Menu collection</td></tr></table>

<b>class Menu</b>
<table><tr><th valign="top">Purpose:</th><td>The stuff for a single menu screen.</td></tr></table>

<b>class GameForm : Windows.Form</b>
<table><tr><th valign="top">Purpose:</th><td>Just the standard empty form there to be used for drawing. Doesn't really contain anything. May be able to just use System.Form directly.</td></tr></table>

<b>class RenderDevice</b>
<table><tr><th valign="top">Purpose:</th><td>Interfaces with the graphics library for all the rendering.</td></tr><tr><th valign="top">Contents:</th><td>All stuff needed for the graphics library
Reference to the form to draw to</td></tr></table>

[Monolith]

Forcing those classes to be singletons isn't really necessary. You just normally keep one instance of those classes around anyway. I actually think it's simpler to not bother with making them singletons. Plus there might be some instances where you want more than one instance of one of those classes. Like for dynaimcally loading one level while the player is in another.

<b>class Application</b>
<table><tr><th valign="top">Purpose:</th><td>Holds everything for the program</td></tr><tr><th valign="top">Contents:</th><td>Main program entry point function
Game object
Menus collection
Form object
RenderDevice object
SoundDevice object</td></tr></table>

<b>class RenderDevice</b>
<table><tr><th valign="top">Purpose:</th><td>Interfaces with the graphics library for all the rendering.</td></tr><tr><th valign="top">Contents:</th><td>All stuff needed for the graphics library
Reference to the form to draw to</td></tr></table>

<b>class SoundDevice</b>
<table><tr><th valign="top">Purpose:</th><td>Same sort of thing as the RederDevice.</td></tr></table>

<b>class ResourceManager</b>
<table><tr><th valign="top">Purpose:</th><td>Stores, loads, and otherwise manages all resources.</td></tr><tr><th valign="top">Contains:</th><td>IResource collection</td></tr></table>

<b>interface IResource</b>
<table><tr><th valign="top">Purpose:</th><td>Abstract base class for all resources (such as graphics, sounds, etc.). Primarily used for keeping track of resources in the Resource Manager.</td></tr></table>

<b>class GraphicResource : IResource</b>
<table><tr><th valign="top">Purpose:</th><td>Contains a graphical resource.</td></tr></table>

<b>class SoundResource : IResource</b>
<table><tr><th valign="top">Purpose:</th><td>Contains a sound resource.</td></tr></table>

<b>class MusicResource : IResource</b>
<table><tr><th valign="top">Purpose:</th><td>Contains the stuff for a music resource. Not actually in memory as it would probably be a streaming thing. I am a little unclear on this one.</td></tr></table>

<b>class Game</b>
<table><tr><th valign="top">Purpose:</th><td>For everything in the actual game (as in part of the gameplay), and nothing else.</td></tr><tr><th valign="top">Contents:</th><td>Level object
Player collection
Game state (running, paused, quit)</td></tr></table>

<b>class Level</b>
<table><tr><th valign="top">Purpose:</th><td>For everything in a single level.</td></tr><tr><th valign="top">Contents:</th><td>Tileset collection
Layer collection
Object collection</td></tr></table>

<b>class Layer</b>
<table><tr><th valign="top">Purpose:</th><td>Contains the arrangement of tiles that make up the level.</td></tr><tr><th valign="top">Contents:</th><td>Tile collection (array)</td></tr></table>

<b>class Tileset</b>
<table><tr><th valign="top">Purpose:</th><td>Contains a full tileset.</td></tr><tr><th valign="top">Contents:</th><td>TilesetResource object
Tile count</td></tr></table>

<b>struct Tile</b>
<table><tr><th valign="top">Purpose:</th><td>Represents a single tile on a single layer</td></tr><tr><th valign="top">Contents:</th><td>Tileset index
Tile index</td></tr></table>

<b>interface IGameObject</b>
<table><tr><th valign="top">Purpose:</th><td>Abstract base class for all dynamic objects in the game.</td></tr></table>

<b>interface IUpdatableObject</b>
<table><tr><th valign="top">Purpose:</th><td>An object that can be updated.</td></tr><tr><th valign="top">Contents:</th><td>Update function</td></tr></table>

<b>interface IRenderableObject</b>
<table><tr><th valign="top">Purpose:</th><td>An object that can be rendered</td></tr><tr><th valign="top">Contents:</th><td>Reference to a Graphic Resource through the Resource Manager
Render function</td></tr></table>

<b>class Player : IControllableObject</b>
<table><tr><th valign="top">Purpose:</th><td>Everything related to the player in the game</td></tr></table>

<b>interface IControllableObject</b>
<table><tr><th valign="top">Purpose:</th><td>An object that can be controlled by user input?</td></tr></table>

<b>class Menus</b>
<table><tr><th valign="top">Purpose:</th><td>For a system of menus.</td></tr><tr><th valign="top">Contents:</th><td>Menu collection
Current menu</td></tr></table>

<b>class Menu</b>
<table><tr><th valign="top">Purpose:</th><td>The stuff for a single menu screen.</td></tr><tr><th valign="top">Contents:</th><td>MenuObject collection</td></tr></table>

<b>class MenuObject</b>
<table><tr><th valign="top">Purpose:</th><td>Some sort of base class for menu items such as buttons, edit boxes, etc.</td></tr></table>


There will be multiple tilesets used within a level?

Is IGameObject the same as I'm thinking for IUpdatableObject? IUpdatableObject can be used outside of the game though, such as for the menus.

I think we won't need a GameFrom class. A normal Windows.Form should be fine.

I know we need something for input, but that's not something I'm too familiar with.

Also I'm thinking the Game and Level objects should be both Updatables and Renderables.

[Onag]

The dream was to allow multiple tilesets to be used on a given level. Using this method, we could make the tilesets more specialized (hence, smaller).

I think both the IGameObject and IUpdatableObject interfaces would probably serve the same purpose, as most (all?) objects in a game have state that can be updated.

Let's start fleshing out these interfaces:

IResource
- .Release()
IUpdatable
- .SetState(IObjectState)
IObjectState (?)
- .Name
IRenderable
- .Render()
IControllable
- .SendCommand(IControlCommand)
IControlCommand()
- ?
IMovable
- .Transform(Matrix)

Changes? Additions? Am I overdoing it on the interfaces yet? I can add more! I'm not sure what overhead is involved (if any) when using interfaces in .NET. We'll have to do some careful profiling to make sure we don't incorporate something that will bring the game down to a crawl.

-Nag

[Monolith]

Interfaces are good so long as they're abstract. Once you start getting to where you can specify data or functions, then you should start using real classes. Like for the IMovable. That is at least something with a location, so right there it has some specific data and functions for that data. (Actually you might as well let the location data be public if it's simple enough.) IControlCommand might not be an interface either.

I'm not sure what you're thinking of with the IObjectState for the IUpdatable. My purpose of the IUpdatable is that it has an update function. This way you can have a collection of IUpdatables to loop through in the update task, just like you'd have a collection of IRenderable to call Render on in the render task. States for objects probably wouldn't be needed till you get to something more specific.

And for resources, I have to think a bit about how resource management would work.

[Onag]

Here's an example (though not a very good one) of where IMovable would be useful:

A mine explodes, sending a shockwave throughout the surrounding area. In this area, you have the player, some baddies, some ammo lying around, and a large, half-burried rock.

You would want everything but the rock to move. One easy way to handle this is to check all objects in the shock-wave to see if they implement IMovable, then move them accordingly.

We could put the location data and move method in a class, but .NET limits us to single inheritance outside of interfaces, so we have to be careful about what we put in base classes.

IObjectState can go. I was misinterpreting the meaning of IUdatable. Also, IRenderable is a must, but I don't think it should have any implied reference to a graphic resource. This would limit its capabilities.

-Nag

[Monolith]

I think before we can flesh out all the object classes and interfaces, we need to know what all the objects are going to be. So basically objects need to be completed in the game design before we can work on it in the technical design.

There's still pleanty of stuff on the technical side that can be designed in the meantime though, such as how input, rendering, updates, resource management, etc. can be delt with.