DigitalDuck

Level editor is planned for the future but I wanted to release in stages for a similar reason - if I just tried to put everything I wanted in the game all in one go then it'd never be done. I do have an implementation of colour clash but I decided not to include it in the end as my version allows for guardians to overlap level cells and I couldn't make that behave in a way I was happy with; it wouldn't be sustainable with potential future goals anyway. I'll definitely get a Linux build sorted in the next week or so, I don't have access to the computer Redux is on at the moment.

I think the fact that it says "We must perform a Quirkafleeg" confirms it's deliberate. I bet someone could build a map based on the label, there's a lot going on there.

In some of crem's routes, there are a few times when extra unnecessary jumps are done (these don't cost score as they come before waiting on a guardian to move out of the way anyway); a good example of this is in The Vat, where there's an unnecessary jump while following the pink kangaroo (as there are more than a few frames of waiting in that cavern, I think I walked Willy further to the right first instead).

Mostly, but not quite - for example, jumping slows the game down a bit, and it's faster to wait a game step if it means two fewer jumps; however, there were no cases where that tradeoff was actually needed. Some of the caverns were re-routed to minimise jumping, and in at least one cavern I collected an item earlier just to remove it from the game updates to save a frame. (Remembering which one is harder when it was the best part of a year ago.) In any case, in all cases apart from the three caverns listed (the first Kong Beast level is actually significantly more than one frame - the entire right side of the level has to be climbed and descended again) it doesn't conflict with the maximum score goal, so you're right in that there shouldn't be any issue there.

That just makes it even more complicated! If you want to do it manually, you're welcome to. It's worth noting that the whole run is different in terms of inputs (mainly because the goal is slightly different - real-time speed vs. in-game score), but obviously there's a lot of overlap between these goals and therefore in the routes, so it shouldn't be too much to tweak.

Yes, I have this program (it's a great way to be able to watch individual routes, and thanks to Norman Sword for making it). If you download the .bk2 file linked and extract it using any unzipper (it's actually a zip file), one of the packaged files is called Input Log.txt and has lines that look like this: |......................................................................|.....|.....|.....| |......................................................................|.....|.....|.....| |.......................O..............................................|.....|.....|.....| |.......................O..............................................|.....|.....|.....| |.......................O..............................................|.....|.....|.....| |.......................O..............................................|.....|.....|.....| |.......................O..............................................|.....|.....|.....| |......................................................................|.....|.....|.....| |......................................................................|.....|.....|.....| |........................P.............................................|.....|.....|.....| |........................P.............................................|.....|.....|.....| |........................P.............................................|.....|.....|.....| Each line represents one video frame (at ~50.02Hz), and each column represents an individual input (most of them are keyboard keys, shown by a . when not pressed and a different character when pressed; the three groups of five at the end are joystick inputs). This small section tells me that I pressed nothing for two frames (about 0.04 seconds), pressed and held O for five frames (about 0.1 seconds), pressed nothing for two more frames, and then pressed and held P for three frames (about 0.06 seconds). This could be converted into the same format as before fairly easily; just condense the relevant inputs in each line so this would become: . . O O O O O . . P P P The issue is that Manic Miner doesn't run at one step per video frame, or even at a fixed frame rate - in this snippet (taken partway through Central Cavern) the inputs were only processed on the third, seventh, and tenth frames, meaning it would actually be: O O P The idea would be to take the original file, remove any line where inputs aren't processed, and then condense it, which can all be automated fairly easily. There are two issues with this: 1. Left/right/jump inputs are not processed while Willy is airborne even though the game continues to step through, but the format used requires these to still be accounted for. 2. Music/pause inputs are processed at an entirely different point in the game cycle (usually about two frames later). Because of this, I can't just remove lines where inputs aren't processed. In order to convert the format I'd need to find a memory address that changes every game step in very close proximity to the left/right/jump input processing; I then record the current inputs to file whenever this memory address changes and convert it, and we have everything exactly as needed. 1. Is there a memory address that changes every game step in very close proximity to the left/right/jump input processing? I tried using the air counter but that's about as far as away as you can get. 2. Alternatively, are the current step's inputs stored in memory anywhere (i.e. if Willy is walking left/right or has started a jump)? If so, I could just read them whenever the air counter changes. If the answer is yes to either of these questions then I can convert it pretty easily. Unfortunately a modified version of the game that adds either of these in isn't going to be helpful as it's likely to run at a very slightly different speed than the original game and therefore cause the inputs to become out of sync.

To be clear, it's not my video - the way TASVideos works is that you submit a "movie file" that basically encodes a list of button presses; because I'm using BizHawk, this is a .bk2 file, but a .rzx is also a movie file. Then it's verified by someone independently taking a copy of the game (obviously it has to be the same version) and playing the movie back to prove there's no funny business going on. I'll go further into depth on this, maybe in a new topic, when I have my JSW2 run published (I'm happy with the actual run but I need to provide a writeup for it). From what I understand, crem's algorithm is heuristic-driven, which means that rather than try every possible iteration for the entire length of the cavern, it only does so over a short period and then gives each state a score (which will likely be a function of items collected and some added checkpoints reached). If you were to try to brute force every set of inputs over the entire length of the cavern, it would take a very, very, very long time. A typical cavern takes about 500 in-game frames to complete optimally; each frame there are six different actions you can take (nothing, left, right, jump, jump left, jump right), so the total number of inputs to test is on the order of 6^500, which is a number with 390 digits. Granted, the actual number is smaller than this as inputs in the air are ignored, and deaths will cut a branch short, but it's still an unfathomably large number. By using a heuristic, you can periodically prune the tree, removing any branches that (seemingly) aren't making progress, or are progressing slower than other branches, to keep the number of possibilities to check much lower. The disadvantage of this is if you're keeping a history of (say) five seconds, you're going to miss if there's some secret in Central Cavern in which if you hold left for six seconds it automatically wins the cavern for you. So it's important to prune the right amount - too little and it never finishes, too much and you miss some optimal solutions. crem almost perfectly straddled this line - as it happens, the right side of the Endorian Forest required just a tiny bit more planning ahead than the algorithm was afforded. I would still say the algorithm won the battle though - there were a few caverns where I'd played through what I thought was optimal but scored lower than the algorithm, so had to go back and improve it. I wouldn't have known otherwise (and that's one of the reasons crem is listed as a co-author). If it helps, as I mentioned above the .bk2 file is already a list of inputs - it's just a case of working out when the game actually acts on them. I'm sure there's a way to automate that too but I'm not familiar enough with the actual internals of the game.

I can certainly do Linux. Mac requires a lot of extra steps because reasons but building to Linux is trivial enough.

That's not a bug - you get a temporary invincibility on starting the level in the Redux presets. It does allow you to cheese a few levels but I'm allowing them as pro strats. I don't have a Mastodon account so I don't know who you've been messaging but hopefully they're not too bothered by it. I'd have to have a think about how to do the same thing for Chuckie Egg - it's a lot more arcade-focused so I don't think infinite lives is the best solution. Perhaps having more of a focus on individual levels and having score/time/other targets to beat?

Here's v1.1; saves are fully compatible so it's safe to just extract this over your old version, or copy your save file to the new version, if you want to keep your progress. I'm not expecting to make another smaller patch like this, next time will be a more substantial update. Added: Progress is saved as you play, so now you can close the game and continue where you left off another time Input handling revamped, now supports controllers There is now a progress counter showing how many levels have been completed so far Final score screen now shows the preset game name just above overall rank After completing or quitting a game it now returns to preset/custom game screen instead of main menu General optimisations Fixed: Smith jump was one step too short One of the sprite options wasn't being added to the available list when unlocked Level version menu option could sometimes be highlighted and changed when greyed out Music volume wasn't set correctly on game load Probably fixed (these are hard or impossible for me to reproduce for various reasons): Deaths sometimes caused the game to freeze for a few seconds Game ran too fast at 120/144Hz Balance tweaks: Small modifications to a couple of levels to allow them to be completable in all modes Score rank requirements raised As always, any comments, criticism, bug reports, suggestions for improvements, heckles, and sharing of high scores welcome. I'll leave you with CPL's playthrough of this version: ManicMinerRedux11.zip

I've never actually used Gamemaker, I'd originally remade Manic Miner in MonoGame and then gave Godot a go and I think it's better for this. Having said that, Godot is only being used for rendering, sound, and inputs - the physics and collision detection is done entirely manually in code. If there's something in particular you need I can give some pointers but I think a large portion of it is either generic to every project, or too specific to Manic Miner to be applicable.

Yes, I think there's been a confusion in my wording - by "die" I meant "lose all lives". I don't think it's required to collect all items, just to reach the ending itself.

Glad you enjoyed it! I did think about having an option to turn on the GBA backgrounds for fun, but that seemed too cruel. I would've liked to bring the SAM version's enemies into the Spectrum style but that's far beyond what I'm capable of. Personally I find 30fps too fast - Manic Miner is all about precision and timing rather than pure "action", and I think the default 15fps works best for that; but everyone has their own preferences, which is why there are so many options. I did think about including a 60fps mode but that's obviously too fast. SAM levels on the Spectrum would still be a worthwhile project - this version obviously isn't running on the Spectrum, and not all levels are included (I didn't make an attempt to port the two Twilight Zone levels as they're... very non-standard). The extra notes are there because I felt some options needed explaining, but not having notes for all options felt empty so I figured it was an opportunity to have some fun. I do have a patched version imminent which fixes a few issues that have been brought to my attention and adds a few features that have been requested, but don't let that stop anyone from making more suggestions.

I've been a fan of the Miner Willy games for a while; I played the games as a child and didn't especially like it then, but after learning to speedrun them I found a new appreciation for them. Manic Miner is designed around score attacking (which for 17 of the 20 levels is the same as speedrunning it), and is more fun when you play it that way. Since then I've played basically every version of Manic Miner going and enjoyed most of them, and I was especially enamoured by how most versions add their own mechanics and levels. For the 40th anniversary of the game I wanted to write a love letter to the game in all its forms, and after experimenting with a few different ideas and tools I ended up remaking the game from the ground up in Godot. So here's Manic Miner Redux. It contains: 83 levels from various official releases of the game, including Spectrum, BBC Micro, Dragon 32, Game Boy Advance, Oric Atmos and SAM Coupe; levels almost exclusively use graphics from the Spectrum versions of Manic Miner and Jet Set Willy, but in terms of gameplay they should be near-perfect. In addition, 56 levels have slight variations fixing minor issues or making them fit a more general mold; 2 levels have major variations that basically make them entirely new levels; and there are 3 "fun" experimental levels thrown in for good measure. 3 preset modes; Original (Spectrum Bug-Byte recreated as accurately as I can), Redux Short (my preferred physics options and the same levels reordered with a few fixes and tweaks), and Redux Long (80 levels... good luck). Choice of music from the Spectrum, GBA, and SAM versions (or turn it off) Choice of Willy sprite, colour, and outline colour; doing well in the preset modes unlocks more options Lots of gameplay customisation Game speed is adjustable from 12fps (roughly Manic Miner Spectrum speed) to 30fps (roughly JSW2+ speed) Jumping, conveyor behaviour, and item collection behaviour can be switched between how it works in Manic Miner Spectrum ("Smith"), Manic Miner PC/GBA ("Noble"), or JSW2 ("Rowson"). Note that I haven't emulated the different turning behaviour or sprites of JSW2. Nasty collisions and fall damage can both be made more lenient, allowing you to "stand" on nasties as long as there is also floor present, or fall a further distance before dying. They can also be made to drain air instead of killing Willy, as can guardian collisions. Items can be made to be retained after death; Willy's spawn position can be set to the last safe ground he stood on; and there is the option for a JSW2+-style temporary invulnerability on entering a cavern or after death. Gameplay mechanics from other versions implemented: Forcefields that toggle on/off (BBC Micro) Horizontal level wrapping (Dragon 32) Diagonally moving guardians (Oric Atmos) Trampolines (SAM Coupe) Vertical conveyors (SAM Coupe) Ice (Spectrum, not used and probably unintended) Stairs (JSW) Future plans: If you look at any of the level files, you might notice that they're fairly easy to read and edit. At some point I'd like to add a level editing and sharing tool, but I currently don't have an idea of what that would look like and I don't have much free time to work on it at the moment. And of course I'd like to give JSW the same treatment. Any comments, criticism, bug reports, suggestions for improvements, heckles, and sharing of high scores welcome. EDIT: v1.1 released, check this post:

Sorry for the bump: Yes, I'm using the standard +e.22 version, as posted above. I believe you're only required to reach Central Cavern and die to get the WELL DONE screen, I don't think 100% is necessary. This marathon was one of the more fun ones and it's a shame we haven't been able to do another like it.

About time I made an account here, I think... So crem initially made these to help with speedrunning the game, and they were very useful for us in either confirming that our routes were optimal or finding new routes. I took crem's inputs and used them (in a modified form) to help produce a fully optimised TAS (tool-assisted speedrun; essentially completing the game as quickly as possible using tools like slowdown, frame advance, rewind/rollback, savestates etc.) which you can find here: https://tasvideos.org/5052M Anyway, in the progress of doing so I managed to save a single frame (i.e. score an additional point) on Endorian Forest - scoring 1841 points. This was due to some forward planning on the collapsing ground - I spend as much time as possible on it while climbing up and it results in one less frame waiting for it to disappear on the way back. This means the highest obtainable score for the Bug-Byte version is 39531 and the highest obtainable score for the Software Projects version is 39532.