Original post follows below:
v0.1: DOWNLOAD
Controls - as Sonic 1, plus:
- down+A/B/C while standing: Spindash (Sonic 2)
- up+A/B/C while standing: Peelout (Sonic CD)
- up while rolling: unroll
- down or A/B/C while airborne: curl in air
- A while paused: regenerate level (only loses progress since last checkpoint)
------------
About S1RL:
S1RL: Random Levels Project is a hack/mod of Sonic the Hedgehog that allows the game to generate its own levels in real-time. Other changes have been made with this in mind: Sonic's moveset is now tailored for maximum control rather than risk/reward payoffs; acts are much longer than usual; the timer now shows hours, minutes, and seconds, and the time limit has been extended to 24 hours; the life system has been removed entirely, with any death resulting in going back to the previous checkpoint; the camera moves in front of Sonic to reveal more of the level ahead; checkpoints trigger when going past them at any height; and there are multiple palettes to each level that change either with time or with a monitor. There are also numerous other minor cosmetic changes and bugfixes.
S1RL contains a number of monitors additional or changed from the original game.
- Static: changes the level palette
- S: gives both invincibility and speed shoes
- Eggman: hurts Sonic
- Sonic: produces a number of rings
Code added to the game was written in 68k ASM. Data added to the game was first produced by a program written in C#, and then tweaked by hand.
This is version 0.1. Only Green Hill Zone is playable in this version.
------------
Development backstory:
The idea for this hack first came about in 2009. I was writing a maze generator and experimenting with tiling patterns and fitting different types of tiles together with different rules, and I wondered if the same could be done with the large chunks in a Sonic game. In 2010 I tried with limited success, getting Sonic 2 generating usually traversable levels in this way in the timespan of ~12 seconds. However, the levels weren't frequently traversable enough, nor was the generation time low enough, for myself to consider it a success. At the time I was also suffering a nasty breakup as well as needing to focus on my Games Computing degree, and the stress of it all left me abandoning it entirely for a while.
For my Final Year Project I chose to study real-time adaptive track generation in racing games, creating a racing game which dynamically produces a road ahead of the player tailored to their driving style, and writing a dissertation about it, complete with user testing showing its effectiveness. It was successful enough that I was asked to cut down the dissertation into journal paper format and submit it to GAMEON'2012 with help from my supervisor.
During that time I read a lot about procedural generation, took a thorough look at how other games used it and how well it worked, and began forming new ideas about creating random levels in a Sonic game. Gone was the original tile-based generator, replaced with a strip-based generator instead. Objects could and should be attached to chunks that they're not contained in, and even in entirely different strips, provided it makes sense for them to be there. Strips that are otherwise the same can be duplicated to allow object placements that prevent certain tile placements, making the objects as much part of the level generator as the terrain.
However, I couldn't work on it in any serious capacity. I was too busy applying for jobs and attending interviews (and not getting the jobs), working with a team and a publisher as my own company to produce a shmup (and getting rejected by the publisher), spiralling into a depression at the first two not going anywhere, getting a new girlfriend, and working on my own mobile games - I still intend to make this professional when I eventually find software I like. I had a few small attempts at it; inspired by Sonic Runners in 2014 I recreated the boss and playstyle, testing the infinite-level concept in S128, along with using strips that were 8 chunks long and tall and attempting to tile them correctly. I also made a quick prototype of S1RL towards the end of 2015 and... it was a massive improvement over my 2010 attempts.
But after simply not finding any engine up to snuff, I got stuck in a rut again. I still wanted (nay, needed) to code, and the focus shifted back to S1RL. I had no distractions. Studies were over, job well was dry, relationship was stable, and mobile games were going nowhere. So I dug deep into 68k (I'd learned it previously, but only with frequent reference to an instruction list), learnt how the game engine works, which parts needed to change and how, and plugged away at it. I didn't manage to do everything I wanted to, but I'm happy enough with the results to release it now. Of course, I'm going to continue working on it...
------------
How you can help:
This hack is far from finished, and certainly not bug-free. Reporting anything you feel shouldn't belong is appreciated, even if I've already been made aware of it and it's in the list below. What I find particularly important in this case is identifying any problems with the generated level - perhaps two strips are joined together incorrectly, or perhaps two objects are overlapping when they shouldn't be. Because of the nature of the hack, I will not be able to fix these without a savestate in the affected area and a full description of what's wrong and how it should look.
Known bugs:
- Objects respawn after hitting a checkpoint. This is not so much a bug as a workaround; I couldn't figure out the OPL routines, so I chose to have objects consistently respawn rather than unpredictably despawn/respawn/not load in the first place.
- Checkpoints sometimes load already activated, causing the level beyond to stop loading. I'm not sure what causes this, but regeneration (start+A) usually fixes it.
- Signposts sometimes load earlier than they should, with corrupted graphics and typically causing death shortly after touching it. Again, I'm not sure what causes this, but regeneration (start+A) usually fixes it.
- Demo does not lock Sonic's controls and cannot be ended with the start button. (fixed for next release)
- Dying with speed shoes causes music to stay at the faster speed until more speed shoes are collected.
------------
Credits:
Original game by SEGA and Sonic Team
Modified by Digital Duck using the Sonic Retro disassembly with great help from the SCHG How-to guides
Special thanks to all involved in making the disassembly and guides