Friday Facts #209 - Optimisation is a way of life

[keyboardhack]

In regards to the bots. I would say that making the the proposed change just for optimization would definitely be worth it. As you said in the FF, having it not apply to Construction Bots would be good because otherwise that would be too cheaty sense they are involved in combat and such. However, having Logistics Bots not be mined or be able to take damage would actually be an improvement even outside of the performance increase.
I really don't think it would be too cheaty or anything because it's not like it's giving the player any type of unfair advantage, it's just simply increasing game performance and getting rid of the announce of accidentally picking them out of the air as well.

Fully agree with this. Making the optimization will also make handling bots a lot better.

[Omarflyjoemacky]

I too can not get enough of these optimizations! I love reading about them, and love playing with them even more.
The electric network and smoke improvements are really nice as those are two that I personally noticed getting a bit high as well.

In regards to the bots. I would say that making the the proposed change just for optimization would definitely be worth it. As you said in the FF, having it not apply to Construction Bots would be good because otherwise that would be too cheaty sense they are involved in combat and such. However, having Logistics Bots not be mined or be able to take damage would actually be an improvement even outside of the performance increase.
I really don't think it would be too cheaty or anything because it's not like it's giving the player any type of unfair advantage, it's just simply increasing game performance and getting rid of the announce of accidentally picking them out of the air as well.

I can imagine that the performance improvement from making the change would be pretty significant and welcomed by most people. I know I would certainly enjoy it!

Agreed. All for the optimization on logistic bots. Love the stone graphics too. I see that little cactus and hi res plant too...

[kovarex]

I've been thinking about smoke. Is there any reason why smoke needs to be ticked at all?

Just store a static list of smoke start location (x,y in chunk) and tick number that it was placed there (which could be as low as 4 bytes). All the logic can be in the render function: smoke age = current tick - placement tick; location is a pure function of age, start location, and the current wind vector. All the cleanup you have to do during the tick is advance the head of the circular buffer to invalidate the old smoke (should only be a single int per chunk).

This is the current data layout

Code: Select all

  TrivialSmokeID id; // 1 byte
  uint8_t remainingUpdates; // 1 byte
  uint8_t lastByteOfLastUpdateTick; // 1 byte
  SubChunkPosition position; // 4 bytes (contains only the lower 2 bytes of position and requires chunk position to retrieve the complete MapPosition
  float verticalSpeedCoefficient = 0; // 4 bytes - it is either the default or 0.99 for fire smoke, we could just make it 2 possible value bit if we wanted to be extreme
  CyclicFramePosition framePosition; // 4 bytes - 2 might be enough
  float verticalSpeedSlowdown; // 4 bytes - might be removed?
  float height; // 4 bytes - 2 bytes might be enough
  TinyVector movingDirection; // 4 bytes
  float verticalSpeed; // 4 bytes 2 bytes would probably be enough

As you can see, there are some possible savings to be done, but not that much.
...
When I think about it, starting frame position is random, so it could be some xor of position, and with other changes, it could get down to 16 if I wanted. But it might not be needed until smoke shows on the profiler again.

[MrGrim]

Those new stone paths are fantastic! I'd love to see what they look like bordering some concrete.

Re bots, the invulnerability thing bugs me. It could be exploited as others have pointed out. Personally, I consider combat and biter management an important aspect of the game, and bots should need to be protected. I'd hate to see biter management reduced as I love having that external force factor into expansion and decisions.

[Rhamphoryncus]

After Factorio is released the team can move on to their next polishing project:

[cpy]

Well how about allowing mods to use separate CPU thread to run? I'm sure that factorisimo running in 8 more threads itself with each of mini factory which is world itself would allow us to create insanely big worlds. But that would require some connection that connects those separated worlds.

I think that's essentially why the speed of light is a limiting factor in this universe. Through that one simple trick you achieve locality but lose globality. "The number of things at time x" or "The amount of power consumed at time x" or even "time x at different places" do not exist anymore after losing globality. Lag-hiding tries to compensate for that by creating an illusion that two people can actually play the same game at the same time. Wait.. i'm talking about thousands of cores with weak interconnects. Running 8 threads on the same CPU in parallel where each does some part of the work each tick is "no big problem". You still need to chop up the tasks but that's quite less hard.

Are you drunk? Your post have no meaning at all, just some random english words put together. I guess it's friday and people get drunk.

[Kno]

I think you are going attacking the bot dilemma the wrong way. First you have to ask if logistics robots being an entity is a desirable game-play element, then see how to optimise the implementation, and not the other way around. Many gameplay elements could be eliminated for the sake of a faster game, but that is not optimising anything, that's eliminating parts.

Going to the extreme to fix the UPS problem of robots, why not add a late game tech that adds teleport chests, that way there is no graphics, not robot position or anything, just pure optimised item transfers.

If you just change logistic and not construction bot, it will be weird to have two bots acting so differently (not interactable and invulnerable for one).

And having things that can move resource even over enemy base is not in line with other transportation mode. As bot always fly there will be no way for biter to stop bot from transporting as even destroying roboport won't stop them to transport. Belts and train can be destroyed. In some use case it can be use like an exploit even more in some modded game with big roboport that can cover enemy base.

I agree with this.

[RobertTerwilliger]

Intellectual job is indeed hard not to take home) It took me several years to learn "to toggle off 'at job' state of brain" ; )

Logistic bots should never be invincible, IMO. They indeed don't get in danger too often, but becoming invincible will cause exploits for sure.
Mining them is a pain, probably just increase time of mining them?

Brick walkway has too contrast contour. Consider reducing shadow intensity, 'cause it looks like a high stair from the ground.

[Nasabot]

Nice looking stone path!

Can you please make stone paths and concrete paths be more in line with each other?

Id like it if:

-both paths give the same movementspeed
-cost the same amount of stone

Concrete being cheaper AND faster is not good. All the technical optimizsations are great, but if you'd put the same effort into game design refinement, factorio will write history!

[infogulch]

My goal would be to make all smoke immutable. It's current state is directly calculated from starting state and current tick, and only for the rendered region; it's never updated until it's removed. This would turn a read/write loop on the whole map into a read-only loop (+some calculations) in just the few rendered chunks.

I've edited the struct layout with my thoughts/questions:

Code: Select all

TrivialSmokeID id; // I'm guessing this is the smoke type?
uint8_t remainingUpdates; // Drop
uint8_t lastByteOfLastUpdateTick; // Drop
SubChunkPosition position; // 4 bytes. Rename to "startPosition", never change it
uint16_t lastByteOfPlacementTick; // Add. 2 bytes. never changed. the last bytes of the tick when this smoke was created
float verticalSpeedCoefficient = 0; // Drop. Get verticalSpeedCoefficient value from lookup on id
CyclicFramePosition framePosition; // 4 bytes. What is this?
float verticalSpeedSlowdown; // Drop. Do the same as verticalSpeedCoefficient
float height; // is this height from the ground?
TinyVector movingDirection; // 4 bytes. Do all smokes need to move in independent directions? Could this be looked up somehow?

The idea is that a smaller, mostly read-only structure + a little bit of integration (recalculating the position at every render) < larger memory that has to be updated every tick.

[Engimage]

Great job on those optimizations guys!
And new graphics look cool!

Have to admit that Factorio is making not only yours brain addicted. Sometimes I just can't sleep half of the night cause I just can't stop thinking on optimizing factories and different builds.
So this game is definitely heavy drugs

[Kyralessa]

Those stone paths are beautiful. I never build stone paths in the game because they're not as fast as concrete, and I don't like how they look. If they looked like this, they're probably all that I would build!

As for the bots, though...it feels really cheesy to me to make the logistic bots invulnerable. Nothing the player creates is invulnerable, except maybe stone and concrete paths and landfill. It seems really weird to have a special snowflake item that is invulnerable for no apparent in-game reason. (Paths and landfill have a reason; they become part of the landscape. Not so with bots.)

[Eddek]

Trylinka!

[gregor]

I love reading about these optimizations! Keep it up!
Regarding the robots and the trade-off with making them like smoke. If you find it too big maybe make it an option. Have a special megabase mode with most things optimized for performance. Like no smoke or aliens at all etc. Just have the building part of the game intact. Might be hard to do don't know, but with be nice.

Would be nice to see some benchmark on a bit bigger map like the one I posted in the "Post your save thread"

( https://drive.google.com/file/d/0B2mZJW ... hod0E/view ) googlemaps: https://factorio.twilightguild.se/

Starting to get slow with sub 10 UPS. hihi

[ratchetfreak]

IMO it is possible to make the logi bots bounding boxes available for collision detection while still keeping the speedup of collapsing the mutating state.

Code: Select all

BotID id; //to select the sprite special value for those killed/mined early
Bot* pointer;//pointer to the actual bot entity for out of band stuf to contain the item stack and job and such
SubChunkPosition endPosition; //currentPos = endPos - speedDir*(NextUpdateTick - currentTick)
vec2 speedDir;
uint8_t lastByteOfNextUpdateTick; 
UpdateID updateReason; //arrive at dest, edge of chunk, battery empty, etc.

keep the area each of these arrays span and you won't have more than a few hundred to loop over when checking collisions though time until next update won't be constant.

It will probably pay to require that bots are explicitly included in area based entity selection.

[Axios]

Nice FFF as always, love to know how things are going.

For the logistic bots dillema. I don't think thats a good idea :

If you just change logistic and not construction bot, it will be weird to have two bots acting so differently (not interactable and invulnerable for one).

And having things that can move resource even over enemy base is not in line with other transportation mode. As bot always fly there will be no way for biter to stop bot from transporting as even destroying roboport won't stop them to transport. Belts and train can be destroyed. In some use case it can be use like an exploit even more in some modded game with big roboport that can cover enemy base.


I understand the need for optimization but there should be limit to it.

I agree. Ok, Factorio is not combat focused but it's part of challenge. Will be weid if teh two robot types would be so different.

I prefer logistic robots minaebe and damageable.


PS: thanks for another awesome FFF!

[Supercheese]

♪ I'm optimizing the railroad

Allll the live-long daaaay! ♫

[impetus maximus]

the coding world needs more addicts like you kovarex.

cheers

[QGamer]

I have a few things to share:
1) Thank you for optimizing. I have yet to make a megabase big enough to slow down the game, and I'm glad that I don't have speed issues.
2) I personally think the logistic & construction robots should both be regular entities. I think that if they somehow wander too far astray (e.g. into biteropolis or a war zone) they should get damaged. Both types of robots. Maybe even add away for them to get damaged in nuke explosions?
3) I love the stone paths! Much nicer than the current ones! Keep up the good work!

P.S. I like how when you switch to high-res graphics you rethink the way it should look.
P.P.S. What will high-res concrete look like?

[Selvek]

God I wish you and your team would go work on the multi-thousand-dollar CAD software I use at work. Imagine factorio...except that every time you add, remove, or edit any entity, there is a 1-2 second lag and a 0.1% chance of crashing. Then pretend you do that 40 hours a week for a job.

At least there are no biters... but I would gladly take them to make the crashes go away!