Thwimbly - Kepler's Platformer Dev Thread

[KeplerElectronics]

​

Howdy everyone!

I've seen some gamedev threads here on the forum and really enjoyed reading through them as a hobbyist game dev myself. I've been toying with making one myself, and figured that, now that the demo is out, I should just go for it.

Thwimbly has been in development off and on since summer 2021 based on what's been going on with school and stuff. It's made in TIC-80, a fantasy console (similar to PICO-8), which aims to limit the developer on various metrics (number of colors on screen, number of sprites, music, map size), and I've been using every trick in the book to break past those limitations. I've really been trying to design the game so it doesn't feel like a tech demo or normal fantasy console game.

​

The game itself is a pretty standard 2D platformer, but I've tried to optimize it for the kind of game I like to play: Fast paced, colorful, and fluid. I've had a lot of fun trying to optimize routes through each level to beat them as fast as possible. It's particularly inspired by Kaizo Mario World and Celeste, but with a simpler moveset on the player side.

Hopefully it lives up to that goal, but a lot of the reason for the demo release is to try and get an idea of what might need to be changed for a full release. This is only about 1/7th of the content in the full game, but I think it's enough to get the vibe across.

If you want to give it a try for yourself, you can play it in the browser, either at my website: https://keplerelectronics.com/Wiki/Thwimbly

or at Itch.io: https://kepler-softworks.itch.io/thwimbly

If you want to see some of what my development process has looked like, I have a bit of a devlog on my site as well (I need to update it soon -_-): https://keplerelectronics.com/Wiki/Thwimbly_Dev

Please let me know what you think, or if you run into any bugs! I'm open to constructive feedback, I want to make sure that all the time I've poured into this game is worth it.

 

[jadd]

This is really cool, although on my laptop the game slowed down gradually (including the music) when progressing through a level.

 

[kevin supermarket]

i got a similar slow down after dying a few times. the same thing corrected it, but it was still a little strange to have happened

 

[KeplerElectronics]

Huh, it's been fine on both my laptop and desktop but I guess I haven't done a full test of the web export. I'll start investigating that, thanks for the tips Kevin and Jadd!

 

[KeplerElectronics]

Just made a new version after doing some tests, but I think the web export is just having some problems. Even before starting gameplay it was just super sluggish. It runs fine when downloaded, but when attempting to run it in firefox on my laptop it's just super slow, even with the new low spec option I added. If you're on desktop it seems to run perfectly fine, probably just a significant performance penalty that my desktop has enough power to handle.

There are new downloadable versions that can be accessed through itch (https://kepler-softworks.itch.io/thwimbly) that seem to run significantly better on lower spec hardware, but I can only test on one laptop right now. It's running with a super stable framerate on my 2015 macbook pro (running KDE Neon linux) so it should be able to be played on pretty much anything from the last decade when downloaded, but I'm willing to be proven wrong.

I have a hunch that the slowdown @kevin supermarket was experiencing was from the particles building up upon dying to the munchers, so the new version reduces the life of those particles so they don't stick around as long.

This brings the official version number to 0.1.1, full changelog can be seen at https://keplerelectronics.com/Wiki/Thwimbly_Changelog.html

Please let me know if you have any more feedback :)

 

[KeplerElectronics]

I've been doing a lot of thinking about Thwimbly over the last couple days, and have come to the realization that I definitely need to pivot in some direction.

The game is closing in on being "feature complete" in the sense that most of the underlying mechanics are done, it's just pixelart, level design, and music that need to be completed. Realistically, I can probably get the rest of the game done in 100-200 hours of solid work, but with working full-time and trying to balance my other creative outlets and responsibilities, that could still be a year off.

This game is closing in on being in development for four years (sometime in June 2021 was when I started working on it). While I haven't been working consistently on it over that whole time, it's really been a part of me. it feels wrong to put it out in a subpar state after how much of my time and energy I've spent on it.

That brings me to the current problems, most of which are caused by the engine. It's a fantasy console, so it's trying to lock you into a set of limitations that mimic retro consoles (16 colors, limited code size, 256 tiles, 256 sprites, limited map memory, etc). This can be good, and helped a lot in the early days: having code/sprite/map editors built in was excellent for prototyping. The problem now is that the game can't be all that I want it to be because of the limitations.

Problem 1:
The audio engine in TIC-80 is too limiting. I'm limited to four channels, each monophonic. It's slightly less limiting than the original gameboy, as each channel can be any waveform including noise, but you're still effectively limited to gameboy sound. While there are a lot of phenomenal albums and tracks made on the gameboy (Spectra by Chipzel is an incredible achievement), those don't have to contend with sound effects.

If you've played the demo and picked up a bunch of coins in quick succession, you might have noticed that it sounded glitchy, that's because the sfx for coin collection is overwriting the sound on channel 3. I tried to mask it by making channel 3 the drum channel, but I think it's still noticeable.

Besides just chopping the music down to three channels and leaving one for SFX, I can't see an easy path forwards living within the engine. Music is one of my favorite parts of games, and I would like Thwimbly to have some bangers without getting overwritten by the .

Problem 2:
The map limitations are pretty rough. I'm currently limited to 28 levels of exactly the same length as those in the demo. I can make them shorter, but they can't be any longer because that's where the map size ends. I actually don't think that the levels are too short, I like how long they are, but it would be nice to have more of them. I really wanted to have a sort of "Master Quest" "Kaizo" mode that was super ultra difficult after the main game was complete, but I just won't have room for that without making a fully new executable or trying to encode level data in text and pull it in at runtime.

I'd like the game to be longer than 1.5 hours, but even if I make the levels pretty difficult, I don't think it'll take an average player much longer than that for a first playthrough.

Problem 3:
TIC-80 does not support Steamworks. I would like achievements for one, as I really enjoy hunting for them. This basically requires modifying the engine to overcome.

Big Solution 1:
Port the game to Löve2D. TIC-80 is Lua based, Löve2D is as well. Graphics calls and map data would be more complex, as primitives like lines, circles, triangles etc would need to be recreated, but this would effectively solve all of my problems in one swoop.

Löve2D also already has a library to integrate Steamworks, and is running LuaJIT, which is a much faster version of Lua that would help me squeeze more performance out of the current code without rewriting much of anything.

I won't be able to have a web app anymore, but the current web app is way too resource intensive anyways.

Big Solution 2:
Fork TIC-80 and compile a custom version that breaks some of the restrictions. If it's simple to just add on a couple more channels that I can route SFX to, even if I can't use or edit them for music, that would be great. Similarly, if I can't already just paste extra banks of sprites/maps at the end of the .lua file, breaking that restriction so I can would be great. Even if I can't edit those sprites in the engine, being able to copy them from a different project would be fine. Steamworks will have to manually be grafted on later.

Big Solution 3:
Just deal with it and stay true to the fantasy console limitations. I'm confident in saying that Thwimbly is one of the frontrunners in terms of high-effort games made with TIC-80. Emuurom is the other high effort game I'm aware of, and it would be cool to push the engine to the limits. Emuurom does have a Steam page, but does not take advantage of Steamworks or any of that stuff.

If I take this road, I'll have to trim back my musical compositions to allow an extra channel for the SFX, which could leave things feeling a bit empty (even fewer chords than I can do with 4 channels). I'll also have to lock in to 28 levels and just accept that.


The Road Ahead:
If any of y'all have any input, I'd love to hear it. Solutions 1 and 2 are probably going to require me commissioning or hiring someone to help with that process, so if you or anyone you know is interested in helping or can maybe even just give me an estimate of how long / expensive that might be, I'm all ears.

I'm reaching the desperation stage of this project. I need it to be done so I can clear out all of the brain RAM it's taking up. But I also don't want to release something I'm not proud of. The current web export performance problems and general audio problems are not something I'm proud of.

I also really should refactor my collision code, but the engine decision should really be made first.

 

[KeplerElectronics]

Currently too lazy to rewrite the engine or port the game to anything else, so I'll just go ahead with the original plan of sticking to the limitations. I might just distribute level packs as separate executables? anyways, scope creep can wait for another time.

I haven't been doing much lately on Thwimbly because my day job has become mostly programming and it's been really busy (like 60h a week busy, things are looking to slow down again and I am hype) but I suddenly got the motivation to break it open again tonight and wanted to share some screenshots!





World 2 is a spooky mansion/forest zone, with a number of gimmicks inspired by Super Mario World (including 1F0-type tiles that the player falls through but NPCs do not), and some less mario-y gimmicks that I won't spoil :)

Music has been in this world since summer 2023 or so. Very Henry Homesweet inspired. Definitely needs some more work, but it's one of my favorites of whats in the game right now.

I'm so heckin close to finishing this game, it's just level design and sprite design and music and overworld design remaining... at least the programming is pretty close to being done unless I actually rip out all the collision code and start over. I'm really hoping that sharing some of what's coming incentivizes me to put more time into it over the coming months. I'd really like to get this out before the year is done.

 

[KeplerElectronics]

doin some work on the platformer again

The main bottleneck is just inspiration with worlds 4-7 in terms of level design. I have gimmicks/mechanics implemented but need to figure out how to combine them into cohesive/fun levels that aren't brutally hard. My tendency is towards Meatboy/Celeste/I wanna be the guy levels of difficulty, and I'm trying to hold off on that for the moment. I'm thinking of Kaizo-hacking my own game once this is done, maybe with a new world theme... I've been thinking of some sort of cherry blossom/Torii gate/Edo period Japan themed level that I don't have room for in the base game.

...I've also been thinking of scope creep. (-_-)

Pushed a new update to itch today, getting rid of the web exports since the webassembly conversion takes way too much of a toll on performance. It runs fine in the browser on my desktop (ie. Ryzen 5 Titan XP beast), but it's basically unplayable on anything else. Local versions run fine though.

Download at https://kepler-softworks.itch.io/thwimbly if you dare :3

the new version features minor changes, such as a death sound effect and fixing a potential frustrating level design quirk in 1-2. I also got rid of the settings screen from 0.1.1

Wanted to share a look at what the tileset looks like for world 1. There's a fair amount of empty space (more than immediately obvious because most of the bright orange bushes aren't used anywhere anymore). If anyone has any ideas for things I could add to the tileset for this world using just the colors available in the bottom left, let me know :)



Also, here's what the world map looks like for W2. It could definitely use something, but I'm not sure what yet. more, different plants? pillars? better blending between the left and right halves of the screen?

Finishing the map and making it look decent is going to be a brawl with the tileset, since all seven worlds need to use the same graphics. I'm using palette swaps to switch between them as the player free-roams the map to match the graphics and palette seen in each world, but this part of the game definitely needs more polish.

 

[KeplerElectronics]

I've done more work on Thwimbly in the past three days than I've done in the past six months I think. it's not what I was supposed to be doing, but it is what I did (I have so much laundry and cleaning to do )

Some of that work will come out in the next update to the demo, but a lot of it is level design for the later worlds (hecking finally I have ideas for this thing). And what I've come to realize is just how much of a house of cards this game is code-wise.

Some of that is to be expected, with the game's first mechanics being programmed by me FOUR YEARS AGO in summer 2021. My only other major gamedev projects when I started this experiment were my Space Invaders clone Gravitaz (link to play in browser), and a twin-stick shooter I really want to get back to sometime. Neither of those games come even close to Thwimbly in terms of complexity. Gravitaz topped out at 1500 lines of code (though if I was programming it elegantly it should probably be closer to 1000). Thwimbly is currently at 6002 lines, plus some 1300 sprites (incl. dupes)? it's got to be close to a thousand hours into this thing at this point? 347 commits tracked in Github since I uploaded it in spring 2022.

Part of the problem with the house of cards is inheriting 19-year old me's garbage code practices. Thankfully I started the game with object-oriented principles so various entity types share a common data type (compared to Gravitaz where each projectile type is a completely separate code structure, adding to the bloat).

Thwimbly was also never supposed to hecking get this big, it was supposed to be a small project while I waited for the Picotron framework to come out. Between having too many ideas and Picotron not getting released till last spring, I had plenty of time to scope creep myself slowly enough that I wouldn't notice until it was too late. At this point I've basically capped out the amount of space in TIC-80, so thankfully there's a hard limit on how far I can scope creep, and the end is in sight.

Anyways, there is truly some garbage in the codebase. like the entity draw calls specifically avoiding certain entity types (all hard coded because of course they hecking are) because I need to draw them in a different way later. What I should have done was use some sort of layer system or flag to draw this entity type differently later, but at this point I'd rather not change it since it technically works.



also I've done 99% of the code in this low-res pixel editor because it's just way too easy to just Ctrl+R to run the game and test, then Esc to change a val and then repeat. It's super fast to iterate and honestly probably half the reason I've kept going as long as I have.

The thing that made me realize how "house of cards" this codebase is was attempting to make these jumping plant guys work with conveyor belts. here's a funny gif of me not realizing what the jump trajectory would look like.


please ignore the blurriness, I scaled this gif down because it was too large to upload otherwise.

Anyways, I don't have flags for groups and each entity is basically just running a script for just that entity type (i.e. no children anywhere ever, partly because this game was never supposed to get this big and partly because Lua does not support object oriented coding, you have to hack it in yourself). Because of this, using the conveyor to move all entities would move ALL entities. Only about half of the entities behave as expected when applying velocity. There's a lot of really messed up code in there for platforms, portals, static bouncepads, etc because I didn't realize how easy it would have been to organize things better.

What I ended up doing to make the conveyors work is to basically hardcode them to only work with these jumping plant guys. There's just not enough consistency in how entities behave when being given an x velocity to trust it to not implode.

I was originally planning on doing some sort of level design competition when the game came out, daring people to hack it and do all sorts of weird stuff with it, but there's just so many things like this where it only works in very specific contexts. this game was not meant to have minecraft-core inter-entity interactivity initially (try saying that five times fast). It's slowly moved that way over time, and me trying to stretch 19-year old me's code is causing me to cringe so hard because there are so many ways I could have made this more flexible and prevented so many headaches. It's like I was afraid of functions or something.

and like, I totally should cringe at my code from 4 years ago, it's proof that I'm learning and growing.

heck man, since I started this project I graduated with a mechanical engineering degree, took classes where I had to write computational fluid dynamics algorithms to solve partial differential equations. I'm so hecking excited to start on a new project with a blank slate where I can put what I've learned to the test.

that's part of the reason I don't want to go back through and fix all of these things, just try and finish this darn project so I can move on rather than scope creep and take another year to refactor the entire codebase. if it doesn't impact the player experience then it isn't worth fixing. (I really should refactor the player collision code though)

in other cringe, here's a comparison between the original art for level one and where it is now:





anyways, go make something bad and learn from it so you can do it better next time. I can't hecking wait

 

[kevin supermarket]

this is hecking awesome we love to see our game devs learning and growing

 

[jadd]

it's always so interesting to read these kind of posts as a dev myself too!

 

[KeplerElectronics]

Suddenly hit a wall with level design and stalled out with about 7 levels left to make. There are graphical changes I need to make as well (the world map is so ugly everywhere but world 1), but I decided to turn my attention towards music today (drawing is hard).

All music is now made using three channels instead of the maximum of four, which means that I can only have a maximum of three things playing at once (melody, bass, drum, or melody, melody, bass, etc). This lets me allocate channel 4 to just SFX so it hopefully improves the auditory experience when collecting coins. It will force some tracks to be a bit more minimalist, W1's music sounds emptier now :( but I think that's a worthwhile concession to make. As much as I love TIC80, I do definitely feel like the audio system is underpowered relative to the other restrictions.

Anyways, I worked on a handful of tracks today, including reducing repetition on W7 and starting a sketch for W3, but W4 is where I think I'm the happiest.



W4 is a cowboy world, and level 4 is called Slingshot! after the Good Kid song (also because the main mechanic is a slingshot), and I figured that since I couldn't come up with anything western for the OST I'd try something reminiscent of Slingshot!

The beginning based around dual eighth note melodies that harmonize, very similar to the intro of Slingshot!, but veers off for the second half. I need to build a third section or something to add more variation, but this is a good start. I caught myself looping it while browsing the internet, so that's a good sign it isn't too repetitive? Not sure, I'm always paranoid about stuff being too stale.

Desperately trying to hold on to the motivation to work on this thing despite it all. After the total inspiration-fest that was last weekend, I appear to have mostly run out of easy dopamine farming tasks.

At some point I need to put together a real marketing plan for this thing, bite the bullet and sign up for a steam dev acct, make a trailer, and maybe try and get it into some sort of indie showcase. Not sure how much longer it'll take to do the last dev work, don't want to start promoting it too early. Argh I should probably get back on Bsky and posting about it.

Remaining major goals (no major order):

• Finish basic level design so I can start sending the full game to testers
  • 7 levels
  • Incorporate collectible wrenches into a bunch of "complete" levels (15 or so levels)
• Finish level graphics
  • W7 overhaul
  • W6 needs more variation and character
  • Misc BGs and polish
• Finish mechanics
  • W5 needs one more mechanic, or to polish up an unused one
• Finish music
  • W3 needs to be fleshed out
  • Start W5 music
  • World Map music
  • Title screen music
  • Polish/extend everything else
• Finish world map
  • Graphics
    • W6 graphics are extremely unfinished
    • W7 graphics haven't been started
    • W3 graphics are extremely rough
    • W5/W2 graphics are kind of decent
  • Lock player out of next world if current has not been completed
    • Physical lockout and graphical blockade
• Misc JUICE
  • Moar SFX
  • Jingle for level transition
  • Polish level transition animation
  • Title screen animation
  • Procedural tile animations
  • Background elements
• Some sort of ending
  • How to make game satisfying to complete?
    • Credits?
    • Cutscene?
• Improve collision code
  • Not sure if I want a complete rewrite or just some more checks to prevent/save player from clipping into walls if moving too fast.
    • I don't want a hard speed cap but also don't want people getting backrooms'ed lmao
      • or just kill the player if they get trapped in a wall
• Marketing
  • Add screenshots to itch page
  • Trailer
  • Talk to someone about indie showcases

 

[KeplerElectronics]

No Bluesky embedder
As stated in the above post, Thwimbly has now been updated. I'm making progress on the remaining six worlds in the full game, need to finish at least a blockout of each level before I can send to testers.

This demo update encapsulates a whole host of new changes that improve or change basically every aspect of the game, even if it is relatively minor. Graphical improvements, control changes, level design streamlining... the list goes on.

The most major change is the addition of a run button. Thwimbly's old top speed is now only achievable when holding down then run button, much like Mario. When not holding, his movement speed is halved. When my brother was in town for SGDQ I had him play through basically every level that is somewhat finished, and the movement was just too twitchy for someone who hasn't spent literally hundreds of hours practicing. Hopefully this makes it better? World 1 is relatively easy all things considered (I've sanded off most of the difficult parts to try and minimize player frustration), so I'm not sure if it'll be a noticeable change when playing the demo, but it should allow for more dynamic gameplay for both casuals and speedrunners alike (you can get way more jump arcs by modulating holding run/jump now)

There's still an absurd amount of work, but things are moving. Not sure where the next major progress will happen, but I need to block out the remaining levels. Might just lock myself in a room and force myself to make some garbage levels to try and get inspiration. Having something is better than nothing, right? I can always rip stuff out later and keep what ends up working.

If any of y'all play the demo, please let me know what you think! If any obstacles were too easy or difficult, I'd love to hear it.

Link:https://kepler-softworks.itch.io/thwimbly

 

[KeplerElectronics]

Released a new demo a couple of days ago, and it really feels like the game has a new lease on life. I'll explain.

I got a critique on the last demo that it felt like the player was losing progress when they died because the coins would respawn. This was interesting because the coins literally had zero purpose. They were mostly there to telegraph to the player that this path was safe, you wouldn't die if you collected the coins.

I was faced with two options: Either remove the coins or make them more integral to the gameplay. I decided to take the coins and use them for a cosmetic hat system: Coins can be traded for hats that can be worn by the player.



There's a lot of references to games I like and things I thought would be funny (like 7 Grand Dad, the bootleg NES game) This was a really fun system to make, and I was able to take what I learned from how much the entity system sucks and make it a pretty modular system. It has flags for whether to render the player behind the hat (for those more mask/costume type hats) or to show the border, and the whole thing is arranged as a table so it can easily be rendered in the shop.

hats={[1]={img=256,os=-2,cost=0,text="simple and not classic",border = true, owned=true, showplyr=true},
          [2]={img=268,os=-9,cost=164,text="Plumber",border = false, owned=false, showplyr=true},
          [3]={img=266,os=-2,cost=599,text="Blue Eyed Skellington",border=true, owned=false, showplyr=false},
          [4]={img=281,os=-2,cost=360,text="Chicken Child",border=true, owned=false, showplyr=false},
                    etc.
         }

This led to an overhaul of every level in the demo, adding coins all over the place and giving a bit more of a reason to explore the levels. There are little nooks and crannies that hide bunches of coins, and this is what led to the game's new lease on life.

See, the level design mantra I had been working with was basically an obstacle course. The player would graduate from one obstacle to another in increasing difficulty until the level is over and we introduce a new mechanic in the next level. Any space in the level where there wasn't a challenge actively presented to the player was wasted. This had friction against the goal of the "base game," which was to create something fun and engaging but without a ton of difficulty. There was no reason for these middle-sections to exist, save for looking pretty.

With the introduction of coins, it allowed these middle areas to be filled with optional tasks: "Jump to the left and collect the coins", or "go off the obvious path to find a lot of coins." It lets the levels breathe a bit more and brings the level design closer to the Super Mario or Sonic levels I was originally being influenced by.

I still plan to do a more chaotic and hardcore campaign later (though whether that's incorporated into the same executable or spun off as a separate project file remains to be seen... I hope it's the former but there are some technical hurdles to overcome).

I've also been working on the levels later in the game that aren't in the demo: See the final level of world 3 below.



I'm extremely happy with how this level is turning out, the physics are different when the player is above/below the water line, allowing for some cool jump arcs and challenges. Graphically it might be the coolest level in the game, with how the colors change below the water line, the warbling water effect, and how the player splashes when entering/exiting the water.

We'll see how much of the old level design can be retained (I completely wiped world 2's levels, world 6 might be fine?) with the new direction. The levels are feeling more fun than ever and it feels easier to make them, so hopefully this pivot doesn't push the game's timeline too far.

No longer hoping to have the game done by the end of the year, but hoping to be able to get a playtest build with all basic levels done by the time AGDQ hits and try and get some feedback from some platformer runners there. One of these days I'll go back through that todo-list I posted a couple months back and update it, but it might be disheartening to see how few of those major milestones have been accomplished. Scope creep and sudden creative bursts can be real cruel sometimes.

Oh yeah, this update finally incorporated a save system too, I didn't want people to buy hats and not be able to keep them when they booted up the game. It saves level completion times, collectible wrench progress, coins, deaths, and which hats have been purchased. I still need to write some sort of progression-lock to prevent people from just walking to the last level, so that save system will get tied into progression at some point.

Still hoping to recompile the engine to allow me more space for levels (fantasy console limits to eight banks, seven of which are being used for levels, one for a world map. Each world bank can hold four levels, allowing for a total of 28). I'm hoping to blast that number up to 16 or 24 banks, which would allow me another 28 levels for kaizo-type hardcore challenges and extend the runtime of the game significantly. I've any% speedran the demo and it can be beat in about a minute if you know what you're doing, so extrapolating that it'll probably be less than 10 minutes any%, or less than an hour casual. Below the steam refund threshold so I'd much like to add more content to keep people engaged. That's a scope creep for another time. Gotta try and get the base game done before AGDQ (assuming I can afford to go -_-)

 

[KeplerElectronics]

Just realized that the Sonic Amateur Games Expo (SAGExpo) is early September. I had wanted to submit Thwimbly to it a couple years back but the game just wasn't nearly as far along as it needed to be. Deadline to submit is the 5th of September, and this is my last chance to submit with my goal of launching the game next spring.

This means I need to do three things within the next month:

1. Make a virtual booth for SAGE
2. Get a steam page up and get the demo build on there.
3. Make a trailer that can be put on both

Thankfully, most of the level design assets are nearing finalization, so I can make a couple tweaks to remove my developer aids, throw together a couple shots of each world and go from there. I need to make some music, but that needs to happen anyways.

I did mess around with recompiling the engine a few days back and thanks to the power of doing something poorly and getting someone to tell you how to do it the right way, I have an extremely cursed build that allows for an extra 24 ish levels (look at the top bar lmao). Does it export properly? not sure, but it is possible. Credits to MineRobber on the TIC discord for pointing me in the right direction.



I've also deleted most of the levels that were born pre-saturday, they just weren't fun. I do have a level based around a flash flood (the previous level is a rainstorm) that features currents and rain in a city environment. Extremely excited for this one to see the light of day.



Probably gonna try and get a trailer cut together and ask y'all for feedback sometime in the next week or so. Still trying to throw together a submission for a mario level design contest, get ready to move, and also figure out if I'm going to grad school, so hopefully I can cram everything I need to in over the next couple weeks.

Current marketing plan so I don't forget:

1. Get trailer into some sort of game showcase
2. Immediately upon launch host a bounty on Speedrun.com. Give a prize to whoever has the best run after a month. Try and get Celeste and Mario runners to compete
3. Host a level design contest a little while after the game launches, the entire engine is available with the game when purchased, so it can be hacked by whomever, which I love.

 

[KeplerElectronics]

Two weeks since the last update, and boy howdy have there been a lot of updates. Too many to list here, but I have a temp changelog for the new update on my website here!

This update will have like three updates worth of changes lmao, its so heckin long. Mostly polish, the levels have been improved, adding in secret areas, reworking the palettes, and doing some backend work to improve performance. I managed to speed up cloud rendering by 10X!!



Also been working on things that won't be in the demo.




Hoping to have the new demo version out within the next week or so, but I really want to add/fix some SFX stuff first. Hopefully I can bring the web version back too if I'm able to pry back enough performance from the entity and particle systems, but that's still up in the air.

 

[KeplerElectronics]

Its been another two weeks since the last update, and there have been a lot of changes. Still no idea when the demo will release, I still have a handful of things I want to do before I push out a demo.

• Major engine overhaul:
  • Recompiled engine for a second time because my original fork couldn't export files. The stock version of TIC-80 pulls down a "Stub" version of the engine from a web server and attaches that to the game file, which would have issues with my changes to the game file format. Solution was to reroute the web path to my neocities site and host my own stub version of the engine there. Can now export, but only to Windows. I need to compile separate stubs for Linux/MacOS. This also closes the door on a web version, at least for now, since I need to compile those separately, and there isn't any current documentation on how to do that. the recompile lets me fit 2x as many levels in there, so its worth the hassle. It's not a "pure" TIC-80 game anymore, but idk, it's not that much different than a NES mapper chip or adding extra ROM size to your cartridge.
• Steam Store page incoming:
  • I paid the money, I gave Valve my driver's license and social security number, and now I can make a steam store page. yee haw. The plan is to finish the trailer, make some marketing materials (banner, curated screenshots, text about the game, etc.) and then yeet that onto the steam store once the next iteration of the Demo is done. Absolutely no shot at getting this all done in time for the Sonic Amateur Games Expo, but there's still time to get it done before AGDQ in January.
• Tons of new mechanics:
  • Carryable items
    • 
  • Breakable walls
  • New enemies
• Near-total refactor of moving platform code:
  • Platform entities are now treated the same as the map tiles, rather than feeling like a completely different physics engine! I also broke this out into its own function, below is the code (written in Lua, which is not supported by the code block -_-)

  • --platforms
    function platlogic(id,left,right)
    
    if not left then
      left =-7
    end
    if not right then
      right = 16
    end
    
    if (p.x+p.vx) < ents[id].x+right
        and (p.x+p.vx) > ents[id].x+left
        and p.y+8+p.vy > ents[id].y
        and p.y+p.vy < ents[id].y
        and p.vy>0  then
            landing()
            if ents[id].y>30
            and ents[id].ty == 213 then
             ents[id].y = ents[id].y-0.5
            end
            p.x = p.x+ents[id].vx
            p.y = ents[id].y-7+ents[id].vy
        else
            if ents[id].ty == 213 then
             if ents[id].y<ents[id].oy then
              ents[id].y=ents[id].y+0.5
             end
            end
    end                 
    end

  • This code was inspired by Maddy Thorson's platform code for Celeste, though applied differently
  • ignore the fact that all the indents are weird, my editor treats spaces and tabs as the same width d(-_-)b
  • This method of breaking out logic is also being used for carry logic and other things, which is honestly a killer way of organizing this that I should have been using for forever.

There's still a heckin ton of stuff to do, but things are movin. I need to make some pretty major gameplay decisions soon, because that'll dictate how I market the game in the near term, but I'm still focused on getting all the base-game levels/mechanics in so I can send it off to some playtesters.

Big things that still need to happen:

1. Figure out plot/lore
2. Figure out bosses (at least one I think)
3. Figure out how much to lean into "Kaizo" marketing
4. Finish editing trailer
5. Commission some key art (probably need more than two characters q(-_-)p)
6. Write world map music so I can ship demo without it feeling super sluggish
7. Build at least two kaizo levels for demo, and they have to feel good (be hard but not frustrating)

Things are going to slow down pretty massively thanks to my research/teaching assistant grad school stuff, but I still have hope of getting the steam page+trailer+demo up by the end of the year.

 

[KeplerElectronics]

In a break from the tradition of this thread, this post is going to be less of a "what has Kepler been adding to Thwimbly lately" post, and more of a "Kepler channels all of his OCD rumination into thinking about Thwimbly and catalogs it on a public forum" post. Since I'm not writing videos about competition robots anymore, this is the next best outlet for my manic scriptwriting energy.

Anyways, I've been thinking about verbs.

Since returning from Summer Games Done Quick (SGDQ) I've gotten way back into watching Twitch streams. Thanks to watching Shoujo and ThaBeast721 running Super Mario World (SMW) romhacks, my love of SMW came back in a big way. Couple that with an excess of time on my hands thanks to being unemployed, and I spent a lot of the past couple months watching SMW on Twitch while working on Thwimbly.

Among the streamers I've been watching is Glitchcat7, one of the best SMW players, who also happens to be working on a Super Mario Bros. 2 romhack, and was doing some work on stream for that. He was talking about this theory of video games where it all centers around verbs. Basically, you can break down everything in a game mechanically based on what you can do.

Thwimbly's verb list, for the longest time, looked like this:

• Walk
• Jump
  
  • Fastfall if pressing down
  • Slowfall if holding A
• Context-dependent actions
  
  • Climb if next to a specific wall type

This is an extremely small number of actions. I think this was adding to the game feeling relatively boring, because aside from avoiding deathtraps and bouncing on friendly entities, there really wasn't that much to actually do. It was all based on pure platforming. Let's take a look the verb lists of the main two inspirations for Thwimbly.

Celeste's verb list looks like this:

• Walk
• Jump
  
  • Fastfall
  • Slowfall
• Dash
  
  • Wavedash
  • Wallbounce
• Climbing
• Wall Jumping
• Crouching
• Carrying items
• Context-dependent actions
  
  • Dream blocks, etc.

There aren't too many more actions, but it really does a lot to make the game feel more dynamic, there are many more options for things to do. Not to mention that Celeste has so many mechanics that are all applied in a myriad of different ways (carrying Jellyfish is different than carrying Theo, Dream blocks preserve dash direction, etc.)

Super Mario World's verb list looks like this:

• Walk
  
  • Run
  • P-speed (run for long enough and you'll start moving at a faster speed)
• Jumping
  
  • Slowfall
• Spin Jumping
  
  • Don't take damage from most enemies that would otherwise hurt to land on
  • Destroy enemies that don't hurt to land on rather than knocking them out (this creates a smaller bounce as well)
  • Destroy spinblocks
• Crouching (can use this to slide through gaps that would otherwise be too small)
• Powerup Actions
  
  • Cape flight
  • Throw fireballs
  • P-balloon
  • Yoshi has a ton of mechanics on his own
• Carrying items
  
  • Set down
  • Uptoss
  • Throw forward
    
    • Shelljumps are possible from this
• Context-dependent actions
  
  • Pipes etc.

Now, I attribute a lot of these two games' lasting modding scenes to the dynamism of their movement systems. Heck, even in the base games both are using their movement in interesting ways. Mario is a lot more focused on giving the player a sandbox and letting them explore how best to utilize the moveset, whereas Celeste is more focused on giving the player a challenge and requiring them to apply their mastery of the moveset to progress.

Thwimbly, at least at this very moment, does not land in either of these camps. It does not have enough options to be a sandbox, and the mechanics don't have enough depth to provide a satisfying myriad of challenges. There's a reason Thwimbly has more entity and platform types than Celeste despite being about 1/10th the length :/

Thwimbly also has trouble landing on one side or another of this fence in terms of level design. The levels are trying to provide both exploration and sandbox-style gameplay and force the player into a rigid path to progress. I think there's a way to do both in the same game, but maybe not the same level.

This post is getting long and I'm concerned about my internet crashing again, so I'll split it up into multiple.

 

[KeplerElectronics]

Over the past couple of weeks, I've been exploring different ways to add dynamism to Thwimbly's moveset.

Thwimbly's moveset, as of today, looks like this:

• Walk
  
  • Run button for more speed control
  • P-speed (if player runs for 30 frames get a 1.05x multiplier to velocity cap)
• Jump
  
  • Fastfall if pressing down
  • Slowfall if holding A
• Carry objects
  
  • Set down
  • Uptoss
  • Throw forward
• Slide
  
  • Brief boost of speed, allowing larger gaps to be covered
  • Can take out enemies if sliding into them
• Context-Dependent Actions
  
  • Climb if next to certain wall type, etc.

This looks much closer to the games its taking inspiration from. However, there are a few issues with it.

1. Jump distance drastically increased with slide
2. It is not possible to maintain or obtain P-speed in most levels (you can do it in 1-1, and that's about it)
3. Carrying items is not introduced until 4-4
4. All levels were designed around not being able to kill enemies

These issues lead to functionally requiring a full redesign of the entire campaign from a level design perspective. While I think the overall improvements to the moveset warrant this, I'm honestly not sure what direction the levels should take.

Let's talk through what it would look like for the levels to be a more Mario-styled sandbox experience.

The levels would be more open rather than the zig-zag designs I've currently been doing. Above is a goofy recreation of SMB 1-1 I was making from memory just to see how this felt. I did add in blocks that can hide entities inside, but there isn't really anything that is worth getting inside besides more coins to collect hats. The game doesn't have powerups, and there's a whole other question of how they would work in Thwimbly.

This question ties into a bigger question I've been having lately, why aren't there indie games featuring Mario-like gameplay? You have indies that are basically modern recreations of Metroid, Mega Man, The hecking Zelda CDi games people made YTPs of in 2011, Castlevania, and like dozens more classic franchises. But no Mario. At least no good indie games that channel Mario energy. Is there a reason for that? There are a ton of super cool mario fangames that would make excellent indies if they had a fresh coat of paint to remove all of Nintendo's IP, but no super polished indie projects like other franchises have. Is Mario just too popular? Did low-effort cash-grab indies poison the well a decade ago and everyone is just too afraid to go near it? Are people too afraid to reference Nintendo's biggest guy? People make indie Zelda-likes all the time, so why is Mario different?

The question then, dear reader is whether trying to make something that holds more closely to this style of gameplay is a bad idea. Will it hamper the game's public opinion? Is the game doomed from the start? Or is this an untapped market that most indie devs are too risk-averse to try (or just have better ideas maybe)

(-_-) *sigh*

I've been racking my brain to think of a Mario-styled indie and the closest I can think of is A Hat In Time, which isn't 2D. I 100% was planning on my next game pulling very heavily from Mario, but the plan for that was to build something at a higher resolution/color count in a new framework and without 4 years of past Kepler's mistakes leaving the project in massive technical debt. I think Thwimbly's artstyle isn't going to do it any favors when it comes to seeming like a Mario derivative.

Let's explore something closer to Kaizo or Celeste.
Kaizo, in this context, refers to difficult levels prioritizing flow and execution. Celeste is the most popular indie game that pulls from Kaizo (and Maddie has made two Kaizo SMW romhacks since Celeste came out, so she's definitely into Kaizo). Rebounder is an upcoming indie that I can't see not being successful thanks to its incredible visual design and tight gameplay. I've been playing the free demo of Rebounder so much over the past few days it's not even funny haha.

Building the game around Kaizo would put it on a shortlist of indie titles directly pulling from this subculture. Kitsune Tails is one of the only released indies directly referencing Kaizo, though they're using it as a bonus postgame challenge. Rebounder and Inpulse are two indies that are heavily marketed around kaizo, with Celeste not mentioning Kaizo but being the poster-child of the indie kaizo movement in my mind.

The problem I've been running into when designing kaizo levels is attempting to keep things feeling tight. Thwimbly's movement is extremely loose and floaty. In some cases this is good, in others its bad. All that's to say that I think a lot of the physics values will need to be tweaked to prevent the player from travelling too fast to see clearly and prevent things from being too floaty.


Above is a video of an exploration into something more Kaizo-adjacent built inside of Thwimbly. this is adding in a new mechanic directly inspired by Thumbshredder levels in Super Mario World (the name is a reference to Glitchcat7's level Thumbshredder's Dad). I think this looks pretty good, but it is extremely difficult. I think it took me about an hour to get this clip (and I died immediately after the clip ends which is why it cuts off so abruptly). and I have hundreds of hours playtesting this game lol.

The mythical third option: Combat focus
This option would require giving Thwimbly more options for combat. Whether that's some sort of projectile or sword I'm not sure, but the idea would be to move even farther from Mario/Celeste and towards something closer to Shovel Knight/Megaman.

A lot of the game would need to be reworked mechanically to make this happen, since neither Thwimbly nor enemies have health, and all damage is done by just walking into things. Honestly I don't really have too many thoughts on this, so maybe that's a sign it's not worth even thinking about any more.

So what's the plan?
I'm not sure. I was hoping that by writing out all of my thoughts rather than just letting the rumination take over (though I'd rather ruminate on Thwimbly than existential dread. also my zoloft isn't working as well as i hoped), I could try and come to some conclusions.

I still have a ton of ideas for Thwimbly, including minigames, mechanics, level themes, and more, but I feel like this project isn't going to be a success (in terms of being a polished complete game, not necessarily commercial success) if I don't have a solid direction. As of right now, the game is getting so close to completion. It can be played 80% through in terms of base game, (missing only a handful of levels/mechanics). My plan was to send the game out to testers once the levels were blocked in so they could help me tune mechanics and physics values, but I feel like I need to take a step back and evaluate the game on a more fundamental level.

They always say that having a design document is super important when developing a game, and wowee are they right. Thwimbly is effectively a virus that got way out of control and periodically takes over my life and every waking thought. This started as a simple project to try and program a jump arc while stuck in a hotel during summer 2021, and over the past four years has morphed quite a lot. I have definitely learned a lot about scope creep, technical layout, my preferred workflows, and program logic in general, so it's been worth the effort, but the question is where to go from here. If I had a concrete idea at the start that could be boiled down into an elevator pitch, maybe I wouldn't be in this predicament.

This leads me into a handful of options:

1. Finish the game as-is. Write the last few tracks, remove the movement options from the last week that break everything, build the last few levels, make the Minimum Viable Product and yeet it onto the internet for free. This was basically my plan as of this spring.
   1. Pros:
      1. Lets me remove this parasite from my mind: move onto a new project and take these lessons in a new direction.
   2. Cons:
      1. Not an awesome end product. Would not be a good showcase of what I'm capable of.
2. Rebuild the game more focused around casual/exploration focused gameplay. Pulls heavily from Mario, moderate difficulty. Sell game for $5-7
   1. Pros:
      1. Less likely to alienate players with difficulty.
      2. Can explore this seemingly untapped vein of indie ideas.
   2. Cons:
      1. Game will probably be very short and beatable within steam refund policy.
      2. Levels have a strict size limit thanks to engine limitations, so only so much exploration will be possible.
      3. thwimbly's aesthetic is already pretty safe/generic thanks to engine limitations, so pulling even more from Mario mechanically will make the gameplay even more generic.
      4. Need to come up with ways of sandbox-ifying gameplay to add more options
3. Rebuild the game around Kaizo gameplay specifically
   1. Pros:
      1. Difficulty increases game length without requiring extra content
      2. Not a ton of indie games plumbing these depths right now, and none that I know of with bosses either
         1. Thwimbly doesn't have bosses right now but it's on my ideas board
   2. Cons:
      1. Need to do a ton of rebalancing on the movement tech, potentially adding more to increase the possibility space for level design.
         1. I've already rebuilt basically every level twice, what's another couple thanks to updating the movement code?
      2. More difficult to speedrun. Celeste manages it, but most Kaizo romhacks don't. Rebounder is very fun to speedrun though, this might be a non-issue?
4. Rebuild game as hybrid: More sandbox-y levels with kaizo secrets and special challenge levels that are pure kaizo. This is what the levels are like now, kinda
   1. Pros:
      1. Almost wholly unique in the realm of indies to my knowledge (Kitsune tails is the closest I'm aware of but I still need to play it)
      2. Lets me stand in both camps since it seems like that's what I want anyways
      3. Probably the most fun for building a speed game thanks to the multiple options
   2. Cons:
      1. Still probably needs to come up with ways of sandbox-ifying gameplay with powerups or attacks or something. Hidden areas made this better but it still needs something else. Maybe the slide attack will fix it?
      2. Levels are only so big and will have trouble hiding secrets

Maybe the correct answer is to step back, get some space, and re-evaluate. I'm still having tons of ideas and enjoying working on the game, but this lack of direction is kind of concerning.

 

[KeplerElectronics]

Did I just sit down for two hours and slap together this entire post? i guess. I didn't even realize it'd been 2 hours lmao.

Anyways, where was I?

Watching the kaizo video back, I think the movement needs work. Thwimbly is really, really floaty. That can be good (I love SMB2 Peach movement, I've been on record saying this), but Thwimbly's feels kind of like a crutch to atone for some kind of other movement sin. What that sin is, I'm not sure. Too much speed? Requiring too tight of jumps?

While I haven't decided a plan for the entire game's future, I do know what I'm doing in the short term.

1. Tweak the movement to get it feeling good in a super basic level. Ignore multiple worlds, entities, focus on jumping, sliding, running. Make this feel really good in isolation.
2. Design a basic level or two using World 1's tileset. This will probably flow between "standard" type levels (exploration, sandbox) and kaizo-type levels. maybe one of each.
3. Send this build off to some platformer folks for feedback. Use that feedback to tweak the physics to make it feel even better.
4. If I can't get the new movement feeling good, then just slap together the rest of the game, revert the movement changes to how it was last month, and throw it up on itch for free and move on to a new game project.

Anyways, if anyone reading this wants to test the current (non-public) build out, let me know and I'll get you a build from before I started gutting all the levels in World 1.