FOSS gamedev and creative worlds

I'm working and working on my fractured subgame, trying to find a way to turn pvp on in part of the world and off in another part.

But really, I think this functionality (the ability to control where/when pvp is active) is something that would be very useful to a lot of different subgames. Imagine the following scenarios:

1: pvp is on in the "wild west" but off in the east (the fractured scenario)
2: pvp is off, EXCEPT in designated arenas, there everyone can fight all they want.
3: pvp is off during the day, but on at night!
4: pvp is off unless you are wearing a certain helmet, everyone wearing that helmet can fight each other.
5: pvp is on except in certain designated "safe" areas like spawn or traders village
6: pvp is on by default, but a player can cast a "truce" spell that turns it off temporarily.
7: pvp is on except in protected areas.
8: pvp is off for new players, but on between players who have been on the server more than one day.
9: pvp is off with ordinary weapons, but allowed with certain special weapons.

etc, there are LOTS of possibilities to make the game very interesting by making pvp more complicated than just a simple Boolean on or off.

So, I would humbly request a new API hook:

register_on_pvp(function(attacker,defender) )
possibly on_pvp(function(attacker,weapon,defender)) or would it be best to get that by attacker.get_wielded_item() ???

The idea would be that if the game has registered an on_pvp function, then every time one player attacks another, the on_pvp function is called first, it can check whatever conditions the game developer wishes, and then return "true" or "false" to either allow or disallow this particular blow.

I have no idea how the pvp code works, but the above does not sound particularly difficult to implement, and I think it could add a LOT of interesting variety to multiplayer games.

Thank you for taking time to listen.

For me, PvP is more a choice of the player (which might vary over time), but never of the current location. Arenas might be places where PvP might take place, but even then players might visit them just to take a look. Even if you add more variations as to when it may be enabled/disabled, don't make it too complicated. Most players are not particulary bright and try to kill just about anything and won't even understand why that doesn't create a good game.

Sokomine wrote:For me, PvP is more a choice of the player (which might vary over time), but never of the current location. Arenas might be places where PvP might take place, but even then players might visit them just to take a look. Even if you add more variations as to when it may be enabled/disabled, don't make it too complicated. Most players are not particulary bright and try to kill just about anything and won't even understand why that doesn't create a good game.

An entirely valid point. But that is one of the advantages of having an API Hook, it would give the developer control to allow pvp under whatever circumstances they thought would work best for their players.

Sokomine wrote:For me, PvP is more a choice of the player (which might vary over time), but never of the current location. Arenas might be places where PvP might take place, but even then players might visit them just to take a look. Even if you add more variations as to when it may be enabled/disabled, don't make it too complicated. Most players are not particulary bright and try to kill just about anything and won't even understand why that doesn't create a good game.

Killing is the foundation of video gaming itself, so that is not surprising. Too bad they try to do that in Minetest, however.

Maybe there ought to be a before_use for tools like there is an after_use. In this function you could check, whether the action is allowed and return true to continue with the default on_use or false if you want to stop the function.
This has the advantage that you can make specific functions for each tool but has the disadvantage that you have to modify every registered tool.
This could be also useful for protection mods (or maybe not, maybe it's easier for the to leave the tools alone and simply pay attention to digging attempts).
Using before_use, you can benefit from the default behaviour, but still call a function on every use.

TeTpaAka wrote:Maybe there ought to be a before_use for tools like there is an after_use.

Might be handy, although I HAD thought I could do that with on_use, but apparently not.

TeTpaAka wrote:This has the advantage that you can make specific functions for each tool but has the disadvantage that you have to modify every registered tool.

Which is exactly why I still think a register_on_pvp() function would be incredibly handy. No need to try and modify the function of every tool individually, just modify the way pvp value is calculated.

Kilarin wrote:Which is exactly why I still think a register_on_pvp() function would be incredibly handy. No need to try and modify the function of every tool individually, just modify the way pvp value is calculated.

I know, it could get a little complicated. But register_on_pvp() is a little to special IMHO. With this function, only the special case when a player hits another player is handled. There are some uses, but if you have mobs, you might also want to disable attacking mobs in a specific area. With register_on_pvp() this is not possible, or the name is misleading.

Would this help?
This is, I think, exactly what you described.

TeTpaAka wrote:Would this help?

YES YES YES!!!!!!
TeTpaAka, you are my HERO! :)

It just got merged.

so this mornings update should include it, tomorrow at the latest! Looking forward to playing with this!