Some questions regarding entities

Welcome to games programming, where everything is either incredibly verbose or ad-hoc, with some cryptic spice thrown on top. Enjoy your stay.

Before I continue - the entity config system is really one of the more cryptic parts of the engine. It's been around since before KAG existed, which should give you some idea of why it's so crusty.

u8 - 8 bit unsigned int
f32 - 32 bit float
and so on.
$ and @ are used because MM hates typing, presumably.
Reminds a little of perl/php-like sigils, which is an extra layer of confusion if you have that kind of background.

The type prefixes are required in blob configs because they aren't sent to clients as whole config files (kilobytes in size), they are serialised to a bitstream for a compact representation over the net. This has been in place long, long, long before modding was an intended use for these.

This is why the order matters 100%. You cannot modify the order of any of the variables in a blob config, other than completely removing certain components (replacing their factory with the empty string)

Anything that fits into the given format. I need more info on what property you're interested in if I'm going to help more here. The order fits, the name doesn't matter (other than the type)

Doesn't really matter as long as the types are right (same as literally everything else). Making it consistent with the value you assigned the animation is convention though. The animation section (as you've probably noticed) starts and ends with "magic" values.

there is a brain_scripts (though again, the name doesn't technically matter) - the object in question must have a brain component though. Have a look at the animal configs (sharks and fish are better examples than the wisent, which is a hacky mess).

Scripts are attached to the component in question, or the blob itself, and then specific hooks are looked up by name and signature and called at appropriate times (onTick of the correct type every update, onInit on initialisation of the object, onHit when hit by something, etc). It's a little more complicated than that for performance reasons but that's the interface.

I'll deal with multiples of the same script below.

Scripts are called differently depending on what they're attached to - a script with void onInit(CBlob@ this) can be attached to whatever you like, but that hook will only be called when the script is attached to blobs, on intialisation. Similarly for (eg) void onInit(CMovement@ this) in a movement scripts list.

The script organisation is ad hoc at best. Most of the splitting is likely due to the file hitting some critical mass where it became annoying to work with.

Nothing is forced other than that you use at least one of those hooks appropriately, or your code will never be run.


NOTE: config files themselves (eg the rules configs, and kaggen map generator files) are indexed by name and do have default values and aren't order-dependent. Only the blob configs are serialised to a bitstream based on naming patterns and are subject to all of these "scary" rules.

https://doc.kag2d.com <- hit this up, its ever-slowly-expanding.

Honestly inheritance would make this even more cancerous, partly due to the way reloading code in angelscript works, and partly due to OOP being shit for games. To make reloading work for shared class inheritance we'd have to nuke the entire script engine and recompile everything every time any file changed, making iteration no fun at all. An inheritance based approach would not make sense in 99% of the code either, as most of the functionality is disparate. If you really want you can think of each script as an extension on top of the existing component interface, but with the ability to mix and match different extensions as you build an object out of a handful of scripts.

What's going on in KAG is technically a half-baked component oriented/entity component system approach. We're well aware that it's not perfect by any stretch of the imagination, but we're also not going to rewrite the game or engine because of 20:20 hindsight, as the game is "done". The engine provides a fully networked, scriptable game system with everything you need to build any top down or sidescrolling 2d game, and the backbone required to go further than that.

You might actually have to (gasp) do some work to get anywhere with it, but we're not interested in facilitating lazy modders anyway.

 

I feel like the "technical challenges" in modding KAG compared to modding, say, Quake are far, far more trivial.

Modding in KAG is "hard" because you're writing code, and writing code isn't especially easy. There's not much magic in between you and the game engine, once you understand how to hook everything up - the only way we could give more direct access would essentially be providing an official mechanism for injecting native code into user's computers, something we aren't exactly excited about.

We could make things "easier" by obscuring access to the internals - ie providing something akin to classic modding where you just fiddle with config variables and have a grand old time until you need some new functionality, which you have to provide by hacking the binaries (again, as is the case in classic modding).

Honestly, I don't see the attraction at all. I feel that resistance to the "write code" approach is, at it's core, laziness or unwillingness to learn. This is coming from actively modding cortex command; a game that had a very active modding community despite having an obtuse, often underdocumented, piecemeal modding system for the majority of its life - I and others struggled with it for years before getting interested in standalone game development.

Those that have earnestly applied themselves (@Skinney, @norill, @Aphelion3371, @Strathos, heck, even @AsuMagic ) have generally had a genuinely hard time only when there's something that needs to be added engine-side that we're not providing, and we've been as accommodating as we can, there.

Feel free to suggest concrete ways we could improve the modding experience without hindering freedom to implement whatever you like; our current plans are largely limited to improvements to documentation and the way code can interact with the tilemap.