Tutorial Level - Open for collaboration

[x3n]

I tested the level yesterday as well. I know almost every detail of Orxonox, so I easily made it through the tutorial, but I noticed many details that need to be improved. Because every time I think "huh...? oh right" an inexperienced player will think "huh...? I'm lost".

My number one of missing features is:
1. Waypoints

Currently the user is guided to the next location through radar markers and you really have to read the messages carefully and think about which navigation marker could be the right one. Waypoints would guide the user to the next location.

Examples:
- If there are less than 3 boxes left, the pirates are highlighted
- It sais "Fly towards the pirates" but there's a big white arrow directing you to the space station / portal
- "Find the Hydrogen Farmer." What's that?
- Suddenly the docking menu pops up. Should I really do that? I'm trying to find that god damn hydrogen farmer

So I guess feature number two is (not necessarily a coding feature, could probably be done by spawning objects like pirates, portals, etc only when they are needed):
2. Hide unrelated radar markers. Maybe use a maximum distance to hide the objects at the other end of the portal?

And finally the notifications:
3. They should disappear after some time. New notifications should maybe flash when they show up? If there are multiple messages in short time, show them below each other (like the chat overlay).

Otherwise the tutorial looks quite good. Maybe the movement stuff should be explained before shooting?


Concerning the non-linearity of the triggers, I also noticed that sometimes the whole cascade of triggers fires off. I guess this depends on the order in which the triggers are updated. If the first box is destroyed, all listeners are noticed. If we're lucky, all triggers except boxtrigger1 are inactive, so only boxtrigger1 can be triggered. This is often the case because of the order how the triggers are defined in the XML file (boxtrigger4 before boxtrigger3, 2, 1). So naturally they will be updated in this order. But for some reason they might be updated the other way round. In this case, boxtrigger1 gets triggered right away. Then boxtrigger2 gets the notification and because boxtrigger1 is already triggered, boxtrigger2 will be triggered as well, etc.

To fix this, I think we can add a small delay. Now the boxtriggers get activated shortly after a box was destroyed. I think the delay can be almost infinitesimally small because every delay > 0 will lead to at least 1 tick delay (which is already enough). However 0.1 second is also fast enough because it takes some time to notice the explosion of the boxes anyway.

Code: Select all

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

[x3n]

I was asked what exactly I mean with "waypoints". Actually it's nothing really new as we have all concepts already implemented in some way, but not bundled in one class.

We have Billboards to show points of interest (like the red billboard in the tutorial level if you fly towards the pirates), but no one tells the player that he should go there. If he does, it's only because he assumes that this is the intended way to play this level. But that's not really how I define good gameplay.

We have billboard chains to show a path, but that's tedious to create in the level file and those chains are usually aligned along one axis because that's the easiest way to create them, there are no curves. And again no one tells the player to follow the chain.

We have radar markers and arrows to the 3 nearest targets, but there are many markers on the radar and the destination point may not be among the 3 nearest targets, so the arrows are more confusing than helpful in this case.

What I'd like to have (could also be a PPS ticket) is a class which combines these things. You place a waypoint in the level, but it's usually invisible in the beginning. If you activate the waypoint (probably by making it visible with a trigger), the waypoint becomes both visible on the radar and in the world as a glaring and very noticeable 'thing' (which at the same time doesn't look like a regular model - it has to stand out). The waypoint could be animated on the radar and have a unique color (ideally the same color as the 'thing' in the 3D world).

There should be a big arrow guiding the player towards the waypoint and maybe a permanent message which tells the user to reach the waypoint (the message could be an attribute of the waypoint and specify some details like "go to the portal", "reach the transporter", etc). The arrow should be bigger than the other arrows. It could even be a 3D arrow which doesn't point at the border of the screen but shows the actual direction to the waypoint. This arrow could be always visible at the top of the screen, even if the waypoint itself is visible on the screen (unlike radar markers where the arrows are only visible if the target is not on the screen).

And we might even add something like a path from the current position to the waypoint. This is optional and could be implemented later, maybe only for easy difficulty. Ideally we would use the AI's path finding algorithm to draw a path which avoids obstacles and considers the player's speed and orientation to show a feasible path.

If the player reaches the waypoint, it disappears and the mission continues. I guess the waypoint itself shouldn't BE a trigger, but it might HAVE a trigger (attached). This allows us to use waypoints to navigate the player to some location, but also to mark enemy ships (or other mission critical targets). In this case the waypoint would disappear if the target is destroyed, so the triggering event is not from a distance trigger.

Some examples:
GTA, waypoints are big colored cylinder that reach into the sky
3D arrow in a crappy game
NFS Shift shows the racing line (green if you're slow, red if you're too fast)
Amazing how hard it is to find some decent screenshots. The screenshots don't show how we should do it in Orxonox, rather some other games that have similar or related elements.

[x3n]

Beware, awesome gimp drawing skills below

screenShot_08312011_101831596.png (242.74 KiB) Viewed 17827 times

[1337]

awesome indeed...

[The Jo]

Next steps:
- colouring: it should be made clear to the player which object is a target and which shouldn't be attacked at all. Therefore I suggest a kind of colour code.
- add quests: every kind of information presented directly on the screen should be re-readable in the quest menu.
- create & add waypoints: the player should be guided trough the level.
- fix the spacecruiser's weaponsettings - is triggering a warning
- fix the spacecruiser (the model isn't located at the right place)

----
I'm not sure if I have enough time and energy to finish these tasks in a reasonable time. So everyone is welcome to join this project.