nexustix/godot-nexustix-utilities

Fork 0

Checklist class for handling game "checks" and progression flags #5

New issue

Closed

opened 2026-02-09 23:42:31 +00:00 by nexustix · 6 comments

nexustix commented

2026-02-09 23:42:31 +00:00

Owner

No description provided.

nexustix added this to the (deleted) project

2026-02-09 23:42:31 +00:00

nexustix commented

2026-02-10 00:12:32 +00:00

Author

Owner

The class will need some way of:

Adding a check
Checking a check
Querying the status of a check

A check might be fine as a boolean that is being stored in a String-keyed Dictionary

There needs to be a signal for when a check becomes checked

There should be a mechanism to ensure all logic pertaining to checking a check has been run before marking a check as checked

The class will need some way of: - Adding a check - Checking a check - Querying the status of a check A check might be fine as a boolean that is being stored in a String-keyed Dictionary There needs to be a signal for when a check becomes checked There should be a mechanism to ensure all logic pertaining to checking a check has been run before marking a check as checked

nexustix commented

2026-02-10 00:14:47 +00:00

Author

Owner

A check can be turned into a non-primitive; which would allow a check to simultaneously contain the checked status, as well if the check has been "collected"

class Check:
    var checked: bool = false
    var collected: bool = false

A check can be turned into a non-primitive; which would allow a check to simultaneously contain the checked status, as well if the check has been "collected" ```gd class Check: var checked: bool = false var collected: bool = false ```

nexustix commented

2026-02-10 00:23:55 +00:00

Author

Owner

There will need to be a separate reward logic to actually dispense rewards that are the result of a check.
Checks and rewards are not guaranteed to be a 1:1 relationship at this level, and rewards should not be modelled as part of the Checklist.

The reward logic should hook into the Checklist signals for a check being checked, run their reward dispensary logic, and afterwards mark the check as "collected".

There will need to be a separate reward logic to actually dispense rewards that are the result of a check. **Checks and rewards are not guaranteed to be a 1:1 relationship at this level**, and rewards should not be modelled as part of the Checklist. The reward logic should hook into the Checklist signals for a check being checked, run their reward dispensary logic, and afterwards mark the check as "collected".

nexustix self-assigned this

2026-02-10 00:24:33 +00:00

nexustix commented

2026-02-10 00:31:10 +00:00

Author

Owner

When using a String keyed Dictionary the keys interesting_check and INTERESTING_CHECK are distinct keys, it may or may not be desired. Maybe keys should be sanitized/normalized before being used as an index.

When using a String keyed Dictionary the keys `interesting_check` and `INTERESTING_CHECK` are distinct keys, it may or may not be desired. Maybe keys should be sanitized/normalized before being used as an index.

nexustix commented

2026-02-10 00:34:32 +00:00

Author

Owner

@nexustix wrote in nexustix/godot-boilerplate#5 (comment):

When using a String keyed Dictionary the keys interesting_check and INTERESTING_CHECK are distinct keys, it may or may not be desired. Maybe keys should be sanitized/normalized before being used as an index.

sanitizing and normalizing of keys will be treated as an external issue, and will not be handled in the class itself, since it would also add unneeded complexity.

@nexustix wrote in https://git.nexustix.net/nexustix/godot-boilerplate/issues/5#issuecomment-15: > When using a String keyed Dictionary the keys `interesting_check` and `INTERESTING_CHECK` are distinct keys, it may or may not be desired. Maybe keys should be sanitized/normalized before being used as an index. sanitizing and normalizing of keys will be treated as an external issue, and will not be handled in the class itself, since it would also add unneeded complexity.

nexustix commented

2026-02-10 01:14:57 +00:00

Author

Owner

Preliminary implementation written, needs testing: bb10a45211

Preliminary implementation written, needs testing: bb10a45211

nexustix added this to the (deleted) project

2026-02-10 01:20:35 +00:00

nexustix added the

new feature

label

2026-02-10 02:14:45 +00:00