• User experience: Anything that's uncomfortable or not obvious from playing the game alone should be reported as an issue.
• Balancing: The game aims to be approachable and not overly challenging. But we need to know how you feel about it.
• Map design: The map design is on its first iteration. We want to learn as much as possible about it.

• Enemy count
• Heat

density = enemyCount / heat

tension = targetDensity / density

• If the chunk is at the target enemy density, it has a value of 1.
• If the chunk has a lot more enemies than it should, its value gradually go towards zero.
• If the chunk has less enemies than it should, its value will quickly raise
  
  The mathematicians are screaming into the monitor as I am explaining division to the crowd. "Look at what gamedevs need to mimick a fraction", or something
  image.png
  But tension was the main ingredient here: When it's time to spawn an enemy, the Game Director will rank chunks by tension, and favor those with higher tension. Picking an element from a list at random with weighted probabilities was a recent topic of discussion, so I won't delve into that.
  
  There's some twists I added to the idea, for extra chaos. Heat is typically computed by checking things in that chunk, like chests and whatnot. Each chest adds some heat, barrels add some heat too, and so on. But then I added a noise function on top, so even if two chunks have the same amount of stuff in it, some chunks will tend to be a lot more densely populated than others, just like life itself: And to you, the player, the real reason behind this variance is that I'm sure those slimes have a plan which makes them have some areas more heavily guarded than others.
  
  I mentioned at the start of the section the game director had two goals: It turns out, the two goals are actually one and the same. A nice property of this system is that Initial spawn and respawning are two sides of the same coin. You start with an empty map, and you keep spawning enemies until you're satisfied!
  
  It's hard to show this in action since the point is to feel it over the course of the run, but this was my best attempt in a short looping gif:
  image.png
  And then the FPS dropped
  
  But no tale is complete without some performance testing. What's this I see? 45 FPS in my debug build? No, that won't do.
  
  Spawning enemies near the player has some advantages. You get to play smoke and mirrors with them and despawn enemies once they venture too far off. When it's you against the horde, nobody will notice a missing bat. But now that there's enemies all over, I couldn't pull off this trick anymore. It only took a quick glance at the profiler to notice the issue. Hear me out now: Invest some time into having a good profiling system!
  
  The solution? Simple! Every performance issue can be solved in one of two ways: (1) Do it faster, (2) Do less work. Since my enemy logic is a port from Carrot Survivors, I know it was pretty optimized already: zero-allocation, uses a fast path for the spatial partitioning logic that's specific to enemies... So (2) was the obvious choice.
  
  The next best thing you can do when you can't despawn faraway enemies is to freeze them. And that turned out reasonably well! I also took the chance to add culling logic to my Sprite component, which I hadn't had the need to until now (because most things in the game are tiles or grass and those are culled!).
  
  Closing
  
  Anyway, I hope you enjoyed the devlog! I tried to go for a longer one this time, but I think it was time well spent. If I get to be a little selfish, please do let me know if you enjoy these. Gamedev can feel a bit lonely sometimes and despite what it might seem, morale among the carrot ranks hasn't been the highest.

Attachments

image.png (873.68 KiB)


enemyspawn.gif (9747.26 KiB)


image.png (20.24 KiB)

Kampffrosch wrote: Wed Mar 11, 2026 6:48 am I try to always carry a cheap a6 notebook in my pocket, so I can just jot down some thoughts or tasks for later and free up my mind in the moment.

celes wrote: Wed Mar 11, 2026 12:09 pm physical calculator

• Hmmm the game is too easy, let's improve the stats of this monster.

• Hmmm now the game get's unbeatable because there aren't enough sword items so I can't hit the serpent, let's add another sword item to the level

• ...

Attachments

image.png (345.63 KiB)


image.png (38.02 KiB)

no formal proof for you

Sugui wrote:Just where it hurts

I have an array of N elements (representing the N letters of a given alphabet), and each cell of the array holds an integer value, that integer value meaning the number of occurrences in a given text of that letter. Now I want to randomly choose a letter from all of the letters in the alphabet, based on his number of appearances with the given constraints:

• If the letter has a positive (nonzero) value, then it can be always chosen by the algorithm (with a bigger or smaller probability, of course).
• If a letter A has a higher value than a letter B, then it has to be more likely to be chosen by the algorithm.

Now, taking that into account, I've come up with a simple algorithm that might do the job, but I was just wondering if there was a better thing to do. This seems to be quite fundamental, and I think there might be more clever things to do in order to accomplish this more efficiently. This is the algorithm i thought:

• Add up all the frequencies in the array. Store it in SUM
• Choosing up a random value from 0 to SUM. Store it in RAN
• While RAN > 0, Starting from the first, visit each cell in the array (in order), and subtract the value of that cell from RAN
• The last visited cell is the chosen one

So, is there a better thing to do than this? Am I missing something?

I'm aware most modern computers can compute this so fast I won't even notice if my algorithm is inefficient, so this is more of a theoretical question rather than a practical one.

I prefer an explained algorithm rather than just code for an answer, but If you're more comfortable providing your answer in code, I have no problem with that.

The idea:

• Iterate through all the elements and set the value of each element as the cumulative frequency thus far.
• Generate a random number between 1 and the sum of all frequencies
• Do a binary search on the values for this number (finding the first value greater than or equal to the number).

Example:

Code: Select all

Element    A B C D
Frequency  1 4 3 2
Cumulative 1 5 8 10

Generate a random number in the range 1-10 (1+4+3+2 = 10, the same as the last value in the cumulative list), do a binary search, which will return values as follows:

Code: Select all

Number   Element returned
1        A
2        B
3        B
4        B
5        B
6        C
7        C
8        C
9        D
10       D

Attachments

image.png (89.86 KiB)

• Get a hold of the "scene", "map", "world" or whatever it may be. This could be an ECS if you're one of those. You also want to query that scene. I don't use an ECS but I still want to get the "EnemySpawner" from the scene, or iterate all instances of Player. There's various ways to do this. My point? I need the ability to do this everywhere because it keeps coming up everywhere.
• Play a fire-and-forget sound effect. Seriously, playing the sound effect goes next to the line of code that performs the action that produces the sound effect. You can't convince me otherwise. If you have opinions about this, don't show me your "clean code", show me your sound design.
• Firing off tweens. Similarly, I want the ability to fire off a tween pretty much anywhere. I'll write about how I do tweens some other time but this is the kind of thing I want to do at a "print" level of convenience. I want my game to be juicy so animations are everywhere. I cannot work with the mindset that there's some "animator" that looks at the pure state of the game world and makes decisions based on that. But that might just be me.
• Drawing debug and non-debug geometry, but especially debug geometry. If your "framework" doesn't let me call a bunch of draw_line and draw_rect to debug one of those tricky computational geometry snippets I am awful at, you've already lost me. No I don't want to spawn a "DebugRenderer" in the scene so I can get a hold of it. That's as dumb as passing a "printer" around to just print.

• Scene Globals: These live in the scene. Accessing them means getting them from the scene tree. If you change scenes, you get a different set of globals. So, every access goes through some logic to get the currently active scene, then pick the thing from the currently active scene. You can replace scene with ECS if that helps you sleep at night, but my point is these have to be accessible from anywhere: No passing around, no funny dependency injection shenanigans.
• Game Globals: These are true globals, just one for the duration of the program. They use static variables, or whatever it is that your language calls them.

palas wrote: Sat Mar 14, 2026 12:40 am Types 1 and 2 are in the safe category, so spamming them won't hurt too much. When it comes to 3, they directly affect how well can one reason about the codebase locally.
This is still mostly unsolved for me. It's not about whether or not to use them (can't really gamedev much without at least some global scene/level manager), but how to design in a way to keep as much locality as possible. For example, if I'm storing references to game objects, they can still be deleted from anywhere else. What happens if they do get deleted? Idk

if (SceneGraph.GetFirstEntityInGroup("Player") is not {} player) return;

if (SceneGraph.GetFirstEntityInGroup("Player") is not {} player) return;
TweenManager.Spawn(..., tick: (t) => {
    player.color = somethingSomething(t);
});

Palas wrote: As for the API to handle potentially missing entities... The first thing that comes to mind is Handle<T> with the following api:

Code: Select all

fn Entity::handle(self) -> Handle<Self>;
fn Handle<T>::get(self) -> T?;

As an owner of a steam controller, I know how annoying it is when games use mouse movement as an indicator that the player is using keyboard and mouse, so I'm not gonna do that.

Using keyboard input as a predictor that the player is playing with their mouse is thus not possible.

Problem is, if my code has any sort of special logic that depends on the input device, as I described above, I need to undo that, and... check each input device manually?

if Input.Pressed(InputAction.Attack) is action {
  match action { 
    ActionType::Mouse => {},
    ActionType::Controller => {}
  }
}

I'm very mad no other engine has it.

palas wrote: Mon Mar 16, 2026 3:04 am A bit confused by this. Even if the player uses the mouse to attack, they are still using the keyboard for movement. Could attack action be bound to both mouse and keyboard at the same time? That way, both styles are combined in one.

palas wrote: Mon Mar 16, 2026 3:04 am Ha! Before you showed your API, I've pictured something like:

palas wrote: Mon Mar 16, 2026 3:04 am Most likely another classic instance of "we do whatever is most simple for a beginner, any slightly more complicated use case is the user's problem".
But, surely every half competent engine has a way to tell whether a mouse or a controller is used, and process each one separately? This is such a fundamental feature after all.

• ! (pronounced as "never") is a special type, which can never be instantiated. It has an important property of being auto-convertable to any other type. This is useful for language primitives that affect control flow. For example:

  Code: Select all

  //this function never exits
  fn panic() -> ! {
    ...
  }
  

  Code: Select all

  let opt = Some(10);
  let value: i32 = match opt {
    Some(v) => v,
    None => panic!("it crashed"); // ! is converted to i32, as in this branch we never return anyway
  };
  

let x = foo(return 5);

let x = match value {
  Some(v) => v,
  None => return None, 
};

=> { return None; }

fn zombiejesus() {  
    loop {  
        while (return) {  
            if (return) {  
                match (return) {  
                    1 => {  
                        if (return) {  
                            return  
                        } else {  
                            return  
                        }  
                    }                    
                    _ => { return }  
                };  
            } else if (return) {  
                return;  
            }  
        }        
        if (return) { break; }  
    }
}

let x = {
  { return; };
  5
};