Hi! I'm a university student studying game development. I've just recently started to build what I intend to be my first "serious" game engine in C++.

So I've been researching, reading architecture books and doing tutorials. I've got a lot planned but there are still some decisions I'm in two minds about, I was hoping I could run some of them past you guys and get some opinions and advice before I sink hours into a lost cause XD.

The first matter of concern for me is SDL. I was really tempted to use SDL at start, but now I'm having some reservations. Eventually, I'd like to support multiple renderers with my engine. University uses DirectX for my upcoming graphics course, but I'd love the cross compatibility of OpenGL too. SDL's support for both made me include it in the plan, it could handle my input and sound too. It was also compatible with Emscripten, which I'd also like to try at some point.

The problems are that, for what I'll be using of it, it's a rather large library with a lot of functionality that's useless to me. I know it's over head is supposed to be quite low, but I still wonder if a simpler library would be better. The other problem is sound. I was looking into SDL sound before and saw that 3D sound isn't natively supported. There are solutions, but the sound engine is apparently mediocre and people where suggesting to use OpenAL.

Sounds great, but I have NO experience with this library. Has anyone ever used or known it to be used successfully with Emscripten? And if I do go for it, SDL seems even more huge and OTT for my needs. Should I just settle with GLFW/GLUT for now and implement a separate window class for DX when i come to it?

The other choice is to include both SDL and OpenAL. Again, I'm worried this is wasteful, but it would be a convenient way to make cross platform render targets... And I'd still make use of the Input functionality... Decisions decisions....

It's kind of hard making a choice on a library I have to experience using, that’s why I was hoping anyone with some opinions on this would share their wisdoms with me. Even if you've got unrelated advice you think would be useful, I'd like to hear it :). For now, I guess I'll carry on with my log manager, but it would be nice to start putting some triangles on screen.

Thanks for any help. Sorry about the wall of text, brevity has never been my strong point.

Don't worry too much about choices. The only way to know which one is good is by doing a real test run with them. Only by use you can get an informed opinion on something.

Learning programming is making hours coding. Spending hours deciding what to pick is not coding.

You are not making library choices for the rest of your life. If the one you pick now doesn't work for you, pick another one for the next game. If it's really failing, switch to another one halfway in development. Usually, even if you get something like SDL wrong, in the end, the amount of code that you must change isn't that large. If you're worried, add an abstraction layer so SDL-specific code isn't all over the program. This may be a good thing anyway, even if SDL is fabulous.

Edit: Why do you need a log manager?

(btw "manager" is very generic, try to avoid that, and give it a better name, like storage, or configuration, or whatever your "manager" does exactly)

Thanks for the advice. to Isvar Arthur. I've had a look at some of your suggestions. SFML sounded interesting, and I'd not considered it until now. Seems it doesn’t play well with Emscripten though...

To Alberth, I'm well aware of getting bog down in the details and achieving nothing because of it lol. The reason I'm trying to put a bit more effort into my choices is because of all the target platforms I hope to support. So example, SMFL sounded great until I saw a few people having troubles with Emscripten. I'm just trying to avoid wasting time on things that are just not compatible with each other etc. I'm more then up for some testing and try outs, but I'd be silly not to use other people’s experience to help me. The goal is to have something I could potentially use as part of university projects so there is a soft time limit and need for QA.

As for the manager, this is the choice that seems most controversial with people. The managers are singletons that will be managed by my base Engine class (which will be the main entry point/API for people using the engine). I wasn't found of using singletons myself, and have only recently tried this design pattern after both "Game Coding Complete" and Game Engine Architecture" (both wrote by very credible people) recommended the pattern to avoid C++ compilers tendency to "optimise" your initialisation order. It also helps when trying to get access across the engines components without complicated chains of passing references or calls to members of members of members of members.... "Game engine architecture" recommended looking at the source for Ogre3D and I have implemented a very similar system to them for the time being, all be it on a much smaller scale. Hope that clears up why I decided to go that way.

Thanks again for taking the time to hear me out and help.

As for the manager, this is the choice that seems most controversial with people.

I am not sure I would do it again, maybe in the end it's simpler to just pass a few additional pointers into the constructors of the sub-systems.

The big thing that people argue against here is the dependency injection. If a component uses the log manager, you won't find that anywhere in the class, except buried deep in the code. I think it's a fair point. Your code can't be moved to some other project without the logmanager. Whether that is something you should worry about is a different problem :)

As for SDL being good enough, check the requirements, otherwise, it's a fine choice. Lots of people use it, including myself. I would not try to find a single solution for all projects. Pick the best solution for each project instead. Duplicating a little code is not a problem, just a few hours work at most. Not having the best tool is going to be much more costly.

My remark of logmanager was more about

a) why do you need a log, I mean, it's a game, not a web host or a network hub, what are you going to do with a log? let the user read it? (Maybe it's just me, I tend to first ask myself for the simplest possible solution, ie "printf" here.)

b) "manager" bears no meaning what it does. If being singleton is the biggest functionality, LogSingleton would better express the function of the class. Similarly, LogStorage or LogAnalyzer expresses some sort of functionality, that "Manager" does not (it expresses LogGenericSomething, to me, but then again, I never understood managing either :) ).

I decided to take your advice Alberth, and just get to it lol, see how things work out. I've dropped SDL for the time being seen as I think I will be using OpenAL for audio anyway, so I've just included glfw to get going and will replace it with SDL if I need to later. I’ll keep glfw behind a window and input class too as you suggested.

As for the manager naming convention, I do see your point. I meant to say before that because it's a convention used throughout the code it holds a bit more meaning to me, and implies that the objects have similar behaviour and intention (meant as part of the init and shutdown chain). I have seen it used a lot for this design pattern so I stuck with it, but it's worth thinking about.

As to why, why not XD. I wanted a good base for debug output from the start so I didn't have to go in later and fix everything up. ATM, I can set up alerts for when things go wrong, disable them if they are inside a loop so I don't get spammed and output debug messages to file and/or debugger output. It also supports channels, so I can later set options individually to only see debug output from the renderer or lua, etc. It was a bit of faff to set up, and it's still a way of a proper logging system, but I'm sure you can see how much of a help this will be with debugging as the engine grows.

a) why do you need a log, I mean, it's a game, not a web host or a network hub, what are you going to do with a log? let the user read it? (Maybe it's just me, I tend to first ask myself for the simplest possible solution, ie "printf" here.)

I use proper logging for every project I work on. This helps in so many ways:

• ability to filter out text by importance or by module lets you diagnose problems easier
• errors logged to file can be easily sent from one developer to another to find issues
• if something weird happens during execution, the log can be read to try and work out if something went wrong a long time earlier
• less technical developers (eg. artists or junior coders) can get instant feedback if they've done something that the engine doesn't like
• test suites can check for the presence of an error log file and detect when the game has broken in some way that didn't stop the build

it's a rather large library with a lot of functionality that's useless to me

No, SDL is quite a small library really. If you're writing a whole engine then the size of SDL will be dwarfed by whatever you add to it.

I can't comment on OpenAL; never used it. It's had a troubled history by being abandoned and picked up again, and it's not a standard in the same way that OpenGL is. Most professional developers are using Wwise or Fmod.

Emscripten is also a bit out of my area of expertise, since (again) it's not something pro studios are making much use of directly. The issue you'll encounter is not so much whether the code itself can be compiled to Javascript, but issues of accessing OS functionality (which you can't do from inside browsers or restricted environments) which is presumably why they have gone to some effort to support SDL and OpenGL.

EDIT: looking into things in more detail, Emscripten is quite limiting in terms of what sort of multimedia libraries you can use. It has explicit support for SDL because they have a version of SDL built for the Emscripten environment. Other libraries would have to be compiled from source; and for them to work, they need to use Emscripten-specific APIs, which probably means you need to fork the library and make those changes yourself. Luckily, OpenAL appears to be supported already. With other libs you may not be so lucky - but check this list first, and the documentation on Emscripten Ports

Kylotan, thanks for all the info! That list has been favourite lol (I'm pretty sure I'll be using zlib and FreeImage at least), that will save some time. As for Emscripten being used in proffessional enviroments, you may be surprised, I know I was. Unity used it while making their web player, and Unreal4 have been doing the same from what I hear. I was so impressed when I first saw unity games a few years ago playing in a browser, I kind of have to try it myself XD. Saying this, the desktop engine will be my main goal, but the more functionality I can get into the web player the happier I'll be.

Glad to hear I was overly worried about the size of SDL, I guess it just felt so perfect when i was using it so much functionality AND it was easy going with Emscriptem... Then when all I wanted from SDL could be done by GLFW I just started to think. I'm still using GLFW for the time being but it's behind some interface classes so i can swap out if needed easily. I'm already finding things I would of still used it for (multi platform Alert/Dialouge Popups)...

Thanks again for your advice.

I have experience with the engine or at least the 1.5 version. I liked it but I also like handling most things myself. SDL's weakness is rendering, I would try openlg. Here's what you should do, use multiple libraries. I think you should use SDL but choose another library for rendering. This is your challenge.