There's definitely truth to what L Spiro says, I just don't take as hard-line a stance on it. GLFW is a crossplatform library to make windows and get inputs. Your interests may lie elsewhere in terms of making an engine. I liken it to cooking. If you want to make an Italian dish you might just not have any interest in making homemade noodles so you buy those. Since you like making sauces you grow your own herbs and tomatoes so you have the freshest ingredients that taste how you want them. Not to say you should avoid making noodles! You might really like it and it might be worth it to bring out the flavor of your homemade sauce. I guess this is to say that not making your own noodles doesn't mean you're not cooking. But it might be better if you did.

That's what I mean :D But, without the noodle analogy haha

Hi, @codelyoko373!

I'm working on a game engine, too, so I will tell my two cents.

My game engine is written in C. Since you mentioned GLFW, I'm using GLFW, too, and OpenAL. For image loading, I'm using libPNG and libvorbis for audio loading (but I might replace them).

It takes time. A lot of time to "finish" a game engine. This amount of time will be determined by what you want to accomplish (is it a generic engine? For 2D and 3D?). The tools you use aren't even the big factor that will determine how long it will take. Most of your time will be spent designing things. How each piece of your engine will be integrated together (update system, rendering system, physics system, assets management, objects life cycle, main loop).

You mentioned you could use SFML. If I was using C++, I would use it. So, I suggest you to use it for two reasons. 1) because it already provides some basic stuff (like window creation, audio and image loading and drawing on screen) and GLFW will only provide window creation. ONLY WINDOW CREATION. I say that because you should be warned that making shaders and functions to draw stuff could be one step to jump if you use a tool that already provides that. 2) because you clearly are a beginner in the subject when you said "uses something called OpenAL for Audio."

I make game engine because I *like* to make game engine. The task isn't always enjoyed by many game developers, so you will hear a lot of "whyyyy?" IF you like to do it, do it.

Good luck! :)

Look at what everyone has wrote, SFML seems like the best choice and is apparently similar to LWJGL though I'm just not sure what I should use XD.

SFML seems to have far more tutorials for it though I'd love to follow along with ThinMatrix's tutorials which uses LWJGL which seems to use GLFW

I would recommend going through the tutorials at LearnOpenGL.com as that's going to get you started in the right direction for an OGL engine. There's a ton of stuff to learn for a 3D game engine and expect it to take years to get the basics down.

While I agree with L. Spiro's general premise - that the point of making an engine is to learn and you defeat that purpose if you take too many short-cuts, and I greatly respect her experience as a veteran game maker, felipefsdev is basically correct; GLFW saves you from learning the deep internals of Linux, MacOS, WIndows, etc. And learning operating system program for every operating system out there is not learning game programming.

I've done it both ways. When I learned DirectX 11 I tried not to use any libraries other than C++ (and thus STL) and DirectX. I wrote the code to handle the Windows OS. But the code was not at all cross platform compatible; I mostly only knew what I was doing because I had many years before spent a year or so learning deep Windows programming. The code is very locked into a specific version of Windows, Windows 7. It's not compatible with Win8, Win10, or Windows 3.1. (It would probably run fine on Vista and maybe XP. It might even run as legacy code in Win8/10.) Although, it probably would not be a huge rewrite to rewrite it for Win10 and such, but then it would be locked into that and not Win7 unless you included the code for both. This path of doing OS level stuff is not an easy one and has basically nothing to do with game programming; plan on forgetting entirely about game programming and focusing on OS programming for at least a year or two and that's if you plan on only supporting Windows in your engine. I have no idea what you would have to go through to add Linux or MacOS support to your engine. I didn't even try to support anything outside of Win32 such as Win8 or Win10. So, I consider something like GLFW that handles many versions of Windows, Linux, and MacOS to be a real boon and welcome companion so that I can get back to game programming. The Visual Studio Project file for the DX engine is available for download on my website.

I also did not use a library for 3D models, but rather wrote my own Blender exporter in Python and the supporting C++ code to load the data and turn it into a 3D model. That source code and all the associated files are in the download. (Or you can look at this thread where I incessantly ranted on and on about my Python Blender exporter and posted the code.)

When I went to OpenGL 4.5, I decided to take another tack. One of the advantages of OGL is that it is cross platform. I have various reasons for wanting to do OGL, but a big selling point is the cross platform compatibility. To get that, you either have to learn some pretty serious OS programming in every OS and spend a few years on each OS before you even begin to learn about anything else, or use a library that handles that for you. Right from the start, OGL lends itself to using libraries. I decided to just go with that philosophy and embrace it and thus have been a lot more likely to use libraries as I begin to put my OGL engine together.

Of course, we are talking about a very simple 3D engine. A video of where I am at on the OGL engine is available for download on my website. I haven't gotten the Blender model support into the OGL version yet and really both are still very much a work in progress although I don't expect to get back to the DX engine in the foreseeable future and even the OGL engine is on hold right now while I study 3D modeling and maybe Vulkan sometime in the future. I've debated on whether to bring in the model support code from the DX engine or use a library like Assimp. Doing it myself was an excellent learning experience and still has much left to teach me. But I may try out Assimp and see what that's like.

For my OGL 4.5 engine, I used GLFW, GLEW, GLM, and FreeImage libraries. That's pretty much a minimum for doing 3D OGL. GLFW keeps you from having to learn a mountain of OS stuff that has basically nothing to do with game programming. GLEW handles all the OGL extensions which I hear is a real pain to handle and again has little to do with game programming. I have some complaints about GLM and I am a little tempted to write my own math library, but it's pretty standard and if I'm doing tutorials it's probably best to stick to something people can download that is tried and tested rather than bogging them down with a math library of my own creation. Plus, I make due with GLM. It works. It gets the job done with few issues even if I do have to force it to my will by using it in non-standard ways. FreeImage is pretty much a requirement. I tried another photograph library that is popular but could not get it to work with C++ as it seemed to be more oriented for C programs. FreeImage plays nice with my C++ OOP code. And OGL doesn't seem to natively support any type of image files. DirectX at least natively supported .DDS files. I really don't want to have to study the JPEG standard and learn to write code to compress and uncompress JPEG files just to support one image format. That's 6 months I could be spending learning game programming instead of learning one image format. Ok, maybe it would not take quite that long, but it would certainly take some time to decode JPEG. I'm not even sure if the info is out there. Seems some of those formats like MPeg are closely guarded secrets.

For example, the .FBX model format is owned by Autodesk and they aren't sharing it with anyone. They have a library you can download that will load and save .FBX files. And some seem to have somewhat successfully guessed the format. But the format is a closely guarded secret and any changes they make will require re-guessing how they did it if you try to work with the file format directly. I considered learning their library just to support .FBX files and decided if I was going to have to spend that much time learning something, I might as well learn Python and how to write an exporter in Blender to create my own model file format. So, that's what I did. (The exporter is in the DX project file download as well.) If I had to do it again, I might learn the .OBJ format although I don't know if it supports skinned animation (neither does mine for that matter, but when you write your own, you can always add to it).

Anyway, all the source code for my OGL 4.5 and DX11 engines are available for download on my website at VirtuallyProgramming.com and you are welcome to download them, study them, or otherwise use them as you see fit. It's certainly nothing to compare to Unity or Unreal. In fact it's pretty bare bones. But it's enough code to put textured models on the screen, animate them, and move the camera through the scene while taking keyboard and game controller input. It doesn't support sound yet. There's still much work to be done, but it's a start. You can't make 3D games until you can do at least that much.

Also, going down this OGL road, you are going to have to learn GLSL probably sooner rather than later. There's a Blinn-Phong shader included in my engine that will get you through the first couple of years that you can just copy and paste. I have a whole video series on HLSL (the DX version of GLSL). My GLSL shader is basically the same shader for OGL. It's probably worth your time to watch the HLSL series to learn GLSL; much of it is math that will be the same whether it is HLSL or GLSL. And with a copy of the shader code in GLSL, you should be able to mostly follow along.

If you don't know linear algebra pretty well, you maybe should check out my Vector and Matrices videos before attempting the HLSL videos. There is a lot of vector and matrix math in shaders and game programming in general.

And I would recommend learning OGL 4.5 before Vulkan. I might point out that I don't know Vulkan; it's on my somewhat near term agenda to learn it. I've only read one book on the subject and I'm looking forward to it, but it's more complex than OGL and there are fewer resources for learning it. OGL 4.5 is a long ways from being abandoned or obsolete. And it seems to me that learning modern OGL first gives you the advantage of learning is a somewhat easier platform as well as being able to code in both once you learn Vulkan. I'm not discouraging you from learning Vulkan but learning OGL as your first step into the world of bare metal graphics programming is going to be an uphill slog. Learning to "hike" with OGL before you try and climb the Matterhorn, might help keep you from giving up. OGL by itself as well as 3D graphics programming by itself is a long arduous journey. There's plenty to learn without making it extra difficult. And you can always come back and pick up more; Vulkan will still be there waiting and so will OS programming if you want to learn to write low level Linux code or learn to support every version of Windows ever made. And the mysteries of the JPEG file format are not going anywhere either.

DX11 is very comparable to OGL 4.5. DX12 is supposed to be very comparable to Vulkan although I've only read books about either and compiled a tutorial program or two. I find OGL to be easier because of all the libraries, but the cross platform compatibility really makes the libraries a huge boon. And really, the only library that I would say at all "cheats you out of a game programming education" is Assimp. Even that might be a good idea when you are first learning. DX has a math library pretty much built into it. So, it's not a huge cheat to use a math library. And GLFW (or GLUT) and GLEW are considered "par for the course" with OGL. I think you would be hard pressed to find anyone who doesn't use them.

Good luck with the engine project! There's a lot to learn. For this path, you have to appreciate the path itself. It will take you so long to travel down it, the only way to make it is to enjoy every step of the journey rather than making it a race to the finish. It is the slow and difficult path less traveled.

What I recommend is first to learn how C++ differs from Java and C# on the build side. Teach yourself to set up a comfortable and productive build pipeline. A simple Visual Studio project file might be fine in some cases, but remember that it might be a pain to add libraries that might not intergrate well with your solution, especially if they only supply a makefile. For this, have a look at premake5 or CMake.

Now, you can look into which libraries you want to use to ease the low level parts. As a first time approach, I recommend to start out with a good set of libraries to make you able to focus on architecture rather than implementation. Game Engine development is all about good architecture and this is where I see many fail. They just start programming from day one, but after a while, without some good outline of the engine structure and design, your code start to become bug prone, coupled, locked to specific API's and having lack of seperation that in most cases makes people start completely from scratch (anyone in here who has NEVER tried this?).

Good recommendations to look at is:

- Bgfx: An API-abstracted library that wraps Direct3D 9, 11, 12, Vulkan, Metal and OpenGL. It goes very low level, but still supplies you with the ability to write API abstracted rendering code. It even provides some very useful examples.

- Dear ImGui: An immediate mode GUI library that enables you to rapidly implement debugging and testing UI in your game/engine without all the hassle of creating, destroying and keeping track of state.

- OpenAL (-soft for Windows): A library for implementing both output and input sound

I left without a library that serves creating windows and managing input, as these systems are less complex and could give you a good opportunity to learn the different OS API's to know, without spending too much time on the platform-agnostic code.

This will give you a head start, but remember: Writing an engine is a VERY complex beast to start with. In most of my programming career, I always spend most my time on engine programming rather than game programming because I found it the most interesting. But I also learned that it is a very difficult area, it requires a lot of thought and there is just so many systems to maintain to get a proper game running. You really need to dedicate some time into this.

Good luck!

The only other option is writing each backend for each platform (write with Xlib for Linux, wgl for Windows, Cocoa for Mac) and writting loading libraries for OpenGL (if OP uses OpenGL), which I feel like something really out of scope and a big amount of work

It is right that these would need some sort of knowledge about what to do but as I think it is worth it. I personally wanted to learn anything to the ground of the OS level so know after I got some window handling class and the GL/VK wrappers I would do it again. For GL/VK a simple XML parser/creator helpes me to load current specs from GitHub and create functions/structs/interface methods from it commented by the Khronos manual pages comments

They provide an SDK to allow you to easily access all content in an FBX file. It is a format mature enough that Unreal Engine uses it along with naming conventions for all or nearly all mesh importing they do.
I would recommend making your converter work with FBX files rather than specifically for one tool or another. My engine converts FBX files to its own format, so artists can use Blender, 3DS Max, or Maya, whereas your current converter requires specifically Blender.


L. Spiro

That makes sense. FBX seems to be the most popular format out there. I used it a lot in XNA and then in when I did a short stint in Unity.

In my particular case, I don't ever plan on supporting Maya or Max. Blender is all I plan on using for modelling in the foreseeable future. So, tying myself closely to Blender feels right for me in my particular case. The intent of my engine is for it to be a private engine for my own personal use and to post the source code for it for anyone who wants to look it over as an example or get some ideas from it. But if one wanted to support many modelling programs and/or made use of different modelling programs, using the FBX SDK makes a lot of sense. If one were making a commercial engine, it would almost be a necessity. People expect you to support FBX. I would expect it in a commercial engine and would probably not use the engine if it didn't support FBX.

When I was deciding what to do with my engine, I considered Assimp, the FBX SDK, and writing a Blender exporter. I first decided to use the FBX SDK and spent some pretty serious time looking the FBX SDK over. It was my first time having to write a model importer like that. I realized it was going to take a month or so for me to figure out the FBX SDK. For one thing, the FBX format is a "kitchen sink" format. As I imagine you know, it is not a format for game models at all; it is a format much like the Blend file in Blender that encompasses everything. It's for making movies, it's for saving your entire project, it's for saving your lighting, your animation, your cameras, the animation of your cameras, your shaders and so forth and 90% of what can be saved in an FBX file is just garbage from a game programmer's perspective. Most of the time, I just want the model data, not a light that my game engine doesn't know how to use, or a shader built into the modelling program that won't be there in my engine.

Anyway, I realized it was going to take me a month or more to figure out the FBX SDK and how to use it and that instead I could spend that month digging into Blender's data and figuring out how to extract the raw data directly from Blender. So, I abandoned the idea of the FBX SDK. And in my case, I am glad I did. It was a great learning experience working with the raw Blender data to see how Blender is organizing things internally as well as to see exactly what it takes to extract raw Blender data into my engine and turn it into a 3D model. It has given me a tremendous amount of confidence in approaching any other format in the future or using any other library or SDK. Which is why I'm thinking about trying Assimp next. And at some point, I might want to try the FBX SDK again.

The FBX format is certainly extremely popular and supporting it really does give you a lot of options.

I cannot assist with specific libraries, since my own experience is with a codebase so old that the original programmer (not me) wrote all of his own libraries, including basic things such as collection classes.

However, I notice that you have not written anything about what kind of game that this engine is for. What kind of game that you want the engine to be able to run will have a big impact on what sort of engine that you need to write for it, and, in turn, what language you want to use and what libraries that you should consider using. You will also need to decide whether you want to write an open source game engine (if this is just a learning project and something for your CV/resume, then this might be a good idea) or a commercial game engine before you decide what language/libraries that you will be using, since you will have a wider choice of libraries if you plan to develop an open source game engine.

A game engine for text adventures will be very different to a game engine for a 3D action game, which in turn will be very different to a game engine for a resource management simulation.

For games that do not use real-time 3d graphics and are not action games (i.e. games that involve controlling an object drawn on screen in real time), you probably will not need any game specific libraries at all.

Also, do you want just to write the engine, or do you also want to write the game that goes with it? (It may be rather hard to test a game engine without a game, after all). Unless you have a very specific idea in mind already of what sort of engine that you want to write, if this really is just for your own education (and CV/resume) you might want to consider simply writing a relatively simple (but perhaps innovative) stand-alone game with its own engine using only basic libraries (collection classes, GUI components, etc.). A card game is a good, if unoriginal, example of the sort of game that one might develop in this way.

On the other hand, if you are actually out to create a real-time 3D game engine from scratch that could actually be used for more than one non-trivial game, that is a very serious undertaking, and not something that I should recommend as your first project in a language that you do not yet know well.