Warrior, rogue or wizard?

hey there!

I just started the 2d course and wanted to add a bit of flair and make my text game a little more fun. The idea im working along is the old D&D type class idea. I’d like to be abel to ask the player in the first screen what class they want to be.
based on that choice i’d like to set up a boolean of some sort that represents that.
Then, as the player goes through the game, i’d like to offer them alternate ways to progress dependent on class, so it’d be like this :

A monster is ahead. Would you like to:

  1. attack the monster
  2. magic the monster
  3. creep past the monster

then dependednt on thier class and the choice, the game would say wether it passed a check or not. So obvs the warrior would choose option 1. but if they chose option 3 then the game should go a different way because a warrior can’t sneak past…

anyone know how hard it would be to introduce that with the state system?

1 Like

Hi Kheldarath,

It’s not that difficult to realise your idea but I would suggest to complete the project first before you add more complexity. Once the “normal” story game is done, you could, for example, add an integer variable to the State class. You give each State object a number. And in the AdventureGame, you could check the value of the variable and do something depending on the value.

Depending on your idea, you could use something other than an integer, for example, an enum.

Before you start, draw a flow diagram of the logic you would like to implement before you implement it. That’ll make most things easier.

Also please feel free to ask our helpful community of students over on our Discord chat server.

Hopefully, this helped you a bit. :slight_smile:


See also:

I just completed the Complete 2D course and I fully agree with Nina. I too put much complexity in my first story project but I was never able to finish it due to my knowledge didn’t match my ambition.

You’ll learn how to do all these things you’re asking throughout the course. The course is organized in such a fashion to introduce new concepts along the way.

My biggest suggestion for you is to DEFINITLY implement your own ideas (best way to learn) but try to fit your ideas into the direct concepts you’re learning about (or have learned about in previous projects) instead of trying to implement something you have not learned yet.
This will help keep you on track and you’ll learn MUCH faster. :slight_smile:

Good luck!

I don’t see any problem in trying to add something one hasn’t learned yet because there is always something one hasn’t learnt yet. In my opinion, the best way to learn is to implement one’s own idea, to apply one’s knowledge and to do some research by oneself.

The relevant mechanics to make Kheldarath’s idea work have already been covered in the Text101 and the NumberWizard section; expect for enums, which one could easily look up on DotNetPerls. The rest is just about adding stuff to the State class similar to what was already done with the story text, and in the AdventureGame class, one would just have to add a few if-statements which depend on the rules of the game. The rules of the game must be defined by the game designer.

There have been a few beginners who sucessfully added pictures which changed depending on the current state by applying what they already learnt and by looking up the Image class in the API themselves. Another beginner successfully added a history, so one could “go back”. I just pointed them to the Stack class and assisted them a bit but they developed the solution mostly by themselves.

And even if the current solution is incompatible with the new idea: if necessary, replace the current solution with another one. Rick’s solution solves Rick’s problems, not necessarily yours. The concept is key. As long as you have a concept and break it down into small, manageable tasks, you will very likely be able to accomplish your goals. :slight_smile:

2 Likes

If you are new to coding you can pretty much do this without even changing or adding things to your code, the problem being that you’ll be copy-pasting way too many things, but it could also lead to some very interesting results.

To manage this without coding, I would do this: Create the story with a single class in mind, after finishing it, copy paste the whole states into another folder and adjust the options for another class.

If you want to code it you can pretty much do it with your current knowledge as Nina already stated.

Here is a simple solution I can think of.

using UnityEngine;

public class Player : MonoBehaviour
{
    [SerializeField] public bool canSneak;
    [SerializeField] public bool canCastMagic;
}

using UnityEngine.UI

public Class ActionButtonHandler : MonoBehavior
//class that you can attach to each of the options that will activate/deactivate button
{
    [SerializeField] bool requiresMagic;
    [SerializeField]  bool requiresSneak;

    void Start()
    {
        Player player = GetComponent<Player>();
        Button button = GetComponent<Button>();
        if (requiresMagic && !player.canCastSpells)
        {
            button.interactable = false
            return; //button is already deactivated, no need to continue
        }
        if (requiresSneak && !player.canSneak)
        {
            button.interactable = false
            return;
        }
    }
}

That’s the simplest way to do it. If you want to get more fancy you can make the UI display dynamically so instead of disabling the button, it doesn’t display it at all. But that’s a bit more code.

If you want to get a little more intricate code, could also use inheritance and make a base player class, then each character class inherits from that.

using UnityEngine;

public class Mage : Player
{
    //various mage things here
}

public class Rogue : Player
{
    //sneaky stuff
}

Then in the button handler instead of requiring the bool on the Player class you can use this:

if (requiresMagic && player is not Mage)
{
    button.interactable = false;
}

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms