• Advertisement
  • entries
    503
  • comments
    1888
  • views
    334548

Mixin-It-Up

Sign in to follow this  

170 views

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
  • Sign in to follow this  


    4 Comments


    Recommended Comments

    Guest Anonymous Poster

    Posted

    The smell of design pattern in the early morning! Yummy!

    Share this comment


    Link to comment

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

    • Advertisement