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?

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.

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.

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.