"I'm trying to do X, which design pattern should I use?" is usually the wrong question to ask.
A design pattern is a proven solution to a recurring problem, but its value as a pattern lies largely in its name: once you've solved similar requirements in similar ways several times, you can more easily remember the combination of classes and relationships that did the job, and you can more easily communicate the decision to other practitioners who also know the name and the pattern.
But when you don't know what to do for a set of requirements, simply being told the name of a pattern will do almost nothing for you. You will have to follow the details of the situation, understand the pressures involved and why one decision is preferable to another in order to take away any benefit from learning the pattern. It's almost always better to attempt your own solution to understand the trade-offs involved, and then compare your code to the example code given in the pattern literature. Then, either you will have reinvented a pattern - congratulations, you've added a useful tool to your tool kit. Or you might suddenly "see the light" and understand why this other arrangement of classes and methods works better - congratulations, you've acquired a new tool and found a solution to your task. (Or you might find that your own solution actually works better. Double congratulations! You've succeeded better than others, and perhaps you can eventually extend it a new pattern of your own.)
In any case, you usually do better by writing code for your problem and then comparing it to example solutions than by choosing a design pattern and recreating it for your use case simply because it's a well-known pattern. You don't know whether or not a pattern is a good fit for your situation until you've had a go at it and understand what makes it tricky. Immediately seeing "Ah, I need to construct a Bridge for this" only works when you already know both your problem and the design pattern from experience.
So far, you haven't described anything that would require a complicated arrangement of cooperating classes at all. Users can solve tasks and advance through stages, and they can buy benefits. That doesn't sound like anything more complicated than an entity with three attributes, or maybe n:m relations for tasks and benefits. What's giving you trouble so that you think the straightforward implementation won't work?