Sign in to follow this  
codelyoko373

Wanting to create my own Game Engine

Recommended Posts

I've started to learn how to create my own game engine and truthfully, so far I haven't got far. I was watching some videos on creating a game engine in Java using LWJGL but I decided to switch to C++ instead and I'm a little stuck.

Of course using C++ means I can't use LWJGL so I'm a little confused on what exactly I should use, I've heard about GLFW and SFML and seen some tutorials on both of them but I'm not sure which one I should be learning? I was originally going with GLFW as I noticed it uses the same functions as LWJGL but I've heard a lot of good things about SFML and how it also includes features for Sound, Networking, Fonts and some more.

I am actually wanting to create a game with my game engine while I work on it so I was wondering if someone could recommend what I should use? 

SFML seems to have far more tutorials online and people seem to be using it more then GLFW

Share this post


Link to post
Share on other sites

Why did you switch languages?

The best way to learn how to make an engine is to write a bunch of games, reusing as much as you can from the last game in the next. To that end I'd suggest you focus on making the game rather than the engine, because otherwise you'll wander off on ridiculous tangents that you'll never actually really need.

Well I've made games before within the Unity and Unreal Engine, I just wanted to learn how to make a game engine as it's something new.

Edited by codelyoko373

Share this post


Link to post
Share on other sites

Since the goal is education it really doesn't matter what you use.  You've heard good things about three systems. Use whatever one you want more education about.

Share this post


Link to post
Share on other sites

The best is to write an engine the same time writing a game, working only on what the game needs and not work on lot of features which ends to nothing.
But then if it's only a research, it's never bad to experiments everytime new things.

Edited by Alundra

Share this post


Link to post
Share on other sites

The best is to write an engine the same time writing a game, working only on what the game needs and not work on lot of features which ends to nothing.
But then if it's only a research, it's never bad to experiments everytime new things.

Well that's exactly what I want to do, work on a game while working on the engine.


Since the goal is education it really doesn't matter what you use.  You've heard good things about three systems. Use whatever one you want more education about.

I'm quite interested in GLFW so I'll use that though for features such as audio and stuff, what other libraries would I need?

I know LWJGL uses something called OpenAL for Audio

Share this post


Link to post
Share on other sites

 

The best is to write an engine the same time writing a game, working only on what the game needs and not work on lot of features which ends to nothing.
But then if it's only a research, it's never bad to experiments everytime new things.

Well that's exactly what I want to do, work on a game while working on the engine.


Since the goal is education it really doesn't matter what you use.  You've heard good things about three systems. Use whatever one you want more education about.

I'm quite interested in GLFW so I'll use that though for features such as audio and stuff, what other libraries would I need?

I know LWJGL uses something called OpenAL for Audio

 

 

GLFW does not support audio, GLFW is a window and opengl context creation/handling library, you'd either have to use a separate library for audio, or utilize OpenAL (the audio equivalent of opengl)

On another note, as someone who is also working on a game engine, the rabbit hole goes much further than you might anticipate. While I won't discourage you from this path, I would recommend that you keep your eyes on the goal, don't get too distracted by the enticing prospect of having your own fancy game engine, there's no shame in using someone else's engine to create something fun to play.

Share this post


Link to post
Share on other sites

Half of the entire point of writing a game engine is that you actually write it.  Forget about GLFW and friends and use Vulkan and/or Direct3D 11/12.
Use OpenAL for audio.

If all you are planning to do is cobble together a bunch of premade parts, then you haven't actually made anything and you have certainly learned absolutely nothing.  Making an engine means getting into the nitty-gritty.

You might end up using smaller libraries such as FreeImage to load image files because loading images is not part of the learning process, but if you want to learn graphics then you need to use Vulkan/Metal/Direct3D 12.  If you want to learn audio then you need to use OpenAL.  If you want to learn physics then you write a physics engine from scratch.  Want to learn networking?  Write it from scratch.

Asking for a bunch of libraries defeats the whole purpose of writing an engine.  And as mentioned above you need to have made games before in order to have a good idea as to how an engine should be structured and what it should do, but you are also allowed to make mistakes and start on a new engine later down the line once you have more experience, so don't be afraid to jump in.


L. Spiro

Edited by L. Spiro

Share this post


Link to post
Share on other sites

 

Forget about GLFW and friends and use Vulkan and/or Direct3D 11/12.
Use OpenAL for audio.

 

GLFW only provides window creation (Vulkan and OpenGL support) and callbacks for it (for each major platform). 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 for a beginner to start seeing minimal results.

 

With exception of SFML, all other libraries are barebones, so I don't think they defeat the purpose of writing an engine.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 

Share this post


Link to post
Share on other sites

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.

Edited by BBeck

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

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

Share this post


Link to post
Share on other sites

 

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.

Edited by BBeck

Share this post


Link to post
Share on other sites

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 [i]kind[/i] 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.

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

Sign in to follow this