Populating the City, and More Controls

In other sci-fi and cyberpunk media - Blade Runner, Fifth Element, Mézières' and Moebius' work, Corscant from Star Wars, etc. -  there are two main things that define their cityscapes: density and verticality. The skies are full of flying vehicles, lanes stacked above lanes, many stories tall. To sell the concept that this is a busy, bustling metropolis where you need to get peoples' deliveries to them on time, it needs movement and life. It needs flocks of commuters, making their own way around the city. 

It still doesn't have that, but I'm a lot closer. 

Naturally, the place I started was with GDevelop's Pathfinding behaviour. I knew this probably wasn't going to be the solution - even overdoing it on the pathfinding for one Hunter brought my game to its knees. The pathfinding behaviour isn't performant, and it can very easily tank the game's framerate and make it impossible to play. Sure enough, even trying to carefully manage how frequently I was making calls to the pathfinding behaviour, after adding 7 or so commuters, the game would collapse under its own weight. 

Pathfinding was out, but I wanted the commuters to be affected by physics anyway - which wasn't necessarily going to be the case if they were driven by pathfinding. So I needed a more performant approach, and physics and a handful of clever rules seemed to be the way to go. 

I developed a state machine and events for the commuters that I quite liked. Essentially, I set up a series of nodes - just boxes placed at the map's intersections - and during the commuter's Routing state, it would pick a nearby one at random and set destination coordinates within the area covered by the node. It would enter an Aligning state, where it would orient itself towards its destination. It would then enter a Commuting state where it would travel to the destination, pushed by physics forces to get there. And once it collided with the node, it would reenter the Routing state. It worked really consistently, and gave the appearance of a commuter making travel decisions as it entered intersections. It was all done through physics forces.  

In addition to the state machine, the commuters had a series of moods - a sort of second state machine. The commuter could be calm, panicked, aggressive, etc. which would govern how it would choose a destination and how quickly it would travel. I felt pretty good about it all. 

And then I added more than one commuter, and suddenly none of the code worked. 

The problem was easily understood. Any time more than one commuter was in the same state at the same time, the engine didn't know which instance of it to pick. But I wasn't quite sure how to fix it. So I deleted the nodes, deleted the commuters, and tinkered with other parts of the game instead. But I didn't really let myself move on from it, because barely-managed chaos is one of my design pillars, and that doesn't really exist in my design without the commuters to avoid, collide with, and react to. They're a critical part of the game - not just to sell the "cyberpunk city full of flying cars" aesthetic, but also to the make the core game loop work.  

This was all months ago, by the way. So bHopper has mostly been a back-burnered project since. 

But bHopper isn't the only game I've been working on. I also have my little toy, Erm Labs. At first glance, a cyberpunk vehicle combat game and a bubbly colour-mixing toy are pretty far apart from one another. But they did have one thing in common, a critical need both projects have: making many instances of the same objects have different attributes and make decisions simultaneously. And in Erm Labs, I did figure out how to make a rudimentary state machine and combine it with appropriately-placed For each instance events. 

In this most recent release of the bHopper prototype, I stripped back all of the code I had put together for the commuters, and focused on one thing: getting them all moving independently. This was a success! And while there are nodes on the map (denoted by the magenta boxes), commuters don't do anything with them. Currently, they just kind of pick a random nearby location, go there, overshoot a bit, and then go there again. But they're doing it independently, they're moving through different states, and I have a working foundation to build from. And - the best part - it's extremely performant compared to pathfinding. Instead of crushing the game with 7, I can comfortably drop 2000 or so in the scene and it runs just fine. 

I was a little insecure about the pink boxes, although they're a useful tool for monitoring as I continue to work on the NPC commuters. And I had the idea - I thought I might just make the nodes invisible, but why not dress them up a bit? Why not decorate them as street signs and stoplights and whatnot? There's opportunity there. 

It was a long walk to get here, but I am excited about it. 

Some other highlights of this release: 

• There's a splash screen to start the game! There are also links to Twitch and Discord there. 
• I retooled the UI a little bit in anticipation of a more thorough overhaul. Because currently, there's no real UI to speak of, just floating numbers. I also removed some of the text objects I used for testing. 
• There's another new control scheme that I wanted to try out, which is a mouselook system. It's available on PC but not mobile. 
• I again tinkered with the Nitro Cracker code to make it more reliable. Turns out that sometimes, its starting speed could be below its minimum speed, which for some reason prevented it from ever accelerating to its intended top speed. 
• The game FINALLY has the kind of music the game wants to have. Thanks so much to Hy Vyb, whose work you can (and should) find at https://chillway.bandcamp.com/ Thank you so much for delivering the vibes!