Feedback on this engine layout ...

Started by
2 comments, last by axis2381 19 years, 6 months ago
Hello all, This is my first post on gamedev.net. So please go easy on me =). I'm working on my first game engine, well 2nd really, first was very small. But I believe I have came up with a descent engine layout. What I have, as of now, is a modular design. Core.dll -------- Contains the heart of the engine, really the engine itself. I'm trying to keep it dependant from DirectX or OpenGL as much as possible that way it can just load the proper rendering dll and wrap its calls from there. renderdx9.dll ------------- Right now this is my first rendering dll. It holds, as it's name suggests, the actual DirectX 9.0 api calls. Basically, the functions contained inside would be wrapped into a format the core.dll can talk to without the core.dll being dependant on directx 9.0 or what ever the rendering dll is dependant of. Frontend.exe ------------ Basically, just a entry point into the engine. It's very small in file size b\c all its doing currently is just calling the init of the core.dll and letting the core.dll handle everything else (life of the engine and app). [Not implemented yet] Client.dll ---------- Game specific, client side coding. Server.dll ---------- Game specific, server side coding. Basically, rule sets such as game rules, and sanity checks against the clients. Why would I adapt this design you might ask ? Well, after working on several mods, and just sitting down and thinking it through. I came to the conclusion that this seems to be a fairly, very solid, module approach. The only draw back is that it's a very advance design scheme. As in, its very simple, or alot simplier to just incorporate all your game coding into 1 exe and make it Direct X 9.0 for example and let it be. The hardest part, and one I haven't got to as of right now, is how to exactly wrap the DirectX calls from the render dll into a format so that the core.dll can send and communicate with it in a way that the core.dll is not tied to including any display system such as directx or opengl. That is going to be the whopper of it all I believe. Anyhow, just wondering if anyone has any impressions about this layout or ideas, or comments. I'm simply in the design phase and basically got the frontend.exe and core.dll going right now. I geuss, I just like getting feedback and seeing road blocks and things I can't see looking from the inside. Need the outside perspective on the situation more or less. Anyways, I appreciate the replies and comments ... Thx alot, and hope to be around for future posts as this project plays out ... =) -Axis
Advertisement
btw,

Forgot to mention that for the first go at the engine I was shooting for a win32 platform and direct X 9.0. The reason I was wanting to do each render in a different dll from the core is so I could keep the door open for openGL, or what have you if in the future I choose to go that route.

Just keeping the doors open for future development. Also, in case Direct X 10 comes out, all I would have to do is write a new render dll for direct X 10 and have both versions supported, if this layout proves to work at all that is and is possible.

-The Garage Guy
I would recommend in your early prototypes you do seperate out the Client and Server pieces, and maybe (probably) the FrontEnd piece as well ... but don't necessarily try to design your DirectX / OpenGL agnostic communication between Core and Render yet. It might be advantageous to let the Core and Render bindings be deep and only work with the DirectX render path to start with, because creating the agnostic version will be pretty hard AND there are many gotchas which won't turn up until you have actually written a few of the semi-complicated pieces of the 2. So I advocate you write the DirectX specific version of Core and Render to a reasonable level first, and then REFACTOR them (creating the base Render concepts, and the RenderX9 implmentations, and only allowing core to use the Render base items directly [you will likely need many patterns, but the FACTORY pattern is one of them]). That way, you have a basic working engine doing something before you throw a lot of time at this hard problem, and you have all that expertise you gain writing the engine, which will prove VERY valuable for identifying which types of things can be made render agnostic.

Also, don't hesitate to go 80% of the way and be happy with that ... if core just HAS to code 3 switch statements in 3 places which explicitly do DirectX / OpenGL specific things - but gets away with only using the base Render the other 90% of the time - it's a win for you. The key to real world programs is for things to be GOOD ENOGUH (to get the job done) / BETTER (than the easy alternatives) / and MANAGABLE (enough to survive the modifications that will be made over the life of the code). Managable is 2 sided - 1 has to do with the code staying at a decent quality level and working without bugs, the other has to do with the code being clear and easy enough to understand that you don't get 60% into a project only to find you no longer make any real progress, cause you no longer can understand enough of the elements at once to safely make important changes.
Thanks Xai,

The reply you gave was very helpful and helped build my confidence back up. I like the idea you presented about how to go about starting this layout. So far I'm happy with the core.dll, although I actually have no rendering going on so to speak with directX yet, I have a decent ammount of work already tackled as far as window creation, system checks, memory pool and a very basic resource manager started. I am going to adopt your theory on going ahead and tying in the server and client dll, which I do not have started yet, and just try tieing in those parts of the engine gap I'm missing. Then from there I geuss I will try implementing DirectX 9 calls maybe from within the core.dll to make sure what I have is working correctly, and then if I understood you correctly which seems like a great idea, try to migrate what directX coding I can back out to a render dll to keep things seperated as much as possible for module-bility, if thats an actual word =).

Anyways, thanks Xai for your time and thought on this layout, so far I'm very confident in this. I know its going to be tough, it already has proven to be that way. But whats tough at first tends to prove to be a great learning experience in the end.

Anyways, I know I will be posting here more as time goes by ...

-The Garage Guy

This topic is closed to new replies.

Advertisement