[DigitalDuck]

v0.1.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)

------------

So, it turns out I got my dates wrong and I'm actually away this week. Today's pretty much the last day I can do anything for a while so I've just built what I have.

As far as generating the data on my end goes, Green Hill Zone is 100% stable. I can make changes without the whole thing breaking now. I've made a few changes to the structure of the data and it's a lot easier to fix things as a result.

The generation in ROM may not be 100% stable, but it should be better than it was. I tested Preset A at 13km and the whole thing worked without problems, so there is at least a fully stable level this time.

Labyrinth Zone is going slower, and still fails to generate anything resembling a level so I've removed it from this version. I'll keep trying, but there are some significant problems that aren't trivial to fix.

------------

New features:
- Full options menu, with ability to choose between random and fixed-seed generation, different level lengths, different cameras, turning on/off certain monitors, starting palette, and how it changes over time, and turning on/off the music.
- Distance counter to keep track of how far you've travelled.
- Four-digit ring counter.
- Goggles monitor. It does nothing.

Fixed bugs:
- Checkpoints no longer load already activated, so no longer prevent the level beyond loading.
- Signposts no longer load earlier than they should.
- Demo no longer locks Sonic's controls and can be ended with the start button.
- Invincibility music plays when collecting the invincibility powerup.
- Ring counter no longer overflows.

Known bugs:
- Dying with speed shoes causes music to stay at the faster speed until more speed shoes are collected. Invincibility music also continues after death.

[Chris Highwind]

Nice, just downloaded and ran through a random 500m and 1.7km level, and it feels a lot more varied now.

[Brainulator]

You left the Internet for a week one day after me. Teehee.

Will have to check out!

This post has been edited by Brainulator: 22 July 2017 - 05:49 PM

[DigitalDuck]

Status update:

As expected, not much has happened development-wise recently, but I'd still like to keep in the habit of updating regularly. I've been making the most of my time off before more work gets dumped on me later this month, so almost all the work on S1RL has happened in my head rather than in code.

One thing I'd really like to get in for next time is playlist functionality. Choose which songs you want to hear, and the game will switch between songs as you play. This much is already implemented, but I'd like to port music from other games (because 17 tracks isn't much, especially when nine of them are non-looping jingles and one is invincibility), and also have some sort of display that tells you what's playing.

I'd like to dripfeed a few more monitors into the mix as I go too. The aim is to not have the monitors deviate too much from what's already in there, but just add more variety to the way the levels are played.

When I get back to working on it, the biggest focus will of course be on getting Labyrinth Zone levels randomly generating correctly. But there are other things I want to add too, because it's still missing a lot from a game design perspective, so there should be a lot to look forward to.


I've been doing speedruns of the game, partly for the sake of testing, and partly because I can learn the route playing on my phone on the train.




500m - 00:47
900m - 01:22
1.7km - 02:46
3.3km - 05:28
6.6km - 11:14
13km - 21:22
9999 rings - 49:39

All were done using Preset A so I could learn where certain types of monitors are (or at least the ones I can reliably hit). I have only speed shoes and special monitors for the distance trials, and only shield and Sonic monitors for the ring trial.

I also have video of the last two as I did them on stream a few days ago. I could've been faster for the ring trial but I was dicking about with the glitch by the breakable walls.

[Brainulator]

https://drive.google...LW1ZbzlUOVU3RzA

I encountered this error, apparently. Also, I hate to be that person, but "General Optons."

[DigitalDuck]

Brainulator, on 25 August 2017 - 02:04 PM, said:

https://drive.google...LW1ZbzlUOVU3RzA

I encountered this error, apparently. Also, I hate to be that person, but "General Optons."

I swear I fixed that.

Yes, General Optons has been pointed out to me. Would've been nice if you guys had done it when I showed the screen three months ago, though.

[DigitalDuck]

Status update:

So you may have noticed things have been quiet on this front for... a long time. A lot has happened, and it means that I've been unable to put much time into this at all.

I was coerced into doing a PhD and then dicked about so much by the administration I fell into depression, and eventually had to quit. In the meantime my main computer suffered a Microsoft "user experience improvement" (a.k.a. they bricked it with an update) and getting set up on a new computer (running Mint) took whatever free time I had left. I've been trying to get a house with Mrs. Duck and been dicked about by estate agencies in the process, which hasn't helped any of it. I then got a series of freelance jobs which resulted in nothing because apparently the cool thing to do is to ask someone to fix your code without giving them the bit of code that's broken, and then blaming them when they need more.

I've been doing small amounts of work here and there on S1RL but it's been difficult to get motivated, especially when it seems Labyrinth refuses to create workable levels of any kind. As it stands I don't think I can do Labyrinth Zone in this manner, and the whole thing seems pointless if I can't do different types of zones. The problem seems to be with the way Labyrinth's tiles fit together - for Green Hill, only a small number of tiles can fit together and it creates this organic, dynamic landscape. In contrast, Labyrinth is very blocky, and rather than the tiles dictating the level design, the level design dictates the tiles. This makes it a very different problem to work with.

So for all intents and purposes, S1RL is dead. It requires a paradigm shift to work with different types of zones, although I'm sure what I've done could be transferred to e.g. Star Light, Emerald Hill, Hill Top, Chemical Plant, Aquatic Ruin, Angel Island, and Mushroom Hill as they all have similarities in the way things are laid out. If that paradigm shift hits me I'll be inspired to work on it again but I'm not going to make any promises on that front.

***

However, that doesn't mean Random Levels Project is dead - far from it.

So far, I've taken a console with 7.6MHz processor, 64KB of RAM, and a game which (at the moment) can only be edited in 68k ASM; and used it to generate levels for Sonic the Hedgehog, in real time, and faster than the original game could even load them. And sure, I've found myself at a dead end. Without a faster processor I can't do more exhaustive pathfinding to check levels are completable; without more RAM I cannot let the game create its own tiles; and without a modern programming language and one that's more familiar to me, I'm prone to slower progress and more mistakes.

But who's to say I can't have a faster processor, more RAM, and a modern programming language?

When I started work on this in 2009, there were really only two options: recreate Sonic myself and code a random level generator within it, or modify the original game's code. And although I did end up recreating Sonic physics (and I'll eventually put that to use once I find a general workflow I'm happy with, which at this rate will be never), there was a certain attraction to the idea of making it run on the original Mega Drive.

But I've done it now. That attraction is no longer there. Not only that, but while I was iterating on the processes that lead to S1RL, other things happened in the Sonic community. S&KC became much more moddable; Sonic CD, 1, and 2 were remastered for PC; Sonic Mania was released; and things like Sonic Maker are in development too.

So what do you guys think? Is this only of interest to you because it runs on the Mega Drive, or should I actually learn how to mod PC games for once? Would you rather random levels in S3K, Mania, or a new game entirely? Or should I just do something else with my life because nobody gives a shit about this?

[MainMemory]

I would absolutely be interested in a Mania mod, S&KC mod, or something with Clownacy's Sonic 2 port. I could definitely help you with S&KC if you choose to work with it, but I'm not super knowledgeable about Mania's internals.

Also, you should add an Emerald hunting mode.

This post has been edited by MainMemory: 24 May 2018 - 04:22 PM

[HedgeHayes]

I understand you, I'm both prone to develop methods to produce results that make sense through randomness, and someone that has had that "paradigm shift" issue. My advice would be to take a new project (or a new platform for your project, in this case) and return to S1RL when you find again the will to work on it and the inspiration that allows you to solve the issue with labyrinth; it usually ends up happening, but it can take really long, so it's better to refresh your mind and learn more from other projects in order to get past that obstacle.
As a minor suggestion, since I don't know how does the hack work internally (and still nothing about MD hacking in general), I'd say Labyrinth needs a lot of tile boundary checks to compare heights of adjacent tiles, and controlling beforehand which tiles can connect with the ones already added through collections or a table with the info could get you away with it. Of course, I don't know if Mega Drive can do that or if you already tried (which I'm afraid you did), but this kind of risk control is a basic step to create random maps, specially if we're talking about a "labyrinth".

[DigitalDuck]

MainMemory, on 24 May 2018 - 04:21 PM, said:

I would absolutely be interested in a Mania mod, S&KC mod, or something with Clownacy's Sonic 2 port. I could definitely help you with S&KC if you choose to work with it, but I'm not super knowledgeable about Mania's internals.

I forgot about the various ports in-progress, they're potential avenues too.

I know S&KC kinda tries to emulate various parts of the Mega Drive; I'm guessing you're not still restricted to 64KB of RAM though.

I'm definitely not going to do anything with Mania just yet - I think it'd be pointless to try and work on it until it stops receiving updates and patches; would be interested in doing it, though.

MainMemory, on 24 May 2018 - 04:21 PM, said:

Also, you should add an Emerald hunting mode.

No.

HedgeHayes, on 24 May 2018 - 07:50 PM, said:

As a minor suggestion, since I don't know how does the hack work internally (and still nothing about MD hacking in general), I'd say Labyrinth needs a lot of tile boundary checks to compare heights of adjacent tiles, and controlling beforehand which tiles can connect with the ones already added through collections or a table with the info could get you away with it. Of course, I don't know if Mega Drive can do that or if you already tried (which I'm afraid you did), but this kind of risk control is a basic step to create random maps, specially if we're talking about a "labyrinth".

I am in fact already doing both! The data used for generation is essentially a list of strips of tiles that say which strips can go next to it, and I'm comparing heights of adjacent tiles to generate the strips and determine which tiles can go next to each other. The problem is that e.g. there's absolutely nothing to say an empty tile and a completely filled in tile can't be next to each other, and in many cases it's preferable that they are. If I don't allow them to be next to each other I get bland levels that don't go anywhere, and if I do allow them to be next to each other I start in a box and can't go anywhere.

What I need in order to solve this (as it stands at the moment) is pathfinding. Unfortunately pathfinding can't be done on an individual strip basis, so I can't do this offline and store it as data - it has to be done as the level is generated on the Mega Drive. And pathfinding is slow. Maybe it could be implemented more quickly by someone better than me, but I'm not nearly proficient enough in 68k ASM to do that.

[MainMemory]

S&KC emulates the MD's 68000 RAM, VRAM, and palettes, but within your own code you can do whatever you want, as long as it ends up in a format the game engine can use (unless you want to rewrite that particular part of the game engine). You also have a lot more free CPU time to do whatever you want; the game instantly decompresses all compressed data and never seems to drop frames in the process, whereas the MD games had to do it in pieces.

I can definitely agree with waiting on Mania. Also, I don't know if this would make it easier or harder, but Mania uses 16x16 tiles instead of 256x256 or 128x128.

[DigitalDuck]

MainMemory, on 24 May 2018 - 10:47 PM, said:

S&KC emulates the MD's 68000 RAM, VRAM, and palettes, but within your own code you can do whatever you want, as long as it ends up in a format the game engine can use (unless you want to rewrite that particular part of the game engine). You also have a lot more free CPU time to do whatever you want; the game instantly decompresses all compressed data and never seems to drop frames in the process, whereas the MD games had to do it in pieces.

Looking at the RAM layout of S3K, it should be no problem to store most of the level-related stuff outside the MD RAM area and just hotswap in the parts I need.

MainMemory, on 24 May 2018 - 10:47 PM, said:

I can definitely agree with waiting on Mania. Also, I don't know if this would make it easier or harder, but Mania uses 16x16 tiles instead of 256x256 or 128x128.

Makes almost no difference. If I need 16x16 tiles I can break a 128x128 tile down into smaller parts, and then create new 128x128 tiles; if I need 128x128 tiles I can group together a set of 16x16 tiles. The generator can use whatever size tile I want (technically S1RL uses 256x4096 size tiles...), it's just a matter of making sure the generator outputs it in the format read by the game, which is trivial given loose enough memory and CPU constraints.

[HedgeHayes]

DigitalDuck, on 24 May 2018 - 09:54 PM, said:

I am in fact already doing both! The data used for generation is essentially a list of strips of tiles that say which strips can go next to it, and I'm comparing heights of adjacent tiles to generate the strips and determine which tiles can go next to each other. The problem is that e.g. there's absolutely nothing to say an empty tile and a completely filled in tile can't be next to each other, and in many cases it's preferable that they are. If I don't allow them to be next to each other I get bland levels that don't go anywhere, and if I do allow them to be next to each other I start in a box and can't go anywhere.

What I need in order to solve this (as it stands at the moment) is pathfinding. Unfortunately pathfinding can't be done on an individual strip basis, so I can't do this offline and store it as data - it has to be done as the level is generated on the Mega Drive. And pathfinding is slow. Maybe it could be implemented more quickly by someone better than me, but I'm not nearly proficient enough in 68k ASM to do that.

Well, I didn't know about the strip system but I get the rest. In fact, pathfinding would have been the next thing I could suggest, but maybe it can be done at a smaller scope so you don't overload it. Having three strips of tiles (main, over and under) generated at different points (a quarter? a half of the main one?) could allow for more chances to avoid a closed room, and you could generate those strips relative to Sonic's curent height so you can change which is the main one, allowing for twisting passages and keeping stored only the built strips, not an increasing number of them. Marking when the strip shift happens could control that if you're memorizing the whole path no matter how long it is. For example:

[Strip 0] ······· /-> Above // ··········· /-> Main · // ··········· /-> Under // ··········· /-> Main
[Strip 1] · 0 m. -> Main · //-> 150m. -> Under //-> 400 m. -> Above //-> 720 m.-> Under
[Strip 2] ······· \-> Under // ··········· \-> Above // ··········· \->Main ·· // ··········· \-> Above

And so on. This won't fix the issue entirely unless, if possible, you design very carefully the strips you use. I don't know how bland they could become this way, and still don't know if it's possible at all, but it's the first thing that come to my mind to try a change.Btw, bad news for me that I'm making mine your problem, I'd love to solve this puzzle but I should mind my own businesses first. //forums.sonicretro.org/public/style_emoticons/default/psyduck.png
Edit: forum ate many blank spaces, had to try something different to format my example.

This post has been edited by HedgeHayes: 25 May 2018 - 08:36 PM