Programming patterns my reward system

Started by
2 comments, last by WoopsASword 7 years, 5 months ago

I have this reward logic in my reward , my goal is to build a library which I can keep reuse later , however by this following method I can't


class RewardSystem
{

float m_timer;
void Update()
{
  m_timer -= time.deltaTime;
}

void btn_Reward()
{
   if(m_timer > 0)
   {
       UnityAds.ShowAd();
       if(UnityAds.FinishAd())
       {
          CoinSystem.m_coins += 100;
       }  
   }
   else 
   {
      CoinSystem.m_coins += 100;
   }
}
}

The problem I'm having here is if the user does not have want to have ads system instead doing something else to collect coins or they decided to collect the coins with just pressing a button without looking the ads, people would need to rewrite it, and also it breaks the SOILD principle. So I'm wondering is there any programming patterns can help me to solve this problrem ,thanks

Advertisement

I would use the KISS principle, which basically means that you shouldn't overthink this. Making this feature more complex to allow possible uses that you don't need today and might never need is a waste. Worry about it when you need two different behaviours for the reward system.

And if that happens, the Strategy Pattern seems a good candidate here. Basically you would allow to set a function to the RewardSystem that would be called in btn_Reward, so you can have different strategy functions and create your RewardSystem object with the behaviour you want.

But let me reiterate that this will make your code unnecessarily more complex. It's good to write code that is easy to maintain and modify, but adding complexity for the sake of possible future scenarios is over-engineering.

but adding complexity for the sake of possible future scenarios is over-engineering.

this

Norm Barrows

Rockland Software Productions

"Building PC games since 1989"

rocklandsoftware.net

PLAY CAVEMAN NOW!

http://rocklandsoftware.net/beta.php

If you need to seperate this logic then create another class- and think of abstractions.

"I have an abstracted logic for doing an activity, in the end it returns the state of the activity and rewards the player."

So:

interface IActivity {

bool Run();

}

class A {

IActivty MyActivity;

void Reward() {

var result = mMyActivity.Run();

if(result) { coins +=100;}

}

}

This topic is closed to new replies.

Advertisement