This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Enemy placement in screen-by-screen top-down game

Enemy placement in screen-by-screen top-down game
by on (#206144)
What way would you suggest for placing the enemy characters in a top-down game that scrolls screen-by-screen? (I.e. the enemies are loaded anew with every new scren.)

Declaring what kinds of enemies and how many appear on every screen is pretty simple.

But how do I do their initial placement on the screen if I don't want to have them start in a fixed location?

First of all, they shouldn't be allowed to appear too close to the hero. So, when the hero enters the screen from the left, they cannot be positioned too far on the left side, so that he doesn't get hit unfairly.

Then there's the problem that they shouldn't be allowed to be placed in tiles that are walls, unless they can fly.

I have an array of 16 x 15 bytes that defines which tiles are walls and which are walking ground.
So, generating a random number from 0 to 239 isn't a problem.
After generating it, I could adjust the value and move the position up, down left or right if the character would be too close to the player's side.

And if the value points to a wall, I could simply add 1 until it doesn't anymore, but this would mean that tiles right from a wall are more likely to be picked than other tiles.

But do you know of any other, more elegant ways of choosing enemy start positions on a screen?
Re: Enemy placement in screen-by-screen top-down game
by on (#206145)
Instead of adding 1, make clustering less obvious by choosing the next square Galois-style. Perform one bit of a CRC calculation on it.

Code:
jsr random8
placeloop:
  sta xyposition
  jsr evaluate_position
  bcc position_ok
  lda xyposition
  asl a
  bcc :+
    eor #$D9
  :
  dec total_failures_left
  bne placeloop
jmp clear_and_start_over
Re: Enemy placement in screen-by-screen top-down game
by on (#206146)
I have a bit trouble wrapping my head around this.

Can you please explain in prose what this code is doing here?
Re: Enemy placement in screen-by-screen top-down game
by on (#206147)
In Metal Gear, enemy placement is fixed and deliberate. For the most part, everything is balanced and fair; There's a few tough entryways that aren't, iirc. This has the side effect of rooms being predictable once you've learned them.

Zelda relies more on having enemies appear after a while. MG has that too, but less so. Unlike MG, Zelda will sometimes warn the player of their placement with a puff of smoke.

If you have the cpu time, you don't need to go from left to right row by row when placing enemies randomly. You can have a pregenerated array (fixed at assembly time) with all possible positions in a room semi-randomly shuffled. Then when enemy placement begins, pick a number (randomly) in that array to start from. Then step forward (wrapping around the array) until a legit position is found. Optionally draw a new seed for the next monster, or just step on*, rnse and repeat. You can also check for the position tested if it is too close to the player characters' initial position, so it's not only for wall detection.

*Just stepping on means certain patterns of enemy placement might appear. On the other hand, it should mean no monster is risking being placed overlapping another.
Re: Enemy placement in screen-by-screen top-down game
by on (#206148)
One solution would be to have a rough area where an enemy should start. The area would be, say, 5x5 metatiles. Instead of having an exact location for the enemy, you would indicate the location of the area, and have the enemy start in a random non-solid tile within the area. This way you can still design screens with a general sense of where enemies will be when the player enters the screen.
Re: Enemy placement in screen-by-screen top-down game
by on (#206151)
FrankenGraphics wrote:
In Metal Gear, enemy placement is fixed and deliberate.

Of course, fixed placement would be pretty mundane to design. I will actually do this additionally for specific opponents, but not for most.

FrankenGraphics wrote:
Zelda relies more on having enemies appear after a while.

This one would be a different issue, though. Even if an opponent appears some time later, you still have to apply the basic appearance rules. (Except maybe that you don't need to pay attention anymore to where the hero is standing.)
So, the question whether we use timing or not is a separate feature, but it doesn't influence the actual initialization code itself.

FrankenGraphics wrote:
You can have a pregenerated array (fixed at assembly time) with all possible positions in a room semi-randomly shuffled.

This could require a lot of ROM space.
Actual graphics are stored as variable-length meta tiles, so no matter whether it's a stone or a house, it only requires three bytes on the screen (x, y and meta tile index for a lookup array).
But also having a list of possible start points could be much. If only 25 % of all tiles are walkable, this is still 60 additional bytes per screen.

Celius wrote:
One solution would be to have a rough area where an enemy should start. The area would be, say, 5x5 metatiles.

I'm not sure whether this solves the issue. It still has pretty much all the problems that I have with the whole screen anyway: I still have to react to placement in solid tiles and I still have to take care that the enemies don't appear too close to the hero's side.
Re: Enemy placement in screen-by-screen top-down game
by on (#206153)
Quote:
This could require a lot of ROM space.
You only need one, and that will work for every room/screen. You could have more, but the use is debatable (maybe it could have some subtle effect on an area-for area basis for example, but it doesn't sound like it is worth it). I mean, if you're doing collision checks for monster spawning, that makes up for it not being unique to each particular room. EDIT: For clarity, the purpose of the array is to shuffle the order of positions you're stepping through. It is not directly tied to the layout of any particular room.
Re: Enemy placement in screen-by-screen top-down game
by on (#206155)
DRW wrote:
I have a bit trouble wrapping my head around this.

Can you please explain in prose what this code is doing here?

I'll take this as a request to repost my code with the comment detail cranked up to "scary":
Code:
; Choose a random number from $00 to $FF, where one nibble represents
; the horizontal (X) position and the other the vertical (Y).
jsr random8

; This is a label, a place where execution will continue later depending on
; decisions taken by other parts of the code.
placeloop:

  ; Save the X and Y positions for later use.
  sta xyposition

  ; Call a subroutine that determines whether the position in A is a
  ; valid placement for this object, based on not overlapping walls,
  ; distance from the player, etc.
  jsr evaluate_position

  ; The routine returns whether the position is blocked in the
  ; carry flag. Carry set means the position is blocked; carry
  ; clear means the object may be placed at the position.
  ; So if carry is clear, continue the rest of placement.
  bcc position_ok

  ; Choose a different position based on this one.  Start by
  ; multiplying the X, Y coordinates by 2, allowing the most
  ; significant bit of the coordinate stored in the low nibble
  ; to carry into the least significant bit of the coordinate
  ; stored in the high nibble.
  lda xyposition
  asl a

  ; Linear feedback shift register formula: If the multiplication
  ; by 2 overflowed, XOR the with the polynomial of the LFSR.
  bcc :+
    eor #$D9
  :

  ; This routine has a bug: if xyposition is chosen as 0, it never
  ; gets changed.  Fixing this is an exercise for the reader.

  ; If the placement routine has had to move too many things on
  ; this screen, it may have fallen into an unfixable situation.
  ; Remove all randomly placeable objects and start over.
  dec total_failures_left
  bne placeloop
jmp clear_and_start_over

Re: Enemy placement in screen-by-screen top-down game
by on (#206156)
FrankenGraphics wrote:
You only need one, and that will work for every room/screen.

One start positions array for the whole game (or a major number of screens)?
Do you mean it in a way so that all enemies can only appear in, for example, these places?
Attachment:
Screen.png
Screen.png [ 2.21 KiB | Viewed 2868 times ]

I don't think this would work. If the places have to be always walkable, that limits the level design too much (even if I have 10 different arrays).

And if I have to include collision checks with the ground, what's the advantage of the array? I could simply generate random numbers for my regular screen array and check the collisions just as well.

If this array is just a list of positions in the way that if one position is occupied, the game takes the next one in the array instead of the next closest tile on the screen, I don't really need an array.
I could just say:
Generate a position in my screen array.
If it is occupied, add the value n to it until the position is free.
After every check, turn n into another value (for example, n can be 1, 2, 3, 5, 7, 11, 13 or 17).
Re: Enemy placement in screen-by-screen top-down game
by on (#206158)
tepples wrote:
I'll take this as a request to repost my code with the comment detail cranked up to "scary"

Thanks.

That's the reason why I rather discuss general concepts instead of reading actual example code. It tends to have too much stuff that isn't really necessary for understanding the solution.

All in all, the only really important part of your code is this:
Code:
  ; If position is not possible:
  lda xyposition
  asl a
  bcc :+
    eor #$D9
  :
  ; Check again.

Although I still don't get why it's the value $D9. This is probably some mathematical stuff.

By the way, if it doesn't work after a certain amount of tries, instead of starting over I would simply start moving along the array entry by entry from the last position, so that it's guaranteed that I will definitely find a valid location in time. I mean, otherwise, that algorithm might fail hundreds of times.
Re: Enemy placement in screen-by-screen top-down game
by on (#206159)
DRW wrote:
I still have to react to placement in solid tiles and I still have to take care that the enemies don't appear too close to the hero's side.


This is true. The one nice thing to this approach is that you potentially could get away with manually positioning the areas to always be away from where the player starts. But this could create an issue if you have lots of screens that you can enter from all sides. You would have to position the areas to be away from the edges of the screen.

If the whole screen is up for grabs, I would personally go with the approach of picking a random tile on the screen and having a routine that validates whether or not that spot is allowed. The routine would test all scenarios where the tile is not allowed, and if it doesn't meet any of those conditions, it is allowed. The scenarios where a spot is not allowed seem to include:

-Solid tile
-Too close to player
-Another enemy is already in that spot

In the event that the routine says the tile is not allowed, you would just pick a new random tile and try again. Don't try to go up or down a tile from what you tested; just test a totally random, different tile.

While it's possible that there could be dozens of tests with a "not allowed" result, I doubt it would cause a big delay as the screen is loading.
Re: Enemy placement in screen-by-screen top-down game
by on (#206160)
Quote:
Do you mean it in a way so that all enemies can only appear in, for example, these places?
No, i mean the array would cover all coarse positions on the playfield (except outer walls etc, if any) that are nominally eligible for placement, but have their order shuffled in a way decided by the game designer. The point of such an array is that:

-You can somewhat finely control the likelyhood a position being a spawn point by including a certain position n times in your array.
-The array could potentially do double-duty as a defacto LUT for specific enemy placement when not looked up with a randomized index.
-You can easily exclude positions you don't want if your doors/openings will always be in the same spot (zelda dungeons).
-Shuffled is not the same as random. Depending on the length of the sequence, it may be possible for the player to detect the "designer's hand", or more importantly, learn the pattern, which may appear fairer than pure randomness. Tthere may be a connection to the skill roof. The observant player will learn what to expect and act accordingly.
-A bit of an afterthought: you can keep different arrays for different types of monsters to differentiate their spawn behaviour. Some may spawn more concentratedly in the middle, in corners, along walls. Some may spawn scattered, others more likely in clusters.
-You can have a smaller arrays and assigning it an offset if you can find a use for that.
Re: Enemy placement in screen-by-screen top-down game
by on (#206162)
What kind of game is this? Is it a completely designed interconnected world where you want to apply randomness to the enemy spawning in order to keep the game challenging and keeping the player on their toes?

Or is it a somewhat procedurally generated thing, where the "random" layout of each room is the essence of the challenge?


I'm a big advocate of well designed RNG in video games, meaning that any random descision isn't just white noise (such as in the image above), but based on a number of recognizable patterns or algorithms. A good example would be a boss fight where the boss has an array of different attacks it can use, but instead of distributing them randomly, some will be more likely than others - but the player can never be sure what to expect, so you'd have to keep your distance to see what the boss does before trying to countering it. And again, once an attack occurs that could be three bullets firing in the general direction of the player, but with a random offset between X and Y pixels, making it more challenging to dodge, forcing the player to gauge the action and react quickly.

The reason I'm mentioning this is that I think this applies very much to level design and enemy spawning mechanics, too. So if your games falls in the former camp of moving around through a designed level, I feel like the enemies spawning should be a part of that design, too. A simple example could be a room being set to have four skeletons, one gorgon and three killer robots, and each of those could have 5-10 different possible set spawn points that they populate randomly. That way a player who has played your game before knows what challenges they are going to face in the next room, but will never be able to anticipate the constellation.

I'm sorry in advance if this theory is not applicable to your game at all.
Re: Enemy placement in screen-by-screen top-down game
by on (#206163)
Quote:
meaning that any random descision isn't just white noise

Well worded. Randomness needs to be tamed/conditioned. It can sometimes be unpleasant without.
Re: Enemy placement in screen-by-screen top-down game
by on (#206164)
I agree with Sumez -- it depends on the game design constraints.

What I did in my GBA Anguna game (which has more processing time than the NES):
- some enemies have fixed positions, some are random
- I randomly pick an enemy position, if it's no good, I just try again. If it can't spawn after X number of tries, it gives up and doesn't spawn

What I did in my Atari Anguna game (which is more limited than the NES, and had a limited number of room layouts):

- For every room layout, I picked 8 different possible reasonable enemy spawn locations (far from doors where the player enters, not on a wall, etc), and randomly picked one. This ran into problems with extra-large enemies, but otherwise worked.
Re: Enemy placement in screen-by-screen top-down game
by on (#206165)
Celius wrote:
While it's possible that there could be dozens of tests with a "not allowed" result, I doubt it would cause a big delay as the screen is loading.


This is true. You can test a LOT of tries in the transition between rooms without causing a delay would bother the player.
Re: Enemy placement in screen-by-screen top-down game
by on (#206166)
Having a low number of spawn points per room is probably the most straightforward way to limit randomness. If you are reusing rooms, you also have to decide wether that is unique to each actual room clone, or just the room type (like how spawn points are decided in metroid).
Re: Enemy placement in screen-by-screen top-down game
by on (#206168)
DRW wrote:
All in all, the only really important part of your code is this:
Code:
  ; If position is not possible:
  lda xyposition
  asl a
  bcc :+
    eor #$D9
  :
  ; Check again.

Although I still don't get why it's the value $D9. This is probably some mathematical stuff.

That's what I hinted at with the name "Galois". Évariste Galois was a French mathematician who developed group theory and finite field theory, on which linear feedback shift registers (LFSRs) are based. You can try any of several numbers to ensure that you don't hit a loop too fast. In fact, I may have made an error in the choice of $D9.
Re: Enemy placement in screen-by-screen top-down game
by on (#206196)
DRW wrote:

Then there's the problem that they shouldn't be allowed to be placed in tiles that are walls, unless they can fly.

I have an array of 16 x 15 bytes that defines which tiles are walls and which are walking ground.
So, generating a random number from 0 to 239 isn't a problem.
After generating it, I could adjust the value and move the position up, down left or right if the character would be too close to the player's side.


Well, if you're going to place enemies semi-randomly, you can just pick a random place, and see if it is excluded. Then, if the place is excluded, you just repeat the random number generation again, and loop until you end up having a place which is not excluded. It is excluded if it falls in one of the cases you mentionned : Too close to the player, a non-flying enemy on a solid tile, or another randomly placed enemy already being there.

This can take more time but since it's when the room is loading and not during action, this is a non-issue.
Re: Enemy placement in screen-by-screen top-down game
by on (#206198)
About the whole issue of "pick random spot, if it doesn't work, pick another one": The problem that I have with this is the unpredictability. Moving away from an unallowed tile in a specific fashion will eventually reach a valid tile. But doing another random value means that this could potentially happen very, very often.

FrankenGraphics wrote:
No, i mean the array would cover all coarse positions on the playfield (except outer walls etc, if any) that are nominally eligible for placement, but have their order shuffled in a way decided by the game designer.

I still don't quite understand how you mean it.

Sumez wrote:
What kind of game is this? Is it a completely designed interconnected world where you want to apply randomness to the enemy spawning in order to keep the game challenging and keeping the player on their toes?

It's "Zelda"-like, i.e. completely designed. Fixed positions for certain enemies are of course also possible, but that's a mundane thing to program and doesn't require a thread. (Likewise, enemy movement is a totally different topic altogether.) But I'm looking for good ways for randomly or semi-randomly appearing enemies.

FrankenGraphics wrote:
Having a low number of spawn points per room is probably the most straightforward way to limit randomness. If you are reusing rooms, you also have to decide wether that is unique to each actual room clone, or just the room type (like how spawn points are decided in metroid).

Fixed points per room is the simplest to program, but it requires a lot of ROM space. And if I only use six positions or so, that's pretty limited.

I assume rooms on the overworld won't be reused that much. Although I might consider this for dungeons. But even then, it's only the layout, not the enemy placement.


What algorithms does "The Legend of Zelda" use?
Re: Enemy placement in screen-by-screen top-down game
by on (#206202)
Quote:
I still don't quite understand how you mean it.


Suppose all spawn points are aligned to the attribute grid (they don't have to, but for the sake of making an example).
You'd have all possible spots labeled* like so:
Attachment:
Untitled.png
Untitled.png [ 22.58 KiB | Viewed 2293 times ]

That's our imagined table of spawn point ID:s.

A row is 0-F for making it easy for us to understand what position it represents.

Now, we create a shuffled array:
11, A1, AE, 1E,
22, 92, 9D, 2D,
11, A1, AE, 1E,
33, 83, 8C, 3C,
(add in all you want - but exlude outer walls and doorways)

The array points to which of tile an enemy is spawned. In this example, since 11, A1, AE, 1E appear twice as often as the other ones, they (the corners) are twice as likely to be positions where enemies spawn. It's like having a modified deck of cards where some cards would appear twice, thrice or not at all. Also, the deck is rigged in a certain order.

With the one and only array-approach, you'd want all legit positions to appear at least once. With more arrays, they can be smaller and exclude certain spots if you want to. For example, it could be enough for a certain enemy type to only be able to spawn in corners, in which case you'd need only 4 bytes for that monster type. You'd better move their priority up in the list, then, as their spots are few. Another monster type may only spawn in a centered quarter of the screen. You get the idea.

The pick position procedure could be as follows:

Randomize an index.
Start there.
Vacant spot?
- if yes, place enemy, dec index (or alternately randomize index again). if index = 0, start from top, pick next enemy to place.
- if no, dec index. If index = 0, start from top.
Loop until all enemies in the list are placed or in case there are no vacant spots left to place in (fail level count?), escape.

This way you could tailor 'randomness' pretty efficiently, at the cost of having at least one array. With more arrays, you can have varied "patterns of likelihood".


*It's a mental labeling - you don't need to store this information in ROM. The integers stored in the array can be used for moving the spawn decision to the correspondent position.

Quote:
What algorithms does "The Legend of Zelda" use?

I don't know, but there's a disassembly here:
http://computerarcheology.com/NES/Zelda/


Post script:
I originally got this idea when contemplating the fortunate/unfortunate side features of the 'random table' in the Lone Wolf adventure book series.
Attachment:
AC297c1.jpg
AC297c1.jpg [ 66.71 KiB | Viewed 2286 times ]

It was the game constructors' intention to work as a makeshift die. You'd close your eyes and point your pen, and see what you got.
The fact is that the player will get familiar with the table and know what regions have high numbers, low numbers, high risk, low risk and so on. In this particular game, i think it's bad because it is meant to substitute a ten-sided dice but works nothing like it. There is potential, however. You can modify the chances of certain numbers by modifying their rate of appearance. You can modify the width of relations to neighboring numbers. You can modify the algorithm which picks a cell (you could have a set of methods how to pick a number). And the fact that the player can learn patterns can be used for good, because what you want is not randomness - it is patterns with a touch of chance large enough to keep the player alert/previously explored areas fresh.
Re: Enemy placement in screen-by-screen top-down game
by on (#206211)
DRW wrote:
About the whole issue of "pick random spot, if it doesn't work, pick another one": The problem that I have with this is the unpredictability. Moving away from an unallowed tile in a specific fashion will eventually reach a valid tile. But doing another random value means that this could potentially happen very, very often.


Is your concern getting stuck in an endless or very long loop where you keep testing random tiles that aren't allowed?

If your RNG code is pretty reliable, this shouldn't be an issue, as eventually all tiles will be tested in a time span that is not perceivable to the player. I do understand the paranoia, and lack of comfort relying on something random, because even though it's super unlikely, the player could "win the lottery" and be forced to wait through a hundred thousand tests that result in "not allowed". The funny thing is that even that might take less than one second.

The main problem I suppose is that you might test the same tile more than once if you just leave it random. A simple solution is to have an array with values 0-239, and shuffle that array. Start at the beginning of the array and test that value. No matter what the result is ("allowed" or "not allowed"), you just move on to the next value. This would also simplify the criteria for "not allowed", because you wouldn't need to check if an enemy has taken one of the random tiles. Once a tile is tested, it's never tested again.
Re: Enemy placement in screen-by-screen top-down game
by on (#206224)
DRW wrote:
The problem that I have with this is the unpredictability.

If you're relying on a RNG the result is obviously going to be unpredictable. However, for reasons mentionned by Celius, this is acceptable when loading a new room. It would not be acceptable during action.

Personally in my game which is also screen-by-screen and top-down, I have enemy placement with one nybble (4 bits) for each of X and Y placement. It's not like it's a LOT of ROM space to waste one byte per enemy... Since the bosses and possibly teasure chests have to be placed at a specific place, you need a way to have non-random placement anyway, so I doubt adding random placement on top of that saves any ROM space, even if it saves one or two bytes per enemy who uses it, the code doing it might largely compensate that. However purely gameplay wise I imagine random enemy placement might be much more interesting and less repetitive, especially for replaying the game a 2nd time. You could also have difficulty levels, and more easily add new enemies without changing much else.
Re: Enemy placement in screen-by-screen top-down game
by on (#206246)
Bregalad wrote:
Since the bosses and possibly teasure chests have to be placed at a specific place, you need a way to have non-random placement anyway, so I doubt adding random placement on top of that saves any ROM space, even if it saves one or two bytes per enemy who uses it, the code doing it might largely compensate that. However purely gameplay wise I imagine random enemy placement might be much more interesting and less repetitive


That's exactly why I supported both. Some rooms really need a specific placement to work correctly. Some benefit from randomness to keep them interesting.
Re: Enemy placement in screen-by-screen top-down game
by on (#206275)
My solution would be probably randomizing position again until it isn't near the player or in a wall.

So the algorithm would be (in pseudo code)

1. Randomize enemy's position
2. If the enemy is in the wall or too close to player, go to 1, else carry on.
Re: Enemy placement in screen-by-screen top-down game
by on (#206333)
Honestly, I don't think saving cartridge space is a good enough excuse to make enemy spawning completely procedural. You need at least some kind of setting for how spawning behaves in each room if you want the game to work well, though of course I guess that's just my opinion. :)

If cartridge space is an issue, find a way to compress the data.
With my previous suggestion of having some preset spawn points chosen at random, one effective way to save space would be to make each zone relatively large, for example a 32x32 bit tile, or even 64x64 (meaning each enemy type's spawn map could be contained in a single 16bit bitmap per room!), and just make sure at least one tile within that larger tile is always a valid location (so if you spawn a 16x16 enemy on a 64x64 tile, you'd just pick a new random number & $0F, and increase the index until you find a valid tile).
You could also have more complex spawn maps but reuse the same ones across multiple rooms or enemy types, since you'll probably often find yourself repeating very similar spawn patterns even in rooms that are otherwise very different in their deisgns. Then each spawn map would always be a single 8 bit index at worst.
Re: Enemy placement in screen-by-screen top-down game
by on (#206337)
Thanks for all the suggestions.

In the end, we decided for a pretty simple way that has also been mentioned here:

I will generate a random number and if it isn't a valid spot, I'll do this a few times more. If it still doesn't work after, for example, 10 times, this specific opponent will not trigger at all and the player was lucky.

This way, the algorithm is very easy, without lookup tables or some additional rules. And it has a definite finish point for the rare case where the randomizer really cannot find a suitable location.

Sumez wrote:
Honestly, I don't think saving cartridge space is a good enough excuse to make enemy spawning completely procedural. You need at least some kind of setting for how spawning behaves in each room if you want the game to work well, though of course I guess that's just my opinion. :)

I don't think that's necessary. If the monster can walk to any point on the map that's not a wall, it can also spawn on any point of the map. If I have soldiers who attack in formation, I will skip the radomization in the first place and simply put them in fixed positions. But if I have a horde of wolves, why shouldn't they be in completely random locations?

Sumez wrote:
If cartridge space is an issue, find a way to compress the data.

It's not only the cartridge space, it's also the hazzle to define this for every screen.
So, you don't just have the actual layout of the screen, but also tactical rectangles for enemy placement. Nah, that's too complicated.
Re: Enemy placement in screen-by-screen top-down game
by on (#206344)
DRW wrote:
If it still doesn't work after, for example, 10 times, this specific opponent will not trigger at all and the player was lucky.

I think it's a very good call to have a fallback like this.

There are simple cases where you can guarantee your PRNG will eventually produce a valid result, but it's very easy for edge cases to slip through the cracks when you start adding all the little constraints that come up in a real system.
Re: Enemy placement in screen-by-screen top-down game
by on (#206347)
Quote:
But if I have a horde of wolves, why shouldn't they be in completely random locations?


I think that's a good approximation of a "disorganized", "chaotic" or even "wild" trait, and wolves would fall in the third category. :)

one could also think of wolves having a lookput at the point with the best view, and it will call its pack when in line of sight. Those could either be randomly placed or come in from the edge of the field.

I think that's the options i'd consider for spawning wolves.