Difference between revisions of "EEvent"

From Armagetron
(→‎Implementation: documented my planned implementation)
m (→‎Arguments passed to events: burp..err, yeah next time I'll work a little more)
(8 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
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.
 
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.
  
==Goals==
+
=Goals=
 
* Get a working sound engine :)
 
* Get a working sound engine :)
 
* Modular approach, especially needed for event resources
 
* Modular approach, especially needed for event resources
 
* Future-Proof, as in, you can make up new kinds of event types
 
* Future-Proof, as in, you can make up new kinds of event types
 
* Event description resources
 
* Event description resources
* Client/Server AND Server/External service communication
+
* Client/Server communication
  
==Milestones==
+
=Milestones=
 
* Working sound
 
* Working sound
 
* Event resources
 
* Event resources
* External communication
+
* Text events fully done via eEvents
  
==Implementation==
+
=General Concept Overview=
===eEvent class===
+
You got 3 main classes:
That's the object that will the thrown all the way, it doesn't collect a lot of info, but it collects all which is necessary to execute it(triggering what it is supposed to trigger) or to transmit it.
+
* eEvent
 
 
=====Friends=====
 
 
* eEventType
 
* eEventType
 +
* eEventHandler
  
=====[protected] eEventContext context=====
+
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 ''tOutput''s which have a name string, the context we caught/created this event from and a list of arguments.
Describes the network context the eEvent is found in. An eEventContext is a simple struct, detailled later. This about this as IE's security zones(or whatever they call it), but keep positive about it :)
 
 
 
=====[private] eEventType type=====
 
That's the eEvent's type, what makes it different from another eEvent. An eEventType is what contains the event's type string (ie. zone_conquered) and what actions it triggers.
 
 
 
=====[private] eEventArgumentList args=====
 
List of the eEvent's arguments :)
 
typedef eEventArgumentList std::map< int, vValue >;
 
 
 
=====[public] void Execute( void )=====
 
Executes the event.
 
 
 
=====[public] Broadcast ( void )=====
 
Broadcasts the event.
 
 
 
That's about it. That's not much is it? :)
 
  
===eEventContext struct===
+
The '''eEventType''' class defines an event type. Really. There is a big list of all ''eEventType''s 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 ''eEvent''s and for naming; it also has serval ''eEventHandler''s, which will be used when the event is received.
  
enum eEventContextComponent
+
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 )
{
 
  eEventContext_me      = 0,
 
  eEventContext_server  = 1,
 
  eEventContext_client  = 2,
 
  eEventContext_external = 3,
 
}
 
  
=====[public] eEventContextComponent sender=====
+
On top of that, there are '''eEventHandlerSet'''s. It inherits ''eEventHandler'' so you can use an ''eEventHandlerSet'' instead of an ''eEventHandler''. This allows making different 'layers' for:
The sender.
+
* 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
  
=====[public] eEventContextComponent receiver=====
+
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.
The receiver.
 
  
===eEventType===
+
=Detailed Concept Points=
 +
==Arguments passed to events==
 +
==eEventHandler==

Revision as of 20:25, 13 December 2008

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.

Goals

  • 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

Milestones

  • 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

eEventHandler