What is the KAG engine?

The part he is asking about - rendering - is indeed provided by Irrlicht.

 

To clear up any confusion, yes irrlicht is used for rendering, no it is not used "raw" - we've made modifications to irrlicht and we basically use it to get access to opengl and operating system events in a portable, comfortable way. If we were to do the same thing again, we'd probably use SDL for handling those tasks, but there's a lot of legacy baggage. We actually use SDL for the threads (as mentioned above) so its a dependency anyway.

The scene graph and logical structure is a complete departure from irrlicht, we dont use any of their scene functionality other than a camera - all of the vertices, textures, culling etc in the engine is handled by us. Irrlicht is much more 3d oriented and it helps to have control over the graphical building blocks. We basically give Irrlicht a bunch of triangles to render (properly batched by texture and culled for screenspace of course) and say "render this please" and it handles the last step of interfacing with opengl.

Sound is IrrKlang, an irrlicht extension. The fact that we don't really have source access means investigating some of the sound bugs is trial and error.

Physics is largely Box2d but again there's a lot of glue making that actually work with anything in the sense of a game. In future I think we're going to move away from Box2d as it's been nothing but hassle. Classic does not use Box2d, which is why the physics are very different. The collapse physics in both versions are our separate implementation of verlet physics for optimisation and consistency's sake - that many boxes added as entities would be awful for the network and for performance on both client and server.

Networking is ENet to give us a layer over UDP. The networking model is roughly based on the quake 3 model with many, many alterations to make it work with a large number of objects. We'd do quite a few things differently here too, given the chance, but neither of us is particularly keen on doing a clean slate reimplementation at this point.

Scripting is Angelscript bound to our internal classes manually (no bindings generator, potentially a bad thing but it works)

fwiw the term game engine is nebulous and I feel a lot of people don't quite appreciate the scope of the engine behind KAG. There's 110k odd lines of code (not including comments and blanks) including the scripts now, which is about 40k less than the average during classic development, but still pretty large. The reduction in code size is largely due to refactoring and optimisation efforts but also a result of moving the game into the script files, which allows simpler reuse of logic. You can view about 30% of the KAG source as those .as scripts.
Here's the counts from cloc http://grab.by/p6P4 - scripts are shown as actionscript when they're actually angelscript, but counts should still be accurate. This is not counting irrlicht, sdl, angelscript or anything like that, this is the KAG engine code.

Understand that that code was largely written by two people (some of it was written by Shadlington and FliesLikeABrick as well, props to them) and that handwaving it as irrlicht or enet or angelscript glued together with a few hours work is pretty ignorant :^)

Hopefully this helps the OP and also serves as a resource to link the people that ask this question every few months to.

 

Yes and no, it'd just be our own physics (something we did for classic and would gladly do again - I've had to do a few clean slate implementations of that kind of stuff for uni and other projects) but should be able to handle any geometry as a combination of concave shapes or lines.
For 2d games, and games in general I feel that actual dynamics aren't any good unless you can afford to go the whole way in that direction - ragdolls, force driven actors, etc. It is much easier to make an enjoyable experience with fake physics and reliable deterministic physics.
That rules out Havok, PhysX, Box2d or anything like that for us.

 

Yeah it's super easy, thats why everyone and their mum whips up a networked, scripted game engine.

...In case the sarcasm wasn't clear, no, it's not particularly easy to make a game engine in general, much less one that's networked nicely or easily modifiable. It takes a strong background in programming at the very least, experience from working on other engines helps too.

 

No, why would we?