Hi all,

For the last years (with pauses) I've been working on my own C++ 3d engine.

I'm using D3D9 for rendering up till today (DX11 later now, gathering knowledge and experience first).

Everything's done on a hobby basis and last months I've been working myself through basics, like brushing up C++ and 2d games.

For who's interested: http://www.crealysm.com/games/Asteroidz%20v0.3.zip.

With all knowledge gained and articles/ books read, I'm rethinking my high over 3d engine design.

I would really like to hear your thoughts and gather input, before adding more and more functionality.

Below I've tried to explain 'the basic layout'.

Any input is really appreciated, what would you do, what do you think is wrong as initial design etc.

Next steps will be

- implemening correct usage of 'const' (when passing objects by reference)

- adding an entity manager/class structure (with vectors instead of dynamic arrays, which I now do for the 'static scene')

- rethink/ design classes using inheritance, not done up till now

- make some simple demo's along the way, adjust and improvise along the way

(my apologies for using text, the VS class diagram doesn't work somehow, something about keys being added already)

TOP LEVEL: NAMESPACES (including classes, .....)

- d3drenderer (camera, font, light, mesh, mesh instance, scene, shader, skybox)

- dxinput

- dxmath (boundingbox, struct likes vectors, materials, vertices)

- game (player)

- general (FPS/ timer)

- IO (fileformat for scenes, classes for light, mesh, meshinstance etc., api independent)

- math (structs API independent, vector, indices for materials/ submeshes, colors etc.)

- renderer (scenegraph class and structs for effects/shaders, lights, materials, meshes, instances etc.)

- audio (FMod audio wrapper, class)

Here's my honest opinion. Focus on results, nothing else matters (especially correct usage of const). You see, all the end user is going to see is the results. Most likely nobody else but you will ever look at your source code, so don't waste time making it obsessively neat.

I downloaded and tried out your asteroidz game. Pretty decent asteroids game, good enough graphics. Very annoying that I ran out of ammunition so quickly. There was a sound bug when your shot hits two asteroids in rapid succession the sound effect is not played twice as I would have expected.

Overall, not a very impressive showing of DX9, could just as easily have been coded in SDL or WinGDI, but a good solid game and I spent about 5 minutes using it before I got bored (I reached 9th place on scoreboard).

@Steve; here's the demo I mentioned (work in progress though)

http://www.crealysm.com/engine/2013-05-28%20demo%20-%20in%20progress.zip

(movement W/S/A/D and mouselook)

Here's my honest opinion. Focus on results, nothing else matters (especially correct usage of const). You see, all the end user is going to see is the results. Most likely nobody else but you will ever look at your source code, so don't waste time making it obsessively neat.

I think you need to take this in context - results are what the end user will see, for sure. However, if you are making an engine, that means you are planning on re-using it on more than one project. That means that your end users will actually be other developers (or yourself if you keep it as a hobby). In that case, I would highly, highly recommend going through the exercises that you are describing here and consider different aspects and designs that you could implement.

This makes you think more about how you are doing things, gives you more and more experience with the language that the engine is written in, and helps you learn more about the API you are using. These benefits may not be tangible in the end result of a rendered frame, but they will certainly be tangible in your development experience as well as your debugging of issues during development. So I would agree with Steve that output matters, but disagree that it is the only thing you should focus on!

@Jason/Metsfan; thanks, I also think that having the right base/ design will help me in adding future functionalities.

In this context, can you share your ideas on my highover design?

Hey cozzie,

I downloaded and tried your engine demo. The render is showing up quite dark for me....

http://imageshack.us/scaled/thumb/197/enginetoodark.png

Well I hate to take the ratings hit, but I think people who give you the opinion to work on your game as an engine don't ship many products.

Well I hate to take the ratings hit, but I think people who give you the opinion to work on your game as an engine don't ship many products.

I won't rate you down, as I think it is productive to discuss counter opinions - so I would also suggest that others don't rate you down either. To be perfectly honest, I don't work in the games industry, so I haven't shipped any games. I have however build and delivered many diverse applications that use 3D rendering functionality. So you are right, I can't speak to game development, but I most certainly can speak to software development that utilizes reusable rendering routines and algorithms (i.e. an engine).

So are you implying that you don't have an engine? You just work on one project, and when its time for another project you just take the existing project and modify it? What if you find a bug in your rendering routines - do you have to go back and make the same changes to a bunch of different projects?

It seems a bit silly to me to make the leap that anyone that tries to properly design a reusable library somehow isn't successful at delivering the end product. In fact, I would say the opposite - having discipline and considering a design aspect of a library has always driven higher productivity in my experience. You mileage may vary, but when you have to support many simultaneous and different projects with some common functionality, then I think it only makes sense to consider that common functionality as an engine...