Common game interface and mod adapter modules (cs:s, tf2, dod:s, etc)

[GoogleCodeExporter]

For potential multimod support (cs:s, tf2, dod:s, hl2:dm, etc) we need an 
interface for acessing stuff specific to each mod in a common way.

Everything that's specific to a mod will be handled by its own mod adapter 
module. In case a feature is not available in a mod, it can be faked if 
possible. Round events can be faked.

ZR will detect which mod it's running on and load the appropriate mod adapter 
module for enabling the interface. Obviously, only one mod adapter can be 
loaded at any time.

All features in ZR use the interface and doesn't know about mod specific stuff.

The goal is to keep mod specific code in a single place, instead of everywhere 
in ZR's source (with lots #if defined macros). If something is changed in the 
mod we only have to update code in one place.

Here's a quick overview of stuff that's not common between mods. This needs 
abstractions or workarounds:

Events:
* player_death
* player_hurt
* player_spawn
* player_team
* round_start
* round_end
* round_freeze_end
* player_jump
* weapon_fire

They are slightly different between mods (or doesn't exist at all and need to 
be faked).

Functions:
* TerminateRound
* SwitchTeam
* RespawnPlayer
* FlashlightIsOn
* FlashlightOn
* FlashlightOff
* DropWeapon

Cvars:
* mp_friendlyfire
* mp_restartgame
* mp_autoteambalance
* mp_limitteams
* mp_roundtime

Others:
* team index (solved by teamlib, but we need to move ZR stuff to another place)
* grenades (napalm feature) and knife
* removal of objectives (hostages, rescue zone, and other mod specific 
objective entities)
* buy command
* weapon slots
* damage flags
* money
* night vision

Original issue reported on code.google.com by richard.helgeby@gmail.com on 27 Apr 2013 at 9:01

[GoogleCodeExporter]

A short summary and more implementation ideas.

Interface (game.interface.inc):
* Declares common data structures and constants (related to mod specific 
stuff), such as the VTeam enumeration with team IDs for zombies, humans, 
unassigned, spectator.
* Abstract version of functions. In some cases simplified if ZR doesn't need 
all the extra parameters some functions have. Most of these are based on the 
cstrike functions, and we'll make workarounds/adapters for other mods.

zr_core module:
* Perfect candidate for detecting game mode and loading appropriate mod adapter 
module. It can be one in its own OnPluginStart function, detect the game mod 
there and only forward OnPluginStart to the correct mod adapter module. The 
other modules will never be registered (though always compiled). Keep it very 
simple, there's no case where game mod will change. Load once, done.
* It might also be better to register common mod events here (round_start, 
player_death, etc). A mod adapter module will be responsible for firing and 
handling these events. Mixing various implementations for different mods in 
project_events.inc will make a mess. It's fine for one game mod alone, but not 
if we add support for more later.

Mod adapter module (cstrikeadapter, tf2adapter, etc.):
* Only one adapter module is activated by zr_core, obviously. Always active, 
never disabled, or not supposed to.
* Each adapter implements functions in the game interface, with adjustments and 
workarounds according to its game mod.

The result: A plugin binary with multi-mod support - without messy mod specific 
code and "#if defined" all over the place.

Original comment by richard.helgeby@gmail.com on 27 Apr 2013 at 8:38