I actually almost finished my game framework and I am thinking about creating an engine based on it. Hence I would like to know all your points of view concerning your best possible 2D engine (I wrote "framework" in the title because I guess that some still prefer to work that way)

So, what is your dream engine? Does it already exist? If not, what do current engines miss?

I'll answer first, most games, that I've made have been developed using frameworks because I feel like current engines offer too much which make it easy to be completely lost.

The engines that I prefer are firstly the famous Gamemaker studio, didn't use because I felt limited by the script engine BUT is perfect for beginners who do not try to do amazingly beautiful stuff, the second is less famous, it is the Superpowers engine (http://superpowers-html5.com/index.fr.html), I love the workflow a lot, so simple and modulable as hell (by creating plugins), unfortunately discontinued but still usable (I know that they are working on Hytale right now), but my personal favorite is the "real-time collaboration" which allow you to modify a single file or a scene with all your collaborators, it can make you so much more productive, really a must-have according to me.

I'm sorry if this topic does not belong here, feel free to move it.

1.automatic serialization (e.g. load/save) 2.automatic network multiplayer synchronization

1 hour ago, Pepsidog said:

High-performance physics, shaders, sprite sheets, skeletal animation, and pathfinding.

Those look like features already existing in current engines even if I can understand their importance

1 hour ago, hyyou said:

1.automatic serialization (e.g. load/save) 2.automatic network multiplayer synchronization

I can only agree, especially for the automatic multiplayer synchronization which I would have loved to have in my early days (networking is such a trouble to get into)

Whenever I hear "automatic" I get attended because it is very complicated to get something really automatically done. Either you have too much configuration, in case of networking for example the protocol to use or you are too limited in whatever you try to achieve and enter the complain about the engine loop again.

In the case of networking, this can't work if you expect it to work generally because there are too many possibilities in how the protocols look like, how the gameplay looks like and how that matches each other. Socket programming using some third party tools like RakNet is easy but you still have to implement client/server logic.

Same for serialization; it depends, most of the time your prefered game states are spread along a number of classes and also contain information you don't want to serialize but this is a more lighweight topic.

Collaboration is a good point because most engines I have used are stuck at single-asset-single-scene management and struggle when it comes to some kind of version control on the one hand, on the other hand I know from our software, it is a very difficult topic that needs a well designed concept to not hinder each other too much to their work. You don't want to have something changed you are currently working on for example or have someone placing assets in a scene where you currently design the gameplay. Most important is to have a bakcup of everything. This is the reason most engines don't think about real-time collaboration because you always have the chance to delete whatever you worked on the last 2 hours without disturbing someone else in an offline collaboration environment.

What I like and propably miss in my all-day engines is modularity in code. Plugins are maybe usefull too but the real power appears if you have the chance to add/remove/exchange features by modules and then rebuild the entire engine to your needs. No .dll/.so handling, no workspace polution and a slightly better runtime performance.

The second one is a compiler indipendent environment. I don't know what languages we are talking about but what I like is working with Visual Sudio 2010 but use the newest toolset if MSVC2017/2019 or even another non-ms compiler like clang. This is very difficult to setup  so a simple solution would be nice to have. Work with whatever IDE you want and compile with whatever are your target specs

13 hours ago, Shaarigan said:

Whenever I hear "automatic" I get attended because it is very complicated to get something really automatically done. Either you have too much configuration, in case of networking for example the protocol to use or you are too limited in whatever you try to achieve and enter the complain about the engine loop again.

In the case of networking, this can't work if you expect it to work generally because there are too many possibilities in how the protocols look like, how the gameplay looks like and how that matches each other. Socket programming using some third party tools like RakNet is easy but you still have to implement client/server logic.

Same for serialization; it depends, most of the time your prefered game states are spread along a number of classes and also contain information you don't want to serialize but this is a more lighweight topic.

Collaboration is a good point because most engines I have used are stuck at single-asset-single-scene management and struggle when it comes to some kind of version control on the one hand, on the other hand I know from our software, it is a very difficult topic that needs a well designed concept to not hinder each other too much to their work. You don't want to have something changed you are currently working on for example or have someone placing assets in a scene where you currently design the gameplay. Most important is to have a bakcup of everything. This is the reason most engines don't think about real-time collaboration because you always have the chance to delete whatever you worked on the last 2 hours without disturbing someone else in an offline collaboration environment.

What I like and propably miss in my all-day engines is modularity in code. Plugins are maybe usefull too but the real power appears if you have the chance to add/remove/exchange features by modules and then rebuild the entire engine to your needs. No .dll/.so handling, no workspace polution and a slightly better runtime performance.

The second one is a compiler indipendent environment. I don't know what languages we are talking about but what I like is working with Visual Sudio 2010 but use the newest toolset if MSVC2017/2019 or even another non-ms compiler like clang. This is very difficult to setup  so a simple solution would be nice to have. Work with whatever IDE you want and compile with whatever are your target specs

You are completely right about networking, automatic isn't the right term to use. I guess that we should say "hide some layers to the user", for example, the client prediction, interpolation, lag compensation, those are pretty easy to understand but hard to implement correctly. So it can be a nice idea to provide the user a "networking configuration file" where he can for instance say which packet should be sent using UDP or TCP and such. (Sometimes it can also be largely simplified, for example, if both users have a good connection, nobody prevents you to use a system similar to parsec)

About serialization, like I said a configuration file isn't prohibited, we can simply add a "configuration" file where the user has to list all the variables name that he wants to keep, sure it is a pretty dirty way but it is the simplest, it does not require the highest performance anyway.

I understand your concern about collaboration, in my case, I prefer productivity over security (in this case at least), a workaround can be to have a button like "save version" where the user will specify a version name and add a description, then the version can be loaded at any moment, what do you think about that ?

Concerning modules, can you give me an example of what you would have liked to add in X engine?

If I'd pick a 2D engine today, this would be my demands:
* Pixel exact determinism for 2D operations. OpenGL is a deal-breaker regarding this when each driver has invented its own coordinate system and even the reference implementation is broken by never being meant as a 2D replacement. Using memset and memcpy can give higher performance than the GPU for filling static background by doing a lot less work.
* Hardware-agnostic full-screen using borderless maximization (and the override-redirect extension in X-Lib), not the crashing native full-screen that comes with SDL. If it didn't work the first ten times, why would a new hardware assumption make a difference? My monitor can handle 540p and 1080p fine, but will get frequency out of range for 720p because it chose not to support that uneven resolution. MS-Windows usually hides this by up-scaling to 1080p on the GPU which breaks the timing of v-sync by starting too late, but then you might as well up-scale yourself and define how your pixels should look.
* Context free object management. Don't entangle with objects that don't represent things in the real world. No factory nor draw context. Better to create and destroy a hidden server module with the whole application and follow basic principles to hide side-effects.
* Zero dynamic dependency on third party libraries. Standard C++, Win32, X-Lib and kernel APIs are okay to take for granted on the given systems. Anything that requires manual installation of drivers must be optional extensions and have a fall-back solution that works as fast as it can.
* Clean API of global functions and minimalistic type exposure in headers. Make opaque handles for any type who's full content is not given by the name. Trap null-pointer exceptions if null is not allowed. “foo(bar(A, B));” is much cleaner to read and maintain than “if (A && B.get()) { A->bar(B.get())->foo(); }”.
* Portability, no excuse for being locked to one system when simple 2D graphics can easily be ported in a week.
* Compiling from source should be easy like in StbImage. Fixing bugs should not require some buggy setup with an outdated build system or compiler that nobody heard of.
* Fail-safe. Don't just crash with access violation/segmentation fault, let the caller know which input was not accepted and keep pre-conditions to a minimum when designing the API. Better to resolve type errors using overloads in compile time than using polymorphism on the handles.

I'm currently making my own renderer because no existing library was anything close to what I wanted, but more engines should do things the right way at the lower level instead of just accepting status quo from not wanting to do the dirty work.

On 7/16/2019 at 8:00 AM, Shaarigan said:

This is very difficult to setup  so a simple solution would be nice to have. Work with whatever IDE you want and compile with whatever are your target specs

For Linux, I made a simple shell script that takes root folder paths, searches recursively for source files, looks for changes using check-sums per library and calls the compiler. This way, I keep my module structure forced to simplicity from the constraints and make sure that whatever IDE is being used can just include all source files recursively from the root folder when the static library is being re-compiled or pasted as code for compatibility with the caller's compiler. I just use a separate root folder for the platform specific code and link it separately with one module per system. I can even copy the build script from one project to another and never make any changes.

When buying a computer, it would be insane to list every transistor, capacitor and diode as a separate purchase only to exclude the anti-theft system that belongs to the store. If your old list is missing one component, the seller will take out the soldering iron and ruin your new computer in front of you. This is how mainstream build systems work by assuming that nobody uses more than one. Sure, you can configure it the clean way but IDEs won't help you with that.

15 hours ago, Dawoodoz said:

I made a simple shell script that takes root folder paths, searches recursively for source files, looks for changes using check-sums per library and calls the compiler

This is what I do with our custom build tool. It is not just capable of building context-less projects, it can also handle IDE specific project file generation. But we quickly reached the point to be in need for something more complex just as only grab a folder and the contents of a folder as a project. Sometimes you are writing complex code that has OS level dependencies, the tool also manages that with loosely placed configuration files, I also added support for asm files that were otherwise excluded from build once we needed some assembly code for the Task System, I added different build systems and a build chain to have parts of different coding language in my project; a C# tool and a C++ Module for example or parsing HTML/CSS files as resources for the UI renderer. The tool provides different build systems that are language and platform dependent, so it is also possible to setup the complete tooling environment with just a single command.

Our tool also works free from a projects context, it isn't bound to certain project/folder and can be called from anywhere on the OS. The only feature I'm currently missing is to have the IDE call the build tool with certain parameter instead of the usual target compiler but it is on my list.

I'm actually working on the one I want to see, but it only addresses the 2d lightweight web-targeted engines.

Why? Because I really want to believe that once permission standards on the browser are established, direct access to hardware would be even more optimized piece of a cake than it is today. (and 2d because I work alone and have to start small)

Some of the other dreams I'm already pretty close to establishing is meta-editing: making the engine via the engine itself. Making it easy to extend and modify. It's already editable in a sense but there's a fundamental problem with contexting in anonymous JS functions that needs addressing.

As of the future - I really hope to make a great multiplayer component so that making .io games for example would be a piece of cake. The idea is pretty basic - no coding involved, simply syncing by flagged attributes rather than the RPC approach. Diffs should be easy enough in JSON form, and having JS is (for once) pretty good for this purpose.

Right now it's still a prototype though: https://github.com/g--o/JSCF