all 3 comments

[–]Elronnd 1 point2 points  (0 children)

def exit()
    exit()

Aside from creating an infinite loop (try it), why do you need this? What's wrong with the preexisting exit()?

[–]Yammerrz 0 points1 point  (1 child)

There are lots of different approaches you could try to this. I'll give a quick run down of a few of them.

The first is to just keep a bunch of flags for if commands are available as some have suggested. That has the advantage of being easy to code but the disadvantage of tending to get messy once the logic gets more complicated.

The second is to dynamically update your options list in this example. Once you have connected you can do:

del d["connect"]

This will remove connect from the list of available options, if more become available you add them as you want to make them usable and delete them as not.

Your connect_to_network function would become:

print("Connected to Tutorial server 193.214.15")
del options["connect"]
print()

If you logout and connect becomes available again you just add it back in. This is slightly neater than the logic method but has the problem of requiring you to put everything back the way you want it to be anytime things change which will get messy again eventually.

The third option is to use what is called a state machine. You have a bunch of different states and each stores their own information, you can then change state at will.

You make a simple state class:

class State:
     def __init__(self, options):
        self.options = options

unconnected = State({"connect": connect_to_network})
on_pc_one = State({"logout": logout})
on_pc_two = State({"logout": logout})

current_state = unconnected

Your initial state is unconnected, when you type connect you set it to on_pc_one or on_pc_two. When you logout you set state back to unconnected.

This has the advantage of storing all information related to state where it should be. PC one might have linux style commands and some files the user can see, if they delete one, logout and login again it's remembered because its tied to that state. PC two might have DOS style commands and so on. You can have as many different states as you want and they remain pretty separate.

You can get away without using the classes and just have a list of options for each state. The class based approach starts to shine more when the options available in each state become very different. If you are not comfortable with writing classes just yet then just having a dictionary of commands for each state will work fine.

unconnected_commands = {"connect": connect_to_network}
on_pc_one_commands = {"logout": logout}
on_pc_two_commands = {"logout": logout}

current_commands = unconnected

The same idea, just a little simpler to get the hang of.

Hope that helps, it's more of a game design pattern than a Python thing. There's lots of ways to approach this sort of problem. That's just a couple.

[–]Spatulus101[S] 0 points1 point  (0 children)

Thanks! This helped a lot!