VectorSatyr

I don't remember how many times I had to record the fight, but obviously not enough to be upset over it. It was a glitch with the new move being used on her, hence it getting removed from following patch revision.

Happy birthday, musician sir!

... Cinnamon Toast Crunch?

Yes, seriously. Although I'm hoping it's because we're all too busy working on fangames to talk about trivial shit...

Happy birthday, good sir!

Happy birthday, good sir!

Happy birthday, good sir!

Happy birthday, good sir!

Happy belated birthday, good sir!

Happy birthday, good sir!

K.I.S.S: call it "Desert Base Zone". EDIT: or "Sand Station" or "Desert Dungeon".

Do I hear an echo?

Awww, I missed it. ;_; Happy birthday, master sir!

Happy birthday, good sir!

Oh... welp! Can't help you there. Sorry. =(

Start with this, for now. EDIT: Animations are case-sensitive. If an animation is not playing that you think should be playing, chances are you either spelled it wrong when you tried to apply it, or it wasn't properly loaded.

In general you find a spot right after the player's x and y position has been updated, but before a new ground object has been acquired. Then you check if there IS a ground object from the previous step, and you simply add the object's movement vectors to the player's position. This can be done without needing a specific "moving parent object" as is likely included in your build of DASH and will depend on how the object is moved. If you're using hspeed and vspeed you can simply apply those, but you can also use the numeric difference between the object's previous and current positions (ie. x-xprevious). If you use the later, you'll want to place the object's movement code somewhere before the step event so the player isn't lagging behind the object's movement. Lastly, any translations you do to the player's position should be floor'd (floor( x )) so the player doesn't 'slide' while standing on the platform. All of it should look similar to the following: if (ground!=noone) { x += (ground.x-ground.xprevious) y += (ground.y-ground.yprevious) }

(big image) Levels like this have existed as early as Labyrinth Zone, but levels of this type are Scrap Brain Act 2, Metropolis Zone, Marble Garden Act 1, Ice Cap Act 1, Sandopolis Act 2, and Sky Sanctuary Zone. Sonic 3K just loves its Y Axis. There's a lot of benefits to this type of level design. No Boundaries: There's no limit to how far levels can go vertically in this scenario. Water zones love abusing this by having endless Y Axis "sections" to simulate a water slide. Other zones may use this because they're a vertical climbing based level (Marble Garden, Sky Sanctuary). This type of level design is also good for maze labyrinths (Scrap Brain 2, Metropolis, Sandopolis 2), as the mazes can become ridiculously complex and difficult. High Routes, Low Routes, Average Route, How about None: Instead you get every route being the same degree of fun level design no matter where you end up. As said before, Sonic 3 already chunked that concept out the window. Only one real complication: Which is your problem, not the players problem. The issue lies that the bottom of the levels map must be able to perfectly align with the very top of the level map on the Y axis. This requires some careful planning on your part. I would advise if you're drawing out the layout on paper first, to draw a bit of how the level will flow on the top of the map, at the bottom of the map as well, and vice versa at the top. So basically you're redrawing part of a level twice on the top, and the bottom of the map, so you can know what part connects where. If this isn't giving you a good mental image, just look at how it's done in Metropolis Zone Act 1. Actually there's another: I have yet to see levels like this in fan games. I'm not sure if there's technical difficulties behind this, but if you're a fan gamer rather than a hacker, you might be out of luck here. Biggest mechanical limitation is correctly representing objects that are not static on both ends of the loop. That is a functionality that was already integrated into the original genesis hardware that freeware game making suites such as MMF2 will have a hard time replicating due to the level of abstraction. If you don't mind not having ANY possible moving objects near the edges of the loop, there are viable workarounds to everything else... at least, in Game Maker.

AFAIK, ProSonic is not dead. Saxman's just taking a long breather. If you dig around Retro, you can find the release thread and dick around with the source code yourself. Hope you can make something cool with it.

Happy birthday, good sir!

Some versions of DASH are really bloated and hard to run on low-end computers. If this one doesn't show improvements for you, though, you've got problems. =(

I don't find bigger pupils very stylish. If I had to pick one though, it'd be pink.

Specs: Microsoft Windows 7 Ultimate Edition Service Pack 1 (build 7601), 32-bit Intel® Core2 Duo CPU T6500 @ 2.10GHz 3.36 GHz CPU Speed 2.1 GB RAM Mobile Intel® 4 Series Express Chipset Family Recommended: (For 60 FPS or better) Fantastic quality, 512x386; or Simple quality (any resolution)

Game Maker 8.0 only, because I'm stubborn.