ffa_1life / Last Man Standing

[kevATin]

I see there's already "ffa1lf", but that one insta-kills on hit. I'd like a gamemode similar to 1dm but without teams. Do you think you could add that one; or how hard would it be to do it? Since I suspect individual rounds to be over quite quickly, the winner should probably be the one that can secure 3 or so wins first.

[biell]

So, you want ffa, but players are sidelined after their first death? And the last player playing is the winner?

[kevATin]

Pretty much; I think it would be a very fast paced game, that the average player might take more serious than ffa (and also enjoy it more), and there wouldn't be any team play pressure like in tdm and 1dm. I'm planning to have last man standing tournaments in the mmorpg, but I also think the gamemode could be fun in standard alti gameplay.

Do you think this is more something to realize with a script than adding it as a new gamemode?

[biell]

With the use of the server patches /denySpawn, this should be doable as a new game type. I think the type should be called 1fa, that will make it look more like 1bd, 1de, and 1dm. Map names would still be ffa_1fa_....

Maybe we should make lives configurable, with 1 being the default. What do you think? If you want, you could set the life count to 3 for a map. For your uses, you could create a way for players to earn extra lives.

[kevATin]

So far the 1fa mode seems good; 3 lives and 3 minutes feels very balanced. Also the matches aren't over nearly as quickly as I had thought, so counting wins over multiple matches isn't necessary to get a good game.

As we talked in game before; I think a good addition would be to have the server randomly broadcast the kills, lives, and location of currently alive players.

At the end of a match the "top 3" who managed to stay alive the longest could be spelled out, instead of just having one player be proclaimed winner. Maybe also make "ties" work better, dunno~ The vanilla alti match-end screen of ffa already displays the people who killed the most; so writing those in the chat probably wouldn't add much.

Could you add the ability to have lives be shared between team/color members? A plus.txt command to enable and disable it would be useful. I think this could be fun in team modes, but also in ffa. Whether there's 1, 2 or 8 teams, sharing lives would add an interesting dynamic.

If I find the time I'll work on a script for N-life-ball/1lb, or whatever we could call it (3 lives, if the lives value is a number then this is what everyone's lives is set to after each goal; if it's a "+N" then these lives are added to everyone's lives after each goal, allowing people to stack).

Is it already possible with the current setup to manipulate an individual player's lives easily? Lives could be added for collecting powerups, for kills, for ball scores, etc. I'd need the ability to set lives to a certain value, to add lives, and to subtract lives.

I think the /set lives command should work like this; /set lives [N] {all/team/color/player} The former can be any number and will set the lives of everyone on the server to N, and will be the default for everyone who joins newly (except if it's player name or if the newly joined isn't part of that team/color). If N is "+N" then the number is added to everyone's current lives. No change to lives of people who haven't joined? If N is "-N" then the number is subtracted from everyone's current lives. No change to lives of people who haven't joined? The later can be omitted (in which case it'll count for everyone), or it can be a team or color descriptor or player name. Possibly also a list of targets? What to do with players who join red (lives: A) and switch to blue (lives: B)?

What are your thoughts on this?

[biell]

As we talked in game before; I think a good addition would be to have the server randomly broadcast the kills, lives, and location of currently alive players.

The location is a good idea, but I don't think we need the rest of it, as you can just press the tab key to see those statistics. I have found that I do that from time to time, especially after I am out and just watching, to see who is ahead of whom.

At the end of a match the "top 3" who managed to stay alive the longest could be spelled out, instead of just having one player be proclaimed winner. Maybe also make "ties" work better, dunno~

This is totally do-able, it would be similar to the TAG game mode. You could also use the number of deaths as the tie breaker if multiple people were still alive at the end of the round. I will look to add this over the winter break.

Could you add the ability to have lives be shared between team/color members? A plus.txt command to enable and disable it would be useful. I think this could be fun in team modes, but also in ffa. Whether there's 1, 2 or 8 teams, sharing lives would add an interesting dynamic.

I am not convinced this would be a good addition to this game mode. I have found that anything which requires coordination quickly breaks down. Aligning people to teams, and getting them to work together, especially when they technically can kill each other, causes all kinds of issues. Just look at my attempt to test out FFA on Coop with ffa_coop_wrap_around. For this to work, it would need to be a tournament, where teams self-identified before the tournament, and the server knew who would be playing together. I think a script when worked off of the base code would be the best way to implement this. When a player died, you would just sync their out count.

If I find the time I'll work on a script for N-life-ball/1lb, or whatever we could call it (3 lives, if the lives value is a number then this is what everyone's lives is set to after each goal; if it's a "+N" then these lives are added to everyone's lives after each goal, allowing people to stack).

You could do this and then for each goal, have a:

foreach my $player in (player::list) {
     mem->game('oneout', $p)=0;
}

However, I currently only keep that counter up-to-date for you on map type 1fa. So, we would have to revamp some of that code to be more generic. If you are really serious, then I can do that. But, if you aren't going to do it, then I would just rather leave my code alone.

Alternatively, you could keep all of that in a script.

A final option would be to fork alti+server's repo, make your changes in a branch, and then issue a merge request for me to re-incorporate your changes. Theoretically, 1lb, would belong in the main code base, as it would be generic to multiple maps.

Is it already possible with the current setup to manipulate an individual player's lives easily? Lives could be added for collecting powerups, for kills, for ball scores, etc. I'd need the ability to set lives to a certain value, to add lives, and to subtract lives.

For my code, as it sits now, lives is a general number that applies to each person. However, you could implement your own per-player life count. For example you could set lives as such in mapChange:

foreach my $player (player::list) {
     mem->game('lives', '1lb', $player)=3;
     mem->game('outs', '1lb', $player)=0;
}

Then, to give a player an additional life (in powerupPickup or powerupAutoUse), you would just mem->game('lives', '1lb', $p)++;.

I think the /set lives command should work like this; /set lives [N] {all/team/color/player} The former can be any number and will set the lives of everyone on the server to N, and will be the default for everyone who joins newly (except if it's player name or if the newly joined isn't part of that team/color). If N is "+N" then the number is added to everyone's current lives. No change to lives of people who haven't joined? If N is "-N" then the number is subtracted from everyone's current lives. No change to lives of people who haven't joined? The later can be omitted (in which case it'll count for everyone), or it can be a team or color descriptor or player name. Possibly also a list of targets? What to do with players who join red (lives: A) and switch to blue (lives: B)?

What are your thoughts on this?

Any of that last part doesn't make sense. All of the syntax for the plux.txt file is really for static and map wide settings. And those things have overhead throughout the code and affect the configuration packet. My suggestion to manipulate a person's lives would be to use the mem->game(...) interface for storing objects in memory. You just have to initialize the settings on mapChange and clientAdd, then I will clean it all up for you when the round is over.