EDIT: A diagram of the boot procedure







So this weekend saw some actual bare-metal work.

It has been a LONG time since I've had to do any engine programing 'save for at my day-job' so I was kind of excited.

So I made a copy of the Flare 3.0 engine (same engine that Morning's Wrath is made with), And ploped it down into a new directory.

I had been fussing over the name of this engine for a while, finally I settled on somthing simple.

The S3 Engine

With S3 being Story Scripting System

That seems to sum up my visions for this engine pretty good, here are the engine's goals.

Role - A game engine for making 2D Isomtric Adventure Games (story games)

Compiled - engine is a sealed exe, no real code neccisary to make a new game w/ it

Simple - artists and scripters should be able to use it

Scriptable - Game logic is controled via external scripts

HighLevel - as above, the engine only exposes high level features (there is no scriptable blitter, or writing an image loader, etc.)

DataDriven - All of what makes up the game should exist in external data files (configs,images,scripts,etc.)

WellDocumented - all engine features will be well documented in thier technical aspects and implications as well as their usage

Performant - should efficantly use resources and optimized processes


Procedure:

So with all this in mind I knew there were a few things I wanted to do to the Flare Engine to get it ready to become the S3 Engine

1. Home Rolled? Hit the Road.

Flare uses a plethora of Home-Rolled container classes, these will be replaced with STL equivilents.

2. XML

Flare ALSO uses a home-rolled XML parser document object, I have replaced this with TinyXML and so far I am pleased.

3. API Indipendant == Headache

Flare has a system of API adaption that allows it to work with 'any' potential API if an adapter DLL is crafted for it. This system really did us no good in the past and was a pain in the ass to build and maintain.

This time around we will be using Direct3D8 (with png image files), DirectInput and DirectAudio8 (with ogg files), directly (no pun intended =D)

if it is discovered that we need platform indipendance, a platform indipendant engine version can be produced and used with the same data (data driven, remember =D)

4. Model View Controller

To keep game-state in one place I have implemented a Model/View/Controller type pattern for the engine. With this, saving a game will be as simple as game->save(); and starting a new game as simple as Engine::newGame(new Game());

5. Time-Event Clock core

Flare3 is currently implemented for Time-Based motion and animation, with velocities expressed as Pixels-Per-Second and Frames-Per-Second.

An addition to this is a Real-Time (but scalable) Event Clock, under normal circumstances, each game loop measures the time it took and applies this time to the clock, the clock state is examined and events are fired off accordingly.

onStep - not time related, it is called every game loop

onSecond - called every in-game Second

onMinute - called every in-game Minute

onHour - called every in-game Hour

onDay - called every in-game Day

There is also an abilitiy to 'scale' time progression, with this you can slow down the game or speed up the game. The scaling is done at the root of time progression as a modification of 'milliseconds passed' so everything that makes use of the time system (everything =D) is affected by this.

While we are unlikely to use this feature a lot, it will be exposed through the scriptable api, and it's values will be serialized with the game-state.

The uses can work for slow-motion (coupled with dark lighting and other effects could make for a dream scene?), or fast-motion (could be used to create intensity (move-fast think-fast))

Another system is the ability to 'set' named alarms,

setAlarm(obj,"Leave",4,Seconds);

these will end up calling script functions, in this case, after 4 seconds it would raise:

onAlarmLeave()

in the script of the respective object for which the alarm was set.

6. New rendering core

I am currently working on rebuilding the graphics core for the engine (no longer in an adapter dll), I am also working to make it usable on even lower hardware (currently testing on a voodoo3)

I have been speaking with the brilliant minds on Afternet #graphicsdev (reltham, superpig, promit, sages), and they have been advising me on proper implementation for optimal results.


That is all for now, work will continue on implementation of the graphics core and then move on to scripting system implemenation.

The renovation is off with a bang!

Wish me luck =D