I'm curious whether anyone has done this in a game of theirs. Preferably one they've completed. I'm making a game where it's probably going to be easier to make a game engine and then make a game with it. Having invested so much work into the engine, it would be nice for it to be reusable. Right now, TrueVision is very viable, and really suits the game I'm making, but a different game in the same engine might have very different graphic requirements, meaning an alternative rendering engine might be preferable. Or maybe TrueVision will be getting on by the time I get around to making a second game with the engine. So I might want to plug in a new engine. In which case having a completely asbtract renderer will make plugging in a new 3d engine massively more simple.
So has anyone done this already? Any thoughts, tips, experiences?
BTW, I'm not after a how-to. I know how to. I'm just trying to start a general discussion on a subject which is currently interesting me.
I have done something similar in C#.
I found it to be a great asset when it comes to adding support for different platforms/renderers.
I made an abstract rendering API which simple provided a framework to which different graphics engines must adhere in order to work within my system.
After this was completed, i started to implement actual support for the underlying graphics engines. OpenGL, DirectX9 and SDL where to first 3.
It's not an easy task as it requires thourough planning of what your intentions are for the system and considering possible limitations that any of the underlying graphics API's may have. The must be handled appropriatly.
It is more work than just starting on the game, but I find it rewarding as, when it's done it's done and you will never have to worry about the nitty gritty of the Graphics API's again. You can just focus on what you want to do: make games.
The problem is defining a decently transparent API that suits your needs. It is very hard to create a very generic api that will offer both ease of use and performance without making the underlying code to complex to manage.
This is probably the reason why the AAA titles have engines that are specifically designed and optimized for that particular game-genre/type.
You can design a very generic engine, but this will definatly come at the cost of performance, as your code has to handle a lot of different ways to setting up a proper rendering pipeline and processing data structures, depending on the game that is made with it.
All in all I think it is a definate benfit if you plan to make more than 1 game of the same genre. It's a 1-time investment that will definatly pay itself back ten-fold later on.
It does help to design the game you wanted to make next to it, as a seperate project, using the engine as you develop it. This gives you realtime insight into what the type of game requires from an engine and what is the best and most efficient way to lay out the api. It is very easy to create a fast and seemingly nice engine, but which turns out to be a total nightmare to use in a practical environment.
Thanks for all the thoughts, Jim, there's a lot of interesting stuff in there. I think it's definitely going to pay off, and it won't be as much work for me as it might have been, as I'm going to stick the Render-independent graphics engine very close the renderer I'm using in terms of interface. That way, if I don't decide to use another engine with the same game engine, I won't have crippled the engine needlessly, and if I do, it's still a lot less work to adapt a different engine to the old interface than it would be to recode the actual game engine.
It's a pretty specific game engine, so I won't have too many problems with the renderer not suiting another game with the engine. If it suits one, it'll suit any game you could make with the engine really. So far, it's been tricky, but fun and challenging. I've got to the point where I've got the base classes for lights, meshes, materials, cameras and the engine initialization and management itself abstracted, and what little there is of the game so far now knows absolutely nothing about TrueVision, so I'm pretty pleased with how it's gone.
I just figure I'm going to invest so much time into this game that I should make sure it's an investment that lasts.