What is the KAG engine?

Replacing rendering engine would be like starting all over again and it would cause even more problems and bugs to fix though.

 

What the guy above said - it'd be possible but would involve changing a lot of code. It's not planned at all.
The sound lib is an extension of irrlicht but also probably wont be replaced this late in the day, unfortunately.

 

If people are still wondering and end up reading this thread here is an example of a rough implementation of a similar engine to KAG's current one.
https://forum.kag2d.com/threads/pre-libelle-source-code-example-of-kag-like-engine.18183/ It uses SFML for rendering/input/sound instead of SDL/irrlicht however it also uses angelscript/enet/box2d for scripting/networking/physics. Keep in mind understanding the source code will take prior knowledge of c++ and the ability to read 10k lines of sloppy rushed code.

 

... Irrlicht is the rendering engine, we're not going to replace it with a new one. The game engine itself was rewritten to avoid the limitations of the old one. We do not regret throwing the classic engine out at all.

 

you put a space before the / that's why "[11:05:54] <kostasfighter13> /join #kag.modding"

 

Locking this, some mod can split off a new thread with the posts above and this one if they wish.

A few last words - be careful of going too much down the rabbit hole of X > Y comparisons. When it comes to programming languages, there are a lot of orthogonal axes to consider, and the correct decision(s) will always depend on the programmer, the task, and the time (-> money) allowed.

A well written java* program will trounce a badly written C++ program any day. C++ and C can outperform each other based on how they interact with the hardware at hand**. A small python or javascript program will likely be faster to write but much slower to run than with any native language ***. Most of the platform-associated languages (C#, swing, objC...) can be nice enough to work with on the associated platforms (due to tooling and library support) but are a nightmare to use anywhere else, if it's even possible ****.

Spoiler

*JVMs are some of the most aggressively optimised software in the world - putting java in the interesting position of being the fastest non-native language around. Discarding java as "slow" is a symptom of having worked with heavy-OOP indirection-at-every-corner interfaces-are-always-the-right-choice troglodyte code, or simply being inexperienced.
**For example, a template based sort will outperform a function pointer based sort on desktop any day due to no function call overhead and reduced icache thrashing.
***Even if just-in-time compiled, both languages use hash maps and string operations all over the place - in js even their arrays are built this way. The call stack and program structure generally involves a lot of indirection due to variables being dynamically typed. Duck typing can cause issues in bigger projects as well, or when maintaining code over a long time.
Both languages do get more functionality out of less syntax though, so can be authored faster by a competent programmer, and this can also serve to hide complexity from newer programmers (both a good and bad thing)
****this is often true for libraries built originally for one platform as well.

One thing that C and C++ will have for the forseeable future over all other languages though is tooling and library support. OS libraries work at that level. Most libraries available for multiple languages are wrappers for the C or C++ version. C and C++ can be linked together, with a bit of work. Debuggers and IDEs are most mature for C and C++ on every platform I've worked on (maybe not android). Both of them let you drop down to assembly language should the need arise, and provide intrinsic functions that allow you to access special hardware functions in a portable manner. C++ is the standard for serious game development, and that'll change only when there's a truly viable alternative.

At the end of the day, assembly language is a fine choice for performance sensitive work on any platform with totally known hardware, natively compiled languages are a great all-around way to write code. Scripting languages are often much more succinct than either, and can be easier to understand for people new to the field, but the performance implications must be considered.

My personal opinion is that new programmers who are dedicated to improving will benefit a lot from going as low as possible as early as possible. Performance matters for games, and performance only comes from understanding the hardware. You have to learn it some time, and you spend a lot of time un-learning bad habits that don't translate if you take a different route.
I'm talking assembler for an embedded system or old console, or C and the native OS libs (no portability layer) at the very least.

The other working alternative is to pick up some fully integrated framework and start making games. Love2D or GameMaker are the only ones I'd say are workable long term and viable for new folk to pick up and play with. This route is far more fraught with constantly re-learning things though, which can be just as discouraging as not understanding in the first place. For people having trouble getting out of the gate, this can definitely be the better option.

In both cases, initial projects should be more interesting than hello world but less intensive than your average pipe-dream. A 5 level platformer, a 1 screen survival sandbox, a bridge building sim. Avoid 3d until you've got a serious handle on the programming and the maths required, or at least use an engine that handles it for you. Good luck.