4 ms·

One thing jumped out at me above that I had a question on: With the problem about status effects, how is this typically implemented? Do the rules for interacti

by iamwil 5y ago

One thing jumped out at me above that I had a question on: With the problem about status effects, how is this typically implemented? Do the rules for interactions exist within the game objects themselves, as if-then-else statements? If so, I can see why that would be error prone. Even if those rules exist in abstractions like "Burnable" and "Metallic", it's still hard to see the side effects of changing or adding a single rule. Does anyone ever implement it in a single place, where you can query for the interactions between the different status effects? That way, all the rules are in one place, and being able to query for it, the results would tell you how it came to that conclusion. If not, how come?

larsiusprime 5y ago
I just used it as an example of a bug I had last week and that I solved in 30 minutes -- the point is not how one individual bug occurred, but that there are a million boring technical things to do. You spend most of your time doing things other than enjoying the fruits of creative fulfillment. A significant amount of my time is not even spent coding, but doing admin and spreadsheets.
- iamwil 5y ago
  Yes, game dev has a lot of grind to it. It was just that one example was related to something I've been thinking about: how come status effects and rules aren't in one central place to be queried? That way, you can spend 2-3 mins on it rather than 30 mins, because the system can just tell you how it arrived at that conclusion. But I hear you. 30 mins probably isn't enough frustration to warrant something like that. What spreadsheets? Like systemic design in spreadsheets? Or you're doing accounting?
  - larsiusprime 5y ago
    Yeah if you wanna talk architecture I have a bit of YOLO code that drags on me. But actually in this specific case like 99% of my elemental interaction code is in the same place just as you recommend! In this specific case the problem was entirely that I added a new rule to make ice decay into wet when it was removed, but didn't add a check to see if ice had been applied in the first place before removing it. And of course, that was all in the elemental interactions file. 28 of the 30 minutes were spent in just puzzlement why the fire wasn't applying and checking a bunch of irrelevant dead ends before I thought to check "oh obviously it's probably the elemental interaction code, go check the elemental interaction file." 2 minutes were spent fixing the actual code.
    - iamwil 5y ago
      When I have a bug, I find a lot of the time, my basic assumption of what the system is doing was wrong, largely because I had no visibility into what it was doing. For something like status effects, I was thinking about using a datalog engine, like jasonwatkinspdx mentioned in a sibling comment. That way, you can query it for applications of status effects, instead of hunting it down in code. That said, I never heard any game dev talking about Datalog, and was wondering if there was a reason for that--whether it's obscurity, or if it's impractical for some reason.
  - larsiusprime 5y ago
    Missed your comment about spreadsheets. Yes! So many spreadsheets. So a bunch of design work happens in spreadsheets, yeah, that and long form google docs. Then a lot of business and admin stuff too (if you're an independent dev which means you're making games AND running a business). Whether that's accounting or projections or any number of other sundry things.
  - jasonwatkinspdx 5y ago
    So there's nearly as many answers to your question as there are gamedevs. I've seen quite a few use an OO modeling approach. That's fallen out of favor for good reason. Another approach is Entity Component Systems. I suggest googling for one of the better blog posts on that. Another approach is to build the equivalent of a datalog engine. An approach I favor is to have a stack per entity, and as you parse input events things get stacked up. Then a processing pass iterates across popping things off the stack. If you know how MTG rules work it's roughly the same idea. None of these are a panacea, because you can have logical contradictions in your ruleset that are subtle and only emerge in very niche situations. It's definitely very difficult problem. What you suggest is similar to what I termed the datalog style. If you've ever tried to debug a prolog or datalog program, you'll know that it all being in one file is a trivial concern compared to the emergent complexity and potential for you to have misstated your logic or included contradictions.
    - iamwil 5y ago
      Indeed I was thinking of a datalog engine. (!) I've had minimal experience with datalog, but you should be able to query it for how it got to its resulting fact, no? So if you find a fact that doesn't make sense, I thought you'd be able to query for the path it took to get that fact? If you have a stack per entity, like MTG, how would you find a contradicting rule?
      - jasonwatkinspdx 5y ago
        You can query it sure, but that doesn't mean the problem will be readily obvious. Again, this stuff can get complex fast, and it's easy to armchair quarterback that away. So the stack approach essentially doesn't, because it forces a linearization. You'd have to rewind back through and see why what the system did didn't match your expectation. But at least the order is comprehensible vs some of the other approaches.

by iamwil 5y ago

larsiusprime 5y ago

I just used it as an example of a bug I had last week and that I solved in 30 minutes -- the point is not how one individual bug occurred, but that there are a million boring technical things to do. You spend most of your time doing things other than enjoying the fruits of creative fulfillment. A significant amount of my time is not even spent coding, but doing admin and spreadsheets.

iamwil 5y ago
Yes, game dev has a lot of grind to it. It was just that one example was related to something I've been thinking about: how come status effects and rules aren't in one central place to be queried? That way, you can spend 2-3 mins on it rather than 30 mins, because the system can just tell you how it arrived at that conclusion. But I hear you. 30 mins probably isn't enough frustration to warrant something like that. What spreadsheets? Like systemic design in spreadsheets? Or you're doing accounting?
- larsiusprime 5y ago
  Yeah if you wanna talk architecture I have a bit of YOLO code that drags on me. But actually in this specific case like 99% of my elemental interaction code is in the same place just as you recommend! In this specific case the problem was entirely that I added a new rule to make ice decay into wet when it was removed, but didn't add a check to see if ice had been applied in the first place before removing it. And of course, that was all in the elemental interactions file. 28 of the 30 minutes were spent in just puzzlement why the fire wasn't applying and checking a bunch of irrelevant dead ends before I thought to check "oh obviously it's probably the elemental interaction code, go check the elemental interaction file." 2 minutes were spent fixing the actual code.
  - iamwil 5y ago
    When I have a bug, I find a lot of the time, my basic assumption of what the system is doing was wrong, largely because I had no visibility into what it was doing. For something like status effects, I was thinking about using a datalog engine, like jasonwatkinspdx mentioned in a sibling comment. That way, you can query it for applications of status effects, instead of hunting it down in code. That said, I never heard any game dev talking about Datalog, and was wondering if there was a reason for that--whether it's obscurity, or if it's impractical for some reason.
- larsiusprime 5y ago
  Missed your comment about spreadsheets. Yes! So many spreadsheets. So a bunch of design work happens in spreadsheets, yeah, that and long form google docs. Then a lot of business and admin stuff too (if you're an independent dev which means you're making games AND running a business). Whether that's accounting or projections or any number of other sundry things.
- jasonwatkinspdx 5y ago
  So there's nearly as many answers to your question as there are gamedevs. I've seen quite a few use an OO modeling approach. That's fallen out of favor for good reason. Another approach is Entity Component Systems. I suggest googling for one of the better blog posts on that. Another approach is to build the equivalent of a datalog engine. An approach I favor is to have a stack per entity, and as you parse input events things get stacked up. Then a processing pass iterates across popping things off the stack. If you know how MTG rules work it's roughly the same idea. None of these are a panacea, because you can have logical contradictions in your ruleset that are subtle and only emerge in very niche situations. It's definitely very difficult problem. What you suggest is similar to what I termed the datalog style. If you've ever tried to debug a prolog or datalog program, you'll know that it all being in one file is a trivial concern compared to the emergent complexity and potential for you to have misstated your logic or included contradictions.
  - iamwil 5y ago
    Indeed I was thinking of a datalog engine. (!) I've had minimal experience with datalog, but you should be able to query it for how it got to its resulting fact, no? So if you find a fact that doesn't make sense, I thought you'd be able to query for the path it took to get that fact? If you have a stack per entity, like MTG, how would you find a contradicting rule?
    - jasonwatkinspdx 5y ago
      You can query it sure, but that doesn't mean the problem will be readily obvious. Again, this stuff can get complex fast, and it's easy to armchair quarterback that away. So the stack approach essentially doesn't, because it forces a linearization. You'd have to rewind back through and see why what the system did didn't match your expectation. But at least the order is comprehensible vs some of the other approaches.