Heya! I’m currently working on a little minigame but I’m having a hard time imagining how I can pull this off. Here is the rough idea:
(Code isn’t representing my code, it’s just to give a rough look of what I mean)
That’s the rough idea of what I want to do, my problem is that the player should be able to collect the possible Clues in any order. So for example the user collects the Knife first, the knife would become Clue1, if the player finds the wallet first, the wallet becomes clue 1 etc.
Clue 1 should always represent button 1 which is pretty easy to do. However when I want to call what happens after that, how can I check which PossibleClues represent the actual ClueOrder without doing thousands and thousands of “If’s” or “Switch-Cases”?
One thing that you could do is create a Clue class. You’re currently representing clues as 3 separate primitives. As you’ve already seen this will become a nightmare to extend.
A simple solution could be to have a List<Clue> that you add to as the player gains more clues. Then the first one will be at index 0
And how would I check which index represents each possible clue?
And wouldn’t this pratically still be the same in the end since I need to check
and that for every single ButtonPress?
There are probably a lot of ways to sort this out. I’m assuming the problem is you want there to be an arbitrary number of mysteries that are solved by some arbitrary number of clues, along with many red herring or utility items that don’t solve any mystery.
Think this through without programming first. How do our minds see it?
Well, a clue could be just about anything, even intangibles. Our mind is like a big old bag of clues, and a player’s inventory is a literal bag of clues. A “mystery” is a question with an answer, but we don’t know the answer yet. The clues related to that mystery will reveal the answer if you have all of the required clues.
This creates some possibilities. We could say a mystery is an object. That is has a question and an answer is apparent. It could know which clues “solve” it. If we do it that way, we can ask a mystery if it is “solved” like this:
Each mystery still needs to know which items it requires, but we can generalize this as well. Then you end up with a pretty flexible system without worrying about lots of if statements. For example:
Now, for your example, we could set up the mystery:
The order of the clues won’t matter. The Mystery checks for all three. You can change which clues are required by changing how you create the Mystery. You can add more Mystery objects that use different combinations of clues.
This is not the most elegant or leetcode of approaches, but it will work for a simple game with fewer than a few thousand items without much perceptible delay.
Don’t get hung up on “I made a button and it has to correspond to a specific clue”. The buttons should have nothing to do with figuring out how your game works. As someone pointed out, suppose your inventory is a List<Clue>. Button 1 will always point to element 0 of that list, whether it exists or not. That could be any item, which is why it’s a good thing the Mystery looks at the inventory, not the button.
Part of expert GUI development is living by, “Separate your UI from your logic”. This is an instance of it. The UI is just there to display the game state and accept user input. Don’t write algorithms against it!
I think you should look into Lists or Arrays.
I also think that what others have mentioned with creating classes is a great idea.
Then you could have a List of Clues, List<Clue>, and each clue could have properties like strings for their name, any dialogue related to them, a boolean for whether they’ve been found, and anything else you might want.
For your menu, you could just check for that boolean.
So you mean you don’t want to be doing like this?
What you should do is define a class like
then you can do
The following piece of code was written with LINQPad 6.0. So you can copy paste it there and press “Execute”. What we have here are extension methods on a enum. The enum hold the item values and the extension methods the desired logic. The data structure I used is a queue aka FIFO (First In First Out), so the item that will be inserted first, is gonna be the first clue and so on and so forth. Additionally there is an if conditional statement, that check if the item already exist as a clue in the queue. If yes, then it doesn’t add it again, so no duplicates.
I wouldn’t suggest Lists, because they have no order compared to Queue (FIFO), or Stack (LIFO). For more about Queue you can find here Queue<T> Class (System.Collections.Generic) | Microsoft Docs
C# devs
null reference exceptions