Having a difficult time with Case statements

I am trying to implement a simple frontend for a text adventure that
I’m putting together for ruby practice. My idea was to use case - when
to validate player input and to progress through a menu system,
character creation and the loading of character files. The code runs
cleanly for me but effectively does absolutely nothing. I’ve exhausted
about every idea I’ve had for a nice clean format for handling this and
I’ve decided to ask someone that knows what they are doing. I’ve
attached the source file in question and I would greatly appreciate it
if someone could have a look and offer me some advice on what I’m doing
wrong or how to better design said system. All feedback is welcome,
Thank you.

Add the method you created to the end of the program ‘definition’ you
have.
ie: You have defined the program method startUp without invoking it.

tesThis.rb:12:in startUp': undefined methodblue’ for
“Nephlen”:String (NoMethodError)
from tesThis.rb:165

paradisaeidae.

Mark T wrote:

Add the method you created to the end of the program ‘definition’ you
have.
ie: You have defined the program method startUp without invoking it.

tesThis.rb:12:in startUp': undefined methodblue’ for
“Nephlen”:String (NoMethodError)
from tesThis.rb:165

paradisaeidae.

Thank you for the feedback but I should have mentioned that it is one of
several source files and the startUp method is called from a main
function elsewhere. The source also makes reference to a few things here
and there that are not included in that particular file. I thought it
would be a bit much to just dump all the source code up here so I opted
for the part causing me the biggest headache. When I said it “didn’t
work at all”, what I really meant was that it doesn’t work as I intended
it to. I will post some sample output from me running the game using
that menu/startup system.

bsud.rb combat.rb items.rb magic.rb maps person.rb saved shop.rb
startup.rb world.rb
chris@Dell-D510:~/bsud$ ruby bsud.rb
Nephlen
What would you like to do?

1 - Load a Saved Game.
2 - Create a New Character.
3 - Exit from Nephlen.
4 - View the Readme file.
2
1
3
4
2
1

I go through and try any of the inputs that “should”, in my opinion, be
recognized by the input tracking case statements but nothing happens at
all. I am completely dumbfounded =)

Michael W. Ryder wrote:

Chris B. wrote:

Thank you.

Attachments:
http://www.ruby-forum.com/attachment/2623/startup.rb

Looking at your code it looks like you need to remove the first case
statement and use something like a while loop. From what I can see it
looks like when you select ‘2’ it changes ‘startstate’ to 1 and then
exits the case statement. An alternative is to set startstate in the
main program and then call startUp with the current startstate – i.e. x
= startUp(startstate). Then test x to see if you want to call startUp
again or exit the program.

Wrapped a call to startUp() into the main game loop and made startstate
global…it’s working like a charm now! =) Thanks a billion!

Chris B. wrote:

Thank you.

Attachments:
http://www.ruby-forum.com/attachment/2623/startup.rb

Looking at your code it looks like you need to remove the first case
statement and use something like a while loop. From what I can see it
looks like when you select ‘2’ it changes ‘startstate’ to 1 and then
exits the case statement. An alternative is to set startstate in the
main program and then call startUp with the current startstate – i.e. x
= startUp(startstate). Then test x to see if you want to call startUp
again or exit the program.

Michael W. Ryder wrote:

Chris B. wrote:

exits the case statement. An alternative is to set startstate in the
main program and then call startUp with the current startstate – i.e. x
= startUp(startstate). Then test x to see if you want to call startUp
again or exit the program.

Wrapped a call to startUp() into the main game loop and made startstate
global…it’s working like a charm now! =) Thanks a billion!

Glad to see you got it working. I think what you were trying to do
would have worked in C as the case statements keep executing until they
hit a break.

Yeah I was expecting them to continue until told to quit! Is there a
way to repeat cases in ruby without dancing around it?

Chris B. wrote:

exits the case statement. An alternative is to set startstate in the
main program and then call startUp with the current startstate – i.e. x
= startUp(startstate). Then test x to see if you want to call startUp
again or exit the program.

Wrapped a call to startUp() into the main game loop and made startstate
global…it’s working like a charm now! =) Thanks a billion!

Glad to see you got it working. I think what you were trying to do
would have worked in C as the case statements keep executing until they
hit a break.

Yeah I was expecting them to continue until told to quit! Is there a
way to repeat cases in ruby without dancing around it?

There probably are but my personal habit these days is to use two
methods

one that handles the whole loop like so

loop {
result = get_user_input
break if result == :exit
}

and in that other method call it again and again until it returns
:exit (or evaluate other results if needed).
In my experience everything can be rearranged to be in some methods
which can be controlled and called in any way that is needed to
get the desired functionality. Simply make a method for the case
menu and invoke it again if you need it, testing your input
against it choices.

Michael W. Ryder wrote:

I think what you were trying to do
would have worked in C as the case statements keep executing until they
hit a break.

In C if there is no break it will fall through, yes, but that would
hardly
result in the behaviour the OP wanted. Take this for example:

#include <stdio.h>
int main(int argc, char** argv) {
int i = 0;
switch(i) {
case 0:
i = 2;
case 1:
printf(“i is one (except it’s not)\n”);
case 2:
break;
}
return 0;
}

I assume the OP would want that to execute the 0 case and then the 2
case, but
it executes all three. I also assume that if the 2 case would set i to 0
again, the OP would want it to start over again, which it also won’t.

HTH,
Sebastian

Sebastian H. wrote:

int i = 0;

I assume the OP would want that to execute the 0 case and then the 2 case, but
it executes all three. I also assume that if the 2 case would set i to 0
again, the OP would want it to start over again, which it also won’t.

From the looks of the code that I was tracing selecting ‘2’ would set
the state to ‘1’ which was the next step in the case statement.
Obviously this would not have worked for every selection but it looked
like he was trying to use C’s case statement behavior.

Michael W. Ryder wrote:

From the looks of the code that I was tracing selecting ‘2’ would set
the state to ‘1’ which was the next step in the case statement.

Yes, but selecting 1, sets the state to 4, so in that case he would not
want
1,2 and 3 to execute.
I’m pretty sure he simply expected an implicit while true loop around
the case
statement.

Sebastian H. wrote:

Michael W. Ryder wrote:

From the looks of the code that I was tracing selecting ‘2’ would set
the state to ‘1’ which was the next step in the case statement.

Yes, but selecting 1, sets the state to 4, so in that case he would not
want
1,2 and 3 to execute.
I’m pretty sure he simply expected an implicit while true loop around
the case
statement.

I’m not one hundred percent sure what either of you believe I wanted
but I will do my best to explain =)

The first case prints a list of 4 options that you may choose to
perform. You can only choose one and the corresponding case should be
the only one that is performed. The entire system wasn’t fully in place
yet but the only time you would be back at the first menu is if you
chose to load a character and were unable to for whatever reason. The
“character creation” System would step through each case 1 at a time but
repeat itself if conditions for progressing to the next step were not
met. As it is written it works perfectly(as far as I can tell) when put
into a startUp() method and placed inside a loop. The loop breaks when
case 4 conditions are met.