What's wrong with just calling it "a game"? Does it sound too simple if it doesn't have a tech-sounding name? Are developers afraid that they won't be taken seriously unless they are making "something bigger than that"?  

These things are supposed to be reusable, right? I propose a limitation: you can't call your game code "an engine" until you use it to make more than one game. Until then, it is "just" a game. And there is nothing wrong in just making a game.

Let's say we have multiple game engines, and they are all open-source. If we have a common way to be able to plug features in and out and transfer them between engines, this provides for the most flexible environment. If somebody only needs 2D sprites, input and basic collision detection, like OP, let's collect all necessary code into 3 files:

• Sprites.cpp
• Input.cpp
• Physics.cpp

If somebody wants more, let them dive into and build from a codebase as complex as needed. I look forward to a day when it won't be a matter of choosing U-something versus framework versus bare C++, but only a matter of getting the right .cpp files into a directory (hopefully all licensed MIT or similar) and hitting play, as far as technical features go.

The game is scripts, models, textures and audio. Individual title publishers should retain all the copyright to that. At the end of the day, it's not a matter of what the engine is, but whether the game is out, what it looks and sounds like, how many players it has and what the rating is.

An interesting discussion, giving my two cents to that topic; I think a game engine is more than the game that is set on top of it. The game engine is at least at some point a genarlized framework that offers a feature set you make your game with. This feature set should include

• Basic platform handling and API abstraction (in C like languages)
• Provide some kind of memory management (in C like languages)
• Have a math library
• Have an input library
• Provide some kind of render engine

because such features is what you need in every game regardless if it is 2D/3D or a text adventure (yes folks, text is also rendered!). I don't think a game engine needs a lot of asset pipelines, a complex editor or online.store capabilities as a must have to call them game engine.You could even have your game engine read a lua file and create the level from it without a visual editing feature, have a Blender plugin that converts assets into a format that could be directly loaded into the game etc.

Unity, Unreal and Game Maker are designed as a whole in one solution what is absolutely ok but dosen't make them more a game engine as for example Urho 3D is a game engine. Today we are familiar with tools like a full blown level editor or even Intellisence when we code but I think convinience is ok for some point but convinience also makes us lazy.

In my case, I designed my code to be modular, small and flexible, write my own tools and try to do as much on my own as possible. First this was the reason when I started learning all these stuff but today I came to the conclusion that doing stuff on my own has brought me to where I'm and I would rather use my own Array implementation than using the STL one, even if it takes longer to come to see results, even if my results don't 'look' that fancy as those from a million $ busines company.

But back to topic, I also disagree with the statement of @1024 per se but just for the fact of the feature set that a game engine must have. For me a framework begins at the point of general code reuse, a game engine begins at the point when a framework reached certain feature set that is but not most entirely related to games (as described above) and anything beyond is a game creation suite.

This said, lets be nice to each other ?

Since many of us are working on our own C++ engines, let's come up with a standardized way to move features around. Goals would be:

• Everyone benefits from everyone else's work
• No one has to reinvent the bicycle, unless they want to
• The best implementations of everything are used
• All code is compatible, but can be easily decoupled (example: Water.cpp makes water, and can be used on its own in a simple Hello world game project, as well as inside any of our engines).
• Everything is so modular that there is no more distinction between engines or frameworks, but there are "features" that can be plugged in or out

This way, in a few years, we won't even need the U-engines. We'll have complete control and transparency over all the code. Cat's out of the bag. You can't make money with engine development anymore. So let's not try to. Make money with the games instead.

4 hours ago, VoxycDev said:

let's come up with a standardized way to move features around

That sounds suspiciously similar to this recent discussion. Interesting idea. 

 Welcome @incogni7o. From your list of libraries, I happen to like monogame. The content pipeline actually makes me happy. Most of the grunt work is done for you and the same executable can run on multiple platforms. (i.e. mono onMac but built from windows)  SFML would be my second choice.

"Unity makes it easy, but it isn't"  <-- that's golden.  But it does. See you around.

In my mind, code in an engine can be separated into two categories:

1. Custom code closely related to the game: the editor, level loading, saving, scene graph. People will keep re-writing these parts to make them fit their particular project, maybe forever. And let them do it.

2. General code that could easily be the same in every game: rendering, skeletal animation, lighting, physics, input, audio, model/texture loading.

So what I propose is this: make things modular in such a way that everyone can have their own custom code (1), but have an easily plug-able code base of general code (2) to pick and choose from. What do y'all think?

If all of our engines were put into a single repo, the merging process would look something like this: all code is custom code (1) at first, then we identify pieces that are compatible or interchangeable and slowly migrate them into general code (2). I'm willing to start the sorting process, I just need everyone's Github repos.

@VoxycDev and everyone else reading this; as this is already going a little offtopic, I try to keep this short: A universal engine might be a good point, it won't ever be standardized unless everybody is willing to follow certain standard. Take a look at the C++ "standard", in real there is no standard! Anything that the standard says is how is code compiled and what is inside the STL, it doesn't point to coding style (that is horrible and royally 90's in my opinion) and even dosen't offer platform independent OS features like .NET does for example. Code is written re-written every day (as I mentioned in this topic, humans (including me) tend to think they can make stuff better) so there will always be someone getting to that standard engine and try to customize it to his/her current needs or start writing an own one.

Don't get me wrong, I really like the idea of an open, clean and modular game engine and this is the reason because I started to make my own one (and already partially published some parts of it on GitHub). What I did was thinking in packages, for code, for tools, for everything and getting to a highly modular code base (after 6 iterations), so it might already count as flexible/ reusable as you described above but with the exception that Water.cpp is a Water Package/ Module. The problem is that it isn't reusable as long as the API it is build on top isn't standardized in naming and functionality; you'll otherwise end up using #ifdef's not just for platforms but also for different APIs. I got to at least 6 but 8 basic packages that are necessary to build a game/ an engine from

• Common; C++ platform abstraction and common used classes like Memory, basic Types, Delegate, Stream and some more
• Math; general math abstraction like Random but also 3D math, hashing and crypto math
• Storage; general file I/O and file system operations
• Threading; since 2005 we have access to multiple cores so why not use them, synchronization structs, threads and a task/job system
• Input; for not being pinned to OS messages, this abstracts the HID drivers on PC and Mobile/ standard input features on Console platforms
• Graphics; might be something GL, Vulkan or DirectX but I prefer GL/Vulkan, covers API functions and utilities like Window/ Surface creation/ management
• Text; working with strings and text assets should be optional so this goes here
• Network; not every game is a network game but this covers TCP/UDP capabilities and IOCP for PC and Mobile platforms

The package solution also requires some kind of custom building/ package management tool to setup a project correctly so this has to be standarddized too.

TL;DR it is very difficult to establish such a standard because everyone expects something different from those standards and depending on experience, has a different priority and implementation culture for it.

Feel free to send a PM or Discord message if anyone wants to talk further at this topic

I have old code you can use if it something that simple. It sorta like a demo. Anyways it could be what you need for your game. Don't expect anything glowing. It just organized and built enough to get the job done. I recommend you use an engine or something popular right after you put together you extremely small game.