52 minutes ago, Bleys said:

Tip #2: Don't write your engine. Create it out of existing components.

Yes and absolutely no! It is ok to take existing libraries for some aspects of a game engine but throwing libraries together with 10 classes of glue code isn't an engine! An engine has way more aspects than its functionality and throwing libraries together is throwing functionality together but it dosen't form an engine, even if the glue code is the best glue code of the world!

The most important aspect of an engine is architecture, you want to achieve an homogenues architecture for your system, to convey the impression as the user(or developer) is facing a single unity of systems that work together like a good oiled clockwork. It isn't a shame nor prohibited to write own libraries or better components, that solve the special needs of your engine; providing an extra file format, handling assets in a special way or break your single-threaded loop into a multi-threaded scheduled highway of tasks are for example those purposes.

Third party libs are often implemented for some kind of use in mind and arround some implementation practce that might not fit to what you want. A good point is memory management. Certain libs offer interfaces to attach a custom memory allocator to but most libs don't and/or highly set on the STL. You might not want this sometimes and have to open and change the lib to match your memory model or use your STL style classes.

The biggest pro point of writing components for an engine is to learn how things work (by taking a look into how others did it and maybe investigate some different ways of implementation that look better to you) and to know where to dig when an error occures.

As a side note, use static libs whenever possible. This way, you ship with less dependencies and have a faster code base as dynamic linked libs always have some kind of boilerplate code compiled to access there functions. An exception here are plugins. Unreal for example uses a lot of them for third-party functions.

1 hour ago, Bleys said:

Tip #3: Don't even create an engine. Create games instead.

This is the worst tip I ever read on such topics. The thread is titled with "SDL Game Engine Development (C++)" not "may I or may I not write an engine instead of a game"! If the poster wants to get tips about how to create an engine, it is legit to give tips how to write an engine!

But to be fair, it is a good point to develop an engine along with developing a game, depending on the kind of game you want to want to develop with your engine. An engine should fit certain type of games while an allround-engine isn't a good idea. The reasons are in respect of Unreal and Unity 3D, that those systems are sometimes too general for certain purposes and sometimes lack of functionality for certain kind of game. Thats why those vendors offer an asset store and whats why those stores are full of material (also as same as the libs topic sometimes different versions of assets that solve a single problem).

What I did early after entering the world of game engine development was not creating a game engine rather than writing a framework with those functions a game engine offers that is such dynamic, that one can grab functions together for his/her needs. As I wrote above, an engine is a question of homogenous architecture.

1 hour ago, Bleys said:

Tip #1: Don't use SDL

This is the only point I fully agree with because SDL/SFML seems as if they were once made from a certain approach but offer some implementation that I wont recomend to use in modern game development. One of those is input processing, never ever use OS messages to provide input handling! I prefer the way to go for HID handling whenever possible, especially for Gamepads/Controller input. HID acts on driver level and is that way as fast as Direct Input under Windows for example. Network as another point is something you might put into an own thread pool for handling connections/requests so having a fixed library here that already has a thread pool build in will slow down the engine when you have another library that also provides a thread pool implementation (because both consume your programs available threads).

Now my solution, I years ago started using STL not SDL or SFML as base for my engine framework but ended up implementing anything I need by my own for learning purpose and to keep things in a special style. I have written and tested each feature by its own as much as possible but also together where it seemed useful. I even go without GLFW and instead have a code generator for the GL/Vulkan specs and also my own math implementation.

It isn't as difficult as some people might consider writing from scratch without a library to abstract those platform API calls away, it might sometimes be more work but sometimes also result in better performance.

This is my experience :)

6 hours ago, Bleys said:

Tip #3: Don't even create an engine. Create games instead.

Creating an engine for the sake of creating an engine is bound to fail. Instead create games and learn from your mistakes along the way. This will help you have actual real-life use-cases for the engine. This will be a learning experience in creating software instead of in implementing isolated features. I'm sure you can create decent shadow maps. Can you do it for a whole city? Having concrete milestones is a huge motivator and a great way to measure progress. And what better milestones than games. You're no game designer? Well create a tetris game. Create a 3D tetris game. Clone a simple first-person shooter. Create a simple racing game. Add multiplayer to those. By the time you're finished with this list, you won't be needing tips any more.

Well .... I'm creating my own engine but I think it would be hard to do what I want with a stock engine so it's not "for the sake of creating an engine". It needs to support procedural terrain and procedural placement of assets all done at run time, so my world can be planet sized.  After looking at off the self engines it seemed like I would be bypassing most of their code anyway.  That being said I woudn't mind using off the shelf libraries.  If I can find a reasonable solution for doing just the character animation, I'll use it.  That goes for the physics too but there I have some requirements that might make it sub-optimal, mainly I already have my own mesh format and bounding structures.

I started with the topic in 2009 when beginning my study first in C# learning OpenGL, with my first job entirely switch to C++ and starting again from scratch (using STL), later after another round of iteration, cutting STL entirely and run my own container classes.

You will frequently enter points of refactoring and restructuring your code while you work iterative. I learned from

• Source code for example from Unreal Engine 4 (has been removed from public GitHub sadly)
• Working with Unity 3D (as professional senior game dev)
• Reading Game Engine Architecture Second Edition
• Knowledge exchange with another professional
• A lot of try/error

I tip I also had to learn is to use a build system for your code. It is nothing harder than maintaining a growing project of code files, sub projects and folder trees. You can use make/nmake/ninja or whatever for this purpose or run your own tooling. It is nothing more frustrating than learning the syntax of a build system before being productive on whatever you entirely wanted to develop. Thats why I used to write my own tooling in C# along with the engine framework code in C++.

A first not so fancy step to go might be Memory Management, one of the most anying issues you will have in any game/engine is the memory leak bug. It is far from simply using new/delete and hope anything goes well, a good memory manager system can also do garbage collection and fragment minification

The theory is always up to date even if technologies change