Topics I've Started

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

Basically, my lovely, precious, shiny, smooth white Dreamcast has been slowly deteriorating over the last few years, and has finally gone bang. It's not under warranty any more, and I don't want to have to hunt for yet another one.

So I've been looking at Dreamcast emulators, and have found a few with varying results:

NullDC: I've heard this is the best one, but I just can't get it to work. At all. I have working Dreamcast BIOSes, but they're apparently "too large". Some other files are not found, and apparently don't exist anywhere.

Makaron: I can't get this one to work either. It causes an "Open error" when trying to open the BIOS. Since the filename and path are correct, it leads me to assume that there's something wrong with the BIOS. However, the same file works fine in

Demul: I can get this one working just fine. The problem is, it's slow. Painfully slow. And it has a few problems when it comes to deciding which polygons should be in front of which. I've tried following various sites on the internet, but all it seems to do is make it look worse without affecting the speed at all.

I understand that Shenmue and Sonic Adventure are fairly hard to emulate accurately, but these are practically a must.

If there's any more information you need, I'll happily provide. I'm basically just looking for either ways to make the above emulators work, or another emulator. I may have to up/downgrade my computer, or I may have to wait until the emulation quality steps up, in which case I'll probably buy another Dreamcast.

I just want my Chu Chu Rocket.

EDIT: Shit, I thought this was General Gaming. Please move if it's more appropriate there.

Don't get me wrong, I love watching Upthorn & co. glitch the hell out of the Sonic MD games and achieving crazy speeds, but I'd also like to see how fast the games can be completed in a way the designers intended. Anyone know where/if I can find these?

Almost a year ago, I posted a YouTube video showing a PAR code for S3 that changes Sonic's palette into one that resembles Ashura (here). The following day, I posted another YouTube video showing some of the other variations I'd developed along the way. One of these was a Red Sonic.

Before posting the video, a search on both Google and 7metasearch for "00380A:E006" gave no results. Now it seems to be all over the Internet. As most people in this community will know (or can easily find out), this isn't the code for the "actual" Red Sonic. However, lots of websites now claim it is.

While pleased that the code has been recognised, I'm annoyed that it has been associated with the real Red Sonic code, which makes the game think you're Knuckles for certain objects and bosses.

If I could remove the code, I probably would. I was just wondering if anyone else had any similar feelings.