I hope this is in the right forum.

I'm new to this community, but I've been programming engines for many years as a hobby.

I'm now writing a simple Direct3D 12 game engine, with audio and multithreading support, for Windows (GNU GPL license). I know there are several ready-to-use engines out there, but my goal is not to compete with Unity or any of the others. I mainly want to explore the issues involved with creating these engines, and that's why I'm posting about it here. I also want to help beginners, so this can be used as a learning tool, everyone feel free to copy code (I'll be posting it on Sourceforge, and put sample output on YouTube). Also, if anyone asks me to add a feature to the engine, I will try to implement it. Finally, I want to become familiar with the terminology and industry practices involved, since I am self-taught.

Most of the engine is already planned out, but I want to write some code before divulging the plan to show that I am capable of creating this.

I'm going to finish this post and write some initialization code. If anyone has any comments or ideas, please reply, otherwise I'll be back with a YouTube video.

--237

Ok here we go. The program now does a basic initialization of Direct3D and produces some simple output:

The engine will compile either as a Universal Windows Platform app or as a Desktop app (only a small amount of code needs to change for this, I do this in the code with some #ifdef's. So far the code initialized UWP, the main D3D interfaces, a command list, and a backbuffer. It then enters the rendering loop where a simple animation is created by clearing the backbuffer to various shades of red, then "presenting" (letting the graphics system know the app is done for the frame, processing is finished and the next frame is painted on the screen). This took about 150 lines of code.

If anybody has any questions about how this works, please ask. If anyone wants the source please message me (I'll get it on Sourceforge in a couple days). Otherwise, next post in a couple days. I'm going to move the progress reports to a blog and use this thread just for discussion.

--237

Edit: I should clarify that my intention is to start a discussion about how engines are built, not advertise my engine. So I will ask, what features does everyone feel should be in game engines which do not seem to exist in any of the popular ones?

I asked this question a little ago too but more or less on the core-feature code base as I was (and due to low spare time am still) on the go to reassemble my source base to be more flexible. The initial intention I had with my engine (that has become more of a framework now) was to be totally module based because I thought and still think as for what @kburkhart84 wrote, that the big players have too much stuff in there engines that you might need but mostly not need dependent on each distinct game you make.

Why: Is simple, they want to be general. That means that such engines as Unreal or Unity 3D offer stuff they think is wished from the avarage of there users. Unity did lack of a good UI framework for long times and people used NGUI and whatever was on the market until Unity implemented its own improved UI framework

What: I asked to myself was a simple question. When making a 2D game, why am I still forced to use 3D and 3D math? A good question as it turned out because a single matrix multiplication in 3D tooks (even when optimized) a good ammount more time to compute as a 2D matrix. It may or may not make any difference related to the ammount of computations per frame but in AAA games with sometimes a million of recalculations per frame it does. Just for thought

So at the end I ended up to choose my core features I need to use in every module and decided the same for the features that seem to be not core. As you wrote that your engine is intended to be DX12 I will skip the graphics API diskussion part while I think one should these days not pin to a single or not to such a platform depending API but that is your choice.

What I think should be part of the engine today is (except for the game necessary features Input, Audio, Physics) a good UI framework in the first case before thinking of any voxel terrain or whatever people think they need. Working in the backend I see different UI approaches but the current trend goes to web based UIs. So I decided for me to implement my UI framework based on HTML 5 and CSS 3 for some advantages. First they are standard by the WC3 and everyone has access to that standard so what works in a browser should also work in the engine. It is simple to write UIs as they are HTML code and allow rapid prototyping in a web browser. They are responsive (what was a tricky thing in NGUI and Unity 3D) and support SVG by default.

The second thing I would implement is a good terrain and asset system. I have seen and experienced very often that small and indie games have problems getting artists and level designers. What about a system that proceduraly generates assets and levels by certain rules and at least for small and indie games reduce the dependencie to artists a little? Generated meshes should not look high end but good enougth to use. I have had a talk to someone some time ago that works on a terrain generator AI in a AAA studio that should learn from level designers and users to make new maps based on certain criteria for one of there games. Sounds interesting and could help in development.

I'm curious to read about what other people think

Thank you @kburkhart84 and @Shaarigan for your replies. I am personally already gaining insight into how serious engine development works. I am writing this engine for a personal game project; I will try to give back by including features in this engine others can use.

I will write an engine that will be limited in features, but include what people really need and does it well. It will be a niche engine for those who just need something that is easy to use. One of my main concerns is performance, which is why I chose D3D 12. All the performance-critical code I am writing from scratch. (D3D 12 is much more efficient than D3D 11 when used properly instead of adapting a D3D 11 program to use D3D 12. I might write a D3D 11 or other API fallback but there won't be much code sharing between them.)

I am thinking of mostly experimenting with different ideas, relying heavily on feedback from the community, and later planning the final version. Thank you for your input.

After doing some research, I decided to use the Apache license instead of the GNU one. The code is on Sourceforge:

https://sourceforge.net/p/cookies-video-game-engine/

I'll add comments to the code later.

--237 

For my new "engine" I've decided to create a split between the system and what a traditional engine supplies. By this I mean I have a layer of libs called OSL which contains libs for:

maths(vectors, magic etc)

graphics(render, render states , render.cpp (dx11, dx12, to etc.))

System (memory, time, thread, config string etc.)

So on...

This is essentially a small media layer a bit like SDL but more like sfml or xna, from this I can then create games or most importantly create the OSL_Engine which implements scene manager, entity component systems, AI, physics etc. But doesn't have to know about the low level stuff as that's handled separately.

The engine can then be used to make a DLL for an editor etc.

Be interested in hearing about your approach.

@237cookies I'm currently working on building DirectX12 game engine as well, possibly a bit further along rendering 3D models as well as having 2D UI. I'm looking work co-working buddies or collaborators, and would be happy to chat if you're interested. I generally find that it's more motivating if you have others that you can talk to who are working towards similar goals. I've been looking at a lot of game engines, many have abstracted the hardware layer (DX/GL) from the core of the engine itself. For open source Xenko is the one that I've been looking at. DirectX12 samples has their MiniEngine (https://github.com/Microsoft/DirectX-Graphics-Samples/tree/master/MiniEngine) and Unreal engine 4 is open source (you just have to register on their website).

In relation to this, I recently posted:

Hi, 

Good luck with your engine. I'm curious about what more low-overhead features of DX12 are you using, and if you are using a lot have you found issues running it on different GPUs? 

I.E the closer to the hardware that you get, the less the driver does for you, there may be unexpected behavior across certain hardware.

Sorry everybody for the late reply.

@Jemme This engine is actually going to be relatively simple. For example, the entire engine will use only 32 state blocks (DX12 groups almost all render state into singular blocks), made possible by the fact that everything in the game will be designed to be rendered with the same settings. This also means that the same math will work for everything, and the calculations will generally be coded directly into the low-level rendering routines. This will probably result in a specialty engine, which I'm okay with. (I'm hoping the simplicity an directness will result in increased speed; I don't know if it is possible but I'm going to try to get 60 FPS at 4K with a complex scene and a mid-level graphics card.)

@Lloyd.Crawley I've studied the D3D12 API carefully and am trying to implement it in a highly efficient manner. Microsoft has a D3D11 to D3D12 transition library but I'm not using that at all. I am using most of the low-level features which don't depend on specific cards, I'll put out more info on that later. The engine is in the initial stages so multi-GPU testing has not begun. I am hoping once the engine gets to the level where it does something significant I can find others to help with testing.

I'll be around but should be able to resume serious work about 2 weeks from today.

--237