Jump to content
  • Advertisement
AndrewParker

SDL Game Engine Development (C++)

Recommended Posts

Posted (edited)
Writing Your First Game Engine Using SDL, OpenGL, and C++
 
Ever worked with SDL or OpenGL to write your own game engine?
Let's talk about it!
I'm sure any tips or mentoring would be very appreciated by any new developers!
Edited by AndrewParker

Share this post


Link to post
Share on other sites
Advertisement
Posted (edited)

Tip #1: Don't use SDL. Use GLFW/GLFM instead of SDL. Or why not something even more powerful like SFML?...

If you still think you have to use SDL, don't be tempted to use anything more than window creation, input management, and GL context initialization. This means NO SDL Image, NO SDL Mixer and especially NO SDL net. While these seem tempting and they do kinda-sorta work, they are too limited and most of all absolutely not multi-threading friendly. SDL is one of those nasty globally thread-unsafe libraries. NO SDL call is thread-safe. This includes window creation and input management, but those are generally OK to use in a single thread (the main one).

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

The world is full of wonderful libraries for graphics, networking, sound (well not that many of those but there are some), asset management, navigation, UI, object management, and everything else. Writing even a fraction of these is a monumental effort bound to take years. If you want to come close to something near a success, use these a lot. Focus on architecture and try to combine these libraries in a single engine. Contribute to them rather than reimplementing them. You will learn more, you will get ahead and won't get stuck in reinventing the wheel for the thousandth time.

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.

Edited by Bleys

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites

Regarding "Don't even create an engine", I think, yes there are numbers of genre-specific engine (eg. RPG Maker), and number of generic game engine (like Unreal Engine or Unity3D). However, genre-specific engine might not be flexible enough to use, and the generic engine is usually incomplete. That latter mean you still have to write engine code in generic game engine before it is usable. The more generic the engine is, the more engine code you have to write (unless you're using someone else's components or something).

So, for a game, you'd ended up writing your own engine, more or less depends on what you need. 

Again, the definition of 'game engine' is quite different in one book from another. My understanding is, game engine is an piece of software that uses the predefined context to provide game play to the player. The engine should only utilize minimal programming (either visual or code) eg. for AI. 

Share this post


Link to post
Share on other sites
1 hour ago, mr_tawan said:

Regarding "Don't even create an engine", I think, yes there are numbers of genre-specific engine (eg. RPG Maker), and number of generic game engine (like Unreal Engine or Unity3D). However, genre-specific engine might not be flexible enough to use, and the generic engine is usually incomplete. That latter mean you still have to write engine code in generic game engine before it is usable. The more generic the engine is, the more engine code you have to write (unless you're using someone else's components or something).

So, for a game, you'd ended up writing your own engine, more or less depends on what you need. 

Again, the definition of 'game engine' is quite different in one book from another. My understanding is, game engine is an piece of software that uses the predefined context to provide game play to the player. The engine should only utilize minimal programming (either visual or code) eg. for AI. 

Thanks for the explanation.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

It isn't that I want to make an engine just to make an engine as much as I want to 1 make an engine to learn how they can work and 2 not be chained to only making a game because someone else "graced" me with their engine when I could learn to make my own. It's more of a learning experience.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!