Friday Facts #297 - New resource icons

[V453000]

assuming the random icon generation could be used by modders?
would love to see random icons like that for all of bob's and angels' ores

I'd do it.
I'd do it now, but the question is, does the game engine support this yet? if so, how do I use it?

Not supported yet. Currently it's defined this way in our branch:

Code: Select all

icon = "__base__/graphics/icons/mip/iron-ore.png",
icon_variations =
{
  { icon_size = 64, icon = "__base__/graphics/icons/mip/iron-ore-1.png" },
  { icon_size = 64, icon = "__base__/graphics/icons/mip/iron-ore-2.png" },
  { icon_size = 64, icon = "__base__/graphics/icons/mip/iron-ore-3.png" }
},

[bobucles]

Pure speculation: Smooth animations for arbitrary angles. Example: with single degree precision you couldn't rotate 90° over 60 ticks smoothly.

Then your smallest unit isn't tiny enough. A good 64 bit integer can map every millimeter from the core of the sun out to Pluto and an ordinary clock has 43200 positions for the hour hand.

[jean_doe]

god damn it. random ores? WHY?

[ahydra447]

For some reason I don't like the idea of random ores. I think mainly because it would make it hard to see at a glance the number of items. At the end of the day, the icon is just a representation of "there is an item of this type", no particular need for it to look pretty.

[Krazykrl]

For some reason I don't like the idea of random ores. I think mainly because it would make it hard to see at a glance the number of items. At the end of the day, the icon is just a representation of "there is an item of this type", no particular need for it to look pretty.

Yes, but this is similar to changing the old regularly patterned ore deposit tiles to a non-obvious repeating pattern. Once you get past the very earlygame, you're going to be dealing with a scale of saturated belts; not individual pieces of ore. Very rarely would you ever need singular pieces of ore, and even then the break in the belt compression would create an easy measure (especially since the items-per-tile on belting has been normalized recently.)

[mrtyman]

New resources look great, but I have one functionality concern:

With these slight variations, it may be harder to tell when a belt is fully compressed vs slightly uncompressed. I have yet to use the new system so I don't know, but that's one downside I forsee.

If belt compression is tested to be easily identifiable with the new system, then I have no concern. If not, however, I recommend a toggle for the old sprites or some other reasonable substitute to make belt compression easily visible.

Thank you!

[emlun]

The new resource icons look really, really good! But I can't quite shake the feeling that those messy piles of ore chunks should be spilling off the sides of the belt, especially in the turns and on faster belts. That's probably a problem not worth solving, though.

[Cadde]

New resources look great, but I have one functionality concern:

With these slight variations, it may be harder to tell when a belt is fully compressed vs slightly uncompressed. I have yet to use the new system so I don't know, but that's one downside I forsee.

If belt compression is tested to be easily identifiable with the new system, then I have no concern. If not, however, I recommend a toggle for the old sprites or some other reasonable substitute to make belt compression easily visible.

Thank you!

I never look at the items on a belt to see if it's compressed or not. That would be maddening.
I just use the debug tools (even though they are not meant for gameplay stuff) until we get a better way of detecting usage.
By better, i mean you can at a glance see how much a belt is used without building circuitry.


--------------------------------------------------

I really like the new resource icons, i am looking forward to belts actually having volume to them, not just spacing, so you can stack raw resources tall on belts.

And while i am at it, it would be nice if other icons had rotations to them on belts so they didn't look so uniform either. But that's probably asking a bit much.

[Twinsen]

I used to do game logic with integers only for a previous job and it was a pain. It's a huge game design limitation that is not worth it.
Avoiding floating point problems is not a big deal.

As a developer (but not game), can you elaborate why that is the case?

I can't see something like the angle of an inserter requiring more than single-degree precision.

If you make inserter movement use single degree precision then you are limiting yourself to for example only using integer degree speeds, which would not even work for our tick-rate of 60 because it would mean the slowest inserter can move 60 deg / sec and the second slowest 120 deg / sec. And if you insist on going down this road, god help you when you need to work with map coordinates and precise pick-up/drop-off locations.

The example that was a headache in the other game was health values. We used integer health values, so all damage needed to be integers, which was a huge limitation for game design, and it was causing headaches when balancing things like ticking damage.

To get rid of these annoyances you could multiply the values by some arbitrary values, but then your inserter speeds are defined in thousands-of-a-degree, map coordinates are defined in milimeters and microtiles and unit health pools are 330000/330000.

[Deadlock989]

Not supported yet. Currently it's defined this way in our branch:

Code: Select all

icon = "__base__/graphics/icons/mip/iron-ore.png",
icon_variations =
{
  { icon_size = 64, icon = "__base__/graphics/icons/mip/iron-ore-1.png" },
  { icon_size = 64, icon = "__base__/graphics/icons/mip/iron-ore-2.png" },
  { icon_size = 64, icon = "__base__/graphics/icons/mip/iron-ore-3.png" }
},

Is the "base" icon also used on belts? Or does it match up with one of the variations?

How many variations are you planning (ballpark)?

Sorry for boring questions but I'm unreasonably excited about this.

[bobucles]

map coordinates are defined in milimeters and microtiles and unit health pools are 330000/330000.

Well. A computer's internal value and a game's display output are by no means required to be the same value. 330000 internal can just as easily be 330 with a hidden decimal on the output. A float's going to hide that extra 0.00000021617236 anyway.

Indeed there are valid reasons to use floating point numbers, but almost everything that happens in terms of game mechanics really shouldn't. I mean, how many FFFs uncover yet another bug that is entirely due to the wonkiness of floats?

[SkiCarver]

I'm liking the new ores .... makes me think that it would be cool to have an 'ore belt' and a 'finished product' belt .... that way we could justify a really nice real-world style ore belt with some ores being slurry and some dry ... hhmmm - yellow cake!

https://st4.depositphotos.com/1519281/1 ... turing.jpg

as I say, I'm liking the new ores!

[Meggal_Bozale]

Improving on so many lil things, you all are the greatest! :D You keep on doing you.

[Trapton]

Once again, nice update and blog entry. I take my time every friday, no matter what, keep up the good work!

The new icons look glorious, but I'd prefer coal to be darker for more contrast with stone.

Yeah, the coal definitely needs to get a little darker. With the right monitor/settings it "works", but with some gaming monitors, as already mentioned, it doesn't fit with the stone.
Copper doesn't look optimal on my devices either, here the color saturation could (not for sure) be increased a little bit. In comparison to iron ore, uranium, stone, it doesn't fit perfectly in my opinion.

[Artman40]

I really like the random resource icons. I think an option to disable the random look could also be a good idea.

[BattleFluffy]

That's awesome about the improvements to inserters :D
Also amazing that you caught the bug on that guy's twitch stream so quickly. I had a go at reproducing it after your post about it in the 0.17.44 thread, and I couldn't figure it out..

I love the direction of the new raw resource icons, being randomized and chunky like that looks really good.
I wonder if some "overspill" into adjacent squares would look good? Similar to the way concrete overspills to neighbouring tiles by a little bit, to give a nice border... a similar effect could be used to make the raw resources look more random/mixed and "raw".

For example consider the case of a single piece of ore alone on a belt. If he has no neighbours, he would not sit in a perfectly compartmentalized box... instead he would "spill" a little bit into the other positions on the belt around him.

[aljo]

I'm surprised integers weren't used for inserters, and anything else that shouldn't accumulate error.

I used to do game logic with integers only for a previous job and it was a pain. It's a huge game design limitation that is not worth it.
Avoiding floating point problems is not a big deal.

Agreed, though whole numbers do make sense as an alternative in some situations, like with US dollars. Why bother dealing with floating point errors when you can just store everything in pennies? Completely solves that problem. I think there might be *some* situations were you don't necessarily have whole pennies, but generally speaking it's a solid approach.

[aljo]

map coordinates are defined in milimeters and microtiles and unit health pools are 330000/330000.

Well. A computer's internal value and a game's display output are by no means required to be the same value. 330000 internal can just as easily be 330 with a hidden decimal on the output. A float's going to hide that extra 0.00000021617236 anyway.

Indeed there are valid reasons to use floating point numbers, but almost everything that happens in terms of game mechanics really shouldn't. I mean, how many FFFs uncover yet another bug that is entirely due to the wonkiness of floats?

Out of curiousity, have there been many other FFFs that uncovered bugs due to the wonkiness of floats? Because if this is the first in years, that's a pretty good run.

[gaelyte]

Pure speculation: Smooth animations for arbitrary angles. Example: with single degree precision you couldn't rotate 90° over 60 ticks smoothly.

Then your smallest unit isn't tiny enough. A good 64 bit integer can map every millimeter from the core of the sun out to Pluto and an ordinary clock has 43200 positions for the hour hand.

Even in micrometers it still fit (Pluto goes up to 7,4*10^18 µm, an 64 bit int goes up to 9.22*10^18)

[Cadde]

I think there might be *some* situations were you don't necessarily have whole pennies, but generally speaking it's a solid approach.

No bank ever is going to store currency in whole pennies. They have massive amounts of decimal places. At trillions of transactions per hour, even something as small as $0.000001 is going to mean a thousand dollars every hour is either created or destroyed. I don't find it that plausible for a bank to shelf out in the "destroyed" case.

And even then, storing it in pennies doesn't work for currency conversion. Say between Euro and USD. And interest rates are in percents. 10 percent of a penny is 0.1 pennies...

That being said, this game is not a banking system and would do well without floating point numbers in the simulation.