throng

I got things slowed down. So now it's real-time and playable in the most minimal sense of the word. It's kinda more fun this way?

But the game still updates in a turn-based kind of way, so it looks (and feels) really stilted. I need the turns to be more granular. That change seems like it's going to be painful, but who knows. Maybe it won't be? I should at least try.

I've been thinking for a while, that there is too much to think about each turn in this game. It's just onerous.

So, I thought about making it real-time instead of turn-based to relieve the player from having to make perfect moves. It wasn't as hard as I thought to get started on that path implementation-wise, but all the NPCs are extra fast so I can't assess playability until I slow them down.

It is fun to watch like this, though.

I tried two changes that I thought of while trying to get to sleep last night. 1) I made the guys that can recruit others the rarest ones. 2.) There's more skinny corridors now, as opposed to big, open "rooms."

The changes are not dramatic, but definitely an improvement. The recruiters are now something you want to protect, and the throng size ends up smaller and more manageable.

The narrow corridors are a bit annoying to navigate, but do force you to face danger. Maybe wide hallways that aren't "rooms" are in order.

Other thoughts that occurred to me while playing (insert a "maybe" before each of these items):

- The pushers should push two spaces.

- They should be immune to alligators.

- Individuals in the throng should be lost if they're no longer touching the throng. This could be a way to kick guys out and also avoid managing scattered throngs.

- The exit should never be close to where the throng starts.

- The game should end if no recruiters are left in the throng.

- The concept of "rooms" should inform what creatures get generated in a given space.

- Things could stand to look a little bit less terrible.

I shared this devlog with a friend after which I realized I hadn't touched this project for two weeks again.

So, I took a look again, and I thought of more stuff from the word game to fork than I initially thought. The smaller thing was using random tables to populate the levels instead of a bunch of if-else statements on a random number.

The more important thing is pushing (which, now that I think about it, originally comes from yet an older fork). So, these orange guys push whatever's in the way, and when recruited, can push for you.

At this stage in the project, I think 1-bit color (every sprite is black and white, then overlaid with color at runtime) and 16x16 sprites is the right choice. It doesn't look amazing, but it makes making sprites that are kind of OK really fast.

As for whether or not pushing is actually helpful, I unfortunately can't tell yet. There's not much to push so far, and if you push an alligator, they'll probably eat you right after that.

I feel like there has to be more than recruiting and eating to be able to tell if fun challenges can be made, though.

The hesitation I have about pushing is that it can lead to this becoming a block pusher, in which case I'll have to abandon randomly generated levels and carefully design levels by hand.

Maybe developing more dangers to deal with will help me figure out what's up with this game earlier.

This isn’t the greatest demo video, but it’s trying to show that I implemented acting without moving in the game. A couple functions were assuming that acting (biting, recruiting, someday pushing) would only happen if the acting things were also moving, so that had to be refactored. It wasn’t too terrible, considering I haven’t touched this project since September.