Index: Home     | What Is Izumi | Misc Links   | Random Thoughts | Too Much To Read | The Rant Vault | Quotes
Dev:   Projects | Ideas For Dev | Nerdkill | Rig | Hint

They are all expandable.

Note: this is the development page Nerdkill C#, not to be confused with the Nerdkill C# home page.
Site License And Disclaimer as well as contact information are available here.

$Id: Nerdkill.izu,v 1.1 2005/11/05 21:55:57 ralf Exp $

1. The basics -- 20030922

1.1. Goals

• Revive BeOS-like version.
• F#
• More C# + C# => DirectX
• NUnit
• Methodology

1.2. Simple architecture

• Module gameplay (F#, start with C#?)
• Module engine (C#, hide DirectX and platform)
• Module low-level, aka platform: app, input, rendering, sound.

1.3. Gameplay

• List of nerds (position, direction, state)
• Actions
• Update/move nerds: kill, run away

1.4. Platform

• Create/init DirectDraw, DirectSound.
• Display background, sprites, menu.
• Emit sounds (queues).
• Input capture => queue or state.

1.5. Communication

Gameplay <=> Engine <=> Low-level
             (glue)     DD/DS

The "engine" is simply there to hide the low-level handling from the gameplay, in case it changes. So basically it's not much more than a glue or a passthru. Also it's a good place to store the state of the game (nerds, etc.)

Something like that:

	+---------------------------------------------------+
	|                       init -->--+                 |
	|                                 |                 |
	| gameplay     engine         low-level             |
	| --------     ---------      ---------             |
	|     |        main loop   <- control               |
	|     | <----- actions []  <- capture input (mouse) |
	|     | <----> nerds   []  -> render sprites        |
	|     | -----> sounds  []  -> play                  |
	|     | <----> stats       -> display               |
	|              menus       -> display               |
	+---------------------------------------------------+

1.6. Milestones

• 1.0: Low-level
• App init.
• Load gfx, load snd.
• Display screen, 1 sprite, play 1 sound.
• 1.1: Game loop
• 1.2: Input capture, engine passthru.
• 1.3: etc.

Later (added 20031102):

• 2.0: Use F#, use NUnit

1.7. Engine main loop

Architecture the main loop as a state buffer and a callback, instead of the traditional monolithic while loop. This way it's easier to adapt to a timer callback, or a thread, or a main app loop.

1.8. Planned Implementation

20030923

1.8.1. Classes

• RMainLoopPtc
• RRendererPtcDD implements IEngine2D
• RSoundDS implements IEngineSound
• RInputDI implements IEngineInput
• PTC#

PlatformEngine:

• define IEngineProcess (state + process frame)
• define IEngine2D
• define IEngineSound
• define IEngineInput
• REngine (instantiates subclasses and let gameplay access them)

PlatformGameplay:

• RNerkillGame uses IEngineProcess

1.8.2. Separation

The game will start with a menu, directly using a 2d renderer.
The main loop (platform) starts the game loop, inits the renderer, etc.
At the beginning on the platform, it should be possible to switch renderers at runtime, i.e. not a compile time. Typically I may want to select the renderer depending on the hardware caps.
Later I may want to switch between a 2d or 3d rendering and gameplay at runtime.

2. Real Implementation --

Nerdkill C# 1.0 is almost finished and quite frankly the experiment is a success. OK the initial idea was to use to learn C# and F#. Currently it's all in C#. Using F# can be seen as milestone 2.

Milestone 1 had two goals: first recreate the nerdkill game, functional. And second write a descend architecture, relatively modular and self-explicit. These two goals are completed. This will detail more about the architecture and the methodology.

The methodology was more or less the following:

• Define an architecture, write it down. Some things had to be forgotten but generally I got it relatively right:
• Define modules (namely engine vs platform vs gameplay, later adding resources)
• Ideally these modules could almost be compiled as separate DLLs.
• All communication is done thru the engine, which is the one defining the interfaces that other modules implement.
• Modules heavily rely on each others but there's only one place where the protocol (i.e. the interface API) is defined. Others must comply.
• Implement it. Since it is not a very big project, there was no need to write down enhancements. Some modifications include:
• The engine cannot simply be a list of abstract interfaces. It is also the right place to store the implementation of the main loop.
• Adding a resources module, that loads & stores bitmap and sounds. It communicates with the platform module to actually load into a suitable format. Locally the resources are objects, so the resource module has no knowledge of what the platform module created. This reduces inter-dependance.
• The state of the game is held in the gameplay module rather than the engine.
• The engine holds one class, the main loop, that regulates the workflow (create windows, load resources, manage the frame rate, etc.). Eventually all the game processing is done in the gameplay module.
• Reusability: the architecture is generic enough, it could be reused as-is. The implementation itself is specific. For example the engine split things between a renderer, a gameplay, a platform host and resources. Per se these are generic categories, but the details of each interface are more or less specific to Nerdkill -- or at least to any 2d frame buffer kind of game.

Some details:

• Writing down the design architecture with a list of classes was key in a good implementation.
• Using namespaces to separate modules from the start. This made modules apparent and very explicit in the code and in the project, helping to store the right classes at the right place. On the down side, it made the code a bit verbose (although the using/alias of C# can come up handy to solve this, I have yet to get used to it).

Some things could be done better though:

• The engine main loop performs some pre/post actions that should be done in the gameplay. There could be a pre-init/post-terminate callbacks in the gameplay to perform those.
• There are two sets of constants, one in the engine and another one in the gameplay. Although they serve different purposes, it is sometimes difficult to know where to store new constants. The implicit rule is that if a constant is used solely by the gameplay it should go there. If potentially used by the engine or other modules too, it should go to the engine: all modules can access the engine constants, but only a module can access its own constants.
• Lack of use of NUnit for testing.
• My earlier idea that every function should return a boolean to indicate if it worked or failed is blatlantly wrong and obnoxious. The idea was to uniformize the fact that a function can fail yet simplify the code as throwing exceptions is both heavy on the runtime and the code needed to catch them. The original idea was that most of the time programmers ignore the return value (they may not even check if something is returned). The problem is that not every function needs to return an error flag and making it systematic is actually worse than having to think if a function can fail or not -- as for myself I would often simply ignore checking the return value since I know some functions cannot fail. Ideally I think the language should enforce using functions' return value if present. Throwing exceptions is not the solution -- code that does not catch exceptions is no better than C/C++ code that never checks on invalid null pointers (both result in annoying runtime errors).

A note on the storage of the game state: initially I wanted this to be in the engine. The idea was that both the renderer and the gameplay would access let's say the list of nerds. The problem is that means the renderer knows what the game is about. Instead the renderer should only know about displaying a sprite or a list of sprites. It's up to the gameplay to know what kind of entities are handled and then order the renderer to display some sprite at some location. The renderer must not have any semantic associated with its sprites.
The same goes with sound: the resource module loads sounds and calls a method from the platform's sound class (thru its generic interface) to actually allocate the sound buffer. All what is stored in the resource module is an anonymous object. Later on the gameplay will ask the resource module for the sound description (some kind of id) and pass to the sound player class for playback. The modules are truly independant: the sound player has no knowledge of the semantic of the sound whilst the resource or the gameplay modules have no knowledge of the structure of a sound.

DirectX uses a mechanism where resources are typically created in the associated device. For example sprites are either stored in the graphic card or at least in a format compatible with it. Same for the sound. That implies that creation of a sprite must be done by the platform specific class, nor the generic resource module. Another important detail is that surfaces or buffers can be lost -- for example when switching from fullscreen to windowed. That means that at some point during the game, the resources may have to be reloaded.
Handling that situation is done in the engine main loop: the main loop will ask the renderer is the main surface has been lost. If yes, it needs to put the main graphic loop on hold. When the surface is available again, sprite resources need to be restored.
A side implication of that is that the gameplay cannot cache structures returned by the resource module for a long term (but it can in the context of one frame loop). Each time a sprite is to be rendered, the gameplay will grab the opaque sprite definition by its id from the resource module and transmit it as a black box to the renderer.

Where do I go from now?
First finish and public the game. Two minor weapons are missing and there's no annoying bug left.

Next explorer using NUnits and F#, in parallel. I may not recode the full gameplay module using F# as I originally intended to but it should be interesting. One of the problems is that since I already have a C# module working, it is going to make it more challenging to think the way ML wants one to think. Rewriting the full gameplay module may be just too much, instead I'd like to have a mix/match of C# and F# working on the same data structures, and maybe limit the F# code to a couple of key algorithms like handling the state of the nerds.

Next, or rather in parallel, explorer NUnits to add non-regression testing to the game. Given the simplicity of Nerdkill that may seem unecessary. But on the other hand, that means it shouldn't be too difficult so why not doing it, right? Regression testing for the engine and the gameplay seems like a good thing, whereas for platform or renderer that may be less obvious.

20031108

I did explore separating the current engine in several DLLs.
That did not work very well. There are many problems here:

• The current structure as the engine as a centerpiece.
• Most modules use the interfaces, which are set in the "engine" module. But this also includes the engine main loop. So that means all modules need to include the engine as a DLL reference.
• The engine creates the resource instance (when it should be done in the main, my bad). The engine also accesses directly to some private window-related routines.
• So the modules need to reference the engine DLL and the engine DLL needs to reference the modules' DLLs. That doesn't work.

Obviously to be able to produce real DLLs I need some modifications:

• Separate the engine main loop and the interfaces in different modules.
• Only use the pure interfaces in the engine main loop.
• Some of the engine loop logic should go in the gameplay thru interface calls.

20031111

Real modules have been created. Each module is now a sub C# project.
A "core" module was added, to contain the former main loop and engine loop.
The engine module now refers to the engine interfaces, the engine constants and some minor structs (REvent f.ex.).

Also started adding some NUnit testing, as a test.

Site License

This work is licensed by Raphaël Moll under a Creative Commons License.

Options

Color Theme:	Gray  | Blue  | Black  | Sand | Khaki  | Egg  | None

Web ralf.alfray.com

Display Izumi & PHP Credits

Stats

1528 accesses, 1 access from 38.107.191.84
Visited 76 times by Google, last 2010/08/15 19:38
Visited 213 times by Yahoo!, last 2010/09/06 12:37
Visited 3 times by Alexa, last 2009/08/25 03:55
Visited 24 times by Teoma, last 2010/08/30 21:38
Visited 145 times by MSN, last 2010/09/06 22:45

< Generated in 0.29 seconds the 09/09/2010, 03:56 AM by Izumi 1.1.4 >