I have to say that working with an engine has really made making this game so much simpler. I didn't have to worry about setting up D3D or making sure that events got reported, I just overrode the right functions and I got my functionallity. It was much better than coding everything from scratch like I did with Maul Ball (even though I used SDL). I think from now on I'm only going to make games on top of a functional engine (whether it be mine or some other one).
That said my engine was far from perfect. The best example of this was how I had to hack into the engine to be able to draw the FOVs. I had to manually access the D3DXSprite object, turn it off, manually render the FOVs as a triangle fan and turn the D3DXSprite object back on. It would've simply been much more work to add the functionality required to draw primitives into the engine itself.
I've been thinking about the next iteration for the engine and my plans so far and realised that I've been looking at it from the entirely wrong direction. I've been looking at it from the inside out - lets put together a nice graphics kernel with the required functionallity, and then I can build a GUI system on top of that, etc. The thing is that the clients interface is really only left till the later stages of the design process where you have to fit it around your beautifully constructed core processes.
I'm going to go back to the beginning and try to create a decent client interface. Once I have a good idea as to how the client will interact with the engine then I'll fit the engine's inards around that design. I would strongly recommend this article to anyone who is trying to plan an engine. It cleared up a lot of things, espesially the concept of seperating objects logical representations from how they're rendered.
