ballistica icon indicating copy to clipboard operation
ballistica copied to clipboard

Using StrEnums instead of String Constants in bomb.py

Open NishchayKQ opened this issue 10 months ago • 3 comments

StrEnum reference Screenshot 2024-04-27 004720

im thinking to update bomb.py to use enums and while doing that i have few questions

  1. should we update classes like Blast (and their usages) to use enums as well? this is optional as String Enums and normal string can be used interchangeably. (as StrEnums are an instance of string)

Screenshot 2024-04-27 010021

  1. or we could simply just implement it in simple checks for now...I prefer if we update both the class and these if conditions Screenshot 2024-04-27 004842

NishchayKQ avatar Apr 26 '24 19:04 NishchayKQ

Can't really agree on this since it won't improve anything (not even readability)

EraOSBeta avatar Apr 28 '24 16:04 EraOSBeta

Can't really agree on this since it won't improve anything (not even readability)

https://github.com/efroemling/ballistica/wiki/Knowledge-Nuggets#enums-are-handy

NishchayKQ avatar Apr 28 '24 18:04 NishchayKQ

I do not agree with it. Not even for readability, since you still have to jump all over the place and keep track of every bomb type. I think classes that inherit from a parent is a much better, more mod friendly alternative.

All bombs generally share the same functionality, but differ in models, textures and extra functionality like exploding on impact. We could have a single Bomb class and then have child classes like StickyBomb or ImpactBomb that change the base properties or add new functionality on top of the base. If we don't want a certain function, like time to explode, we might want a variable that allows you to disable it in the child class, without changing the parent class functionality. Basically a bomb by design is going to be malleable and expandable, a sandbox.

We can do the same for blasts. Bombs can then reference a child blast class object that should be spawned on explosion. Different blast classes allow for different appearance,s particle effects, sound effects and more.

This is of course assuming we want to somehow """improve""" the code (whatever that means, answer changes from person to person). Without a proper consultance with @efroemling and a clear goal in mind, I don't see a reason to touch fundamental code unless it's a bug fix.

TheMikirog avatar May 09 '24 16:05 TheMikirog