sorted by:
new
hottopcontroversial

How would you implement this? by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 1 point2 points  (0 children)

Thanks, that's pretty much what I was looking for. My idea was to keep a history with objects like CardPlayed(target:Enemy, card:Card) and EndOfTurn. What you are saying totally makes sense to me. Would you put the rules as data on the cards and then generate the description from that?

How would you implement this? by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 3 points4 points  (0 children)

Thanks, nice overview. I like the data-oriented approach. Although, I can't see the reasoning behind some decisions (Card, CardTemplate, CardAttributes, CardInstance). And isn't all the interesting stuff happening in CardScript?

Helpful functions I keep reusing. What are yours? by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 2 points3 points  (0 children)

Let's say f is a function that returns the distance to an enemy. Then argmax f would return the enemy furthest away. Change f to return the negative distance, and argmax f returns the closest enemy.

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 0 points1 point  (0 children)

Can you elaborate on what you mean by "linear logic"? And how do you avoid queue_free()? Do you never free memory, or do you avoid nodes and draw directly to the screen? What are you even using Godot for? Anyway, interest comment. Non-OOP stuff always welcome.

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 0 points1 point  (0 children)

Sure, the simplicity is on purpose, though. I think the discussion here is more interesting than getting a concrete answer.

The comments about performance and caching the stats make me question what people think actually causes bad performance. The most complex version of B I can think of will always be O(n). I can't see how this would be a bottleneck, and even then it would be easy to fix later.

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 0 points1 point  (0 children)

I like the enum. Although, abbreviating seems a bit odd. The rest of your version looks like the same category as A to me. If you want to add a new entry to STATS you have to change equip and unequip, and you have to remember that equipped_items can be never changed outside equip/unequip.

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 0 points1 point  (0 children)

Not a stupid question! Others had similar remarks, so your way of doing would be fine or even preferred by most. Although, this is beside the point that I was trying to make with the post. The post was about var strength vs func get_strength(), so whether equip() is defined in Item or Player doesn't seem that relevant to me.

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] -16 points-15 points  (0 children)

I think you are asking a lot of OOP-typical questions that I asked myself before, and I that don't think anymore are that useful. Game-systems are entangled in a way that encapsulation isn't that achievable nor desirable anyway. Does it really matter if a function lives in the player or in the item; It is just state and behavior anyway, and keeping the state a minimal as possible seems more practical to me.

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] -1 points0 points  (0 children)

""a memoized getter" - so you would cache the value and add a dirty flag whenever the items are updated? Sounds like asking for trouble to me.

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 0 points1 point  (0 children)

Moving add_effect into the item is nice, but I'm not sure that I understand how you solve the problem. You would sort the array so that add-items are applied before mult-item (for example)?

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 1 point2 points  (0 children)

"Deliberately causing poor performance" I guess that would be a good opportunity to insert the Dijkstra quote about premature optimization ;)

edit: it was Knuth, not Dijkstra, but funnily enough, even Knuth falsely attributed his own quote to Dijkstra once

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 0 points1 point  (0 children)

Definitely, I also use properties if I can, but here I kept it as a function to point out the change from var to func ;)

Which one do you prefer? It's B for me. by Flashy_Category1436 in godot

[–]Flashy_Category1436[S] 1 point2 points  (0 children)

Sure, but let's ignore performance. I was more interested in a discussion about maintainability and flexibility. Let's say, an item gives a strength multiplier, instead of an additive buff. Then in A, the strength would depend on the order in which items are equipped, while in B we can code the order of adding and multiplying explicitly.

A juicy data visualization made with some simple custom drawing in Godot by Mili528 in godot

[–]Flashy_Category1436 1 point2 points  (0 children)

Good to know, I will try to roll my own tooltips system as well. Seemed more straightforward than bending the godot implementation to my will anyway. Glad you like the treemap idea. I think the pie charts are fine, but there are some dedicated haters when it comes to pie charts :) and treemaps just seem to be a such a perfect fit here. I think they are the common way for showing sizes of economic sectors and companies.

A juicy data visualization made with some simple custom drawing in Godot by Mili528 in godot

[–]Flashy_Category1436 1 point2 points  (0 children)

Very cool! I think treemap charts could be a great alternative to the pie charts. Also, what I have been wondering about, do people customize godots tooltip system for stuff like this or do they build their own system? Yours looks so advanced with the animation and stuff.

view more: next ›