Shining Aid » Articles » A Basic Events System

A Basic Events System

Introduction

Events are an integral part of the Shining Force (and indeed RPG) experience, and are also one of the hardest to get to grips with. This article aims to give you a brief tour of the events system used by Shining Online, which should hopefully inspire you into ways of doing it.

Please note that this article is only intended to give you ideas as to solving this problem. By no means is it a complete solution – that’d take all the fun out of it! I hope it helps you in your task, and if you’d like to make any comments feel free to email me.

Triggers and Events.

The SO system is made up of two object: Triggers and Events. Their titles should give away what they are, but I shall explain them in a little more detail to clarify.

Trigger

A trigger is what sets off an event. For example, opening a chest would trigger an event to change the chest graphic to an open one, play the sound of a chest opening and show a message telling the player what was in it. As you can see, the trigger is vital to the operation of the entire system!

Event

A trigger is no use if it doesn’t trigger anything! An event is a simple action that occurs in the game. It could be playing some music, playing a sound effect, or make the camera shake for an earthquake effect. With a little effort, events can be chained together to form complex actions which should impress and engross players of your game.

Types of trigger and event.

SO uses 6 types of trigger. There is a trigger that activates at the start of the level, and one at the end of the level. There are also trow triggers that will fire when the player touches them. One will switch off after it’s first activation, the other will always fire. There are also 2 triggers that will activate when the player inspects them. Again, one of them is a one use trigger.

Events are a little more complex and varied. In fact, there isn’t really much of a limit to the amount of different event types you can put in.

Basic object structure.

Ok, on to some programming now. Here’s 2 simple objects that should give you an idea of how to implement both triggers and events in your program.

Trigger

struct Trigger
{
    int type;
    int xPos;
    int yPos;
    int firstEvent;
    bool active;
}

Fields:

  • type : The type of trigger. Eg, 1 to represent a “Start of level” trigger, 2 for an “end of level” trigger, 3 for an “inspect” trigger etc.
  • xPos : The X position of the trigger. Used for collision detection.
  • yPos : The Y position of the trigger. Again, used for collision detection.
  • firstEvent : The ID number of the first event this trigger will activate.
  • active : Whether or not the trigger will activate it’s event. For example, a trigger for a treasure chest would have it’s active flag set to false once it’s opened to prevent continued use.

Event

struct Event
{
    int eventID;
    int category;
    int type;
    string content;
    int nextEvent;
}

Fields:

  • eventID : A unique number to identify the event by.
  • category : The category the event fits into. Such as 1 to represent weather effects, 2 for team effecting events etc. This is more for a readable code aspect than for the computer, but code readability is more important than making it nice for the computer.
  • type : The actual type of event. For example, category 1 and type 1 would be “Make it rain”, type 2 would be “Make it snow” etc. Hopefully by now you should have a better understanding of how things are working.
  • content : A string of data used by the event. Could contain text for a speach event, or a list of object ids that are available from a shop. It’s really just a multi purpose bit of data, and I’m sure there are better ways around this.
  • nextEvent : Points to the next event in the event chain. -1 would mean this is the last event to execute in the current chain. This is used because the events are stored in a linked list format. I won’t go into linked lists here, as there’s plenty of other places you can find out about them.

More detail.

So that’s a very basic look at the structures involved in the SO events system. So how do they actually work together to provide an interactive experience? Read on!

First of all we would place a trigger somewhere on the map. For example, and inspect event for a barrel. We would then create an event to say “X looked in the chest…but it was empty”. The firstEvent flag of the trigger would point to the eventID of this event. Easy, no?

How are events activated? Simple. When the character performs an “inspect” action (and likewise with walking), the program checks the list of triggers to find active ones with the location of the square being inspected (or the square that has been stepped on). If it finds a trigger, it will pass the firstEvent number to the function that handles events.

The event handler is a simple set of switch statements contained in a do…while() loop. Here’s a bit of example code I knocked up to illustrate what I mean.

executedEventID = passedEventID;
 
do
{
    switch (eventArray[executedEventID].category)
    {
        case WEATHER_EFFECTS:
 
            switch (eventArray[executedEventID].type)
            {
                case WEATHER_RAIN:
                    // Do rain code
                    break;
 
                case WEATHER_SNOW:
                    // Do Snow code
                    break;
            }
 
            break;
    }
 
    // End of switch statements
 
    // Set the event to execute to the next in the chain.
    // -1 is used as a terminator.
    executedEventID = eventArray[executedEventID].nextEvent;
 
} while(executedEventID != -1);

So there we go. Like I said at the beginning, this probably isn’t the best way of doing things, but it should inspire you towards creating your own solution.

Good luck with your projects!

Leave a Comment