I say it option 1. To make it good, in my opinion, it will consume week`s of development (if not more). But feature must be implemented in future, no doubts!
Well, then I'll take a look at:
10) Arena
- Find better buttons for the Arena main screen
- Sort out and allow girlsmeets between Arena girls and player (allow recruiting and revisit team-breakups)
- Add NPCs
- Improve messages
The idea of "behind the screens" logic is not just making girlsmeets better but also adding first steps to creating economy, make sure girls have cash to auto-buy items (when that is coded in) and also first step towards creating rival businesses. In any case, most of that is in distant future so we can drop it for the Alpha without to much fuss.
They are my view of code standard for some types of events.
Chance of spontaneous events should be low, chance of "Look Around" events should be a lot higher as long as there is code preventing them to appear to frequently.
They are my view of code standard for some types of events.
It might do for the Alpha, but final version should be something like:
Base event class with:
- basic trigger conditions
- locations
- max frequency (lets say a tuple of "times can be triggered/amount of days")
- name (also prolly the label)
Event dispatcher class with:
- array of all events
- tracking
- event registration method
- parent_location tracking
- etc.
pytfall.ed.register_event("meet_beggar_event", locations=["park", "main", ...], freq=(1, 10), conditions=[...]) would create the event from base class and append to the list.
than on every relevant label pytfall.ed.check_events() is ran to figure out if anything can be triggered.
Event itself is fully written in labels. Anyone with skills to code a complex event would know how to bypass registration and append it to dispatcher directly.
Similar to DSE, only better coded
