Game engines that could potentially be used to spark a FreeBSD gaming revolution

We don't care to.
neither do serious game devs care about other OS, nor do the majority of gamers

statistics is showing what apps populated across what OS'es, and that is the reality which you deal with.

also the concern was not about whether or not FreeBSD can support functions needed for a game, of course it can, maybe even better than win10 I'm pretty sure...the question is in the level of expertise needed to be able to run FreeBSD, how do you envision a person who does not even know what is command line to go ahead and setup FreeBSD in order to start gaming? just as I said, the crowd of gaming is non technical, non programming type people and the game industry is oriented for that crowd, as simple as that.
 
Gaming is dominated primarily by non-technical crowd who do not even know what is command line...yet running FreeBSD... and game dev. community is not going to switch gears in order to support small niche called FreeBSD (or even Linux; Linux gaming is a failure as well)
My point exactly. When FreeBSD devs and programmers and server users wake up in the morning, they NEVER consider what game they are going to play or wish worked on FreeBSD.

I'm also betting that Linux did not get to where it is today based on the number of game players over there.
 
There is so much more to computing than games. Yes, they are a fun distraction, and yes sometimes they provide fun technical challenges to get working but honestly have zero bearing on what constitutes a useful platform.

Surely this is the general consensus right?
 
Well while Unity and Unreal Engine not supporting FreeBSD, that would be not possible. Lots of people uses them and most of them dont know other game engines. Like how much of us seeing Unity logo when downloaded a game? For me Im feeling like 1/5 of games I downloaded was made with Unity. Unreal Engine not requires coding or kinda things so its why user-friendly... I think it reduces the desire to make game. Just why coding a lot of codes with C/C++ while other kids or people be able to do all of them without any code???

I think there is no point to write one more game engine too. There is already a lot of open-source and free ones exist. No point to write a lot of lines for one game too belive. But this doesnt means Im not respecting to C/C++ game makes from scratch. Im trying to be like them sometimes actually and not very respecting to Unreal Engines no-code required games.

Edit:
I see Unreal Engine supports FreeBSD anyway. Thanks to kpedersen
 
Well while Unity and Unreal Engine not supporting FreeBSD, that would be not possible. Lots of people uses them and most of them dont know other game engines. Like how much of us seeing Unity logo when downloaded a game? For me Im feeling like 1/5 of games I downloaded was made with Unity. Unreal Engine not requires coding or kinda things so its why user-friendly... I think it reduces the desire to make game. Just why coding a lot of codes with C/C++ while other kids or people be able to do all of them without any code???

I think there is no point to write one more game engine too. There is already a lot of open-source and free ones exist. No point to write a lot of lines for one game too belive. But this doesnt means Im not respecting to C/C++ game makes from scratch. Im trying to be like them sometimes actually and not very respecting to Unreal Engines no-code required games.
Unreal Engine 4 (also available and working well on FreeBSD) very much requires coding in C++. What you might be referring to is its "low code" solution called Blueprint. Unity has an equivalent but it is quite far behind (as usual).

With things like Blueprint, you can only "automate" the engine. Arguably you could never hope to achieve things such as reading specific file formats, reading sensor data, etc or anything else that isn't spoon-fed to you by the engine. C++ and (to some extent) CSharp will always provide a programmer with the advantage compared to "automaters". Simply because you can tap into 3rd party libraries.

These days, as an independent / hobby developer, unless you already have your own engine, I would recommend just writing your game (I like SDL and OpenGL) and then extract useful parts into your own game framework after release. I think engines are a little overrated. They are just glorified libraries after all. I always find it a bit laughable when the engine size absolutely dwarfs the actual game code.
 
For those of you who don't know, I've been maintaining a port (NOT in the sense of /usr/ports) of UE4 since early 2018 - see this forum for a few threads about it.
These days, as an independent / hobby developer, unless you already have your own engine, I would recommend just writing your game (I like SDL and OpenGL) and then extract useful parts into your own game framework after release. I think engines are a little overrated. They are just glorified libraries after all. I always find it a bit laughable when the engine size absolutely dwarfs the actual game code.
I'll have to partially agree and disagree on that. Disclaimer, I have read and modified the sources of only the Unreal Engine - other engines may not apply.
I agree on the part that writing your own engine/framework/library is possible and as a teaching aid I'd surely recommend it. If you can write just enough code for your needs you'll be certainly off with a much smaller and possibly faster package. But that also comes with its own risks and pitfalls. If you look up the list of (small or large) game developers that created their own engine and went bust it'll be clear that it's a risky strategy. It's also far from easy to support advanced features beyond "display a cube" code. Getting to the same point that the commercial engines are at takes a lot of work. We're talking about man-years here and that's time that needs to be payed for somehow.
Fun fact: the first open-source engine I wanted to "port" to FreeBSD wasn't UE4 but the Nebula Device by Radon Labs. Never got anywhere with it though. Radon Labs went bankrupt in 2010.

Thus, in come the big wieldy engines. They bring nice editors, a more or less usable graphical programming environment and much more features already built in. Taking UE as an example, you have code and build system to support Linux, Windows, MacOS but also PS4, XBox, Android, IOS etc. DirectX, OpenGL, Vulkan, Metal are already there. No need to code anything further. Spatialized audio? Physics engine integration? Network replication? Destructible environments? It's all there. But that all does come with serious downsides too. Being forced to work in a certain way, massive executables, lots of code and features you'll personally never use. It's all a trade-off.
The best reason to start with an existing engine (on a supported platform... ;) ) however is that it just works and there's actual support. If you have something that isn't behaving right you can look to get some help online. Anything you've written yourself means you have no-one else to fall back on for help. Again, a great learning platform but probably not a very commercially-viable one.

Now, if I were to create a game or large visualization project myself I'd start with an existing engine. If I need something that the engine doesn't provide, I'll add it. If performance isn't good enough or executables are too big, I'll look into it and change the code or build system. I'd probably throw out quite a lot of abstractions too, e.g. having multiple RHI's on a single platform will slow down the code. Things that get compiled in while I'm not using them I'd try to out-#define.


Now, to add to the discussion about having a FreeBSD gaming revolution. It's probably not going to happen :D
We all know that FreeBSD is a great OS and is really feasible as a gaming platform as well. But FreeBSD doesn't have the numbers to make porting commercial games or software to FreeBSD a commercially viable solution. It's not just about engine support, it's also having distribution means. There is no (native) Steam for BSD, which is still the largest gaming platform out there. There's no Epic game store either. No GOG installers for FreeBSD. There's just nothing.

Now, you might be thinking that we could indeed start a bunch of open-source games using one of the supported engines. That's great, but it's also a massive amount of work. It's not impossible, but it takes real dedication to get to somewhere that there's actually something playable and gain the attention of people. And once it has people's attention I guarantee you it'll be ported to Linux and possibly Windows. There's also a good chance someone puts it on Steam or a mobile app store under a different name to make a quick buck.
Also FreeBSD doesn't even have ports of all open-source games, clearly indicating that there isn't that much interest of coders/porters. I myself have had The Dark Mod on my todo list for years and still haven't gotten around to it.
 
The best reason to start with an existing engine (on a supported platform... ;) ) however is that it just works and there's actual support. If you have something that isn't behaving right you can look to get some help online. Anything you've written yourself means you have no-one else to fall back on for help. Again, a great learning platform but probably not a very commercially-viable one.
A good point, I certainly see the use of engines. What I kind of had in mind with independent or hobby games, particularly in the open-source world is around the tech level of TeeWorlds, GemRb or SuperTux. I don't feel these are particularly well served by large engines. I see a lot of Flappy Bird clones written in Unity and it just feels so wasteful.

In terms of maintenance, 10 years down the line, it is quite likely someone will tweak a simple SDL2 game to play Flappy Birds. However they likely won't be convinced to maintain a large engine like Unity or UE4, just to play Flappy Birds so that game will end up bit-rotting away and disappear (in this case, perhaps that is a good thing!)

For larger games or simulations, yes, I would rather a maintenance challenge rather than no finished software at all because they are still too busy writing the .obj loader ;)

Also FreeBSD doesn't even have ports of all open-source games, clearly indicating that there isn't that much interest of coders/porters. I myself have had The Dark Mod on my todo list for years and still haven't gotten around to it.
Heh, I know the feeling. Only recently have I picked up on a couple of ports (taking maintainership of allegro5 and a few Half-Life / GCF tools). I need to start hurrying up; I kept promising myself to put together a port of rtcw but I was beaten to the punch with iortcw. They are too similar to be worth a separate port!
 
devel/raylib is a game library in C. The games from it on Youtube look good. There's nothing dependent on it in FreeBSD ports. This one has its own physics engine.

devel/allegro and devel/allegro5 are game libraries in C.

Everyone's heard of devel/sdl2. It's also a gaming and multimedia library in C. games/openbor (Open Beats of Rage) is a game engine for 2D fighting games that relies on SDL.

devel/sfml is a gaming library written in C++.

These libraries have interfaces to other programming languages. So, many games that use these libraries are written in other languages than the one they're made in. Some of these libraries also have an interface to OpenGL, for games that need these capabilities

devel/ChipmunkPhysics is a physics engine that can be used for games that is written in C.

Allegro, SDL, SFML, Raylib and OpenBOR have games which styles include those of classics from console games. Raylib, Allegro, SDL and SFML rely on xlib, and otherwise not on libxcb. The libraries and engines on this page have liberal licenses.
 
Back
Top