Multiple level exits for overworld about tsc HOT 32 CLOSED

Probably we should add identifiers to level exits. The level could then remember the identifier a level exit had and the world could check that identifier after a level was successfully completed. For this to work, each waypoint needs to have a mapping of <exit-ID> => <next-waypoint-ID> elements, which could then be used when unlocking the next waypoint. This will require rewriting the path handling code, see issue #20 for details.

from tsc.

Just to check, will the number of exits (and paths out of it on the map) for a level that are allowed be arbitrary?

from tsc.

I was currently thinking of allowing up to 4 different exits, one for each direction. With some more work, an arbitrary number should also be possible if you need.

Vale,
Quintus

from tsc.

I was thinking it should be arbitrary, but 4 could work for now as long as we keep the arbitrary idea on the radar. There are ways creative people could put that many level exits and map paths to use (as long as we don't have a brittle map path system).

from tsc.

Suggestion - we might add some sort of system by which you can see whether you have a hidden exit you have not yet found when passing over a level on the map.

Super Mario World has levels that look red if they have multiple exits. Donkey Kong Country displays a ! after the name of a level if you have not found all the bonus areas in it. We'll want to come up with something original, but it will help the player if we somehow tell them if they have secrets left to find. It also allows them to go secret hunting.

from tsc.

Nice idea. Some suggestions on the visual indication are appreciated, though.

The information itself could be added to the level, and if an overworld detects a level that contains secret areas, it can change the visual appeareance of the level waypoint. The overworld would have to preload the level from the XML to have that information, though. WAIT. I have an IDEA. That could help us even with the slow loading times. We could preload the levels in a world in separate threads while the player is on the overworld already. Entering a level would then either directly enter it, or wait for the corresponding level loading thread to finish. Inside levels, similar could be done with sublevels. I definitely have try this.

Thanks for the input!

Vale,
Quintus

from tsc.

Color tends to be pretty visual. We probably need different colors than Super Mario World though:

• Green - all exits have been found
• Yellow - not all exits are found (we could also use red)
  --It's supposed to be like traffic lights in terms of color choices.

We also might consider something to denote the number of exits in the level, but if there are a LOT of exits it can only be shown numerically.

The preloading idea is very good. In addition to starting up the preloading of a level when you hover over it on the map, we can keep a level preloaded between deaths in that level and while reloading a level to start over in the editor. I'd also like to add a hotkey for reloading a level to start it over from the beginning for editor convenience. Lastly, it should stay preloaded when you load a save state - people will often load a state for the level in which they just died.

from tsc.

This task is open if anyone is available to pick it up in devel. It would be great if we finished it for the next release after release 2.0.

from tsc.

We will probably need to differentiate normal exits from secret exits in the level editor / level file format. What might work well for this?

from tsc.

I’d just add another attribute to level exits that says "target level on worldmap". That way we don’t have to actually handle "secret" and "normal" exits different and would even allow to shortcut pathes. This requires rewriting the overworld routing system, but this has to be done anyway, these lines are very uncomfortable. It should be replaced with an automatic routing system.

Vale,
Quintus

from tsc.

That way we don’t have to actually handle "secret" and "normal" exits different and would even allow to shortcut pathes.

This is a good idea, but we still might want a way to differentiate them in some cases for the sake of level stats (For the concepts both in #385 and #350).

from tsc.

As for #385, I can’t see how this conflicts with the secret area markers. The information on the secret hangs on the markers, not on the exits. If you place an exit in a secret area, then, well, it’s a secret exit. From a collection perspective, it should be possible to find the number of secret exits in a level by iterating over all secret areas and checking whether there’s a LevelExit instance inside them.

Vale,
Quintus

from tsc.

If you place an exit in a secret area, then, well, it’s a secret exit.

How could we denote whether an exit is in a secret area? Are you thinking the level creator would create a very large secret area rectangle that would overlap the exit?

from tsc.

Are you thinking the level creator would create a very large secret area rectangle that would overlap the exit?

Currently, I’m thinking you drag a rectangle over the area you want to denote as "secret", which is only shown in the editor and invisible in the game. The rest is simple collision checking. I want rectangle dragging functionality anyway, because it is very useful with regard to scripting ("if the player enters here, do something").

Vale,
Quintus

from tsc.

These are the 2 considerations I see with this:

• Some level creators will not properly put the secret area rectangle over the secret exit
  • If they have to denote exits as secret with a menu selection they could forget this, too. The question is which is more intuitive.
• If we use transparency with the secret area marker, it would need to be set such that you can easily see the secret exit but still easily see the objects underneath (it may be a large region). I'd lean towards a higher amount of transparency, but it will have to be tried in the editor.

from tsc.

Some level creators will not properly put the secret area rectangle over the secret exit

Which is no problem. It isn’t recognised as a "secret" exit then by the stats collector, but that doesn’t hinder the exit’s functionality in any way. So I doubt this is an issue.

If we use transparency with the secret area marker, it would need to be set such that you can easily see the secret exit but still easily see the objects underneath

That’s correct. I see two ways around this:

1. Don’t use transparency. Use a thick yellow border around the rectangle instead (or something similar). (Actually this would mean make the actual shape fully transparent)
2. Colourise the rectangle differently. Exits are red by default, so make the secret area rectangle green or so.

I lean towards the 1st solution, because large secret areas would be covered by a coloured rectangle otherwise which may make editing difficult.

Vale,
Quintus

from tsc.

It isn’t recognised as a "secret" exit then by the stats collector, but that doesn’t hinder the exit’s functionality in any way. So I doubt this is an issue.

Yes, breaking the collection system (due to incorrectly submitted official levels) is my concern, actually.

This is another possible algorithm: allow the user to set a field for each exit optionally. If the user drags a secret area rectangle over an exit, change it to be a secret exit automatically. If there's a concern the user may not be knowing what's going on, we could have a dialog box.

I lean towards the 1st solution

I had imagined it having a low amount of transparency, but I'm open to other solutions, depending on how they look in the editor.

We probably should also discuss if we want to track the secret exits at all. I think it would be helpful to track them so that users can see how many exits are left to be found; they open up new areas on the map.

from tsc.

We probably should also discuss if we want to track the secret exits at all. I think it would be helpful to track them so that users can see how many exits are left to be found; they open up new areas on the map.

I’d rather not track secret exits. I’d prefer it to track secret areas. And then display the number of available secret areas on the start of a level like Supertux does.

Vale,
Quintus

from tsc.

I’d rather not track secret exits. I’d prefer it to track secret areas. And then display the number of available secret areas on the start of a level like Supertux does.

Yes, I sensed a possible underlying disagreement here. My thought is that it will be difficult to know how many routes are unexplored (coming out of each level) on the map without this, unless we tracked "explored routes", "secret routes", or something else on the map like this instead. Not having the exits / routes information would seem a bit inconsistent with providing the secret areas information to me. I don't think Super Tux has alternate exits for levels at all, at least last I checked. I otherwise have no problem with tracking secret areas.

from tsc.

As far as i know Supertux doesn't ahve any alternate exits, but i haven't played all the levels yet either.
the doors in supertux usually just lead you to another part of the worldmap, or another layer, etc.

from tsc.

I do like that supertux does track the secrets. And if you didn't know, when you land in the secret area it says "you have found a secret area".

from tsc.

Yes, i think tracking secret exits would almost give the fun away in finding the secret area and seeing what it does.

from tsc.

Yes, i think tracking secret exits would almost give the fun away in finding the secret area and seeing what it does.

It helps a player to shoot for 100% completion for finding all exits. Otherwise you have know idea how many secret exits there are in the game you did not find (and hence you have no idea how many levels you did not play that are part of the campaign, unless you cheat by looking at the level list or game set up). Chances are the secret exits will not all be covered by secret areas, either.

Also, knowing the number of anything could be argued to give the fun away -- with this argument one could say there should be no secrets tracking at all.

from tsc.

I was just thinking on this. In Super Mario Bros. 3, the magic whistles are completely hidden with no tracking, and many players never know about them until they read a strategy guide. In this case it makes sense, since the warp whistles cause such a drastic change in the game (almost cheating).

By contrast, alternate level exits expose major portions of content that the player will not be able to see without playing (unless they "cheat" by manually playing levels individually in the level selector). There are many of these, and it drastically helps to at least have some idea where they are.

Secret areas only offer bonus points. It can be a lot of fun to find them, but they generally offer little reward beyond extra lives (unless we start hiding special items that change the game in them of course, which is an interesting idea).

I don't have any objection to tracking secret areas, but if we do not track secret exits per level, I think we need some sort of other hint system to give clues to the player about the secret exits so that they have an idea what areas they have not found and roughly where they are. It might be good to consider doing it differently than Super Mario World, but I think some sort of hint system is needed.

from tsc.

Rereading the above discussion, I see the point about secret areas being used to denote secret exits (by placing a secret area marker over a secret exit). I also understand that some alternate exits may in no way be hidden.

My concern with this approach is that many level creators will not read published level standards and will simply dump secret exits into levels, without even realizing they might want to mark them as secrets. If there is some way to generate a warning for this, it might work, but I can't think of a way to do this.

from tsc.

Actually, if we just go with the original idea of using color to denote the number of waypoints for levels (or denote how many exits there are otherwise, if we allow more than 4 exits), it should in theory be obvious how many exits there are in a level . With this approach, it would be obvious where unexplored paths are, and it would not require stats tracking as we have discussed with the secret areas.

Color may require a hard limit of 4, 5, 6, 7, or 8 exits. Otherwise we will not have a distinct color to use for each. The only alternative is to make it be shown numerically, which could be argued to conflict with secret areas tracking.

This also would not prevent exits from being marked with secret areas as discussed above, which could provide an additional hint for secret exits in this setup.

from tsc.

I can see the point of not tracking secret areas at all as @sydneyjd pointed out. It’s an effect of surprise when you read later that there are such secret zones. Thus, I’d not be strictly against to not track secret areas at all as well now.

Both that approach and the Supertux one seem fine. What about a compromise: We divide the terminology into "bonus areas" and "secret areas", where "bonus areas" are what the "secret areas" are now, i.e. passages that are rather unimportant that provide you with jewels and lifes. Those are tracked. Additionally, we introduce real "secret areas" that contain special items or alternate level exits that are not tracked, and could thus be everywhere.

For hinting to secret areas (in above terminolgy) I’d suggest to use more subtle hints than obvious colours. For example, have a passage in level A and level B that looks exactly equal, but in level B there is a visible gap with a jewel in the top-left wall. In level A, that gap doesn’t visually exist, but (using passive or frontpassive tiles) is there and leads to a secret alternate exit. The careful player can thus locate the exit by comparing those two seemingly equal passages. This kind of hints requires a lot of creativity and work, but I think we are creative enough for this :-)

Vale,
Quintus

from tsc.

I think we should target this change for the next release if possible. We really need some new features if possible in the game.

For the prior discussion:

For hinting to secret areas (in above terminolgy) I’d suggest to use more subtle hints than obvious colours. For example, have a passage in level A and level B that looks exactly equal, but in level B there is a visible gap with a jewel in the top-left wall.

In all honestly, I think these hints (having coins that hint where exits are), should be done alongside the tracking of the number of secret exits. Using things like coins to hint toward tracked areas is a fairly standard game mechanic in games.

My concern with not tracking alternate exits is that most people will miss them and have no clue how many alternate levels they missed. Most players use some sort of tracking system to find the major things they missed in a game. Missing entire sets of levels means missing a large portion of the content. Players would have to ask on forums or find strategy guides just to see a good portion of the game content, effectively.

Yes, i think tracking secret exits would almost give the fun away in finding the secret area and seeing what it does.

This sort of fun is usually well delegated to "extra" special secrets, such as the magic whistles in Super Mario Bros. 3. Some amount of untracked secrets is good, but it generally is best not to have a large portion of your content untracked. We could look at having a combination of tracked and untracked alternate exits, thus.

Hidden bonus areas could be tracked or untracked; either way it is a smaller portion of the game content.

This of course is just my view; it has a major effect on gameplay, so I wanted to point it out. I do think we need to implement some sort of alternate exit system, especially given that Quintus already started this.

from tsc.

I think we should target this change for the next release if possible. We really need some new features if possible in the game.

Yes, it's a nice idea and hopefully not of the level of complexity the CEGUI and SFML changes were. I'll add it to the 2.1.0 milestone.

In all honestly, I think these hints (having coins that hint where exits are), should be done alongside the tracking of the number of secret exits. [...]
This sort of fun is usually well delegated to "extra" special secrets, such as the magic whistles in Super Mario Bros. 3. Some amount of untracked secrets is good

We could just add this "secret area marker" object to the level editor. If the level designer uses it, the secret area is counted, otherwise it isn't. What is tracked then is just made a question of level design, where it should probably belong. Unless of course we decide entirely against tracking, in which the object would be useless.

A secret area doesn't neccessaryly contain a secret exit, which needs to be valued when counting the number of secret exits. Then there might be multiple regular exits in a level, i.e. equally valid alternate pathes which are not secret. Especially due to the last fact, can we extract the discussion about secret areas and secret exits into a separate ticket? The implementation of multiple exits in a level is independent from the question of counting or not counting them when they are in secret areas.

Vale,
Quintus

from tsc.

Yes, it's a nice idea and hopefully not of the level of complexity the CEGUI and SFML changes were. I'll add it to the 2.1.0 milestone.

I realize we need to get the 2.1 release done in order to stop the game from breaking on newer Linux distributions, but I reasoned that we have not had many new features in a while and needed something to show developing game play experiences. Features that already were started are potentially low hanging fruit for this. This change also will due wonders for giving the game more depth, if we add some alternate exits to the levels in the campaign.

Also keep in mind that after the 2.1 release most people will take a break from development, and it will be a while before new features get developed again.

Especially due to the last fact, can we extract the discussion about secret areas and secret exits into a separate ticket?

A lot of the main discussion is in this ticket. Would we paste every major comment into it? Most people will not browse between two tickets for info; it's hard to get them to read a longer discussion in one ticket. I'm open to a new ticket if we find a way to handle this.

We could just add this "secret area marker" object to the level editor. If the level designer uses it, the secret area is counted, otherwise it isn't. What is tracked then is just made a question of level design, where it should probably belong.

My concern here is that a lot of level designers are either not going to know about it or outright forget. We could catch this in levels reviewed for inclusion in world maps, but it can be hard to notice in a review. We don't really have level standards yet, either. Another solution might be to have a warning display if no secret area marker is placed within a certain proximity of a secret exit in the level editor. The creator would then be inclined to make a decision. Yet another option is to have an option on a secret exit that can be checked to make it mark it as a secret area. It would be checked by default.

Another consideration in our tracking discussion is that the direct tracking of exits as I originally suggested (not indirectly through secret areas) feels a lot like Super Mario World, which we do not want, given that we are derived from Super Mario Clone FX, a Super Mario World Clone. Finding a different way to track secret exits would distinguish us.

from tsc.

Progress! The basics are done, now it needs to be mapped to level exits.

Video: http://files.guelkerdev.de/tmp/multi-exits.ogv

Vale,
Quintus

from tsc.

Okay, it now mostly works, and existing worlds are compatible. Missing savegame of the "progress" still.

from tsc.