From Armagetron
Revision as of 21:35, 22 August 2021 by Cadillac (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
This wiki page has an associated Blueprint on launchpad.

At the time I'm writing this, there's absolutely no way the client can know what's really happening. Until now, the only thing that's different (from the client's view) between a harmless collapse and a base conquer is that it got a different message in English. That poses a great problem as soon as you want, for example, play a different sound depending on what happened. You can't just use the same sound for these both game events.

So here's my solution to this, having, the same way we separate content and presentation in webdesign, we'll separate the actual event and what to do when it happens. So at one side we have the server telling the client that event X happened, on the other side an event resource describing what to do when event X or Y is received.


  • Get a working sound engine :)
  • Modular approach, especially needed for event resources
  • Future-Proof, as in, you can make up new kinds of event types
  • Event description resources
  • Client/Server communication


  • Working sound
  • Event resources
  • Text events fully done via eEvents

General Concept Overview

You got 3 main classes:

  • eEvent
  • eEventType
  • eEventHandler

The eEvent object is what is sent over the network. It's lifetime is short, it's used from the moment when the event is known to happen to the moment when we send it to everyone(or not). It wields an eEventType and a list of arguments, a bit like tOutputs which have a name string, the context we caught/created this event from and a list of arguments.

The eEventType class defines an event type. Really. There is a big list of all eEventTypes so that you can name an eEventType using a string, but you don't have to worry about it anyway, the contructor's main role is to do that for you. So, an eEventType comports: a name string, which is used for transmission via eEvents and for naming; it also has serval eEventHandlers, which will be used when the event is received.

The eEventHandler is some kind of wrapper from the argument list transmitted with the event to the called action's arguments. There is room for predefined general purpose handlers, eg, one that takes <player id> <number>, or one that takes all the argument and turns it into a console message. Their job is also to catch bogus actions, then to either ignore them or report them( by disconnecting or showing a warning to the user )

On top of that, there are eEventHandlerSets. It inherits eEventHandler so you can use an eEventHandlerSet instead of an eEventHandler. This allows making different 'layers' for:

  • actions that would break the entire game logic if not called, but which can be replaced by a module/gameplay's code.
  • actions that the server/gamemode recommends, but which can be fully, and only fully removed
  • actions that are set by the user itself, which works on an incremental basis

As spoiled by the precedent list, and by the Goals section, users will be able so set their own handlers. User-defined stuff means user interface. User interface means different format. This format is going to be an XML resource type, and needs it's own specification.

Detailed Concept Points

Arguments passed to events