Simulacra: The Features
warning: this is lengthy, geeky post and will most likely contain typos, cos i am too lazy to proof-read.
ok, i’m gonna go through the proposed features of simulacra which are by no means definite. which ever way, this is gonna take a lot of time to complete considering i have a day job and also that i’m trying hard to have a life.
the engine is not commercial. i still have to figure which license i will be going with (LGPL?). the primary target platforms are windows and linux. the mac isn’t supported because i don’t have a mac, never used a mac, and i doubt i’ll be owning one ever. basically the subsystems of simulacra, which i will explain are: core, graphics, UI, input, sound, physics, character animation, AI, input, sound, tools.
the programming language of choice is the obvious C/C++, coupled with OOP principles. C# will be considered for tools but at this moment i’m not sure as to its status on linux machines. i’ve heard about the mono-project but that was a long time ago during my last days as a linux freak.
the core system
this is the basis of all game engines. the most frequently used routines will be defined here, platform-specific code will be encapsulated here. C++ features will be implemented and the maths library will be constructed.
low-level: this is the lowest level of the engine and will generally handle all platform-specific system level routines through encapsulation; stuff such as system time, window management, multi-threading? (nasty! by the time this engine will be finished, quad-core cpus will be cheap – screw intel) will be sorted out here. other commonly used routines for file I/O, memory management, and debugging utilities will also be implemented here.
mathematics: i always enjoy this bit (its easy anyway). any engine that deals with graphics and geometry must necessarily have a subsystem for mathematics. this system will consists of math routines for trigonometry, vectors, matrices, quaternions, planes, and lines. for graphics, a data structure for color will also be defined.
renderer (raytracing/raycasting): a raytracer is something I’ve been looking forward to implementing. why? my former classmate had to implement one on a GPU and he seemed to have had fun doing it. and that’s what I want to do. a simple CPU and GPU raytracer.
special effects: nowadays, it’s kind of hard to draw the line between fixed and programmable pipelines as a lot of graphics effects are now implement in the GPU. I haven’t yet decided what and where I’m going to do what so the following is just a rough idea and it will change – i know. when it comes to shaders, it’s very much in the hands of the application writer and shader code is quite specific to the projects it’s used on. however I will provide a few basic sample shaders for different effects.
fixed function: texture loader, basic texture mapping, multi-textures, projected textures, bump mapping, environment mapping, planar reflections, planar shadows, lens flares, billboarding, particle systems, fog, water, fire, sky, terrains, foliage?
shaders: per-pixel/per-vertex lighting, basic texture mapping, multi-texturing, environment mapping, bump mapping, parallax mapping, water rendering, reflective mapping, refractive mapping, cel-shading, HDR lighting, deferred shading, fog.
meshes: will provide support for loading meshes of different open formats (such obj, md5, etc). tessellation will be supported too.
scene graphs: not quite sure if this should be under graphics but i’ll try to make it as generic as possible. scene graph implementations will include octrees and BSP trees. i might consider ABTs if I can get my head around it. also, stuff like level of detail (LOD) will be implemented.
the UI system
writing a UI library is something i think would be interesting. i don’t believe it’s that hard though but yet i think i’m gonna be annoyed doing it as it’s more of an OOP problem that anything else. making a robust UI system would be a challenge. the UI system will support skins (easily configurable and loaded from XML files). or i could just use crazy eddie’s GUI system.
the input system
this is a relatively easy-to-implement subsystem of the game engine and will most likely be implemented using a third-party input library such as SDL's input system, especially useful for linux.
the sound system
just like the input system this is easy to implement and i will be using the FMOD sound libraries, which is quite popular in industry.
the physics system
writing a robust physics engine isn’t trivial at all. it’s a really complex system and i will be going the third-party way again and using PhysX. however since i enjoy physics programming, simulacra will provide support for rigid bodies and collision detection. soft-body physics will be considered but only as far as 2D soft bodies such as cloth physics.
the character animation system
no naturalmotion stuff here :). I hope to implement features such as keyframe animation, skeletal animation, inverse kinematics, mesh skinning and deformation. all these are old-school stuff compared to what naturalmotion is doing.
the AI system
now i have experience writing an AI engine, so this system should be more straight-forward than the others. AI engines, just like shaders, most of the time are game-specific. hence i will only provide agent-based, AI functions for navigation and decision making that are common to most genres.
decision making architectures: the architectures that will be implemented are: finite state machines (FSMs), scripted FSMs, fuzzy state machines (FuSM), rule-based AI, and goal-driven behaviour.
scripting: at the moment, my decision is to use lua (until I look into gamemonkey) for scripting, and XML for file loading. There I will have to written a versatile lua scripting engine. I will mostly like be using TinyXML for XML parsing and will provide a wrapper for it (in case i might want to change XML parsers in the future).
editors: having editors would be swell but i’m afraid this part will be least looked into. i don't have much passion for tools (i.e. gui programming) but a map editor would be cool though.
as i progress with coding, i'll go much more into details about the implementation of the different components. i reckon this engine will take me at least 3 years to complete and that's just being optimistic.
ok, i’m gonna go through the proposed features of simulacra which are by no means definite. which ever way, this is gonna take a lot of time to complete considering i have a day job and also that i’m trying hard to have a life.
the engine is not commercial. i still have to figure which license i will be going with (LGPL?). the primary target platforms are windows and linux. the mac isn’t supported because i don’t have a mac, never used a mac, and i doubt i’ll be owning one ever. basically the subsystems of simulacra, which i will explain are: core, graphics, UI, input, sound, physics, character animation, AI, input, sound, tools.
the programming language of choice is the obvious C/C++, coupled with OOP principles. C# will be considered for tools but at this moment i’m not sure as to its status on linux machines. i’ve heard about the mono-project but that was a long time ago during my last days as a linux freak.
the core system
this is the basis of all game engines. the most frequently used routines will be defined here, platform-specific code will be encapsulated here. C++ features will be implemented and the maths library will be constructed.
low-level: this is the lowest level of the engine and will generally handle all platform-specific system level routines through encapsulation; stuff such as system time, window management, multi-threading? (nasty! by the time this engine will be finished, quad-core cpus will be cheap – screw intel) will be sorted out here. other commonly used routines for file I/O, memory management, and debugging utilities will also be implemented here.
mathematics: i always enjoy this bit (its easy anyway). any engine that deals with graphics and geometry must necessarily have a subsystem for mathematics. this system will consists of math routines for trigonometry, vectors, matrices, quaternions, planes, and lines. for graphics, a data structure for color will also be defined.
the graphics system
the big kahuha. this is usually what makes or breaks an engine. it’s what the graphics-crazy world looks at. well I’ll just say I’m not a graphics whore, I’d rather code physics or AI than do graphics so don’t expect much.
renderer (fixed function): i’ll be using the OpenGL library for rendering on both windows and linux. i might implement a DirectX9 renderer but that will much much later, probably at the end of the project. By the time I through with the engine, this again might be futile as the fixed-function pipeline is giving way to the programmable pipeline (GPU programming). the renderer will support font rendering, and rendering of basic 2D primitives such as lines, triangles, quads, and also 3D primitives such as cubes, cylinders, cones, etc.
renderer (raytracing/raycasting): a raytracer is something I’ve been looking forward to implementing. why? my former classmate had to implement one on a GPU and he seemed to have had fun doing it. and that’s what I want to do. a simple CPU and GPU raytracer.
special effects: nowadays, it’s kind of hard to draw the line between fixed and programmable pipelines as a lot of graphics effects are now implement in the GPU. I haven’t yet decided what and where I’m going to do what so the following is just a rough idea and it will change – i know. when it comes to shaders, it’s very much in the hands of the application writer and shader code is quite specific to the projects it’s used on. however I will provide a few basic sample shaders for different effects.
fixed function: texture loader, basic texture mapping, multi-textures, projected textures, bump mapping, environment mapping, planar reflections, planar shadows, lens flares, billboarding, particle systems, fog, water, fire, sky, terrains, foliage?
shaders: per-pixel/per-vertex lighting, basic texture mapping, multi-texturing, environment mapping, bump mapping, parallax mapping, water rendering, reflective mapping, refractive mapping, cel-shading, HDR lighting, deferred shading, fog.
meshes: will provide support for loading meshes of different open formats (such obj, md5, etc). tessellation will be supported too.
scene graphs: not quite sure if this should be under graphics but i’ll try to make it as generic as possible. scene graph implementations will include octrees and BSP trees. i might consider ABTs if I can get my head around it. also, stuff like level of detail (LOD) will be implemented.
the UI system
writing a UI library is something i think would be interesting. i don’t believe it’s that hard though but yet i think i’m gonna be annoyed doing it as it’s more of an OOP problem that anything else. making a robust UI system would be a challenge. the UI system will support skins (easily configurable and loaded from XML files). or i could just use crazy eddie’s GUI system.
the input system
this is a relatively easy-to-implement subsystem of the game engine and will most likely be implemented using a third-party input library such as SDL's input system, especially useful for linux.
the sound system
just like the input system this is easy to implement and i will be using the FMOD sound libraries, which is quite popular in industry.
the physics system
writing a robust physics engine isn’t trivial at all. it’s a really complex system and i will be going the third-party way again and using PhysX. however since i enjoy physics programming, simulacra will provide support for rigid bodies and collision detection. soft-body physics will be considered but only as far as 2D soft bodies such as cloth physics.
the character animation system
no naturalmotion stuff here :). I hope to implement features such as keyframe animation, skeletal animation, inverse kinematics, mesh skinning and deformation. all these are old-school stuff compared to what naturalmotion is doing.
the AI system
now i have experience writing an AI engine, so this system should be more straight-forward than the others. AI engines, just like shaders, most of the time are game-specific. hence i will only provide agent-based, AI functions for navigation and decision making that are common to most genres.
decision making architectures: the architectures that will be implemented are: finite state machines (FSMs), scripted FSMs, fuzzy state machines (FuSM), rule-based AI, and goal-driven behaviour.
scripting: at the moment, my decision is to use lua (until I look into gamemonkey) for scripting, and XML for file loading. There I will have to written a versatile lua scripting engine. I will mostly like be using TinyXML for XML parsing and will provide a wrapper for it (in case i might want to change XML parsers in the future).
editors: having editors would be swell but i’m afraid this part will be least looked into. i don't have much passion for tools (i.e. gui programming) but a map editor would be cool though.
as i progress with coding, i'll go much more into details about the implementation of the different components. i reckon this engine will take me at least 3 years to complete and that's just being optimistic.
Labels: coding, simulacra_x
posted by c0dec at 22:36
2 Comments:
3 years? HELL NO. This is why I never went into programming.
lol. it's never too late - you know you still want to do it.
Post a Comment
<< Home