Tutorial Level - Open for collaboration

Topics about the general development of Orxonox.

Moderator: PPS-Leaders

The Jo
General DuGalle
Posts: 121
Joined: Mon Mar 01, 2010 7:43 pm

Tutorial Level - Open for collaboration

Post by The Jo » Sat Jul 30, 2011 7:32 pm

i just commited a draft of a tutorial level, which is needed for a release.

Since I got stuck on some details (and run out of energy due to a severe cold), I want to ask for team work on this level.

If you are interested, have a look at missionOne.oxw

Thanks!
Fail. Fail again. Fail better.

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Re: Tutorial Level - Open for collaboration

Post by greenman » Tue Aug 02, 2011 9:27 am

looks nice so far
however after destroying the boxes the tutorial doesn't continue, does it?

what did you intend to continue with afterwards?
There are only 10 types of people in the world: Those who understand binary, and those who don't.

The Jo
General DuGalle
Posts: 121
Joined: Mon Mar 01, 2010 7:43 pm

Re: Tutorial Level - Open for collaboration

Post by The Jo » Tue Aug 02, 2011 1:15 pm

I added a Todo-List and further comments in the file. Here is the brief version. //Already implemented things are placed in those brackets {}
TUTORIAL-TODO:
1. Aiming & Weapons (static targets {the four boxes}), moving targets {bots of type waypointController}, dangerous targets {either a AIController or WaypointPatrolController} )
Learning Targets: Usage of 3 Mouse buttons + "T"

2. Flying & manoeuvring (basic flying, using pickups {drone pickup}, forcefields, docks & portals)
Learning Targets: Usage of "W","S", "SPACE"

3. Game handling (quests, pausing, chat, ... )
Learning Targets: Usage of "F3", "F2", "ESC", ...

4. Extras (other things to discover)
Learning Targets: Usage of "Q","E","A","D","C", "CTRL", "", ...


//1. (where I got stuck) and 2. is absolutetly necessary; 3. would be nice

It is rather easy to place the named objects in a level - my problem is to give the user feedback in a dynamical way. E.g. when the first box is destroyed I want to send a message that states "Now shoot at the next box with the Lighning gun (right click) " or shorter "right click on the next target". Until now I wasn't able to catch the event that a Pawn died, although it is already similarly implemented in fightinourback.oxw (when you kill one member of the sleeping peers or enemies all bots of one of those groups will be activated - search for "Team 0") or theTimemachine.oxw (when you triggered the time machine effect and kill a bot, the time machine effect stops - search for "botdied").

Another nice, but no necessary effect which I didn't use is "hide and reveal": Only display the next target, if the previous task was carried out and thus enforcing a linear tutorial.
Of course the whole tutorial could be carried out as a quest - the only text that necessarly has to be displayed would be "Press F3 to see your next task". I think it is more userfriendly to display the messages directly on the screen. But if one wants to add longer explanations, the screenspace is definitely too short. So in the end there should be both short in game instructions and additional background info in the quest menu.
Fail. Fail again. Fail better.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Tutorial Level - Open for collaboration

Post by x3n » Wed Aug 03, 2011 1:28 pm

May I suggest using the same name for level and level-file? I searched the level list in the game for "missionOne" but couldn't find it. I had to open the level-file and learned the level is called "Tutorial". A few hours later I wanted to have a look at the file again. Accidentally I opened "tutorial.oxw" just to find out that this level is in fact called "Coding Tutorial". What the hell?
:angry-pc:

That's not your fault of course, I just want to appeal to anyone to help making this a bit clearer. :wink: We might even drop the level name completely and just use the file name. Or show the name only in a separate level description window.

---

Ok, now back to topic, I think it's great that you start creating a tutorial :) However I think I remember that Damian started (or wanted to start) with a tutorial level himself, so maybe you should arrange with him before you start doing work twice. And I'm pretty sure he wanted to use a Quest for it. And I'm also pretty sure that you can display quest messages directly on the screen.

I had a quick look at your level file and the code of SimpleNotification. I can't tell you for sure because this is not my code and I didn't study it in depth, but I believe the error might be that the message is sent to the Pawn that triggered the event (which in this case is the box), so the notification is not visible for the player, only for the box. I have no clue how to fix that though. I guess if this is indeed the case, SimpleNotification is simply not the right object. You'd rather need some kind of a "global notification" object that sends notifications to everyone. I'm sure Damian can tell you more.

Unfortunately I don't have the time to help you working on the level. Or, to be more precise, I spend the time I have rather with fixing bugs in the code an enhancing the framework because I feel my work is more valuable there. ;) If this finally results in an editor, it will also make your job easier.
Fabian 'x3n' Landau, Orxonox developer

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Tutorial Level - Open for collaboration

Post by Mozork » Wed Aug 03, 2011 7:35 pm

As Fabian has already pointed out, there are already plans for a tutorial and I've worked towards it, but there are still some gameplay things that need to be done so I haven't started working on the level yet.
Beni has (some time ago) written a rough draft of the story for the tutorial level (mission One is a fitting title, I think).

Here's the mail exchange (in german)
On Fri, 2010-11-26 at 13:57 +0100, Benjamin Knecht wrote:
Hoi Damian,

wie versprochen habe ich mir die Story für das Tutorial noch etwas durch den Kopf laufen lassen und habe jetzt etwas zusammen. Vermutlich werden wir einiges noch abändern müssen, aber solche Unterfangen sind immer von Kompromissen geprägt. Naja mal schauen was sich machen lässt. Schlussendlich brauchen wir einfach eine gute Einfürhung ins Spiel.

Nun der Anfang wird so sein: Der Spieler wird mit einem Raumschiff in der äussersten Umlaufbahn von Jupiter ankommen (das heisst Jupiter kann auch einfach in der Skybox sein). Der Spieler wurde von einem Piloten zum Jupiter geflogen. Während der aber das Schiff nach Problemen untersucht (kann bei interplanetaren Reisen passieren), soll der Spieler schon mal zum Rendevous-Punkt fliegen. Der Spieler ist ein Ingenieur (schliesslich müssen wir uns mit ihm identifizieren können) und soll andere schulen eine neue Technologie im Jupitergebiet zu verwenden.
Die neue Technologie befindet sich auf einem anderem Raumschiff und es gilt sich mit diesem bei diesem Rendevous-Punkt zu treffen. Der Spieler lernt dann die ersten Basics das Schiff zu manövrieren. Da kann man auch noch kompliziertere Navigationsdinge einbringen, wenn wir das später haben. Wenn der Spieler das Schiff steuern kann und denn Rendevous-Punkt ansteuert, erhält er vom anderen Raumschiff einen Notruf-Funkspruch. Hier könnte man noch mehr über das ingame Kommunikations-system lernen. Aber da haben wir ja noch nichts. Der Spieler eilt dann dem verbündeten Transporter zu Hilfe. Er wird von ein paar Piratenschiffen angegriffen. Es gilt sie zu zerstören/vertreiben.
Eines der Schiffe könnte etwas droppen und der Spieler lernt was über Pickups. Es wird dann in Formation zu einem grösseren Schiff geflogen (Formationsflug etc.) Dort angekommen identifiziert sich der Spieler beim Raumschiff (es ist das des Kunden) und man kann andocken.

Ich glaube das deckt mehr ab, als wir überhaupt anzubieten haben. Falls noch was fehlt musst du mir das sagen. Falls du auch noch mehr Infos haben willst. Gespräche, Funksprüche etc. dann kann ich dir das auch noch schicken.

Gruss, Beni

2010/11/26 Damian Frick <dafrick@orxonox.net>
Hoi Beni

Gefällt mir gut! Ich denke da müsste man all die Dinge die ein Tutorial beinhalten sollte relativ gut einbringen können. Ich glaube auch, dass sich das (mehr oder weniger) so machen lässt.
Einige Dinge können wir dann natürlich später noch etwas eleganter lösen, wie z.B. Kommunikationssystem (Dialoge) anstatt nur Notifications/Quests, richtiges andocken und Navigationshilfen.

Was ich mich noch Frage ist, wie wir die Geschichte erzählen wollen (also über was für ein Medium). Entweder wir machen das alles über die Notifications, oder wir machen es mit den Quests. Quests finde ich eleganter, ich weiss aber nicht ob da das Interface schon gut genug ist, aber irgenwann muss ich das ja sowieso machen und dann habe ich gleich noch einen guten Grund. ^^

Das letzte Schiff würde ich aber durch eine Spacestation ersetzen, da wir noch nicht wirklich viele grosse Schiffe haben und eines brauchen wir ja schon für den Transporter.

Falls du die Gespräche/Funksprüche schon hast kannst du mir die gerne schicken, ansonsten schreib ich dir sobald ich was brauche.

Gruss
Damian

On Sat, 2010-11-27 at 13:01 +0100, Benjamin Knecht wrote:
Hoi Damian,

ja, wir haben noch nicht alles, was wir in einem richtigen Game ins Tutorial nehmen würden, aber das ist nicht so schlimm.

Ich stimme dir zu, dass wir das Questsystem nutzen sollten. Das war eigentlich schon so gedacht, aber ich habs einfach nicht erwähnt. Dialoge und neue Aufgaben als Quests und die Notifications für kleinere Dinge, wo ein Questupdate unsinnig wäre oder es das Tutorial effektiv unterstützt. Wir sehen auch gleich die Schwächen und Verbesserungsmöglichkeiten unseres Erzählungsmedium und können so gleich ein erstes Konzept für Kommunikationssystem/Dialoge festlegen.

Der grosse Transporter ist im Moment natürlich mit einer Spacestation austauschbar. Für den späteren Verlauf der Story brauchen wir dann aber einen Transporter.
An den Funksprüchen und Gesprächen arbeite ich noch ein bisschen. Wenn wir das nun als Quest machen, dann brauchst du einfach Texte für die einzelnen Questbeschreibungen oder?

Ich finds aber gut, dass wir das meiste so machen können wie ich es mir vorstelle und dass das Level auch Ausbaumöglichkeiten bietet.

Gruss, Beni
So I suggest to try to modify the level to fit this idea. I am glad to help as soon as I'm through my exams which will be the case in mid-august. And feel free to write if some features are not yet implemented or not polished enough.
I also thing this is going to be a great use case for many features already implemented in Orxonox (such as quests) so feel free to suggest modifications.

As a side note to the level names. I would suggest to keep the level names, because the user doesn't care how the file is named. But I am going to implement a switch that shows filenames instead of level names in developers' mode.

SimpleNotification is indeed not equipped to do what you want. This is because of the networked nature of Orxonox, most notifications should only be seen by specific players not all of them, so SimpleNotification works only with PlayerTriggers from which it can extract the player the Notification is sent to. I agree with Fabian some GlobalNotification could be a solution, and I'm going to implement this right away since it's quite straightforward and clearly useful. However this is only a good idea if the tutorial level stays singleplayer (which is probably the case ;)). An other solution would be to use a MultiTrigger container to send the killing Player with the event fired by the killed Pawn. Or we could create a new gametype for the tutorial that takes care of sending these messages. This could also be useful for some of the challenges I can think of.

I would additionally suggest to seperate the creation of the tutoriallevel from the ai. Could we possibly merge the ai branch soon and create two new branches "missionOne" and "ai3"?

So in short if you need any help (in general or for specific parts of orxonox), clarification or some feature or improvement just write here or write me an email. I will try to help.

The Jo
General DuGalle
Posts: 121
Joined: Mon Mar 01, 2010 7:43 pm

Re: Tutorial Level - Open for collaboration

Post by The Jo » Wed Aug 03, 2011 8:14 pm

x3n wrote: :angry-pc:
Sorry that was my fault. I wanted to create a "Tutorial" level and then realized that a tutorial.oxw already exists. Since I wasn't really satisfied with the name I spontaneously came up with. Thats why I wasn't consequently enough.
Mozork wrote: So I suggest to try to modify the level to fit this idea.
Agreed. I didn't think of a story, but rather of what a new player has to learn.
Mozork wrote: I am glad to help as soon as I'm through my exams which will be the case in mid-august.
I'm also too busy for the next weeks. I'll continue to work on the level after the exams.
Mozork wrote: I would additionally suggest to seperate the creation of the tutoriallevel from the ai. Could we possibly merge the ai branch soon and create two new branches "missionOne" and "ai3"?
Agreed.
Fail. Fail again. Fail better.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Tutorial Level - Open for collaboration

Post by x3n » Wed Aug 03, 2011 8:21 pm

Sounds good!
As a side note to the level names. I would suggest to keep the level names, because the user doesn't care how the file is named. But I am going to implement a switch that shows filenames instead of level names in developers' mode.
I don't mean to highjack this thread, but just a quick remark on this: The users might care about the file-names, for example if they download a new level or try to create their own level.

People creating a new level will probably not define the name in the first instance, but of course they save it with a new file-name before they test it. What happens with these levels? No entry in the level list? Error message? When and where? Displaying the file-name would be a straight forward implementation.

Other level creators will probably start with an existing level by making a copy. The new file has a new name, but the same level name. How to handle this? Error message again? Orxonox acts like a bitch?

Finally many level creators will look up effects they liked in existing levels in the editor. How to find the right file?

I totally see your point, but there are equally many points to show the real file name. Games like UT do that as well. Other's don't.

I think we have 3 options:
a) Display the file name
b) Display the level name but with strong guidelines to keep file and level names as close as possible
c) Pretty print the file name (separate camel-cased words, remove underscores and file extension)

I personally prefer c)

</highjack>
Agreed. I didn't think of a story, but rather of what a new player has to learn.
In my opinion this is the right approach. The story is nice, but the gameplay is more important. After all this is a game, not a movie.
No offense against our talented story writers ;)
Fabian 'x3n' Landau, Orxonox developer

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Tutorial Level - Open for collaboration

Post by Mozork » Thu Aug 18, 2011 12:45 pm

@Levelnames
Currently, if no name is specified, the filename is used. Same levelnames are no problem (except for the user, because he won't be able to distinguish them).
Ok, I see your point. Especially if I were to download some additional levels and some would have the same name (but not filename), I would have to fiddle with the XML file to change the filenames. If we use filenames, then uniqueness is guaranteed and renaming levels is much more straightforward.
Consequently, I prefer c), too.

@Story vs. Function approach
Curiously, current games tend to move into the direction of playable movie.
I find that both approaches have the validity and both need to be considered. After all, in our case the tutorial level has two distinct functions. First it needs to introduce the user to the gameplay. Second (if we want to have some kind of story) the player needs to be introduced to the story and the game's background. If we do it right we can do both, consistently, in one level.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Tutorial Level - Open for collaboration

Post by x3n » Thu Aug 18, 2011 2:29 pm

Mozork wrote:@Story vs. Function approach
Curiously, current games tend to move into the direction of playable movie.
I find that both approaches have the validity and both need to be considered. After all, in our case the tutorial level has two distinct functions. First it needs to introduce the user to the gameplay. Second (if we want to have some kind of story) the player needs to be introduced to the story and the game's background. If we do it right we can do both, consistently, in one level.
That's true, many new games head into this direction. Take a look at this promo video of Need for Speed - The Run. It's the newest spawn of the Need for Speed series and will be out at in Q4 this year. And for the first time in it's history, it has a story. The storyline seems to be omnipresent throughout the game and I really wonder if this is still a racing game or rather an interactive movie.

http://www.youtube.com/watch?v=7bR90k8HGMM
Suffice to see the first 2 minutes, but feel free to watch the whole movie, there are more scripted events and interactive cutscenes.

These interactive cutscenes ask you to press the right buttons in the right time. Basically this boils down to a guitar hero gameplay or even resembles those "see how fast you can type" games in the internet. Also during the racing scenes, there are many short cutscenes where you loose the control of the car.

Now what do we learn from that? First of all, "Interaktive movie"-like games are surely a big thing today and one might wonder if classical games are about to die. But the gameplay of The Run gets mixed response. The Need for Speed series always attracted the casual gamers and they seem to like this new development. But real racing games enthusiasts probably think this game is a joke.

So should we create a game for casual gamers? I think no. I guess the casual gamer today plays his highly polished big-brand games on the console. I don't think the casual gamer even has a computer fast enough to play serious games. And I don't think the casual gamer crawls the internet for open source games. I assume our target group are the computer and gaming enthusiasts that can suffer some pain (searching the web, testing bullshit games, rusty graphics) to find a great open source game in the end.

The second important point is, that I believe we simply don't have the skills, manpower, and time to tell a big story in an "interactive movie"-like style. Maybe at some point we do - but until then we rather start with the gameplay because this usually suffers the most if developers focus too much on cutscenes.
Fabian 'x3n' Landau, Orxonox developer

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Tutorial Level - Open for collaboration

Post by Mozork » Mon Aug 22, 2011 7:24 pm

I agree, that we don't have the resources to create a cinematic gaming experience. But still, I find that the tutorial should be embedded in in some kind of story, that doesn't mean cut-scenes or anything elaborate but just a simple frame to make it less dry.

And then we can have several levels that are for the non-casual gamers, basically just great multiplayer (without any story) levels where bots don't do too badly and we're in business. But I believe that almost anyone giving the game a try will do so in singleplayer mode and that is where we have to hook the player. A nice tutorial level (with some story) will do that trick and set the stage for some deathmatch fun.

The Jo
General DuGalle
Posts: 121
Joined: Mon Mar 01, 2010 7:43 pm

Re: Tutorial Level - Open for collaboration

Post by The Jo » Thu Aug 25, 2011 3:53 pm

How the level should be played so far:
Destroy 4 boxes -> destroy 2 pirates -> goto DuballSpaceStation -> use portal -> goto Hydrogen Farmer -> dock to Hydrogen Farmer -> get the pickup -> use portal -> get rid of enemies
(not fully implemented: -> display victory message -> optional bonus part)

What does not work:
a) force the player to play linearly (e.g. the player is free to destroy or not to destroy the four boxes. If he chooses a different order, the messages are not displayed correctly) // Possible solution: show only one box after another
b) further infos / story : the SimpleNotification's are useful to display brief instructions. // more information and story elements could be shown in the quest menu.

Technical problems:
a) How can I detect the event when all enemies are killed? (event that is triggered when enemy No 1 && enemy No 2 && ... && enemy No N has died)
-> Important for game end
b) hide those enemies until they are activated. (invisibility & no hud markers)

By the way: can spaceboundaries be used in an inverted mode? (Such that they prevent a player to enter a sphere?)
[EDIT] Please test the current version of this level and give feedback.
Fail. Fail again. Fail better.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Tutorial Level - Open for collaboration

Post by x3n » Thu Aug 25, 2011 6:14 pm

Cool! I didn't test it yet though, will do so later
The Jo wrote:Technical problems:
a) How can I detect the event when all enemies are killed? (event that is triggered when enemy No 1 && enemy No 2 && ... && enemy No N has died)
-> Important for game end
You can combine triggers. I can't test it right now but the general layout should be something like this:

Code: Select all

<Trigger>
  <Trigger />
  <Trigger />
  <Trigger />
</Trigger>
The first trigger will then be triggered if all other triggers are triggered. You can use EventTriggers to gather all the kill events. You probably find more information in the Trigger.h/cc and TriggerBase.h/cc files in modules/objects/triggers (or here). There's also a "mode" parameter which can be set to "and", "or", or "xor" to define how the sub-triggers should be combined. Since sub-triggers can also have a mode and more sub-triggers, you can create arbitrary boolean logic with triggers.
b) hide those enemies until they are activated. (invisibility & no hud markers)
You can trigger the visibility and the activity of all objects. I'm not sure if this actually hides the hud markers though. You can either try to implement this or you write some code which allows to spawn enemies during a level. Maybe this also works with the Script class which is able to execute lua code. In this case you need to export the needed functions to lua.
By the way: can spaceboundaries be used in an inverted mode? (Such that they prevent a player to enter a sphere?)
According to the documentation in SpaceBoundaries.h they can:
108 int reaction_; //!< Values: 0, 1, 2.
109 //!< 0: Reflection on boundary (Standard).
110 //!< 1: Decrease-Health-Mode.
111 //!< 2: Inverted Version of 0. Prohibit to fly INTO a defined area.
200 XMLPortParam(SpaceBoundaries, "reactionMode", setReaction, getReaction, xmlelement, mode);
Fabian 'x3n' Landau, Orxonox developer

User avatar
Mozork
Mogthorgar, the mighty
Posts: 134
Joined: Wed Sep 24, 2008 3:27 pm

Re: Tutorial Level - Open for collaboration

Post by Mozork » Thu Aug 25, 2011 7:54 pm

Useful information about triggers can also be found in http://www.orxonox.net/doxygen/classorx ... igger.html

With regard to hiding enemies, I think triggering their activity (resp. the activity of the Waypointcontroller) and visibility should suffice. As far as I know radar visibility (hud markers) should also be dependent on visibility. There are some levels where exactly this is done, probably pirateAttack.oxw or similar.

The linearity problem could also be solved using triggers. The basic idea would be, you have four triggers for each destroyed box one.
A box Trigger would look like this:

Code: Select all

<EventTrigger name="destroyx" activations="1">
  <events>
     <trigger>
        <Pawn />
      </trigger>
    </events>
</EventTrigger>
This ensures that the Trigger switches to triggered when the Pawn is destroyed and then immediately to untriggered and stays that way.

Then there are four additional triggers needed. The first triggers when any of the four boxes is destroyed, i.e.

Code: Select all

<Trigger name="1box" mode="or" activations="1">
  <EventTrigger >
    <event>
       <trigger>
         <EventListener event="destroy1" />
       </trigger>
    </event>
  </EventTrigger>
  ...
  <EventTrigger >
    <event>
       <trigger>
         <EventListener event="destroy4" />
       </trigger>
    </event>
  </EventTrigger>
</Trigger>
The second trigger would be the XOR of the AND of each distinct pair of the destroy triggers. Because if two boxes are destroyed there exists exactly one pair where both were destroyed and any other pair has at most one triggered. I.e.

Code: Select all

<EventTrigger name="destroyx" activations="1">
  <events>
     <trigger>
        <Pawn />
      </trigger>
    </events>
</EventTrigger>
This ensures that the Trigger switches to triggered when the Pawn is destroyed and then immediately to untriggered and stays that way.

Then there are four additional triggers needed. The first triggers when any of the four boxes is destroyed, i.e.

Code: Select all

<Trigger name="2box" mode="or" activations="1">
  <Trigger mode="and" activations="1">
    <EventTrigger activations="1" stayactive="true">
      <event>
         <trigger>
           <EventListener event="destroy1" />
         </trigger>
      </event>
    </EventTrigger>
    <EventTrigger activations="1" stayactive="true" >
      <event>
         <trigger>
           <EventListener event="destroy2" />
         </trigger>
      </event>
    </EventTrigger>
  </Trigger>
  ...
  <Trigger mode="and" activations="1">
    <EventTrigger activations="1" stayactive="true">
      <event>
         <trigger>
           <EventListener event="destroy3" />
         </trigger>
      </event>
    </EventTrigger>
    <EventTrigger activations="1" stayactive="true" >
      <event>
         <trigger>
           <EventListener event="destroy4" />
         </trigger>
      </event>
    </EventTrigger>
  </Trigger>
</Trigger>
The third trigger would then be the same concept with triplets and the fourth would just be the AND of all destroy triggers.

I realize that this is a little bit complicated, so if there are any questions please ask. This could also be solved by implementing a new Trigger which triggers after it has received a specified number of events. (in this case 1, 2, 3 and 4).

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Tutorial Level - Open for collaboration

Post by x3n » Fri Aug 26, 2011 11:02 am

Actually this can be done easier using the "stayactive" and "activations" attributes and a cascade of EventTriggers.

Code: Select all

<Pawn name="box" />
<Pawn name="box" />
<Pawn name="box" />
<Pawn name="box" />

<EventTrigger name="boxtrigger4" activations="1" stayactive="true">
  <events>
    <trigger>
      <EventListener event="box" />
    </trigger>
  </events>
  <EventTrigger name="boxtrigger3" activations="1" stayactive="true">
    <events>
      <trigger>
        <EventListener event="box" />
      </trigger>
    </events>
    <EventTrigger name="boxtrigger2" activations="1" stayactive="true">
      <events>
        <trigger>
          <EventListener event="box" />
        </trigger>
      </events>
      <EventTrigger name="boxtrigger1" activations="1" stayactive="true">
        <events>
          <trigger>
            <EventListener event="box" />
          </trigger>
        </events>
      </EventTrigger>
    </EventTrigger>
  </EventTrigger>
</EventTrigger>

<SimpleNotification message="1/4 done" broadcast="true">
  <events>
    <trigger>
      <EventListener event="boxtrigger1" />
    </trigger>
  </events>
</SimpleNotification>

<SimpleNotification message="2/4 done" broadcast="true">
  <events>
    <trigger>
      <EventListener event="boxtrigger2" />
    </trigger>
  </events>
</SimpleNotification>

<SimpleNotification message="3/4 done" broadcast="true">
  <events>
    <trigger>
      <EventListener event="boxtrigger3" />
    </trigger>
  </events>
</SimpleNotification>

<SimpleNotification message="4/4 done" broadcast="true">
  <events>
    <trigger>
      <EventListener event="boxtrigger4" />
    </trigger>
  </events>
</SimpleNotification>
Note that we don't use different events for each box, each has the name "box" so each of the boxes can trigger all the EventTriggers. All EventTriggers except for the innermost one are deactivated, so the first time you destroy a box, only "boxtrigger1" is triggered. At the same time this activates "boxtrigger2" (because of stayactive=true) which will be triggered the next time you destroy a box, etc. Already triggered EventTriggers won't be triggered again, because of activations=1.
Fabian 'x3n' Landau, Orxonox developer

The Jo
General DuGalle
Posts: 121
Joined: Mon Mar 01, 2010 7:43 pm

Re: Tutorial Level - Open for collaboration

Post by The Jo » Mon Aug 29, 2011 8:08 pm

Thanks for the suggestions. The linearity problem is almost solved. Actually I start to like these triggers.

I let another person (casual player, not knowing orxonox) test the tutorial level.
Watching that person was quite eye-opening. It almost seemed like "What can go wrong will go wrong". :wallbash:

-> A tutorial level must be fool proof. E.g. only one "grey dot" (portal) on radar, activate/deactivate portals in the right moment, make planet collision nonlethal, make Hydrogen Farmer undestroyable, fix DockingController bug (boost), ...

-> More than one message per five second interval will be ignored. Since the one or the other SimpleNotification will be ignored by the player every important message/fact has to be communicated in several, different ways. E.g. friend/foe -> different colour on radar, add more information in quests, ...
When the level is finished, I'll change the timing, such that a new player can cope with the input speed.
Fail. Fail again. Fail better.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests