Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using StrEnums instead of String Constants in bomb.py #694

Open
NishchayKQ opened this issue Apr 26, 2024 · 3 comments
Open

Using StrEnums instead of String Constants in bomb.py #694

NishchayKQ opened this issue Apr 26, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@NishchayKQ
Copy link

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 NishchayKQ added the enhancement New feature or request label Apr 26, 2024
@EraOSBeta
Copy link
Contributor

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

@NishchayKQ
Copy link
Author

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

@TheMikirog
Copy link

TheMikirog commented May 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants