It’s been quite a while so here’s an update post on the progress of the upcoming version 2.1 update for A Koopa’s Revenge 2.
I’d like to start by reminding everyone that this is largely a polish update, and not a content update. That means it’s focused mainly improving the existing experience, rather than adding new experiences. So no new levels, powerups, or cheats. I don’t want to get anybody’s hopes up.
I added quite a bit of visual polish with the 2.0 update, and those before it. But this update is going to go above and beyond in that regard. Almost every tileset is receiving a makeover. As well as many sprites and most of the backgrounds.
There’s a number of reasons why I’m doing this. Firstly, some of the art is just not up to the standards of the rest, leading to an overall lopsided experience.
Secondly, I made most of the game’s tiles with the expectation that they would be rendered in game as vector art. This resulted in many flat looks and simple shapes, as was necessary to render effectively. But at some point I realised that I would need to prerender the tiles and backgrounds to get a decent performance out of the game, so I rasterised them. But what I didn’t do was take advantage of the image complexity allowed by prerendered art. I just used prerendered verisons of the existing simplistic art. I’m correcting that now.
Thirdly, a fresh look will really justify the long wait for this update. I’ve had some setbacks, and suffered from the usual feature creep. Hopefully all this new art will make the wait feel justified.
Fourthly, a great deal of the game’s artwork was made with the intention of replacing it with something better later. But as time wore on I simply got used to the subpar art. For example, the Hammer Toads didn’t really look like Toads; the details were all wrong. Let this be a lesson to always use absolute dogshit art for temporary assets, lest one get used to them and publish a plain looking game.
And fifthly, some of the art has simply been reused to save development time. Many levels have the same background, and some separate level themes use the same tileset. The second ghost house looks identical to the first, the forest ground tiles are the same as the plains ground tiles, and the switch palaces all look identical. This will be remedied in the update. This in’t 1992, saving memory isn’t an excuse to reuse assets, only deadlines and laziness are. The deadline has long since passed, and I don’t want to be lazy on this any longer, so it’s time for an upgrade.
From time to time, I get complaints that the game’s control is ‘slippery’. This consistently appearing criticism has always confused me, as the game has very high friction for the player character. But as a general rule, when people describe what they don’t like about something, especially something as subjective and lacking in strict vocabulary as gamefeel, there are bound to be misunderstandings.
What I think these complaints were getting at is the player accelerates too fast. Which in my mind is the opposite of slippery. But I suppose it can be thought of as trying to hold onto a slippery bar of soap, whereas when I describe a game’s controls as slippery I mean it feels like the player is always subjected to ice physics.
I finally made this connection when I was switching back and forth between testing AKR2 and playing Super Mario Maker 2 (which I play too much of by the way, currently ranked 20th in the world for normal endless challenge). Koopa’s controls are much tighter than Mario’s. Koopa can jump running right at full speed and land to the left of where he started. Mario can’t come close to that. I always considered this a good thing, because you have more control, but I can see how that rapid acceleration might be overwhelming, or create an incongruous feeling.
To fix this disconnect I cut the player’s acceleration in half. It now takes twice as long to get to full speed from standing still, bringing it more in line with the mechanics of modern 2D Mario. This isn’t without its drawbacks though. Objectively speaking you have less control over the player now, but I think slowing things down somewhat paradoxically makes it easier to control. I also have to make some other changes to the physics and controls to compensate for slower acceleration, mostly relating to walljumps, though shell sliding will also be affected. (Side note: speedruns will probably be slower, but there might be some neat speed tech created as a result.)
The biggest drawback to these changes will be extensive testing (this is why I’ve been so reluctant to change things until now). I’ll need to do another thorough beta test to be sure the game is even beatable with a slower acceleration. In my own experience so far, the game isn’t that much harder because the top speed is unchanged and the player can rely on momentum to carry them through most levels, much like official 2D Marios. But many areas, particularly twitchy and vertical areas, will need to be tweaked. It might be somewhat jarring for those used to the lighting fast acceleration, but it feels more natural this way and I’m sure we’ll get used to it.
So I will likely need to start another beta to get some feedback on the new physics. I probably won’t include Boss Rush at first, because the new Yoshi King boss isn’t ready yet, but all the graphics changes so far should be included.
As a bit of a segue here, there’s a quirk/bug where when jumping into a wall, upon reaching the top of the wall the player is given a burst of speed if they tried to move into the wall during the jump. I hope that makes sense. This has been a long standing issue (which further adds to the slippery bar of soap feeling) that I just couldn’t pin down until now. Turns out the walljump code was the culprit. The code that allows you to cancel sliding down a wall wasn’t checking which direction you were pressing, so you could in effect detach from the wall at half your max speed, but move horizontally toward the wall allowing you to keep that speed at the height of your jump when the wall was no longer in the way. I don’t think anyone cares about this nearly as much as I do, but it feels good to get it fixed.
Why don’t I fix the bugs with a smaller patch? Well, due to my own poor planning throughout the project, doing a hotfix is a major pain in the ass. I have no discernible version control. I periodically backup the game, but that’s it. So to fix the bugs I would either need to upload everything I’ve changed since the last version, or go into an old backup and fix them again. And frankly, non of the current bugs are a big enough deal to make that worthwhile. I’ll just have to tolerate getting the same bug reports over and over.
I could go through the entire game and make the code more professional and efficient, but at this point I’d like to put it behind me, and adopt better coding practices for future games instead.
The beta should be available sometime soon. Though it’s not going to be pretty. If you play it, you’ll be doing me a favour. Testing is work, and the experience won’t be pleasant, as the game may be broken. I want to make that clear upfront.
As for when the update is released proper, who knows? I keep finding things I want to alter, so the deadline keeps moving further into the future. This will be the final update (barring major bugs and compatibility issues) so I want it to be a good one. The best I can say for a release date is 2020, probably.
I’m also considering making the Goomba and Shy Guy skins available outside of Lambta.co and Newgrounds. This was originally a ploy to drive traffic to my new site, and it worked. But the “death of Flash” and the decline of personal websites are making it harder to justify, especially for people playing outside a browser.
On a final note, I’m considering changing the version number from 2.1 to 2.5. It’s become bigger than I originally intended, and I think a larger increase is justified. Probably going to do this.
That’s all for now, fellow nerds. Smell ya later.