Sign in to follow this  
Endar

writing an engine specification

Recommended Posts

How do I go about writing an engine specification? I mean, should I just write down things like "multi-texturing" and "per-pixel lighting"? How in depth should I be going? This is my current list:
  • Direct X
  • Loading and animation of MD5 models (doom 3, quake 4) for use with physics.
  • Loading and rendering of BSP maps for indoor levels
  • Loading and rendering of outdoor maps
  • Shaders
  • Per-pixel lighting (implemented with shaders)
  • Easily extendable camera system
  • Easily extendable material system (includes shaders)
  • Resources only loaded once
  • Ensure that shaders and textures can be re-loaded without re-starting engine
This is just supposed to be a basic list. I've also got other notes on how the implementation is supposed to go for some of these. Is this generally how it is done, or should I be making more extensive notes about the implementation of these things (singly)?

Share this post


Link to post
Share on other sites
why are you writing an engine spec? that should determine how much info you need. If its just for your own engine, is there even a need for such a document?

Share this post


Link to post
Share on other sites
I'm writing specs for individual components of my engine, hoping they will be self-contained for portability and pinpointing of issues when they arise. Here is my mesh specification:


Type: Static
Operations: Translate, Rotate, Scale

Store/Render As:
For GL: VBO, Display List
For DX: no idea yet, something optimized for static

Notes:
-Vertices Locked(never change)
-Vertex Shader/Program Slot
-Cannot promote to Dynamic
-Resource Manager should determine if sufficient VRAM for VBO, if not then use Display List, possibly partition between VBO and Texture heap.

------


Type: Dynamic
Operations: Translate, Rotate, Scale, Update

Store/Render As:
For GL: Vertex Array, possibly Immediate Mode
For DX: no idea yet, Vertex Array equiv.

Notes:
-Vertices stream from buffer in RAM
-Vertex Recalc function slot, fires on Update call
-Vertex Shader/Program Slot
-Can demote to Static

------




Static mesh storage would be useful to quickly render a lot of stuff that doesn't change shape, like buildings and landscape features. Some animation could be accomplished by switching between frames.

Dynamic meshes would be more for stuff like explosions, volume rendering(metaballs?) and deformable objects(chipping away at a dirt wall or squashing a barrel under a heavy object, etc.)

That's what I have so far and am in the process of implementing it, not sure yet if everything is feasible.. Just thought I'd post an example of how I'm going about writing the Technical Design Docs.

Share this post


Link to post
Share on other sites
Quote:
Original post by supagu
why are you writing an engine spec? that should determine how much info you need. If its just for your own engine, is there even a need for such a document?


Having a specification document for your own document isn't completely unneccessary. Having the engine written down in front of you makes it easier to spot things which may conflict with another part of the engine, and makes it much easier to remember everything you want to do! Of course it would be more beneficial if it was written for a team, but it does provide a good place to consolodate all the ideas for the engine.

Share this post


Link to post
Share on other sites
Quote:
Original post by supagu
why are you writing an engine spec? that should determine how much info you need. If its just for your own engine, is there even a need for such a document?


Definately. I'm planning on making an actual game with this, and with my previous engine, the one I'm re-writing, it does some stuff, but really has no easy extensibility, or a great amount of flexibility.

Share this post


Link to post
Share on other sites
Quote:

the one I'm re-writing, it does some stuff, but really has no easy extensibility, or a great amount of flexibility.

Writing down specs for a new one won't solve that problem. While some amount of pre-implementation design, which may include writing stuff down, is generally a good thing, it doesn't magically make your designs better. You made mistakes regarding extensibility and flexibility previously. You'll make new ones with this new "engine," and perhaps even some of the same mistakes if you don't build on your existing codebase, refactoring as neccessary.

You should focus your design (and development) efforts on a viable end-product: the game. Refactor your existing "engine" codebase as needed to add generality to it. Unless you have a lot of experience and multiple finished games, you generally can't just sit down and write an engine. You can, however, develop a passable engine by iterative refinement of your existing common code bases -- this is a useful skill to develop in any case, and will yeild much greater returns.

Share this post


Link to post
Share on other sites

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

Sign in to follow this