Turns out the "victory timer" idea wasn't a very good one after all. I need something more concrete for the players to do to achieve victory instead of just surviving. The gameplay is about making progress, so winning should be as well.
I'm trying out something but it still needs some work...
I made the goal of the game very simple, a bit like "survive this long" but instead made it display a percentage after your spacecraft is repaired on the surface of the moon and you can leave. It could've been pretty much anything that takes time, but a spacecraft sounded like it'd fit in. By destroying the zerg hatcheries, you gain zerg biomass which is (automatically for now) used to clone people and increase your "human resources" value, which in turn speeds up the victory progress (more people figuring out how to fix the ship).
The problem with this is that now destroying the hatcheries as soon as possible has become very crucial, because killing them accelerates your progress speed instead of just gives you a step in your progress. I still like this as an idea but I'd also like something to not make killing them always a top priority. Maybe something like "if you don't kill a hatchery before a timer runs out, the zerg gets stronger".
I figured out a fun way to make the players aware of where the hatcheries are: There are randomly spawning larvae on the map, whose only function is to get to a hatchery, and they do so by crawling through the rocks (and everything else too). They can't be killed or even targeted, and they are so small that they don't distract the gameplay in any way. If a player wants to find a hatchery, all they need to do is to spot a larva and go to the direction it's headed (I'll probably make them zigzag a bit later on).
The Research Lab must first be built, and isn't exactly cheap. After that, you can start researching one of the available researches, which takes around 2-5 minutes based on the research, and also requires an amount of power during that time, which also depends on the research... so some researches are fast but require a lot of power (a lot of power generators), and some are slow but a bit less energy-consuming. The more energy that's being used, the more vespene gas is consumed. Getting those gas-preserving upgrades early can be very rewarding on the long run, which is why I made their costs quite high.
After a research is done, the researched thing must be applied separately to every structure or every unit it affects, which happens instantly by using an ability on that structure/unit, but costs resources. Some researches allow SCVs to craft tools that stay on them until they die. The tools are rather cheap, so losing them is just a little penalty for dying. Other researches enable structure upgrades, such as blueflames for turrets or microfiltering for refineries.
I can't add any more moving units for the players than one for each, and anything else that moves in fog of war can't be visible by the players, because of the way the rocks are spawned/despawned dynamically. Enemies move in darkness burrowed, so that pathing is not an issue for them.
One idea I had is that the zerg hatcheries are actually sitting on some protoss relics which the players then uncover by killing the hatcheries... Because protoss just has a lot more interesthing stuff that terran could use for this kind of tech, like the Warp Cargo ability. But still, nothing concrete yet.
Don't they have far longer connection range than turrets? Also, you could make power transfers one-way when powering turrets similar.
I had it one-way previously but it was bad for consistency. I don't want the power grid to become any more complex than it needs to be, and it's working pretty nicely at the moment. All cables can reach pretty far (9 squares I think) and anything longer than that would stretch the cable models by too much, and even with custom models, having insanely long cables just doesn't seem right. I also like the fact that you need to pay more if you want to take the cable further away. The relays being invulnerable doesn't feel too awkward, since all it means is that enemies will ignore them completely, just like they ignore the power cables.
I was going to try tinting the blueflame model, but the model is specified in some other field than Art: Model, and for some reason changing the actor's tint didn't tint the flame model at all. I'll look into it later since it's not too important for now.
More progress today!
I created Microfiltering research which gives Refineries an upgrade (that must be done separately for each Refinery) that increases the total amount of vespene refined from raw gas by 50%, and also the vespene storage capacity of the Refinery by 50% (so that it doesn't fill up any faster).
I removed a rock type from the game that was essentially just a copy of another rock, but looked different, had more health, and required the best mining tool to break in reasonable time. This was previously to limit the players from wandering too far from the start, but now it doesn't really matter if they do. It just added confusion.
Hatcheries now show up on radar from 25 squares away, but the system to find them doesn't feel good yet. They just show the tiny radar dot just like normal units do. I'm not sure how to make searching for them more interesting... Any ideas for that? I also need killing hatcheries mean something more than just slowing the enemies down by a bit, possibly rewarding the players with some research options or something. Just need to figure out what exactly.
The map is still very difficult to get into without anyone telling you what to do, so I'll probably need to rework the starting part a bit, even though I have a sort of a tutorial set up already. Stuff gets going way too quickly for players to have time to grasp everything. But once you get the hang of it, it gets really fun (at least for me and some others I've played with).
Well, there's plenty of playable content already (about an hour if all goes well), but I haven't tested the map with more than 4 players ever, so jumping straight to 8 might be a bad experience... but it needs to be tested one way or another. If it looks bad, I might decrease the maximum to 6.
Today's progress report:
I've made a "blueflame throwers" upgrade for turrets, just couldn't get the actual model changed because the hellion's flamethrower just looks bad on the turret even when scaled to fit the area. The upgrade increases their damage by 50%, but needs to be first researched at the lab, and then upgraded individually for each turret.
Another ability I added is Repair Drones, which can be activated remotely every 1-2 min per player (depending on number of players). They rapidly heal a structure over 10 seconds, using the fire suppression bot model.
I made the "Power Relay" structures invulnerable because they were pretty useless otherwise, as they just kept dying if there was no turret nearby to protect it... and if there was, the turret could've been used as a relay just as well. All structures have a small area around them that is always passable, so it's not possible to block any routes with them.
I've also tweaked balance a lot, so hopefully the next playtest will be even more fun than the previous one (which was rather fun even though it was still very unbalanced).
I just had a 1.5 hour test with 2 players and it seems it's more difficult to build *enough* structures than build too many of them, hehe. I think it will be just fine, just needs a lot of balance testing.
I'm not sure what you mean. My resources are trigger variables, and I can't really upgrade those. Maybe if I'd store the values in some arbitrary data objects, like hidden units, and read and write them from those... but either way, I don't want to make the costs of structures change during the game. The whole idea is unintuitive, would just add confusion, and there wouldn't really be any explanation that'd make sense why a structure's cost would increase if there already was another structure of that type.
@yukaboy: Go
That seems unintuitive, and there's no way to modify ability tooltips on-the-fly, which prevents me from changing cost displays during the game (unless I'd make a separate tooltip for every possible variation of them). A downside of having an entirely trigger-based resource system...
There's no reason to make the structure limit look like a structure limit. It can just be the fact that there are too many enemy attacks going on to be able to maintain that many structures, which is how it's currently implemented. I just need to find a good balance for how much time the players need to spend repairing their structures.
Once I get some production upgrades done, it'll also be more cost-efficient to upgrade a structure instead of building another one.
Sorry for the unclear and confusing explanations, I haven't gotten much sleep during the past week. :P
Alright, so I continued mapping again and got a bit closer towards a playable map. There's one issue which makes designing quite difficult: I'm not sure how many structures I can allow the players to have up at one time. I'd need a 8 player stress test with resource cheats to figure that out, and I'd probably need to get lucky to get something like that organized.
Furthermore, even after I know the structure limit, I still need to figure out how to actually keep the players within that limit. I don't want to just block them from building structures when they reach it, but make the actual gameplay work so that it's difficult to get even close to that limit. What currently allows this is the fact that structures need to be repaired, and if there are a lot of structures, it'll take a lot of time to run around the whole base and keep their health up... but that's also rather annoying.
One possible solution is that at some point, the players will be required to start digging... deep. That'll decrease the amount of time they can spend repairing their base, so I could let them upgrade the base enough to keep the baddies at bay for long periods of time. There already is one gameplay element that is supposed to do this: Destroying zerg hatcheries will decrease the number of enemies that spawn (and it then continues increasing over time as usual), and getting to the hatcheries through the rocks takes time. I guess I'll try to balance the gameplay to work with the current features, and then start adding more interesting things in.
I've also implemented the Warp Cargo ability. It needs to be researched at the Research Lab first, and then crafted by each player. It allows you to warp your cargo directly to the Command Center once every 2 minutes (might change the cooldown). Its cost includes a bunch of Rare Elements, which is a new resource I added. It can be found with a very small chance from common rocks, but there are also some red mineral crystal fields around the map that give a bit more of them when mined.
The biggest thing that's still missing is structure upgrades, but it shouldn't take too long to get a couple of them done.
I was afraid this would happen, but I have once again started a project that would take too long to even become properly playable. The way I have it planned at the moment is a progressive story-like gameplay where you move further and further into the map. What might still save the project is turning it more towards sandbox gameplay, so that I could release the first playable version much sooner than what the current plan would allow, and get motivated by playing it with others.
What I mean by sandbox is that the map wouldn't have any straightforward goal, and the gameplay would be very random at times. If done well, it might even turn out more interesting than semi-linear progression. I should've gone for that from the beginning, so now I need a big overhaul to get back on the right track.
Edit: I just opened the editor. I have an idea... :3
It hasn't been that long since I even started the project (about two months). I've been busy for a month or so with other things (one of them being Skyrim, but I'm done with that now... took an arrow in the knee if you know what I mean), but as soon as I have time to continue mapping, it will be with this project.
Minecraft, for example, also uses fixed random seeds to generate its maps. Procedural generation has been used since the early days of computer game development.
Don't worry about the teleportation, it should be simple enough to just give it a small delay during which the environment can be spawned.
I'm currently working on enemy base system and tying it up with the enemy attack wave system.
The idea is that each attack wave has a (slightly randomized) number of enemies which increases over time, and additionally each enemy base gives a small bonus to that number, which also increases over time for each active base. The closest enemy bases to the players are active early in the game, and the more time elapses, the more bases become active and start increasing the number of enemies to attack. When the players destroy an enemy base, it stops adding that bonus to the number of enemies in the attack waves. This way destroying the bases is beneficial, but isn't absolutely necessary either, since it only helps by a small factor.
Destroying the bases has other benefits too, however, possibly allowing the players to harvest "zerg biomass" or some similar resource which can then be used to create regenerative materials, for example (any ideas for zerg tech, by the way?). To destroy the bases, the players need to build battle tech, since it's not possible to build turrets near the zerg structures as they are surrounded by creep.
Each enemy base also has defensive waves of units, which spawn when players are standing on creep near the base. The defensive waves have a cooldown on each enemy base. Enemy units move faster on creep, making it impossible to destroy the bases by using only SCVs.
Enemy bases aren't visible on the map (at least not at first), but since they are surrounded by a large area of creep, they are rather easy to find.
The first thing that spoiled the immersion for me was seeing the zergling running towards the camera from far away. The enemies would be much scarier if they'd circle around you in shadows rather than running straight at you. The UI also seems way larger than it needs to be, taking away some of the immersion.
I'm also a bit sceptical on how FPS works in multiplayer. I'd much rather see this as an offline singleplayer map, because that's the only way to have decent WASD+mouse controls in SC2. Even if it's "slow and steady", lag with keyboard controls is too annoying for me. But then again, I'm the guy who almost ditched Skyrim because the controls felt too awkward. Even after tweaking and getting used to them and noticing how great the game is, the controls still make me grit my teeth from time to time. Anyway, my point is... don't underestimate the impact that good controls have on making a game good.
Furthermore, horror works much better when playing alone. Multiplayer just takes you right out of the game world.
I added a close-up screenshot of the power cables to the first post.
In case anyone is interested in the technical details on how the minable tiles work:
Spawning multiple units at the same time can be very heavy for performance. I've spent a lot of time optimizing this and it now works very smoothly. When a player moves from one tile to another, a function is called that despawns all rock units that are now far enough from the player, and spawns new rock units in the direction where the player is moving to. This means despawning and spawning about 17-34 units at a time (depending on whether the player moved diagonally or not). Additionally, since a player can't move across a tile in less than 0.5 seconds, I have spread the tile spawning so that on one script engine frame (0.0625 seconds) it only spawns and despawns tiles for one player, and because the player limit is 8, all players are handled within 0.5 seconds. This means that at most 34 units are despawned and at most 34 units are spawned during one frame, causing no performance issues.
It would be possible to have more than 8 players (or player units), and just handle rock spawning for more than one player per server frame, but that'd then cause issues with the number of simultaneously existing units on the map. To not have too many units in the map with 8 players already, I have solved this by only spawning the minable rocks around the players, and not spawning rocks that are completely surrounded by other rocks. A player can see on a radius of 7, and the rocks are spawned in a 17*17 square around the player (8 tiles to all four directions around the player).
In worst case, this approximates to about 2000 rock units existing at the same time, but the worst case is not very likely to happen because there's almost always some empty space near the players as well. This means a bit more rocks than there can be supply-using units in a normal 4v4 melee game (unless everyone's a zerg and only uses lings), but since the rocks don't move and no pathfinding needs to be computed for them, this amount should be alright for performance.
One last point: how the positions of the rocks are stored in memory. Well... they aren't. I have a function that generates random noise based on a fixed random seed, and I call that function to get the rock type on a specific tile. When a rock is despawned and then spawned again, it is randomized in the same way every time during a game, because the random seed is only randomized when the map is loaded.
When a rock is mined, I save a boolean value "true" in the global data table for those coordinates. When I'm about to spawn a rock, I check whether that value exists in the data table, and if it does, I don't spawn the rock. This means the data table needs to store around 200*200=40000 booleans if the entire map is mined empty. I have tested setting all tiles as mined when the map starts, and this works just fine.
0
Turns out the "victory timer" idea wasn't a very good one after all. I need something more concrete for the players to do to achieve victory instead of just surviving. The gameplay is about making progress, so winning should be as well.
0
I'm trying out something but it still needs some work...
I made the goal of the game very simple, a bit like "survive this long" but instead made it display a percentage after your spacecraft is repaired on the surface of the moon and you can leave. It could've been pretty much anything that takes time, but a spacecraft sounded like it'd fit in. By destroying the zerg hatcheries, you gain zerg biomass which is (automatically for now) used to clone people and increase your "human resources" value, which in turn speeds up the victory progress (more people figuring out how to fix the ship).
The problem with this is that now destroying the hatcheries as soon as possible has become very crucial, because killing them accelerates your progress speed instead of just gives you a step in your progress. I still like this as an idea but I'd also like something to not make killing them always a top priority. Maybe something like "if you don't kill a hatchery before a timer runs out, the zerg gets stronger".
I figured out a fun way to make the players aware of where the hatcheries are: There are randomly spawning larvae on the map, whose only function is to get to a hatchery, and they do so by crawling through the rocks (and everything else too). They can't be killed or even targeted, and they are so small that they don't distract the gameplay in any way. If a player wants to find a hatchery, all they need to do is to spot a larva and go to the direction it's headed (I'll probably make them zigzag a bit later on).
Also, drivable siege tanks!
0
The Research Lab must first be built, and isn't exactly cheap. After that, you can start researching one of the available researches, which takes around 2-5 minutes based on the research, and also requires an amount of power during that time, which also depends on the research... so some researches are fast but require a lot of power (a lot of power generators), and some are slow but a bit less energy-consuming. The more energy that's being used, the more vespene gas is consumed. Getting those gas-preserving upgrades early can be very rewarding on the long run, which is why I made their costs quite high.
After a research is done, the researched thing must be applied separately to every structure or every unit it affects, which happens instantly by using an ability on that structure/unit, but costs resources. Some researches allow SCVs to craft tools that stay on them until they die. The tools are rather cheap, so losing them is just a little penalty for dying. Other researches enable structure upgrades, such as blueflames for turrets or microfiltering for refineries.
I can't add any more moving units for the players than one for each, and anything else that moves in fog of war can't be visible by the players, because of the way the rocks are spawned/despawned dynamically. Enemies move in darkness burrowed, so that pathing is not an issue for them.
One idea I had is that the zerg hatcheries are actually sitting on some protoss relics which the players then uncover by killing the hatcheries... Because protoss just has a lot more interesthing stuff that terran could use for this kind of tech, like the Warp Cargo ability. But still, nothing concrete yet.
0
I had it one-way previously but it was bad for consistency. I don't want the power grid to become any more complex than it needs to be, and it's working pretty nicely at the moment. All cables can reach pretty far (9 squares I think) and anything longer than that would stretch the cable models by too much, and even with custom models, having insanely long cables just doesn't seem right. I also like the fact that you need to pay more if you want to take the cable further away. The relays being invulnerable doesn't feel too awkward, since all it means is that enemies will ignore them completely, just like they ignore the power cables.
I was going to try tinting the blueflame model, but the model is specified in some other field than Art: Model, and for some reason changing the actor's tint didn't tint the flame model at all. I'll look into it later since it's not too important for now.
More progress today!
I created Microfiltering research which gives Refineries an upgrade (that must be done separately for each Refinery) that increases the total amount of vespene refined from raw gas by 50%, and also the vespene storage capacity of the Refinery by 50% (so that it doesn't fill up any faster).
I removed a rock type from the game that was essentially just a copy of another rock, but looked different, had more health, and required the best mining tool to break in reasonable time. This was previously to limit the players from wandering too far from the start, but now it doesn't really matter if they do. It just added confusion.
Hatcheries now show up on radar from 25 squares away, but the system to find them doesn't feel good yet. They just show the tiny radar dot just like normal units do. I'm not sure how to make searching for them more interesting... Any ideas for that? I also need killing hatcheries mean something more than just slowing the enemies down by a bit, possibly rewarding the players with some research options or something. Just need to figure out what exactly.
The map is still very difficult to get into without anyone telling you what to do, so I'll probably need to rework the starting part a bit, even though I have a sort of a tutorial set up already. Stuff gets going way too quickly for players to have time to grasp everything. But once you get the hang of it, it gets really fun (at least for me and some others I've played with).
0
Well, there's plenty of playable content already (about an hour if all goes well), but I haven't tested the map with more than 4 players ever, so jumping straight to 8 might be a bad experience... but it needs to be tested one way or another. If it looks bad, I might decrease the maximum to 6.
Today's progress report:
I've made a "blueflame throwers" upgrade for turrets, just couldn't get the actual model changed because the hellion's flamethrower just looks bad on the turret even when scaled to fit the area. The upgrade increases their damage by 50%, but needs to be first researched at the lab, and then upgraded individually for each turret.
Another ability I added is Repair Drones, which can be activated remotely every 1-2 min per player (depending on number of players). They rapidly heal a structure over 10 seconds, using the fire suppression bot model.
I made the "Power Relay" structures invulnerable because they were pretty useless otherwise, as they just kept dying if there was no turret nearby to protect it... and if there was, the turret could've been used as a relay just as well. All structures have a small area around them that is always passable, so it's not possible to block any routes with them.
I've also tweaked balance a lot, so hopefully the next playtest will be even more fun than the previous one (which was rather fun even though it was still very unbalanced).
0
I just had a 1.5 hour test with 2 players and it seems it's more difficult to build *enough* structures than build too many of them, hehe. I think it will be just fine, just needs a lot of balance testing.
0
I'm not sure what you mean. My resources are trigger variables, and I can't really upgrade those. Maybe if I'd store the values in some arbitrary data objects, like hidden units, and read and write them from those... but either way, I don't want to make the costs of structures change during the game. The whole idea is unintuitive, would just add confusion, and there wouldn't really be any explanation that'd make sense why a structure's cost would increase if there already was another structure of that type.
0
@yukaboy: Go That seems unintuitive, and there's no way to modify ability tooltips on-the-fly, which prevents me from changing cost displays during the game (unless I'd make a separate tooltip for every possible variation of them). A downside of having an entirely trigger-based resource system...
There's no reason to make the structure limit look like a structure limit. It can just be the fact that there are too many enemy attacks going on to be able to maintain that many structures, which is how it's currently implemented. I just need to find a good balance for how much time the players need to spend repairing their structures.
Once I get some production upgrades done, it'll also be more cost-efficient to upgrade a structure instead of building another one.
Sorry for the unclear and confusing explanations, I haven't gotten much sleep during the past week. :P
0
Alright, so I continued mapping again and got a bit closer towards a playable map. There's one issue which makes designing quite difficult: I'm not sure how many structures I can allow the players to have up at one time. I'd need a 8 player stress test with resource cheats to figure that out, and I'd probably need to get lucky to get something like that organized.
Furthermore, even after I know the structure limit, I still need to figure out how to actually keep the players within that limit. I don't want to just block them from building structures when they reach it, but make the actual gameplay work so that it's difficult to get even close to that limit. What currently allows this is the fact that structures need to be repaired, and if there are a lot of structures, it'll take a lot of time to run around the whole base and keep their health up... but that's also rather annoying.
One possible solution is that at some point, the players will be required to start digging... deep. That'll decrease the amount of time they can spend repairing their base, so I could let them upgrade the base enough to keep the baddies at bay for long periods of time. There already is one gameplay element that is supposed to do this: Destroying zerg hatcheries will decrease the number of enemies that spawn (and it then continues increasing over time as usual), and getting to the hatcheries through the rocks takes time. I guess I'll try to balance the gameplay to work with the current features, and then start adding more interesting things in.
I've also implemented the Warp Cargo ability. It needs to be researched at the Research Lab first, and then crafted by each player. It allows you to warp your cargo directly to the Command Center once every 2 minutes (might change the cooldown). Its cost includes a bunch of Rare Elements, which is a new resource I added. It can be found with a very small chance from common rocks, but there are also some red mineral crystal fields around the map that give a bit more of them when mined.
The biggest thing that's still missing is structure upgrades, but it shouldn't take too long to get a couple of them done.
0
I was afraid this would happen, but I have once again started a project that would take too long to even become properly playable. The way I have it planned at the moment is a progressive story-like gameplay where you move further and further into the map. What might still save the project is turning it more towards sandbox gameplay, so that I could release the first playable version much sooner than what the current plan would allow, and get motivated by playing it with others.
What I mean by sandbox is that the map wouldn't have any straightforward goal, and the gameplay would be very random at times. If done well, it might even turn out more interesting than semi-linear progression. I should've gone for that from the beginning, so now I need a big overhaul to get back on the right track.
Edit: I just opened the editor. I have an idea... :3
0
It hasn't been that long since I even started the project (about two months). I've been busy for a month or so with other things (one of them being Skyrim, but I'm done with that now... took an arrow in the knee if you know what I mean), but as soon as I have time to continue mapping, it will be with this project.
0
Yeah, it's created dynamically when attaching a cable. It's actually quite simple if you think about it. ;)
I also use different variations of the cable model for different length ranges so that I don't need to change the scale too much.
0
@Ranakastrasz: Go
Minecraft, for example, also uses fixed random seeds to generate its maps. Procedural generation has been used since the early days of computer game development.
Don't worry about the teleportation, it should be simple enough to just give it a small delay during which the environment can be spawned.
I'm currently working on enemy base system and tying it up with the enemy attack wave system.
The idea is that each attack wave has a (slightly randomized) number of enemies which increases over time, and additionally each enemy base gives a small bonus to that number, which also increases over time for each active base. The closest enemy bases to the players are active early in the game, and the more time elapses, the more bases become active and start increasing the number of enemies to attack. When the players destroy an enemy base, it stops adding that bonus to the number of enemies in the attack waves. This way destroying the bases is beneficial, but isn't absolutely necessary either, since it only helps by a small factor.
Destroying the bases has other benefits too, however, possibly allowing the players to harvest "zerg biomass" or some similar resource which can then be used to create regenerative materials, for example (any ideas for zerg tech, by the way?). To destroy the bases, the players need to build battle tech, since it's not possible to build turrets near the zerg structures as they are surrounded by creep.
Each enemy base also has defensive waves of units, which spawn when players are standing on creep near the base. The defensive waves have a cooldown on each enemy base. Enemy units move faster on creep, making it impossible to destroy the bases by using only SCVs.
Enemy bases aren't visible on the map (at least not at first), but since they are surrounded by a large area of creep, they are rather easy to find.
0
The first thing that spoiled the immersion for me was seeing the zergling running towards the camera from far away. The enemies would be much scarier if they'd circle around you in shadows rather than running straight at you. The UI also seems way larger than it needs to be, taking away some of the immersion.
I'm also a bit sceptical on how FPS works in multiplayer. I'd much rather see this as an offline singleplayer map, because that's the only way to have decent WASD+mouse controls in SC2. Even if it's "slow and steady", lag with keyboard controls is too annoying for me. But then again, I'm the guy who almost ditched Skyrim because the controls felt too awkward. Even after tweaking and getting used to them and noticing how great the game is, the controls still make me grit my teeth from time to time. Anyway, my point is... don't underestimate the impact that good controls have on making a game good.
Furthermore, horror works much better when playing alone. Multiplayer just takes you right out of the game world.
0
I added a close-up screenshot of the power cables to the first post.
In case anyone is interested in the technical details on how the minable tiles work:
Spawning multiple units at the same time can be very heavy for performance. I've spent a lot of time optimizing this and it now works very smoothly. When a player moves from one tile to another, a function is called that despawns all rock units that are now far enough from the player, and spawns new rock units in the direction where the player is moving to. This means despawning and spawning about 17-34 units at a time (depending on whether the player moved diagonally or not). Additionally, since a player can't move across a tile in less than 0.5 seconds, I have spread the tile spawning so that on one script engine frame (0.0625 seconds) it only spawns and despawns tiles for one player, and because the player limit is 8, all players are handled within 0.5 seconds. This means that at most 34 units are despawned and at most 34 units are spawned during one frame, causing no performance issues.
It would be possible to have more than 8 players (or player units), and just handle rock spawning for more than one player per server frame, but that'd then cause issues with the number of simultaneously existing units on the map. To not have too many units in the map with 8 players already, I have solved this by only spawning the minable rocks around the players, and not spawning rocks that are completely surrounded by other rocks. A player can see on a radius of 7, and the rocks are spawned in a 17*17 square around the player (8 tiles to all four directions around the player).
In worst case, this approximates to about 2000 rock units existing at the same time, but the worst case is not very likely to happen because there's almost always some empty space near the players as well. This means a bit more rocks than there can be supply-using units in a normal 4v4 melee game (unless everyone's a zerg and only uses lings), but since the rocks don't move and no pathfinding needs to be computed for them, this amount should be alright for performance.
One last point: how the positions of the rocks are stored in memory. Well... they aren't. I have a function that generates random noise based on a fixed random seed, and I call that function to get the rock type on a specific tile. When a rock is despawned and then spawned again, it is randomized in the same way every time during a game, because the random seed is only randomized when the map is loaded.
When a rock is mined, I save a boolean value "true" in the global data table for those coordinates. When I'm about to spawn a rock, I check whether that value exists in the data table, and if it does, I don't spawn the rock. This means the data table needs to store around 200*200=40000 booleans if the entire map is mined empty. I have tested setting all tiles as mined when the map starts, and this works just fine.