News

This week, I added support for loading levels on the web build.

So now you can try out some basic levels!

This week, liquids of different densities separate properly - so oil tends to float on water, rather than stay as globs floating in water.

The trick was in rewriting the atom sleep logic, which led to a bit of a performance optimization rollercoaster.

Also, you can cast three spells now, so let's have at it!

Last week, I promised to write a bit more about how multiplayer could work (assuming I find funding for it).

Even the basics of multiplayer are complex, so this update turned out to be a lot of words - and it's a bit more technical than normal too. If that's not your jam, feel free to skip past the multiplayer theory-crafting.

(After the words re multiplayer, you can play with some sort-of-working oil - yes, we have oil now).

This week, fire learned to boil water into steam, and water and acid now mix to make poison!

I also spent a lot of time on that most thrilling toil known to all small business owners: paperwork.

Wait, no, don't leave! Said paperwork might help networked multiplayer happen (maybe). That'd be cool, right?

This week, I implemented acid and fire! So now you can use acid to eat away the terrain and fire to, well, burn things.

And you can do those things to moving bodies too!

Plus: where there's fire, there's smoke - so now there's smoke too.

This week, a wild Slow Rush Discord server appears! And I reflect a bit on writing these updates.

What's that you say? Something about a game? Oh, right, that!

Well, you can now jump into water to splash it around, push falling sand & brick atoms out of the way, get buried by them, and (usually) dig yourself out - all the good stuff.

This week, it's my birthday!

To celebrate, I fixed the biggest outstanding bug in the "moving bodies to atoms" physics bridge: terrain can now have holes in it, without glitching out moving bodies!

Plus, the game now supports multiple players, including via gamepad controllers!

The prototype's pixel atom physics are coming along nicely, so this week I had a think about the other big part of the game: spell casting.

A neat physics system is fun for a bit, but it does get old pretty quick without some kind of goal like killing baddies, and in my unbiased opinion, killing baddies is way more fun when you have cool spells.

This week, atoms finally play nice with moving bodies thanks to last week's particles.

That means you can fling a moving body into water and the water makes a little wave, and moving bodies & players don't have their movement blocked by falling sand anymore! (Oh, also, atom movement is vaguely plausible again, unlike last week - yay!)

There was a lot of fiddling to get this all somewhat working, so let's get our feet wet.

This week I had a second shot at implementing particles, which are my planned solution for stopping atoms from crushing moving bodies (so that dropping sand on a box doesn't cause the box to flip out).

And this time it worked! Or at least, the particle implementation worked. And I added a neat time travel debugging feature to help figure out why the rest of things weren't working.

This week I can confidently say that falling sand no longer completely crushes a moveable body that it falls onto! (It does still crush it a lot, which isn't the best, but we'll get to that.)

First, a small announcement: I've formally resigned from my day job! I had already been working on this fulltime via extended leave, but from March 2nd onwards it'll be official. That did mean that I spent entirely way too much time this week wrapping day job things up, but now that it's mostly done I can get back to focusing on making physics pixels move around semi-predictably.

Secondly, some terminology: I'm sick of writing "physics pixels", so let's call them "atoms". They're the smallest indivisible unit of our game, and we know for a fact that atoms cannot be divided further, so the shoe fits.

Now, back to our usual programming: let's talk about inertia, and our blatant disregard of it.

We're back with another Wizard-Pixels-flavored update, again on duct-taping together two physics worlds!

Last time we ended up with moving (rigid body) colliders being created from physics-pixels, and physics-pixels were stopped by fixed rigid body colliders - so you could stack boxes on top of a sand pile, and sand would be stopped by fixed platforms.

This week, well, you can still mainly do those things. But! Wait! Don't leave! This week it performs at least 10x better, which makes it actually playable! And you can draw custom moving bodies, and actually walk on the sand as a player too - both of which are sort of neat.

How is this black magic possible? Let me tell you!

Welcome back! The game will have physics taking part in the magic system, and currently it has two types of physics in it: "pixel physics" (falling sand, flowing water, etc) and "rigid body physics" (boxes, balls, etc).

More physics is better, right? Sure, except for that right now they can't interact with each other at all. Which means a ball will fall straight through a sand pile. Or water falls straight through platforms rather than flowing around it. Not very good, so let's fix it!

In last week's playable demo, the edge of the world would jitter back and forth about the width of a pixel when you moved your character - which looked terrible and was very distracting.

This was caused by the rendering (the camera) not being "pixel perfect", and - I'm not going to lie - fixing it was a hell of a rabbit hole! You might think it's a trivial problem to solve, but each game has slightly different constraints, so let's take a quick tour through the many different aspects of it!

This week, I added physics-based platforming support - so now you can control a little box who can move around, jump and push some balls around.

Making movement feel good is really tricky! For example, real life physics would lead you to think that a jump makes you travel in a parabola, so that the time taken to reach the peak of your jump is the same as the time to fall from the peak to the ground... but in a game, that feels terrible!

This week, I ported my "game" to two different Rust game engines. Why two engines? Why Rust? Let's dive in!

As a reminder, I'm aiming for a 2D game with "pixel physics for PC", which means it has some high level requirements from any engine...

New year, new adventure!

I'm making this thing a little more official by spinning up a website so people can follow along, so let's talk a bit about what game we're aiming to build.