SGA-A / c2c

Source code for the custom app exclusive to cc, where most interactions begin and end.
MIT License
2 stars 0 forks source link

Changes to working in a broader perspective #40

Open SGA-A opened 6 months ago

SGA-A commented 6 months ago

Is your feature request related to a problem? Please describe. The commands surrounding working are very basic. No data is being tracked and recorded, meaning you don't get a bonus if you consistently get the work done. Neither does working poorly get you sacked, which is needed to regulate jobs within the economy. This doesn't create any incentives for the end-user, people don't see a reason to work if there is nothing special you gain from it. There are no punishments either for not coming back or consistently to do your work shift.

Describe the solution you'd like A system similar to Dank Memer. The bot should track the following:

Some more may be added in the future.

Additional context You can only perform a job and nothing special happens when you work in your given job. Players within the virtual economy can work in their chosen jobs. The functionality for this is currently very simple and basic, a fixed salary is only being considered and nothing else is calculated and recorded in the process.

SGA-A commented 1 month ago

I want to fix some other issues with the working as well and just bunch them up altogether in this single issue, here are the highlights:

  1. More job data analysis (successful shifts, failed shifts etc)
  2. More tasks available to perform in jobs (they will continue to be generic)
  3. Streamline the process of how the working is handled afterward (explaining this now)

So for all the different tasks that are out there, there's a view that made just for it. That's not a problem, but the main problem lies in what's done after the shift is completed. As of right now, you need to build the logic for that in every single view. Terrible idea obviously because it defeats the purpose of reusability (functions). So gonna change it by either adding a View.wait() method at the end of the prompt and each individual view would have to fill out specific data in its instance (like self.reward and self.shift_streak, not sure what will be there just yet).

That being said, it'd be much better if we just create an ABC (abstract base class) that deals with all the common logic processes involved like on_timeout the work attributes, even the stored interaction data in just that ABC. All the work views should inherit from that base work view. This is very much ideal and preferred.

On the flip side, could make it so that a single view is used to handle every single work task out there. That is difficult but from the looks of it, Dank Memer does it too. But as a drawback their available tasks are quite (terribly) similar to each other. The choice is yours. Personally, I'd go for the former (making multiple views that involve unique tasks).

This is unlikely to be in the works until the end of July (2024), when the school semester ends.