(yeah, that's it, just "Maze")

I authorised a new map recently (yeah, it's already been a few days, I know...), Maze, and I do have a few comments to do on it, towards whoever made it (he signed his map by the name "Dan"), in no order in particular.

• There is an issue with the big bugs, as Edwards very well explained in this topic, for the big bug scripts to work the sprite must be the first of the two, in your map they are the second of the two which means it alternates between it and... a shield (which happen to follow the second sprite in the sprite order)!

• A mysterious black square sometimes appears at the beginning. It's just a black sprite which is there who knows why in the background layer, which can sometimes appear above some background tiles at runtime. In the editor it's hidden behind background tiles, just move away the ones over it and remove that black intruder.

• Pickups don't have color for many of them, nor do they have the pickup pulse around them; for the first one you need to manually set the color, for the second you need to add an Extra2 between 1000 and 1200 (such a pickup pulse is expected around pickups).

• There are not enough background tiles around the zone where you pick up the blue color

• I triggered the red switch behing the door protecting the green gun, but the door didn't open.

• I went right through the door that protects the missiles (they have a weakness around their edges, put door fitting around them and some invisible walls if necessary).

• The colors are not the exact right colors! You have to use the yellow, red, blue, green and forest green that are in the sample level.

• Perhaps you should change the filename from the one of the template you started from...

• Save-Beam-thingies exist for a purpose, you know... The same goes for "Invisible wall", it's better to use that rather than normal walls placed in layer 10, as with these Invisible wall you can know at a glance in the editor which walls the player is supposed to see and which ones he isn't.

• You really should put an actual start point, even if the current behavior of starting from 0,0 works right now, Lars Gafvert once said "you should probably still set up a starting point so that you can control where the player starts better. (just check the sample levels)."

• You should definitely put a ReadMe along with the level. I don't mean to impose the same rules as Nova add-ons (and trust me, I'm a specialist of the matter), but it's better all around for everyone if your level comes with a ReadMe!

• And lastly, I don't think it's the best way to have secret passages. In fact I'm going to develop that over the remainder of the post.

So this level shows promise, but it's definitely not finished yet; in fact it cannot be completed to the best of my knowledge.

Back to secret passages - I've seen that in GSN's Race To The Finish as well, and I don't think it's a good way to do such a thing. A little context: FPSs overdid this back in the day (think of Doom and Duke Nukem 3D), with secret doors that look like ordinary wall that open if you "push" (i.e. use the normal door opening key) them. That was annoying when you had to bowse kilometers of walls and regularly "hmpf" them until you found the right one. It's even worse with SketchFighter, as probing the walls actually costs you (a little, admittedly) life!
Another game that gives a better approach, IMHO, is the original Legend of Zelda, in it doors could be open (or locked or keylocked, but that's another thing) or there could be a wall instead of a door, but sometimes these walls could be cracked open using a bomb. So I think a better method could have to have some walls be actually vulnerable to shots; perhaps only to missiles, but then you'd better give one hell of a hint there is something there as the missiles supply is too limited to probe walls with.
Another approach would be to have the wall disappear when you do something else, preferably far from it, like destroying an enemy or getting a pickup, though I'll have to investigate the technical feasibility of this. This way it's a bit of a secret that the door opens.
Back to LoZ, in the very advanced levels of this game (in the second quest, in fact) some of these walls couldn't be opened by bombs but could be crossed by going right through them! So I think you can have such fake walls, but that should only be done in the late parts of the level so as to still give the player a surprise when he already knows about the destructible walls, and only when the player has gotten the third ship, so that he does not lose life when probing walls for such secret walls. Of course these can not simply be fake walls as has been done already, as they are going to be spotted immediately when firing on them when looking for destructible walls, however you can do them in a clever way by setting the wall to be a child of another sprite (that you put just next to the wall, in front of it) which is set to be a pickup (solidity type 4). This way the wall is going to be solid against shots, but will magically disappear when you go next to it!

A related issue is that of the walls of the secret passage. It's not a good idea either to have them be just invisible walls (whichever way this is implemented) as has been done, as the player will end up hitting them repeatedly while looking for his way in this secret passage. So I think it would be better to have walls that are shown, even if only symbolic (say, like the lines in the somewhat secret passage with blobs in the Volcano). Now you may be thinking "Yeah, but if the player does see these secret walls of the secret passage, he will know there is something there!" Fear not, fellow mapmakers, for there are solutions! If you only have limited needs, you can simply put a few perfectly aligned background sprites in a layer >3 above the few walls that could be visible from the main part and you thus want to hide, and have these background sprites be children of the initial wall that the player destroys, this way they will disappear when discovering the secret passage. If you have many portions that could be seen from the main part of the map, this first way won't work as the hiding background tiles won't be shown when their parent (i.e. the initial door) isn't on screen, in this case set all secret walls to be fully transparent (alpha=0) and set them some Extra2 value, and give the same Extra2 value to the initial door, when the initial door disappears the Extra2 link will cause all these secret walls to turn opaque black, without any range limitation. The downside is that you have to assign an Extra2 value to the secret passage (and there are only 200 of them to begin with).

So that's it, I'm done with my ramblings about secret passages. Have fun sketchmapping!

This post has been edited by Zacha Pedro : 04 January 2007 - 08:40 AM

One question about secret passages -- pellets will travel down them, correct? So, while I agree with you that they should be used with extreme moderation, couldn't you simply constantly fire pellets or super pellets, and watch where they go?

xander

Yeah, that's right... but I don't like this, after all usually secret doors (in other games, that is) are not permeable to shots, and I prefer to check myself, physically. Especially as it's technically feasible as I said to make secret doors that block shots.

@zacha-pedro, on Jan 3 2007, 03:47 PM, said in New Level: Maze:

Another approach would be to have the wall disappear when you do something else, preferably far from it, like destroying an enemy or getting a pickup, though I'll have to investigate the technical feasibility of this. This way it's a bit of a secret that the door opens.

It works perfectly- I've implemented that sort of setup for a couple of doors in a proof-of-conceptish level that I made a couple weeks ago (and that I really should get around to uploading). The only (minor) problem is, as you point out later, that it requires the use of one of the Extra2 links.

(EDIT) Some commentary for the author:

1. Small Flickers do not follow walls, they travel in large clockwise circles. Yours spend a disproportionate amount of time ramming the walls. I'd recommend reading through my AI Guide (pinned in this forum) to see if you can find a suitable replacement for them.
2. Try very hard not to allow the player to crash into the back or sides of a wall segment, especially if it overlaps the front of another segment. Impacting those sides of the sprite will pull the player towards the front of the sprite, doing 1% damage about 10-20 times per second. This damage will be increased if the game tries to drag the player through the front of another wall, as it will then be harder than normal for the player to get away from the wall. I have actually accidentally managed to create a instant death point at a very sharp corner, but I haven't seen any corners in the maze so far that would be like that. (Note: there is a wall that very literally pulls you through it near the Wave Gun, probably due to an overlapping Layer 10 wall whose back sticks out in front of the visible wall's front- this could be used as a nasty secret door setup, but in this particular case, it is a bug.)
3. Basically, the most important advice I can give to you, and any other level designer, is to test the level personally before releasing it, at least to the point of knowing that it can be completed (yours can be, but only due to problems with the Super Door collision detection). If you run into a problem you can't figure out the source of, post a thread asking about it, and someone here should be able to solve it.

Edwards

This post has been edited by Edwards : 03 January 2007 - 08:12 PM

Inquiring minds want to know how you do it. They also want to know about that puzzle you described in commenting GSN's RttF (where you also said you didn't like this way of hiding a secret), though they can understand you not posting it in public where future users of the levels will know the trick before even playing them.

Heh, I checked out the Maze the other day too and found most of those same issues. I then proceeded to try and fix it in the editor and learn all about the editor at the same time. In particular, I looked into backgrounds.
There is a 'tile' feature which would seem to be intended for creating large backgrounds to cover your map with just a single object but the problem is that sprites only get drawn if the center of the sprite is within a certain distance from the player. This means a background sprite can only be tiled up to about 400%, after which you start having problems. The other problem is that you are required to have some sort of background or else the game will just be one massive graphical glitch. As a workaround for both of these issues (not to mention the annoyance of having to lay out the background yourself, one piece at a time) I would suggest simply to allow a background to specified for the entire map. No objects - just a property of the map. If you want different background in some places then you can simply lay them out yourself on top of the main background.
Well that's just one more of my wishes for 1.0.1 :). Guess I should have posted it in that thread but oh well.

Hmm, interesting. I think I'll do that for the next version of RttF. Which will come out after 1.0.1. Heh. I just thought of a great secret passage. I'll have to re-do some things, but that's okay. Too bad I can't get the little Zelda jingle to play when the passage is opened ^_^

This post has been edited by gray_shirt_ninja : 04 January 2007 - 12:32 AM

@guy, on Jan 4 2007, 02:50 AM, said in New Level: Maze:

Heh, I checked out the Maze the other day too and found most of those same issues. I then proceeded to try and fix it in the editor and learn all about the editor at the same time. In particular, I looked into backgrounds.
There is a 'tile' feature which would seem to be intended for creating large backgrounds to cover your map with just a single object but the problem is that sprites only get drawn if the center of the sprite is within a certain distance from the player. This means a background sprite can only be tiled up to about 400%, after which you start having problems. The other problem is that you are required to have some sort of background or else the game will just be one massive graphical glitch. As a workaround for both of these issues (not to mention the annoyance of having to lay out the background yourself, one piece at a time) I would suggest simply to allow a background to specified for the entire map. No objects - just a property of the map. If you want different background in some places then you can simply lay them out yourself on top of the main background.
Well that's just one more of my wishes for 1.0.1 :). Guess I should have posted it in that thread but oh well.

A nice 1.0.1 spoiler:

Spoiler

There's an auto-background tool in the editor of the next SketchFighter.

Btw: Really great guide ZP (as always) with good ideas which were immediately "stolen" for my own small plug-in project. Though it's a bit annoying that you can't see any invisible (alpha=0) sprites in the editor, this seems to be something for 1.0.1, too.

Hmm... unless you have particular needs (like my lines to indicate secret passage walls, that need to turn visible at some point), it's better all around to simply place invisible sprites in layer 10, it exists for that purpose.

I have a few addenda to my initial post. First, it's technically very feasible to have a door/wall that disappears when you do something far from it (thanks to Edwards for the way): a direct Extra2 link with the wall won't work, as it will simply turn it into a non-solid wall that's still visible; the Extra2 link needs to be made with a pickup (solid state 4) which is the father of the wall, this way when the sprite that's supposed to open the secret wall is destroyed, the pickup father will be removed and the wall with it! (Notice there is currently a bug with the current release that will prevent this from working if the the Extra2 link is triggered by picking a pickup rather than destroying a sprite, this means you can't have a secret wall open when the player gets a pickup for now).
Then, for the most advanced version of secret walls (the ones triggered by a pickup), you can use just about any sprite for the pickup trigger (except, of course, sprites of actual pickups like missiles or stars), including the same sprite as that of the wall you wish to make disappear in such a way; you can put this sprite a bit in front of the wall you want to be the door to the secret passage, or you can put the sprite (if it's the same sprite as the wall sprite) just on top of the wall, this way the passage will open if, and only if, the player actually hits the wall in question (thus being more like the Zelda inspiration, where you had to push the wall for a little time before it would let you through)! Of course, this trigger pickup sprite should be in layer 10 so as to be invisible. And needless to say, have solid state 4.
A little precision about the second method of having secret passage walls: the lines that indicate where are the walls, even if they are initially solid, will turn not solid when they will become visible with this method, so they are only an indication to the player, you need to put a few Invisible wall sprites to make the actual walls.

That's too bad we can't indeed have this lovely Zelda jingle (or anything else for that matter) play when we do such a thing, we can't like in Nova have this start an invisible mission that causes a cloaked ship to appear, that uses a harmless weapon that plays "the Void that doesn't end" when fired on us...

Hmm... this will probably be put in a more stable place in the future, but I don't know where - the place I used to use (for my Nova guides) has suddenly become unavailable with the upgrade to IPB 2.2.

So uhh.. is it possible to make a door turn on when something is activated, instead of strictly turning off?

Been trying to figure that out for awhile now..

@xel, on Jan 4 2007, 09:41 AM, said in New Level: Maze:

So uhh.. is it possible to make a door turn on when something is activated, instead of strictly turning off?

As far as I have been able to work out, no (barring Boss and Mini Boss doors), but I have come up with a rather ugly work-around that works fairly well (it won't block shots, and is only solid from one side for the player, but is otherwise fine):
Step 1: Place two Super Force Fields on top of each other. They must be the same size, but pointing in opposite directions so that they cancel each other out. The one pointing away from the area you want the player locked into should have an Extra2 of 1xxx, and the one pointing in should have an Extra2 of 1yyy (replace "xxx" and "yyy" with two numbers between 0 and 200, exclusive).
Step 2: Place an arbitrary sprite, with Solid Type "Pick-Up" (or "Enemy"), outside of the walls near the door. Give it a unique name, and an Extra2 of 1yyy.
Step 3: Place a non-solid door sprite with a color chosen to match the background (alas, Extra2 links that cause a sprite to turn black will not affect the alpha value) in the same location as your two force fields. Yes, it will be nearly invisible if you get the color right. Make it a child of the sprite from the previous step, and give it an Extra2 of 1xxx.
Step 4: Set your activation switch to have an Extra2 of 1xxx, and your deactivation switch to have an Extra2 of 1yyy.
Step 5: As a finishing touch, you may want to place a layer-10 Player type sprite in the doorway to keep enemies from passing through. If you do so, you may also want to make it a child of the Step 2 sprite to allow enemies to pass after the door is opened again (note that they will not be able to pass before the door closes the first time).

The end result of this is that when the player activates the close switch, the force field neutralizing the one pointing in will vanish, thus physically locking the player in, and the previously-invisible door sprite will become visible, albeit intangible, giving the appearance of the door being closed. When the player activates the open switch, the remaining force field vanishes, and the parent of the visible door vanishes, taking the door sprite with it, thus removing the appearance of there being a door.

As I said, ugly, but functional.

Edwards

Dan wishes me to relay this message:

"I submitted an updated version with the fixed door. And if (you) wish i can fix every other bug mentioned and give it to (me)
to post."

He also said that he did not see any of the bug except the one with the door.

I would like to note that it's a pretty decent level for his first experimentation with the editor.

Pi

thanks for the hack Edwards.. I'll see if I can get that to work (a bit later ;))

I just noticed that there aren't any warnings for the force fields in the level, maybe there should be some glowing "Button edge left" and "Button edge right" sprites next to them.

@zacha-pedro, on Jan 3 2007, 11:47 PM, said in New Level: Maze:

(...)when the initial door disappears the Extra2 link will cause all these secret walls to turn opaque black,(...)

(emphasis mine now)

@edwards, on Jan 4 2007, 06:31 PM, said in New Level: Maze:

(...)(alas, Extra2 links that cause a sprite to turn black will not affect the alpha value)(...)

I don't know if you've noticed the dissonance here (I certainly did), and after some testing I realised the game reacted inconsistently: if the Extra2 link is triggered by a pickup, then the sprites with the same Extra2 do turn 100% opaque (as I was assuming), however if the Extra2 link is triggered by destroying a sprite, then the sprites with the same Extra2 will keep the same alpha value... this is probably a bug, I've asked for more precisions on this in the beta list.