New Density Check System

[Flafla2]

Implemented a new "density detection" system where the level would check to make sure that there aren't too many monsters in each 5x5 set of tiles. The max number of monsters in each set changes per difficulty(easy=3 monsters, normal=7 monsters, hard=12 monsters, and nightmare is 100000 monsters(virtually infinite, pretty much what the game is now)). This system limits the possibility of huge swarms of monsters on easier difficulties.

[danielduner]

+1

[Flafla2]

Thanks daniel, giant monster swarms really annoyed me when I started playing. Hopefully this will get accepted and I won't get annoyed anymore :).

[danielduner]

That is the magic of open source :)
Scratch your itches!

[Flafla2]

That's a pretty awesome backscratcher if you ask me ;)

[Flafla2]

Well... are there any objections/complaints to this pull? So far I don't see any reason not to merge.

[master-lincoln]

I like the idea. Did you actually try if this suppresses huge swarms for you? I thought I also saw these swarms when no spawner was near...
The only thing that worries me a little is rebuilding the density map each tick.
For your approach you could also do that in the addMob method.

[eterzenbach]

it would be nice to have a switch for this... cause i like it, if you break a wall after some time and get swarmed with monsters

[Flafla2]

@master-lincoln I was thinking of adding a delay(ex. only update the density map every 10 ticks, or something like that). I can also go on your idea and do the check in the addMob method. Do you think that I should do either of those changes? Also, I have tested it a bit, and so far it shows good results.
@Elosanda The braking wall thing was actually what I was meaning to stop when I came up with the system.

[Ampa]

I think swarms are something that need to be considered in the greater scheme of the game design (especially from a single player perspective).

The game currently feels somewhat bland as a single player experience precisely because the action is so uniform. Think how much effort Valve put into the Director in Left4Dead to engineer periods of intense activity and moments of calm.

Rather than simply suppressing swarms they need to be engineered to occur at the right times. I believe that some of this will take care of itself once mob behaviour is refined, but some of it will come from a more sophisticated level design, where triggers can be added to shape the action.

[Flafla2]

@Ampa That sort of system shouldn't be too hard to implement, because the max densities per-difficulty are stored in a simple integer array. We could just get a synchronized random "swarm" timer, and if the swarm mode is on, all the spawners would increase their spawn rate, and the max densities would be raised.

However, that is probably another topic for another pull. I might work on that next.

[Ampa]

Slightly off topic but... my candidate for a swarm mob.

[xDreamCoding]

@Ampa +1

[Flafla2]

Heading back to this pull request topic, should I add a tick delay with the density check, or put the check into addMob()?

[danielduner]

@Elosanda and @Ampa
Those are good ideas. But I do believe that they are separate concerns. This pull request is about limiting the uncontrolled, random build up of enemies. It can easily be complimented with non-random swarm creation. So let's try to focus on one thing at a time ;)

@Flafla2
Regarding implementation, there is a class called BB in Math, It is used by Entities to get a list of nearby Entities from Level. It is (for example) used in Loot's tick() method to get a list of all nearby collectors. And that seems to work fine, without using any delays. So if you just use BB to check for nearby Mobs each time a mob is about to be spawned, that could do the trick.

[eterzenbach]

i didn't mean a switch in the options, just a boolean i could change locally to turn this behavior off.
ok, i just saw i could also change allowed densities for all difficulties to 100000, so forget i said something ;)

[Flafla2]

Okay, just moved the Density logic, see the commit above. Also, @danielduner Level.java already has a getEntities method that uses BB to check for mobs. That's what I used for the check.

[danielduner]

Aah! Well then, in that case there should be no need to add a delay.

+1 on merging (again)

[Flafla2]

Well then, are there any complaints/suggestions now?

[master-lincoln]

Yes...please remove the commented code. Then I'll merge this.

[Flafla2]

Okay, removed!

[danielduner]

Merging!