Ambrosia Garden Archive
    • Multiple MiniBosses


      With Doors!

      This is the first time i've seen this method of multiple minibosses, so i thought i'd post it. It has doors, which is an upside, but each door uses two Extra2 values, which is not.

      Attached File A_Level.zip (11.18K)
      Number of downloads: 21

      Hope this is of some use.

      Pi

      EDIT: To make this clear: You are free to use this method in whatever you like. I'd like it if you give me credit in readme, but it's not at all required. Also, Edwards has a more complex, but better looking, method of doing this Here.

      This post has been edited by PiSketch : 15 February 2007 - 07:59 PM

    • But there is only one miniboss.

    • Well, yes. But the technique used for the door can be used for many minibosses. I'll put up a new one showing that.

    • Thanks for that, do you mind if I use it in my level?

    • @---(Cool name): Not at all, that's what it's there for.

      New version with three doors up.

    • Interesting... can you make them spawn health/missiles when they die?

      xander

    • Probably. Giving them several layer 10, not solid boxes would do it, right?

    • There are a few problems with this which may or may not bother the average map-maker:

      • If you shoot through the space before the door appears, then you will see your bullets going 'under' the covering for the door since it isn't background.

      • When the door appears, it flickers in a slightly nasty way (the least serious issue)

      • Once the door has appeared, you can shoot through it too!

      • You can even (with a fast enough ship, like the #3 you gave to start the demo with) get through the force-field that is the door. Try it with the first one :). Of course, one could simply make the force fields larger but:

        • You would either have to extend them into the room

      which means you would be pushed far away from the door whenever you got near it

      * or would have to extend it away from the door behind it  
      

      which means you can easily poke your (ship's) nose through it and would get pulled through the door from far away

      I tried a less complicated variation of this once myself, but it failed much more miserably (at least this sort of works!) - I couldn't find a good solution 😞

    • And here I'd thought that someone had actually worked out the (sort-of) elegant way to do this. Oh well. Maybe I'll post it in an hour or so.

      @pisketch, on Feb 13 2007, 12:16 PM, said in Multiple MiniBosses:

      Probably. Giving them several layer 10, not solid boxes would do it, right?

      No, dropping shields/missiles is a feature of Solid Type 1, not of the box sprite. Sorry.

      (EDIT)All right, this is a unique method, and is a bit simpler than the one I described here. Do note, though, that mine avoids several of the bugs that Crono mentions. Anyway, nice job!

      Edwards

      This post has been edited by Edwards : 13 February 2007 - 08:57 PM

    • You can make multiple bosses by naming them "Boss1", "Boss2", etc.. I don't know if Boss Start triggers work though.

    • All right, then, as I've had this sitting around for a few days now:

      Multiple Bosses

      The game does have some support for multiple bosses, but it is not easy to set up.

      When the play enters a trigger named Boss Start, that trigger is removed, and the game looks for the last-placed sprite with the name of "Boss". If it does not find any sprite named "Boss", it will look for the last-placed sprite with the name "Boss2".
      If it finds a sprite with one of those two names, it will create a boss health meter linked to that sprite, and search for the last-placed sprites with the names of "Boss Door 1", "Boss Door 2", "Boss Door 3", and "Boss Door 4". These four Boss Door sprites (first one it finds with each name) will be moved to layer 3(?), and made solid (note that they need not be "doors"- the Ice Caves boss has a normal-looking wall as one of its doors).
      If no Boss or Boss2 is found, nothing will happen.

      After the Boss features have been activated, if the player kills a sprite ( any sprite) named "Boss", "Boss1", "Boss2", "Boss3", "Boss4", "Boss5", "Boss6", or "Boss7", that sprite will start the "Boss Death" animation, the Boss Health Meter will vanish, and the previously-activated Boss Doors will be deleted.

      Once one boss fight is over, another can start, using the same rules. It is possible to have multiple bosses with the same name, which will be activated in the reverse of the order in which they were placed. The same order will be used for multiple Boss Doors with the same name. For practical purposes, I recommend placing all sprites with the same name at once in one location, and testing them in-game to see what order they are used in.

      WARNING: Boss1, and Boss3 through Boss7 cannot be linked to Boss Health Meters.
      WARNING: Do not confuse Boss1 with Boss. They do not have the same behaviour.
      WARNING: If the player passes through a Boss Start trigger while a boss fight is in progress (meaning: before a Boss has finished exploding- note that the Boss Doors open several seconds before the Boss finishes the death animation), that trigger will be removed, but will have no effect on the game.
      WARNING: If you choose to give multiple Bosses the same name, note that only one of them (the last-placed, I think) can have child sprites.
      WARNING: The game-saving routines in 1.0.1 will likely mess up order-of-placement setups for multiple bosses, either by resetting Boss Doors, deleting on reload all Bosses and Boss Doors instead of just the ones that have been destroyed, or all of the above.

      A similar setup should work for minibosses, except that only "Mini Boss" and "Mini Boss 2" work for the mini boss sprites (the doors still go up through 4).

      Edwards

      This post has been edited by Edwards : 13 February 2007 - 11:58 PM

    • Hmmm… troubling. I've named bosses 1-4 "Boss1", "Boss2", etc.. The last boss will be named "Boss". Will that screw things up? Only the last boss will be using boss triggers. The other four are linked with Extra2s to something. If the Extra2s get reset when you reload the level, it will be unplayable.

      This post has been edited by gray_shirt_ninja : 13 February 2007 - 10:34 PM

    • @gray-shirt-ninja, on Feb 13 2007, 08:33 PM, said in Multiple MiniBosses:

      Hmmm troubling. I've named bosses 1-4 "Boss1", "Boss2", etc.. The last boss will be named "Boss". Will that screw things up? Only the last boss will be using boss triggers.

      No, that won't be a problem unless you decide to use Boss triggers for the earlier bosses at some point in the future. Oddly, although I swear that I had previously tested Boss1 and determined that it did not produce a Boss Death animation, it appears that it does. It does not get included in the Health Meter lineup, however.

      @gray-shirt-ninja, on Feb 13 2007, 08:33 PM, said in Multiple MiniBosses:

      The other four are linked with Extra2s to something. If the Extra2s get reset when you reload the level, it will be unplayable.

      Extra2 links will not get reset, so you have no cause for worry there. Boss Doors, on the other hand, probably will- I know that they are in the built-in levels (yet another reason for a "Reset Enemies" trigger!).

      Edwards

    • I've not had the time to analyse your various methods, but a little warning: anything that relies on the order of placement (i.e. last placed boss), which comes down in fact to the order of the sprite in the file, is completely unreliable and could break if the sprites are reordered (say, because the editor felt like doing so), or if the algorithm changes slightly in a future release of the game. Any behavior dependant on this order is an implementation detail and I'm afraid you can not reliably depend on it.

    • @zacha-pedro, on Feb 14 2007, 03:55 PM, said in Multiple MiniBosses:

      I've not had the time to analyse your various methods, but a little warning: anything that relies on the order of placement (i.e. last placed boss), which comes down in fact to the order of the sprite in the file, is completely unreliable and could break if the sprites are reordered (say, because the editor felt like doing so), or if the algorithm changes slightly in a future release of the game. Any behavior dependant on this order is an implementation detail and I'm afraid you can not reliably depend on it.

      It's still possible that the beta testers get Lars to add multiple real bosses, it's nothing you should count on, though.

    • @freq245, on Feb 14 2007, 09:09 AM, said in Multiple MiniBosses:

      It's still possible that the beta testers get Lars to add multiple real bosses, it's nothing you should count on, though.

      If you guys do manage that, could you also lobby for a slightly more modular system for the boss doors- say, Boss1 uses all Boss Door 1s, Boss2 uses all Boss Door 2s, etc.? At the very least, setting Boss Door 3 and Boss Door 4 to only activate with Boss2 would be a major improvement, with no side-effects in the built-in maps.

      Edwards

    • This is slightly relevant I suppose:-

      A trigger named "Preboss Start" will cause the health to show up of a sprite named "Preboss1". Upon killing it, it will then bring about the penboss sketching sequence with the random enemies, and will then make a sprite named "LastBoss" visible (from layer 10/non-solid? I didn't try it out much...). This also displays health.

      I'm not too sure if the sprites then behave as wanted, though - it might be hardcoded or something....

    • See my post in FireFalcon's "Last Boss Script" thread.

      Edwards

    • After experimenting with your technique I came up with this. Simple and short, I can see how this could be useful when done on a large scale with some modifications.

      Attached File Accumulative_Mini_Boss_Doors.SketchMap.zip (4.95K)
      Number of downloads: 9

    • @silverwind, on Feb 16 2007, 05:05 AM, said in Multiple MiniBosses:

      After experimenting with your technique I came up with this. Simple and short, I can see how this could be useful when done on a large scale with some modifications.

      Very nice, although I'd like to point out that you can use two-fifths fewer Force Fields if you replace them with Super Force Fields. Other than that, that's a very nice proof-of-concept. I particularly liked three points it demonstrates: First, the door-hiding sprites don't need to be blindingly obvious through bad offsetting. Second, the door force fields don't need to suck the player through when they get too close. Third, the sprite you use for the door itself doesn't need to be a door, and in fact can be something else that it more reasonable to shoot through. I hope that level designers will take note of these- this is a wonderful workaround for a weakness in the game engine, but most of the implementations so far have been flawed.

      Edwards