News

Happy holidays! When I went and sat on Santa's lap this last week, he pointedly told me:

Firstly, maybe I was getting too old for this lap-sitting business (haha, good one Santa).

Secondly, I should expect only one gift - and I would have to share it.

Networked multiplayer now works in the playable web demo!

Crazy, right? I can barely believe it myself.

Last week I quipped that networked multiplayer should work on a dialup network connection.

But would it really? I dove into simulating bad network conditions to find out.

As of last week, network multiplayer worked in moment-to-moment gameplay, but still had sharp edges.

And to talk about those sharp edges, I need you to meet John.

After a week of cleaning up last week's mess, networked multiplayer is starting to get into shape.

I've even added amazing features like "adding a new player" or "finishing a level without crashing the game".

And just for fun, you can edit levels with friends in a multiplayer game too!

I implemented the most horribly hacked-up version of rollback-based networked multiplayer.

But it actually works! Or at least, it works during regular gameplay...

I rewrote most of the atom movement and made it about 40% faster on my big test level.

Yeah, I know, I've written a lot of updates about performance-tuning lately.

So instead, let's talk about how I made fluids behave a lot more, well, fluidly.

Improving performance of the atom simulation has been like pulling teeth: slow, painful, and not well suited to being featured in short videos paired with a couple hundred explanatory words.

So let's talk about something a tiny bit more fun: geometry! And a light serving of mathematics!

I know I've got you hooked now, so let's set the stage.

I carefully made a surgical change that dramatically improved the performance of the entire game.

Or did I? Perhaps I instead opened up a can of worms, and one of those worms was a big ugly boy with "Nondeterminism" writ large upon his cursed frame, and then said worm proceeded to slowly bludgeon me to death?

Questions, always more questions... and to answer them, we need to start at the beginning, don't we?

I simulated what game performance would be like in a rollback-networked online multiplayer world, and the answer was "Terrible".

So I made it a lot less terrible!

And I incorporated some feedback on last week's Lightning spell too.

I added a lightning spell so now you have a full(-ish) roster of spells to cast.

I know, I know! It's a terrible pun title and you heard it coming a mile away. I couldn't resist.

This week I've got some wild news to share: I've secured some funding!

I guess I'm a game developer for realsies now? Read on for the lowdown.

Some weeks, it's hard to think of what to build next.

You catch up on email, start a new todo list, watch twenty-two vaguely relevant Youtube videos, fantasize about a total rewrite - and somehow you're still not inspired.

But, this week wasn't like that! I knew I needed a Barrier spell, and I just needed to build it.

A surprisingly common question I get is "what are you using to send out those emails?".

So I figured I'd share a little of what goes on behind-the-scenes for these weekly updates.

Continuing on our spell extravaganza, you can now cast Mine spells.

Mines are not just for exploding enemies! Turns out they're good for healing and jumping too. (Also for exploding your friends.)

And I added a basic player HUD so you know what your buttons will do.

If a player summons two elements that merge into another element, but the player didn't see the merging happen... did the merging even happen?

Not really! From the player's perspective the game is just unpredictable.

But, our new animated spellbar fixes that - and it was damn tricky to build!

Continuing from last week's elemental spellcasting, this week I added support for casting Rock spells and Shield spells.

And, you can now aim spells with the mouse!

So far we have had spell casting based on a lookup table, and it worked but felt a little lackluster.

So this week I experimented with some twists and alternatives, including a Magicka-style spell casting based on mixing elements together.

I've been brainstorming how to make the spell system more customizable, and one of the ideas I had was to explore using gestures to cast spells.

So let's see how that went down!

Being new to game dev while also working solo is great fun.

Most of the code was written by your least-favourite colleague: you from several months ago.

And the bigger your game gets, the more prolific that incompetent colleague seems to be.

But hey, you can always rewrite code, so that's what I did with the atom movement logic for powders (sand, coal, etc) this week.

Finally, we have explosive barrels! And explosive fireworks!

Wait, explosive... fireworks? Yep, and I'll tell you why.

Levels now have ladders. Seems simple, right? Think again!

And we're trying out some quick'n'dirty jump pads too.

Facing family flu season in full force, I figured fiddling with flow was fitting.

A core feature of Broforce is chaotic chain reactions, and this week our untitled wizarding game gains a bit of boom juice too!

And, bonus: those of you using high refresh rate monitors get a much-needed bugfix.

In the spirit of making death more fun, enemies & players now get crushed by moving bodies, and bleed when they get hit!

For now it's mostly you doing the bleeding, since you don't have a spell that does physical damage to enemies yet. But that'll come!

Fire wasn't anywhere near as much of an all-consuming inferno as it should be - so I fixed that.

Oh, players also have sprites now, so they're 87% less house-shaped.

Killed enemies now turn into physically-simulated corpses!

Finally a use for all that work to marry two physics engines together - phew.

This week I tried out a new spell-casting scheme, including adding 2 new spells.

And, atoms learned to apply status effects to characters, such as "on fire" and "poisoned".

This week, enemies progressed to toddler stage: they now chase players!

And we've got a new type of enemy too.

This week, enemies learned to see the player and shoot in their general direction, which increased their deadliness by approximately infinity percent.

This week, I added some enemies to kill, so watch out! The enemies might.. err.. well, they can't move or shoot yet so they're not super threatening.

Still, you can kill them with (two of your three) spells! So you could say they're target practice.

The good thing about building an engine just for your game is that it lets your game do things other games can't (and it's often fun - or at least educational).

The bad thing about building an engine just for your game is that if you want to Frobber something, you first have to build Frobbering into your engine.

The ugly thing about building an engine just for your game is that building an engine means making a lot of choices (what can even be Frobbered?). And - especially when you're coming from a non-game-development background - it can be hard to tell whether you're making the right choices.

This week, levels have a goal to reach, and reaching the goal loads the next level.

You can also die, and revive players by touching the spawn point again.

This week I added support for tile maps, so levels can be created with the LDTK editor.

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.