Game modes

[GoogleCodeExporter]

Making native support for certain game styles, such as:

- Barricading
- Riot
- Escape

In each mode there are certain rules that tell how modules like infection,
respawn and other events should act.

Riot (requires bot friendly maps):
Gameplay like Zombie Riot with, day emulation and lots of bot zombies.

Escape:
Make gameplay more escape friendly. Respawn zombies to spawn, block death
event so hlstats won't give negative score when falling in traps, etc.

Original issue reported on code.google.com by richard.helgeby@gmail.com on 7 Jan 2010 at 12:55

[GoogleCodeExporter]

Another game mode idea:

Use hostages in maps to rescue and protect them from zombies.

Original comment by richard.helgeby@gmail.com on 8 Jan 2010 at 11:04

[GoogleCodeExporter]

Escape:
- Make plugin compatible with maps that slay afk players, so they don't end up 
in a 
endless respawn loop. Or make a workaround for afk-kill features in maps.

Original comment by richard.helgeby@gmail.com on 8 Jan 2010 at 3:45

[GoogleCodeExporter]

That hostage idea sounds awesome.  Like zombies should be able to creep around 
easier, 
but have much lower HP, but they respawn quicker.  Humans don't respawn and 
there is no 
infection, just death.  And all that can be configurable.

Original comment by andrewbo...@gmail.com on 9 Jan 2010 at 7:29

[GoogleCodeExporter]

Idea by Annihilator:

------
And I got an idea. How about if teams (like in normal matches) would spread to 
different teams (T and CT) and not 1 person get infected, but the whole team. 
Ofc 
the team thats going to get infected would know it. And after x rounds teams 
change 
sides and the other team get infected? (The team thats going to get infected 
should 
be frozen before the infections so they wouldnt bother the human team 
preparations)

Would it be possible to make an extra plugin or and edit in ZM:R to make this 
possible (at least the thing when the whole team gets infected)?
-----

Original comment by richard.helgeby@gmail.com on 11 Mar 2010 at 2:12

[GoogleCodeExporter]

How game modes could be implemented:

Make a game mode manager. It's just like the event manager for the base system, 
but 
all events in the game go through the game mode manager too. It decides if a 
event 
should be allowed or not. This means that modules would probably need to 
register 
their events in the game mode manager instead, while the game mode manager 
register 
events in the event manager. Just like an event hierarchy.

In most game modes, the game mode manager would allow all events.

The game mode manager should provide some utility functions so other modules 
can 
read (and possibly modify) game mode info.

Some (or all) modules need to make their own decisions based on the current 
game 
mode. How they deal with each mode is up to the individual modules and whats 
the 
best solution for that game mode.

Since some game modes may have a completely different gameplay (the mode is not 
ideal for respawn, tele, or whatever) there should be several sets of settings 
for 
these modules, so that each game mode have their own settings for each module. 
These 
different sets of settings should be kept as cvars, so they're still compatible 
with 
map configs. To deal with that there should be a system to manage these setting 
sets, apply them and switch between them when game modes are switched.

The game mode manager should support live switching of game modes in mid-round. 
However, certain game modes could force a round restart if the mode doesn't 
support 
live switching.

Original comment by richard.helgeby@gmail.com on 13 Apr 2010 at 12:59

[GoogleCodeExporter]

It should be possible to use map configs to modify settings in a certain game 
mode 
setting set.

Original comment by richard.helgeby@gmail.com on 13 Apr 2010 at 1:02

[GoogleCodeExporter]

So, a game mode manager is like an event controller. Maybe we should make an 
event 
controller in the base and make the game mode manager use it and extend it with 
game 
mode related features.

Original comment by richard.helgeby@gmail.com on 16 Apr 2010 at 12:27

[GoogleCodeExporter]

Event hierarchy

Compatibility mode and game mode modules usually just block or allow events. 
Modules may also check what game/compatibility mode it to do the correct 
actions.

       +----------------+
       |   Raw events   |
       +----------------+
               |
               V
+-------------------------------+
|   Compatibility mode events   |
+-------------------------------+
               |
               V
    +----------------------+
    |   Game mode events   |        
    +----------------------+
               |
               V
     +-------------------+
     |   Module events   |
     +-------------------+

Original comment by richard.helgeby@gmail.com on 10 Jun 2010 at 5:35

[GoogleCodeExporter]

One problem with this hierarchy is that it conflicts with the base's event 
manager. If modules use the base's event manager they would get any event like 
the game/compatibility mode managers wasn't there.

We need a design with layered event managers, that is practically just 
allow/deny filters on multiple layers.

Original comment by richard.helgeby@gmail.com on 10 Jun 2010 at 5:41

[GoogleCodeExporter]

Design change idea in base: 
http://code.google.com/p/smprojectbase/issues/detail?id=57

With that design, compatibility and game mode modules will just modify the 
event filters.

Original comment by richard.helgeby@gmail.com on 10 Jun 2010 at 7:43

[GoogleCodeExporter]

Apparently this feature was already implemented in the base as EventMgr_Disable 
and EventMgr_Enable.

Also note that the game modes module should be dynamic. Modules for game modes 
should not be hard coded. Module names will be used in game mode configs.

Original comment by richard.helgeby@gmail.com on 26 Jun 2010 at 12:55

[GoogleCodeExporter]

Game rules config syntax:
"gamerules"
{
    "<module name>"    "enabled"
    ...
    "infect"           "enabled"
    "knockback"        "enabled"
    "classes"          "enabled"
    ...
}

Original comment by richard.helgeby@gmail.com on 26 Jun 2010 at 8:16

[GoogleCodeExporter]

Correction:
"gamerules"
{
    "<rule name>"
    {
        <modules>
    }
}

Original comment by richard.helgeby@gmail.com on 26 Jun 2010 at 8:18

[GoogleCodeExporter]

"gamerules"
{
    "zr"
    {
        "modules"
        {
            "napalm"    "yes/1/on"
            "days"      "no/0/off"
        }

        "config"
        {
            ...
        }
    }
}

Original comment by richard.helgeby@gmail.com on 26 Jun 2010 at 8:40

[GoogleCodeExporter]

Make one or more safe-mode game rule sets (for zr and zriot) with as few 
modules as possible loaded, while the game is still playable. This might make 
it easier to remotely troubleshoot other servers by telling them to activate a 
safe mode game rule set.

Original comment by richard.helgeby@gmail.com on 5 Jul 2010 at 3:38

[GoogleCodeExporter]

The configuration part is discussed in issue 225, with this conclusion: 
http://code.google.com/p/zombiereloaded/issues/detail?id=225#c1

Original comment by richard.helgeby@gmail.com on 16 Sep 2010 at 10:09

[GoogleCodeExporter]

Escape maps: Use the location manager (issue 246) to each player's progress in 
the map. This progress can be used for various stuff (no special ideas at the 
moment, but it might be useful).

Original comment by richard.helgeby@gmail.com on 29 Jan 2011 at 10:17