5 hours ago, JustHusk said:

Thanks for the suggestions, again i am just learning at college level and although i'm doing this project because im ahead of my class and need something harder i dont really have a grasp on a lot of the keywords etc. I feel like it must be bad practice but would it be okay to just call methods depending on the players decisions?

Essentially that's what the decision tree does.  It just does it in a more computationally elegant way.  I'm not suggesting that you make this your go-to solution for everything, but you can start here https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/switch

Pay particular attention to the some of the later examples, get a grasp of what's going on here and then return to the Decision Tree info.

2 hours ago, Alberth said:

I'd suggest to do simple experiments, eg

- Switch and a door, you have to throw the switch before you can use the door.

- Somewhat more difficult 2 switches and a door, switches must be in the same position.

- More common form, switch, door, key to second door behind the first door.

It's not so much an adventure to play, but an adventure to program. You get through the process of writing the program, and managing all the variables. They are sinmple enough to try again if you don't like the solution in some way, while you pick up nice pieces of code and knowledge how these things work.

I can do this no problem, it makes sense to me.

But having twenty to a hundred of these put in an order that works based off decisions is what confuses me, i'm just looking for a better less messy way.

1 hour ago, Septopus said:

Essentially that's what the decision tree does.  It just does it in a more computationally elegant way.  I'm not suggesting that you make this your go-to solution for everything, but you can start here https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/switch

Pay particular attention to the some of the later examples, get a grasp of what's going on here and then return to the Decision Tree info.

Hmm okay, i understand switches as I've studied them but they seem rather limiting for what i want to do, well at least at the simple level I've learned them.

22 minutes ago, JustHusk said:

Hmm okay, i understand switches as I've studied them but they seem rather limiting for what i want to do, well at least at the simple level I've learned them.

They are VERY limited, and contribute to some significant code smell if you aren't careful how you use them.  I only suggested that specific article because it covers some basic uses of classes in the later examples.  Studying some of those might help you to begin understand some of the underlying mechanics of the Decision Tree code examples I threw at you before.    I imagine though, that most of the knowledge you are still lacking will be covered in short order in your college classes.  For now, just consume what you can and work with the tools that make the most sense.  You'll learn a lot by doing it the wrong way too.

15 hours ago, Septopus said:

They are VERY limited, and contribute to some significant code smell if you aren't careful how you use them.  I only suggested that specific article because it covers some basic uses of classes in the later examples.  Studying some of those might help you to begin understand some of the underlying mechanics of the Decision Tree code examples I threw at you before.    I imagine though, that most of the knowledge you are still lacking will be covered in short order in your college classes.  For now, just consume what you can and work with the tools that make the most sense.  You'll learn a lot by doing it the wrong way too.

Right that makes sense, i'll definitely work on that. I appreciate all the help! 

8 hours ago, Satharis said:

You'll find that a lot of suggestions on how to code something better are often simply different ways of doing a very similar thing. For instance it's quite possible to write your entire game using one giant code file with a ton of variables (enums or whatever). That would work and not really be any slower, code wise. Problem is it's horrible to look at, work with and just about everything else.

First I would figure out how you want the game to play, what is the interface like? Is it like a MUD or something? Do you type in text commands like "get key"? Is it a bunch of buttons you press in a graphical app? Text based doesn't tell you a lot. You can make a console game and have the interface be vastly different, rogue-likes are a good example of this.

Unfortunately it's hard to just suggest a way to code it because as I stated before, there are many different ways of doing the same thing. Some are more generic, some more specific, some work well in certain situations, some in others. Often a difficult part of coding is just deciding what method you want to use to tackle a problem.

That's fair, by text adventure i meant bare bones console describing the environment to you,  typing for where you want to go and what you want to do. I understand i didn't make that clear. I appreciate the point of view.

3 hours ago, lawnjelly said:

I don't know about your level of programming, but assuming nothing, a key concept that I see missing from the discussion so far is that for a text adventure, you should aim to make something that is 'data driven'. That is, you *can* actually make an adventure game entirely in a standard programming language such as c++ or c#, with each room taking you into a different function that displays the text for the description etc.

That is a very valid way to learn some basics of a language, but to make anything bigger than a few rooms you should aim to make your own mini text adventure 'engine'. That is, you should decide upon some data structures to hold rooms, objects, and e.g. decision trees, and make it so this data can be loaded in from files, rather than being hard coded as part of the program.

Once the 'story' becomes data, the role of the program becomes to do things like keep track of which room you are in (perhaps an ID?), and when entering a room, display a description of the room (maybe some text that is associated with that room ID), a list of objects in the room (a list joined to the room object?).. your inventory might be a list of objects joined to your player object?

You have a choice, you can either cheat and do some research how other text adventures store their data, or as a learning exercise, go in 'blind' and try and figure it out yourself. Having a text file describe a room with an ID, and lists of objects should be fairly simple. Encoding e.g. decision trees as text might be a little more challenging but will help you learn.

If you want to get a heads up on what kind of things you might be storing, I'm sure there are plenty of examples, here's one from google:

Just to add to this, you don't have to achieve everything in one go. Imo, your first aim should be to store in e.g. a text data file a list of rooms, e.g.

<room id="0">
"You are in a comfortable tunnel like hall. To the east there is the round green door."
	<exit dir="E" room="1"/>
</room>
<room id="1">
"You are in second room. To the west there is the first room."
	<exit dir="W" room="0"/>
</room>

load these into your program, and display the room description and be able navigate around them (you don't have to use XML btw this is just an example).

Just hearing the word 'engine' makes me feel a bit out of my depth, haven't even finished many full programs especially on the scale i plan with this one. But i will have to give that ashot as it is the most recommended option here and it seems beneficial to learn it now. Thanks for the help!

(Yeah don't really know XML i'm barely scraping the surface of c# lol)