Skip to content

New Density Check System #739

Merged
merged 4 commits into from Mar 4, 2012

6 participants

@Flafla2
Flafla2 commented Mar 4, 2012

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
Flafla2 commented Mar 4, 2012

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
Flafla2 commented Mar 4, 2012

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

@Flafla2
Flafla2 commented Mar 4, 2012

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

@master-lincoln
Collaborator

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.

@Elosanda
Elosanda commented Mar 4, 2012

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
Flafla2 commented Mar 4, 2012

@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
Ampa commented Mar 4, 2012

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
Flafla2 commented Mar 4, 2012

@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
Ampa commented Mar 4, 2012

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

@Flafla2
Flafla2 commented Mar 4, 2012

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.

@Elosanda
Elosanda commented Mar 4, 2012

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
Flafla2 commented Mar 4, 2012

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
Flafla2 commented Mar 4, 2012

Well then, are there any complaints/suggestions now?

@master-lincoln
Collaborator

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

@Flafla2
Flafla2 commented Mar 4, 2012

Okay, removed!

@danielduner

Merging!

@danielduner danielduner merged commit 00e2a11 into Maescool:develop Mar 4, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.