Mechaius Technical Design
 

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.)

...Can anybody tell me what that is?

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#.

class Application : Singleton

Purpose:	Holds everything for the program
Contents:	Main program entry point Game object Menus collection Form object Render Device

class Game : Singleton

Purpose:	For everything in the actual game (as in part of the gameplay), and nothing else.
Contents:	Level object Player collection

class Level : Singleton

Purpose:	For everything in a single level.
Contents:	Tileset collection Layer collection Object collection

class Player : IControllableObject

Purpose:	Everything related to the player in the game

class Layer

Purpose:	Contains the arrangement of tiles that make up the level.
Contents	Tile collection

class Tile

Purpose:	Represents a single tile on a single layer
Contents:	Tileset index Tile index

class Tileset

Purpose:	Contains a full tileset.
Contents:	Tile collection

interface IGameObject

Purpose:	Abstract base class for all dynamic objects in the game.

interface IRenderableObject

Purpose:	An object that can be rendered
Contents:	Reference to a Graphic Resource through the Resource Manager

class ResourceManager : Singleton

Purpose:	Stores, loads, and otherwise manages all resources.

interface IResource

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

class GraphicResource : IResource

Purpose:	Contains a graphical resource

class Menus

Purpose:	For a system of menus.
Contents:	Menu collection

class Menu

Purpose:	The stuff for a single menu screen.

class GameForm : Windows.Form

Purpose:	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.

class RenderDevice

Purpose:	Interfaces with the graphics library for all the rendering.
Contents:	All stuff needed for the graphics library Reference to the form to draw to

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.

class Application

Purpose:	Holds everything for the program
Contents:	Main program entry point function Game object Menus collection Form object RenderDevice object SoundDevice object

class RenderDevice

Purpose:	Interfaces with the graphics library for all the rendering.
Contents:	All stuff needed for the graphics library Reference to the form to draw to

class SoundDevice

Purpose:	Same sort of thing as the RederDevice.

class ResourceManager

Purpose:	Stores, loads, and otherwise manages all resources.
Contains:	IResource collection

interface IResource

Purpose:	Abstract base class for all resources (such as graphics, sounds, etc.). Primarily used for keeping track of resources in the Resource Manager.

class GraphicResource : IResource

Purpose:	Contains a graphical resource.

class SoundResource : IResource

Purpose:	Contains a sound resource.

class MusicResource : IResource

Purpose:	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.

class Game

Purpose:	For everything in the actual game (as in part of the gameplay), and nothing else.
Contents:	Level object Player collection Game state (running, paused, quit)

class Level

Purpose:	For everything in a single level.
Contents:	Tileset collection Layer collection Object collection

class Layer

Purpose:	Contains the arrangement of tiles that make up the level.
Contents:	Tile collection (array)

class Tileset

Purpose:	Contains a full tileset.
Contents:	TilesetResource object Tile count

struct Tile

Purpose:	Represents a single tile on a single layer
Contents:	Tileset index Tile index

interface IGameObject

Purpose:	Abstract base class for all dynamic objects in the game.

interface IUpdatableObject

Purpose:	An object that can be updated.
Contents:	Update function

interface IRenderableObject

Purpose:	An object that can be rendered
Contents:	Reference to a Graphic Resource through the Resource Manager Render function

class Player : IControllableObject

Purpose:	Everything related to the player in the game

interface IControllableObject

Purpose:	An object that can be controlled by user input?

class Menus

Purpose:	For a system of menus.
Contents:	Menu collection Current menu

class Menu

Purpose:	The stuff for a single menu screen.
Contents:	MenuObject collection

class MenuObject

Purpose:	Some sort of base class for menu items such as buttons, edit boxes, etc.

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.

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

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.

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

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.