Minigames

[Peter]

As you can see, all types of minigames get controlled by the central controller. This "controller" tracks which players are playing which type of minigame, and also stores the minigame name/ID they're currently playing in. This allows the script to export functions like isPlayerInMinigame, to check whether he/she is already occupied, but also functions like forcePlayerToMinigame and stopPlayerMinigame. The idea of having this controlled as a single entity is simply because that makes it alot easier to maintain, as well as to update the mode.

:: Race Minigames
Both MTA as SA-MP already have awesome racing capabilities, we have to surpass these obviously. Therefore we allow a virtually unlimited number of races taking place, all defined in their own .xml file for convenience. The race handler must be created as a class of which instances can be created, that way we can setup this system in an OOP-kind of way, which makes doing various tasks alot easier. Settings the race-handler should be able to support are;

- Number of laps
- Type of vehicle
- Vehicle model changes (e.g. for amphibious races)
- Unlimited number of checkpoints
- Pseudo-real time progress bar of your process (client-side calculating?)
- Health pickups for vehicles
- A larger number of (possible) participants per race, perhaps 8 or 10?
- ....

:: Derby Handler
Currently we have quite a limited amount of features for the derbies, which is understandable since there just are a few anyway. It would be great if this can be extended to a more general-purpose system allowing all kinds of derbies. The new system should be controlled by XML files as well, with a virtually unlimited number of derbies and have support for the following features:

- Up to 16 (possible) participants
- Health refills definable in the .xml
- ....

:: Deathmatch Handler
Deathmatch minigames are pretty much my favorite. The new handler really must be huge - it must support gang-matches, one-on-one matches as well as normal DM minigames and team-based games. All results must be saved and available for online viewing, as well as in one's profile. A number of things it must be capable of;

- Weapon pickups
- Free-for-all signup-based games
- Team-based signup-based games
- Gang-on-Gang fights
- One-on-One fights
- Specific conditions (time, gravity, weather)
- Definable weapons/weapon sets
- ....

:: Other Minigames
Controlled as interfaces (so with a set of callable functions) by a custom-controller, for things like Poker, Hay, Fallout and whatever more we can think of.

[pdescobar]

Derbies need "boundaries" defined and it might be nice if we could build-in some anti-idle protection. Currently people have a habit of parking on top of something and sitting there waiting for the other players to drop out which is pretty lame. If we could detect this and either kick them from the derby or just make the car take damage for sitting too long in the same spot it should alleviate that problem.

[Pugwipe]

I'd like to start working on the minigame controller, but I'm gonna be needing some of your views and ideas (particularly Peter's). About the signup system, I'm guessing it will mostly be command-based? And if so, should it be possible to have, say, 2 instances of the same race? I imagine that could lead to someone unwantedly starting a new race, instead of joining one.
I was also thinking to create a fancy minigame GUI (where people can start minigames, sign up for currently active minigames and see the participants and stuff), but I guess we'll cross that bridge when we come to it.

[Peter]

I'd like to start working on the minigame controller, but I'm gonna be needing some of your views and ideas (particularly Peter's). About the signup system, I'm guessing it will mostly be command-based? And if so, should it be possible to have, say, 2 instances of the same race? I imagine that could lead to someone unwantedly starting a new race, instead of joining one.
I was also thinking to create a fancy minigame GUI (where people can start minigames, sign up for currently active minigames and see the participants and stuff), but I guess we'll cross that bridge when we come to it.

I certainly want the larger part of the new system to be controlled using commands, using GUI for this would only make it slower than actually required. I think having multiple instances of the same race and derby won't be required, however, it might be useful in case of a deathmatch minigame considering these have more importance to gang members.

Overall I think the general design of the commanding-handler is quite important, it needs a per-player state system, needs to be able to control and synchronize the dimensions players will be in with the other systems (including the spawn handler for multiple rounds / allowing deaths at gangwars?) and generally be the way to communicate between the different instances. The planning really needs to be done on a per component base from that point on;

I think basic GUI's for menu's if a player requests /race would be fine, however, not more than a few labels, don't create fancy maps with the roads highlighted for every race - that's absolutely not needed. The current syntax like /race 5 should however stay available as well, to make sure we don't force players to use the GUI (personally I'd prefer to use no GUI at all, hence that requirement) and that should be the same with the other minigame types, perhaps with the exception of deathmatch area's. Perhaps it's an idea to create an interface for every type of minigame (google for interface if you're not sure what it means):

IMinigameType
- void HandleSignup (player)
- void ForceLeave (player)
....

That way the controller can purely act as a proxy to the underlaying functions, and won't have to worry about the real implementations at all. That makes it easier for minigames like Hay as well, having the user set features using a simple GUI (weather, gravity, time, etcetera) rather than it being plain and non-interactive. That all improves the average player experience