Adding Mod-Support

[laboooon]

I've been considering adding mod support for DDNet. This would open up a lot of new potential game modes or breathe life into older ones that require a specific client, like https://nodes.teeworlds.dev/, for instance.

My strategy is to implement an interface in C++ and subsequently add Lua bindings for it. Lua is a widely-used scripting language for modding. Numerous games, such as Factorio, employ it to facilitate mod support. There would need to be a Lua-File for the server and the client.

However, to begin with, I'd need to streamline the requirements of the interface. An initial brainstorming session yielded this incomplete API, represented in pseudocode.

Note that x and y refer to absolute coordinates while grid_x and grid_y refer to coordinates of the mapping grid

load_quads(quad_path)

load_entity(entity_path)

entity {
  attributes:
    collision_polygon
    sprite // of type quads maybe?
    x_pos
    y_pos
    x_vel
    y_vel
    hook_type = { hookable, unhookable or hookthrough }
    weight // for when players hook it or explosions happen near it
    properties //json object to enable custom properties
  virtual functions:
    tick(dt)
    on_tee_collision(tee, {x, y})
    on_terrain_collision(block_type, {grid_x, grid_y})
    destroy() // for when the entity should be deleted
}

game_tile {
  attributes:
    properties //json object
  virtual function:
    on_player_enter(player)
    on_entity_enter(entity)
    tick() // allows for entities to spawn to enable custom weapons for example
}

quads { as in editor including animation and color function }

add_entity(entity, pos) returns entity_id

add_quads(quad, pos) returns quad_id // this would enable the mod developer to display custom health bars for example

freeze_player(player, time)

deepfreeze_player(player, time)

unfreeze_player(player)

freeze_player(player)

on_player_spawn(player)

on_player_death(player)

on_player_state_change(player, old_state, new_state) returns new_state // enables the mod developer to check whether a player wants to move.

remove_quads(quad_id)

remove_entity(entity_id)

send_chat(txt)

send_broadcast(txt)

on_tick()

In the first step however I'd tone down the interface and only implement "send_chat" as well as "send_broadcast" to enable mod support for the server. This would work as a proof of concept for dynamically loading Lua-Scripts and using them ingame to influence the game state. For example a proof of concept mod could send a text message of each players position every few seconds.

A big question is malware risk. When done properly the lua interpreter shouldn't be able to access the host system and just use the API. Therefore it is a problem to be solved how to load Sprites for example without imposing a security risk. But as the game allows for custom Tilesets that is a problem that is most likely solved already.

Thoughts?

[Kaffeine]

Hi, I'm a mod maintainer and I see that we cooperate less than we can, and it hurts both players UX and developers eXperience.

I'm not a DDNet developer (in terms that I don't have write access here) and my opinion does not reflect that of the DDNet devs.

I think I understand why we have this situation: the playerbase is too small, and so the dev teams. As I see, only DDNet is actually capable to develop the game, and nowadays it is the only real upstream (as you probably know, teeworlds is stagnating dead).

It is definitely harder to keep a clear architecture with mod-specific code isolated from the game core, and DDNet devs don't have enough practical reasons to work on the components isolation (e.g. it is much faster to implement a feature in-place than to introduce an abstraction, refactor the code and keep the implementation independent). Here I have to appreciate the fact that DDNet devs ❤️ quickly reacts to issues and MRs and do accept code which is not used/needed for ddrace.

Getting closer to the topic: as of now, we can't really ask DDNet devs to develop and support our needs, and without DDNet being a mod based on some common codebase, we probably won't have a base which the mod devs could "just" pull from.

What I can suggest instead is to split your idea into a number of small tasks and deal with them one by one. Suggest something small, get a feedback, find a compromise, and probably end up with something which is acceptable for all participants.

• Instead of "Adding mod support" do a series of "add API for feature X" or "add customization/abstraction point for Y". Here we also want to extend the protocol, and maybe:
  • Support a netmsg to play a custom sound (e.g. embedded into the map; play at certain pos (like NETEVENTTYPE_SOUNDWORLD does) or globally, like does NETEVENTTYPE_SOUNDGLOBAL)
  • Support a netmsg to move a quad or quads to a pos (or a rel pos)
  • Support a netmsg which patches the map on the client side (e.g. makes some solid tile an air tile or makes some hookable tile unhookable)
  • etc
• Open a smaller issue "add server-side LUA scripting support"
• Open a smaller issue "add client-side LUA scripting support" (probably won't be accepted)

Note that client-side LUA support will be treated as cheating. See e.g. #3552 (comment)

There is a teeworlds fork with LUA support: https://github.com/AllTheHaxx/lua-srv for the server side and https://github.com/AllTheHaxx/AllTheHaxx for the client side.

We can continue discussion on particular topic, as this issue has a virtually unlimited scope and I think I can write ten pages here.
In LUA-specific issue we can discuss the security considerations, etc.

[heinrich5991]

I've been considering adding mod support for DDNet.

Cool! Official mod support would be amazing. Thanks for opening this RFC issue. :)

Note however that this is a huge feature, I don't know if it's feasible at all. Also, different people might understand different things when they hear "mod support".

My strategy is to implement an interface in C++ and subsequently add Lua bindings for it. Lua is a widely-used scripting language for modding. Numerous games, such as Factorio, employ it to facilitate mod support. There would need to be a Lua-File for the server and the client.

What is this interface supposed to do? It seems "modding support" means server support for lua modding? How does the client enter the picture here?

I'm not talking about the nitty-gritty details of the interface itself, or the methods it'll use. It seems like this lua script would not implement the physics as far as I can tell, but only listen to events of them?

A big question is malware risk. When done properly the lua interpreter shouldn't be able to access the host system and just use the API.

Yes, definitely, the script should not be able to read sensitive data, and it'd be best if it also couldn't mine cryptocurrencies. I don't know the current state of spectre etc. wrt. info leaks, but I guess the only actually secure way would be to run it in a separate process. This sounds too hard though.

[heinrich5991]

Instead of "Adding mod support" do a series of "add API for feature X" or "add customization/abstraction point for Y". Here we also want to expand the protocol, and maybe:

* Support a netmsg to play a custom sound (e.g. embedded into the map; play at certain pos (like `NETEVENTTYPE_SOUNDWORLD` does) or globally, like does `NETEVENTTYPE_SOUNDGLOBAL`)

* Support a netmsg to move a quad or quads to a pos (or a rel pos)

* Support a netmsg which patches the map on the client side (e.g. makes some solid tile an air tile or makes some hookable tile unhookable)

* etc

I actually also think that it would be a good idea to extend the network protocol; it seems like a prerequisite for the server-side modding API anyway.

[fokkonaut]

There is already a Lua modding API for Teeworlds, it's not known widely though and I don't know how much I can say about it without asking the creator.
But I would definitely go for asking him to come forward if DDNet is really interested in that. (It's vanilla based)

[VoxelDoesCode]

One idea I had for mod support was that we could send small images as assets through the server, so that we can rather have custom weapon designs or custom sprites indicating points in a match. Not sure how efficient it would be, but for something like fokkonaut's playground that has a variety of weapons, it would be nice to have different looks for all the weapons.

[Kaffeine]

@laboooon are you going to push this forward or do you expect others to work on that? Would you mind giving the issue a more specific and precise name? Like, "Server-side LUA support", or "Server and client side LUA support", or maybe abstract "Support server and client side scripts".

Adding Mod-Support is like Make a good game and Make the players happy which is a never ending process.