Okay, look, I know loot boxes get a bad name from the (many) publishers that use lootboxes to encourage microtransactions that milk their players for every last cent.
But I don't do microtransactions! So here we just have certified evil-free loot chests, filled with yummy yummy perks you can pick up in a game.
Also, we now have a way to edit abilities which doesn't blatantly break the game, which is always nice.
Perk Pickups
So we had these perks that you could assign to abilities to effectively "program" what bullet you're going to shoot (or whatever1), but there was no way to actually gain these abilities or perks in-game.
That changes now!
But, in a falling sand world where all pixels are individually simulated (like in this game), these "pickups" come with an interesting design question: what happens if they get buried?
Do players just miss out on buried pickups? Or can players still pick up perks that are really far below them?
Block Bodies
To fix that, I introduced "block bodies", which is possibly the world's dumbest physics engine:
Unlike the regular "rigid body" physics we have had so far, block bodies are allowed to break the laws of physics a little: the block body checks each of the integer-grid positions that it occupies to see if there's an atom there, and if any atoms are in the way, the block body looks around itself to find a new place to move to - even if that means moving through terrain. 2
That means that perk pickups will never be fully buried under sand.
Loot Chests
Just running around picking up perks was a little mundane, so I put them inside chests (which are also block bodies under the hood):
The more powerful Epic and Legendary perks (blue and orange) appear less often, which adds a bit of excitement when you see a rare perk appear, and makes it okay to have overpowered perks.
The chest locations in each level are lightly randomized: I place the possible chest locations manually in the LDTK editor and a number of them are selected based on the level size. 3
Ability Editing v2
You could now run around collecting abilities and perks, but each perk would automatically get assigned into the first ability you had - which can be less than ideal:
And there wasn't a way - other than using the cheat-y loadout editor - to reassign those perks.
So I upgraded the HUD so that you can press Tab to enter an ability editing mode:
There's a lot of hidden complexity in that interface:
- We might have 4 players playing on the same computer at once, so space is limited.
- The UI needs to work with keyboard & mouse, keyboard alone, or a gamepad, depending on which the player is using. 4
- And the UI also needs to tell players what keys/buttons do what.
- And the multiplayer netcode approach causes a bit of split brain syndrome that complicates things further. 5
Splitting Perks
In the original cheat-y loadout editor, once you had acquired a perk of a certain level, you could use it as many times as you like in as many abilities as you wanted.
That's obviously broken if you get a super powerful legendary perk, so now perks can't be 'duplicated' like that.
Instead, if you have a perk that's been leveled up, you can 'split' it by right clicking:
So I guess perks now behave more like stacks of items than acquired traits - hmm, maybe I should rename them?
Playable web build
I've also rolled in a few other minor changes:
- Regular bullets create little effects when they expire or hit things (and cosmetic particles when they hit terrain); I was told there wasn't enough feedback from the bullets so hopefully this will help.
- Atoms that get flung straight upwards no longer create weird wiggling motion when they reach the apex of their trajectory.
Okay, sure, right now pretty much all abilities can do is shoot bullets which get modified by the assigned perks.
I'd like there to be a bit more variety but haven't got around to trying prototyping that yet.
This isn't how collision resolution normally works in physics engines! Normally you have two polygonal shapes and use an algorithm to find how much the two shapes intersect, and what displacement is required to stop them intersecting - then move them according to that.
I do have a way to calculate polygons from terrain atoms - which is used for the rigid body physics engine integration - but calculating those polygons is computationally expensive. So I use this hack job approach instead to avoid having to compute more terrain polygons than necessary.
That does mean that you can get unlucky and have a whole area of the map that doesn't have any chests, but I can rework that later.
Which meant I rewrote my over-engineered (and apparently poorly-designed) control mapping and input handling code yet again. Now any player can have 1-N input devices assigned, each player can use multiple input devices, and the most recently assigned device is the preferred device for any player.
I still need to dynamically update the preferred device based on player inputs, so the singleplayer case where someone swaps from keyboard to controller works seamlessly - but this'll do for now.
You can't directly modify the game state from within the UI because that would cause the game clients to get out of sync. And I didn't want to move the 'editing state' (like mouse cursor position) inside the networked game simulation too, because then the raw mouse cursor position would need to be sent to all players, which would cause a lot of rollbacks and ruin performance while any mouse-using player had the HUD open.
So instead each edit operation needs to be sent as a standalone command, like 'swap ability A perk at position X with ability A perk at position Y', and the UI code needs to accept that the game state might be rug-pulled out from under it at any point.