145 reputation
16
bio website thelatenightcoder.com
location Cluj-Napoca, Romania
age 21
visits member for 1 year, 11 months
seen Apr 15 at 18:50

Mobile & web game developer working at a local company.


Mar
2
awarded  Popular Question
Jan
8
awarded  Yearling
Jan
8
awarded  Teacher
Mar
6
awarded  Autobiographer
Mar
3
accepted Why is the usage of string keys generally considered to be a bad idea?
Mar
2
comment Why is the usage of string keys generally considered to be a bad idea?
That makes sense, but since the presentation was language-agnostic, the "Of course" part made me think like "yet again, strings are bad for keys".
Mar
2
comment Why is the usage of string keys generally considered to be a bad idea?
"Don’t actually use strings, of course. Use symbols or interned strings instead. I’m just using “strings” as a shorthand for “human readable unique identifier." I am guessing, since intern strings were referenced (pardon the pun), that the issue the author had in mind was related to increased string processing if multiple copies of each one were to be created?
Mar
2
comment Why is the usage of string keys generally considered to be a bad idea?
@CodesInChaos I wish I could remember where I found most of the cases, but for now I can paste the bit which reminded me of the issue. It was from a GDC slideshow by Valve which discussed game dialogues and storing facts about the world in <key=string, value=object> pairs.
Mar
2
asked Why is the usage of string keys generally considered to be a bad idea?
Dec
30
comment Designing entities to be self-manageable
Thanks for the tip with the aggregation; I'll try to find a solution that's good enough, and if I succeed, I think I'll centralize all modifiers somewhere. This would be especially useful when saving game data. Without the aggregation, I'd have to store the updated stats as well as the effects on them. With aggregation, I'd only have to store the modifiers (effects). I went with the 2nd way.
Dec
30
accepted Designing entities to be self-manageable
Dec
29
comment Designing entities to be self-manageable
But then, Character would manage all of its components, thus removing the whole "react to small changes in different parts" idea.
Dec
29
comment Designing entities to be self-manageable
Another thing that the 1st way allows me to do is: remove the whole events between Character and its components logic. Character.EquipItem(...) could have { Equipment.Equip(Item); Stats.ApplyChange(Item.StatsChanges); } in its body, and Character would not have to wait for an event from Equipment to fire.
Dec
29
comment Designing entities to be self-manageable
The event from Equipment would still get fired. Character would still receive it and make the appropriate change.
Dec
29
asked Designing entities to be self-manageable
May
8
awarded  Scholar
May
8
awarded  Supporter
May
8
awarded  Student