Friday Facts #335 - Scenario changes, Damage effect filtering
Read this post on our website.
Improving the Team production challenge was prompted by this Reddit post. Team production was made back in 2016 to test the multiplayer networking of the 0.14 update with a larger number of players without the overhead of having a large factory. Since then it has not really had much love.
So after 4 years of accruing wisdom, I started making some general improvements.
[h3]Choose your teams[/h3]
I think this is one of the main suggestions people had for team production. The scenario just shuffled the players and assigned people randomly, and you could end up all alone playing against your two best friends.
Now I believe anybodies first choice would be to add a GUI to handle this. I will go on about GUIs later, but short story is, I didn't want to add a GUI. They add a lot of complexity, and my development mood these days is to keep things simple and small in scope.
So I added little colored launchpads!
I think it is quite intuitive, you will instantly be able to see which team has which players, you will see what map position you will be in when the round starts, etc. Another benefit is that if you want to spectate, you can simply just not walk onto a launchpad, and use the map view to see what's going on (before, there was a button you would press to join the spectators team).
The idea to use tinted concrete came from Albert, as originally it was just a tinted square rendering over the tiles (which didn't need any new prototypes defined) and it looked very janky. A consequence of this is that we now have colored concrete tiles in the game. There is no item available to place color concrete, but players will be able to access them in the editor mode.
[h3]General cleanup[/h3]
This is the not so glamorous but still important polishing we need to make. Things such as fixing GUI styles, switching the loaders to stack inserters, making sure the map sets are making sense, etc.
I also spent some time making the challenges more predictable, the logic before could give a lot of variance to the difficulty of the production objectives, and make things hard to balance. One problem I see in the future, is that the production challenges are 'hardcoded' for the base game. If I find some more time later I might work on a system to more procedurally create the objectives.
I was inspired by some comments a few weeks ago, saying that the Wave defense scenario was a bit of a pushover, especially with a couple of players working together. So I thought an easy adjustment would be to scale the 'wave power' somehow to the number of players. It was a simple change and we released it with 0.18.4 a few weeks ago. Jobs a good'un right?
Well after play-testing it more extensively over the weekend, I realised it wasn't quite so simple...
[h3]More biters; more money[/h3]
A major problem is that the players earn bounty for every biter that it killed. So if I make the waves bigger, then the players earn so much more money, and can buy so many more upgrades, that the scenario is even less challenging than before.
The solution to this is quite abrupt, I just remove the bounty from the units, and this makes the design work better in my eyes:
A consequence of this is that the upgrade prices and bounties needed to be rebalanced, which was actually a little bit easier since the number of spawners and worms is way more predictable.
[h3]Predictable attack locations[/h3]
I also noticed that biters spawning would always hit the base defences at the same places very reliably. This is great if you are the player and only want to invest 1 flamethrower turret to repel all the attacks.
https://cdn.factorio.com/assets/img/blog/fff-335-waves-before.mp4
So I added an extra command to the biters orders, that tells them to first go to a random point within the base, and from there go and attack the silo. This means that the positions where biters intersect your defences will be less predictable.
https://cdn.factorio.com/assets/img/blog/fff-335-waves-after.mp4
[h3]More wave power; same wave size[/h3]
Another observation I made is that even though I increased the 'wave power', the number of biters was still being limited by the number of nearby spawners. This was due in part to a mix of me being clever with optimization and wanting to not make the groups too big. In short the spawning would work something like this:
Well okay I was a clever boy, and now lets remove all this complicated logic and keep it simple:
[h3]Infinite map option[/h3]
I had a few requests for this, and it wasn't so hard to add. If enabled, the Wave defense map will be infinite instead of an island, and the only way to win will be to launch a rocket.
Adding a new scenario at this point of development is a surprise to be sure, but hopefully a welcome one. The concept for this is that you are on the 'space platform', and you are preparing to land on the surface, and once on the planet you need to launch a rocket as fast as possible. You start with all technologies unlocked, and some money to buy starting equipment.
Once you and your friends are prepped, you head down to the launchpad to start.
And then that is pretty much it, you get teleported to the surface, and play the game as usual. We can afford to add this scenario because it is so small in scope and so simple, and it took less time to make this new scenario from scratch than updating what we already have. Maybe it is not the best thing since sliced bread, but I am hoping that my small investment of a few weekends will at least give some players a few more hours of enjoyment. I would be interested in adding more 'small scope simple scenarios' in the coming months, if we have enough time. If you have ideas that might fit this definition, please let me know (but no promises).
It is the classic problem, we optimise a system so its 5x faster, and then we use it 5x more. This time it is the case of flamethrowers and particles again. With 0.18 we added the damage effects for entities, and we generally like the way it works. However when this is combined with flamethrowers, we encounter some problems.
https://cdn.factorio.com/assets/img/blog/fff-335-biter-damage.mp4
First you might say, "It doesn't make sense that a burning biter will spurt blood", and I would agree. Second you might say "That is a lot of blood", and I would agree with that too. In fact it is 1,416 damage events worth of blood particles. The way flamethrowers currently work means they do a small amount of damage very frequently, in contrast to say a grenade which does a high amount of damage in a single action. Even with all the particle optimizations, the performance would once again suffer due to the sheer quantity of particles being created.
So Rseding has gone ahead and killed 2/3 birds with 1 stone, and added damage type filtering to the entity damaged and entity died trigger effects. This means for our immediate problem of bloody burning biters, we can just filter the damage effect to not occur if the damage type is fire, which solves it perfectly. In the longer term the benefits are even greater, as we now have the capability to for instance, make custom dying effects for being run over, or damaged by laser, or dying by poison etc.
Well that solves half the problem, but still, 1,400 damage events is still going to cause problems in other cases. A big part of this comes from the 'fire sticker', which applies damage every single tick. Since it lives for 30 seconds, that is 1,800 damage events. So a nice easy change posila has done, is to add a 'damage interval' to the sticker, so that damage is only applied every n ticks. For now we have set the fire sticker to do 10x the damage, but only every 10 ticks, reducing the number of total events for the sticker from 1,800 to 180, a lot more reasonable. (Note, changing this frequency can affect the damage balancing, as the resistances system in Factorio has an absolute reduction and a percentage reduction. In our case, the entities affected by the fire sticker had no absolute fire resistance, so the result is the same.)
All the changes you see here should be released soon, we are in a rhythm now of doing 1 release every week (typically on a Tuesday), and everything you see here is pretty much done (but anything can change!).
Team production changes
Improving the Team production challenge was prompted by this Reddit post. Team production was made back in 2016 to test the multiplayer networking of the 0.14 update with a larger number of players without the overhead of having a large factory. Since then it has not really had much love.
So after 4 years of accruing wisdom, I started making some general improvements.
[h3]Choose your teams[/h3]
I think this is one of the main suggestions people had for team production. The scenario just shuffled the players and assigned people randomly, and you could end up all alone playing against your two best friends.
Now I believe anybodies first choice would be to add a GUI to handle this. I will go on about GUIs later, but short story is, I didn't want to add a GUI. They add a lot of complexity, and my development mood these days is to keep things simple and small in scope.
So I added little colored launchpads!
I think it is quite intuitive, you will instantly be able to see which team has which players, you will see what map position you will be in when the round starts, etc. Another benefit is that if you want to spectate, you can simply just not walk onto a launchpad, and use the map view to see what's going on (before, there was a button you would press to join the spectators team).
The idea to use tinted concrete came from Albert, as originally it was just a tinted square rendering over the tiles (which didn't need any new prototypes defined) and it looked very janky. A consequence of this is that we now have colored concrete tiles in the game. There is no item available to place color concrete, but players will be able to access them in the editor mode.
[h3]General cleanup[/h3]
This is the not so glamorous but still important polishing we need to make. Things such as fixing GUI styles, switching the loaders to stack inserters, making sure the map sets are making sense, etc.
I also spent some time making the challenges more predictable, the logic before could give a lot of variance to the difficulty of the production objectives, and make things hard to balance. One problem I see in the future, is that the production challenges are 'hardcoded' for the base game. If I find some more time later I might work on a system to more procedurally create the objectives.
Wave defense changes
I was inspired by some comments a few weeks ago, saying that the Wave defense scenario was a bit of a pushover, especially with a couple of players working together. So I thought an easy adjustment would be to scale the 'wave power' somehow to the number of players. It was a simple change and we released it with 0.18.4 a few weeks ago. Jobs a good'un right?
Well after play-testing it more extensively over the weekend, I realised it wasn't quite so simple...
[h3]More biters; more money[/h3]
A major problem is that the players earn bounty for every biter that it killed. So if I make the waves bigger, then the players earn so much more money, and can buy so many more upgrades, that the scenario is even less challenging than before.
The solution to this is quite abrupt, I just remove the bounty from the units, and this makes the design work better in my eyes:
- Bounty is only earned from spawners and worms.
- You can't sit inside your walls and earn money for upgrades; You need to actively go out of your base to earn upgrades.
- Players could set up infinite money farms by spawn camping the biters; This is no longer possible.
A consequence of this is that the upgrade prices and bounties needed to be rebalanced, which was actually a little bit easier since the number of spawners and worms is way more predictable.
[h3]Predictable attack locations[/h3]
I also noticed that biters spawning would always hit the base defences at the same places very reliably. This is great if you are the player and only want to invest 1 flamethrower turret to repel all the attacks.
https://cdn.factorio.com/assets/img/blog/fff-335-waves-before.mp4
So I added an extra command to the biters orders, that tells them to first go to a random point within the base, and from there go and attack the silo. This means that the positions where biters intersect your defences will be less predictable.
https://cdn.factorio.com/assets/img/blog/fff-335-waves-after.mp4
[h3]More wave power; same wave size[/h3]
Another observation I made is that even though I increased the 'wave power', the number of biters was still being limited by the number of nearby spawners. This was due in part to a mix of me being clever with optimization and wanting to not make the groups too big. In short the spawning would work something like this:
- Determine the wave power, bases on factors such as wave number, player count, difficulty.
- Determine how many spawners we spawn from, something between 4 and 15 typically.
- For each spawner, pick a random number of biters to spawn, between 20 and 30.
- Spawn the biters, and remove their 'cost' from the wave power. If we have no more wave power we stop.
- Once we have gone through all spawners, we are done (even if there is a lot of wave power left).
Well okay I was a clever boy, and now lets remove all this complicated logic and keep it simple:
- Determine the wave power, bases on factors such as wave number, player count, difficulty.
- Determine how many spawners we spawn from, something between 5 and 20 typically.
- Divide the wave power by how many spawners we have.
- Keep spawning units at the spawners until all the wave power is used up.
[h3]Infinite map option[/h3]
I had a few requests for this, and it wasn't so hard to add. If enabled, the Wave defense map will be infinite instead of an island, and the only way to win will be to launch a rocket.
New scenario - Rocket rush
Adding a new scenario at this point of development is a surprise to be sure, but hopefully a welcome one. The concept for this is that you are on the 'space platform', and you are preparing to land on the surface, and once on the planet you need to launch a rocket as fast as possible. You start with all technologies unlocked, and some money to buy starting equipment.
Once you and your friends are prepped, you head down to the launchpad to start.
And then that is pretty much it, you get teleported to the surface, and play the game as usual. We can afford to add this scenario because it is so small in scope and so simple, and it took less time to make this new scenario from scratch than updating what we already have. Maybe it is not the best thing since sliced bread, but I am hoping that my small investment of a few weekends will at least give some players a few more hours of enjoyment. I would be interested in adding more 'small scope simple scenarios' in the coming months, if we have enough time. If you have ideas that might fit this definition, please let me know (but no promises).
Damage effect filtering
It is the classic problem, we optimise a system so its 5x faster, and then we use it 5x more. This time it is the case of flamethrowers and particles again. With 0.18 we added the damage effects for entities, and we generally like the way it works. However when this is combined with flamethrowers, we encounter some problems.
https://cdn.factorio.com/assets/img/blog/fff-335-biter-damage.mp4
First you might say, "It doesn't make sense that a burning biter will spurt blood", and I would agree. Second you might say "That is a lot of blood", and I would agree with that too. In fact it is 1,416 damage events worth of blood particles. The way flamethrowers currently work means they do a small amount of damage very frequently, in contrast to say a grenade which does a high amount of damage in a single action. Even with all the particle optimizations, the performance would once again suffer due to the sheer quantity of particles being created.
So Rseding has gone ahead and killed 2/3 birds with 1 stone, and added damage type filtering to the entity damaged and entity died trigger effects. This means for our immediate problem of bloody burning biters, we can just filter the damage effect to not occur if the damage type is fire, which solves it perfectly. In the longer term the benefits are even greater, as we now have the capability to for instance, make custom dying effects for being run over, or damaged by laser, or dying by poison etc.
Well that solves half the problem, but still, 1,400 damage events is still going to cause problems in other cases. A big part of this comes from the 'fire sticker', which applies damage every single tick. Since it lives for 30 seconds, that is 1,800 damage events. So a nice easy change posila has done, is to add a 'damage interval' to the sticker, so that damage is only applied every n ticks. For now we have set the fire sticker to do 10x the damage, but only every 10 ticks, reducing the number of total events for the sticker from 1,800 to 180, a lot more reasonable. (Note, changing this frequency can affect the damage balancing, as the resistances system in Factorio has an absolute reduction and a percentage reduction. In our case, the entities affected by the fire sticker had no absolute fire resistance, so the result is the same.)
All the changes you see here should be released soon, we are in a rhythm now of doing 1 release every week (typically on a Tuesday), and everything you see here is pretty much done (but anything can change!).
