Better Awards

[dacmot]

The awards package currently provides some achievements in WN. The awards are often repetitive (ex. eat 3 mushrooms, eat 333 mushrooms), tedious (place 25000 blocks), and don't provide much guidance to progress through the game.

The idea here would be to add more meaningful awards, and leverage the achievement mechanism to give players direction.

Awards, or goals, should follow some basic principles:

• A goal should not feel like busywork. Placing 10,000 furnaces is not fun.
• A goal should serve as a tutorial. Goals build upon knowledge or resources gained from completing earlier goals to teach the user something new.
• Unless partially completed, goals that require, say, having visited a desert, should not be shown to the user. Keep the amount of visible goals low for early game.
• Goals should be made for every mechanic of the game, from punching trees, to mining ores, to crafting mesecons, to making foods and killing enemy mobs with techniques (sidle a projectile). This is also why we should give future development responsibility of these awards to the developers of these mods (even if one of us is the one adding that code initially). As new mechanics are added to their mod, new awards would also need to be added.

[bell07]

Any Goal / Award should contain any reward defined. Placing 10,000 furnaces does not sense. It's a candidate for hidden award. Unexpected message "You placed 10.000 furnaces" is fun. Place 1 furnace give you capability to melt things. This is a real mission, can be started if first cobblestone is in inventory...

For implementation: Do we need an mtg_awards mod separatelly from whynot to cover all awards, provided for mtg-mods? Or do we just start a new "whynot_awards" mod with home in the game like whynot_compat? I expect the most awards cannot be pushed into the original mods.

[dacmot]

I think for now having a whynot_awards would be the best compromise, as not everything we want to do will apply to MTG mods. We can try to push some of those awards upstream and remove them from whynot_awards as they are merged.

[Lazerbeak12345]

That and we can use whynot_awards as a testing ground for how these new awards would mesh.

[bell07]

Started initial work in #66

Please push additional awards implenemtations directly into whynot_awards branch

[dacmot]

I've been mocking around with awards a bit, including submitting a couple of PRs. Unfortunately, Mr. Wardy is either very busy, and/or unwilling to respond in any way; including a PM on the forums. Given the few other open PRs that are several years old, I get a feeling he's uninterested in continuing work on the awards mod...

It should be possible to add the triggers and awards in whynot_awards if Mr. Wardy doesn't accept the PR. I'm mostly bummed about the translations.

That being said, using cmi would allow the addition of a few awards like killing a dungeon master. I'll open a separate issue for it.

[bell07]

Agree the triggers and awards should be added into whynot_awards, if not applicable to upsteam. If the awards mod is not maintained right, we need to look for alternatives

[dacmot]

While you're at it @Lazerbeak12345 , would you also check https://gitlab.com/rubenwardy/awards/-/merge_requests/88. Hopefully that will prompt Ruben to look at it. Thanks!

[dacmot]

Speaking of making better awards, I just found this article, linked in the repository's issues: https://www.gamedeveloper.com/design/designing-and-building-a-robust-comprehensive-achievement-system

[Lazerbeak12345]

I started reading that, and it's pretty good.

Ironic, however, is that the awards in this mod break every single rule suggested by that game developer. They're repetitive, the art was done incrementally (not all even by the same person), there's a huge amount, they reward tedium, etc, etc, etc.

[Lazerbeak12345]

Another thing, is awards considered still maintained? Most issues were from 3 years ago, some from 1 year ago, but the only commits were from 1 year ago.

[dacmot]

Yeah, it is ironic that the current awards are not very good.

I've asked Ruben Wardy in a personal message on the minetest forums if he was still maintaining it. No answer this past week. Maybe he's gone on vacation. He hasn't posted on the forums since March 22nd.

[Lazerbeak12345]

Perhaps the awards needs categories?

I can easily imagine awards getting out of hand if we add every idea that @dacmot suggested. (Not to say I don't like them - I really really like them. The missions system should touch every playable aspect of the game)

(originally posted in https://github.com/minetest-whynot/whynot-game/issues/60#issuecomment-1121589831)

[Lazerbeak12345]

We have a critical design issue that came up in the PR.

It seems the three of us are in agreement on most of the details:

• We want our awards to not be grindy.
• We want the awards to be hidden-by-default

But it looks like we need this question answered.

Under what criteria should these awards become visible?

[bell07]

My idea was to not throw away the boring default awards (dig 10000 tree) but make them hidden, so surprise appears if reached. The most default awards becomes also visible if reached. For Non-boring awards we need to define the "is visible" event for each award separately. Maybe we should introduce award levels to group them. Example:

Award "Find your new home"

• Description: "Your home is the place with your bed. If you sleep once in bed, you always respawn at this position in case of death"
• Award level: 1
• Award is visible: Always, from beginning (in Level 1)
• Award is completed: User slept once in Bed
• Reward: Unlock level 2 awards

[Lazerbeak12345]

My idea was to not throw away the boring default awards (dig 10000 tree) but make them hidden, so surprise appears if reached. The most default awards becomes also visible if reached.

I agree. Let's keep all of the awards we have, but hide the ones we find boring, etc.

award levels

I was thinking something like this as well. My idea's a bit different though.

In lots of RPGs there's sortof a reward tree, but it doesn't need to be visible. Complete one award to make a bunch of other awards visible, sortof thing. This can amount to the same behavior, but I like it better because it has a bit more freedom. One could implement the levels thing using this, and also have a "side quest" to do something that isn't part of the "core" rewards.

I think the "core rewards" should be in sequence, as in your idea. It could work by making the visible event require all events within a given set to be true (instead of just one event). These events could be things like the ones already in awards, and events like "other reward completed"

To "debug" such a complicated system, however, it might require that during a unit-test a .gv file could be generated so the linkages between awards could be rendered. (integration with QA Block would be a must)

[Lazerbeak12345]

Rubenwardy replied to your PR @dacmot

[dacmot]

Thanks for the reminder. I had seen the notification, but put it aside and forgot. I have addressed the review comments, and waiting for merge.

[Lazerbeak12345]

The achievements mod on contentdb should be considered as an alternative to awards

[Lazerbeak12345]

Upon further research, here's that library:

https://content.minetest.net/packages/Zughy/achievements_lib/

It's not user-facing. No GUI.

[dacmot]

Cool. I'll take a look this weekend maybe. See if it offers additional award triggers.

[Lazerbeak12345]

It seems like this library is basically a headless "awards" mod without any awards by default. I think this is actually the correct way to arrange things, but I don't think it's something we can use right now.

[dacmot]

Having a quick look at the code, it seems very similar to awards . The awards' API seems more mature and complete to me, plus it has built-in triggers for a lot of counting and events already. Achievements_lib seems to leave the trigger mechanisms up to individual mods to implement. If I understand correctly.

Other than not having bad default achievements (which can be flushed anyway), I don't see anything that would make it preferable to awards.

[Lazerbeak12345]

Thanks for reviewing it! These are good things to know.

[Lazerbeak12345]

Just was thinking about it... I don't think we need to remove or disable the current awards to make the awards captivating. It might be best to just add new, better awards. They won't get "Expert Lumberjack" (or whatever it's called) for a very long time, but if there's still something to work towards that's closer in sight than "mine 10,000" of x y or z, then the changes to awards would be good enough.

Crafting-guide related awards is one thing I'm interested in right now. Our current craft guide fork provides an API that should be sufficient for our needs to extend and add awards triggers.

[dacmot]

Bell07 also thought we should not remove the current awards:

My idea was to not throw away the boring default awards (dig 10000 tree) but make them hidden, so surprise appears if reached.

And yes, I'm all for adding craft-guide awards. Feel free to submit ideas in https://github.com/dacmot/sfcraftguide