Java Text RPG

Newbie & Debugging Questions
#1

Hello, all!

Trying my hand at making a text-based RPG in Java. Just working on getting the framework set up and I’m running into a slight problem.

I’m trying to create a method of a Location class that returns whether or not a room contains a specific exit. My “map” (or list of connected rooms, rather) is stored as a hashmap. Each room/Location object has one that stores the connected rooms in the format ( Direction of Exit, Connected Room).

My method to pull whether or not the room contains a specified exit doesn’t work, and I’m not sure where I need to head to be on the right track, here.

This is the method:


public Boolean containsExit( String exit ){
        switch (exit.toUpperCase()){
            case "N":
                if (linkedRooms.containsKey("N"))
                    return true;
                break;
            case "S":
                if (linkedRooms.containsKey("S"))
                    return true;
                break;
            case "E":
                if (linkedRooms.containsKey("E"))
                    return true;
                break;
            case "W":
                if (linkedRooms.containsKey("W"))
                    return true;
                break;
            case "U":
                if (linkedRooms.containsKey("U"))
                    return true;
                break;
            case "D":
                if (linkedRooms.containsKey("D"))
                    return true;
                break;
            default:
                return false;
                break;
        }

Likewise, in my main class I’m calling the method as such:


    private void moveNorth(){
        if (currentLocation.containsExit("N").equals(true)){
            
        }
    }

My method is informing me that I have an unreachable statement, and that I’m not returning anything (and should be).

Any help would be excellent!

Thanks in advance.

#2

Unreachable is easy. Line 29 is unreachable code. The break; after your return.

#3

Ah. I had though a break; after every case (including default) was just the safe bet sort of thing to do.

Think I’ve got my return issue figured out. It’s a little more involved, and I had to add a boolean to compensate for my use of the switch statement.

Anyone have any suggestions or is this fine for all practical purposes?


    public Boolean containsExit( String exit ){
        switch (exit.toUpperCase()){
            case "N":
                if (linkedRooms.containsKey("N"))
                    containsExit = true;
                else
                    containsExit = false;
                break;
            case "S":
                if (linkedRooms.containsKey("S"))
                    containsExit = true;
                else
                    containsExit = false;
                break;
            case "E":
                if (linkedRooms.containsKey("E"))
                    containsExit = true;
                else containsExit = false;
                break;
            case "W":
                if (linkedRooms.containsKey("W"))
                    containsExit = true;
                else
                    containsExit = false;
                break;
            case "U":
                if (linkedRooms.containsKey("U"))
                    containsExit = true;
                else
                    containsExit = false;
                break;
            case "D":
                if (linkedRooms.containsKey("D"))
                    containsExit = true;
                else
                    containsExit = false;
                break;
            default:
                containsExit = false;
        }
        
        return containsExit;     
    }
#4

Your entire switch can be expressed as a one-liner:


public boolean containsExit(String exit) {
    return linkedRooms.containsKey(exit.toUpperCase());
}

Now it’s not exactly the same logic as above, because it allows for exits other than N/S/E/W/U/D, but that is probably a bonus.

Secondly, now that you’re using an unboxed boolean, you no longer need to compare it with .equals(true). You just say “if currentLocation.containsExit(“N”))” instead

#5

Oh my god. You just condensed my 43 lines of code to 3. Freakin’ bravo.

Thanks a ton! :smiley:

#6

A suggestion would also be to use some sort of Enum to describe the various exit types. Not that it’ll save you anything, but it’ll make things a wee-bit better. xD

#7

If you’re at all worried about performance or anything, I would use an array rather than HashMap. And then like UprightPath said use an enum for each direction. Then again it’s a text RPG and who cares? :stuck_out_tongue:

#8

I really like what MOO did with exits: they’re basically just objects in a room, kept in a list in .exits instead of .contents (the separate list is partly a legacy thing, and partly because it gave them a predictable matching order). The direction of the exit was then just the name of the exit (with shorter names as aliases, so ‘e’ would work for ‘east’).

When searching for commands, finding a command that was the name of the exit would simply invoke the exit, causing the player to move through it. Also, it allowed people to do things like “look east” without having to treat the “look” command any differently than for any other object – just match the exit like any other object in the room, and the exit’s description would either delegate to the description of its destination, or if the exit was opaque, to its own description. And by having exit objects, you could have special exits like doors that could be opened/closed/locked or ones that had complex locking behaviors, all by just using regular old subclassing of the standard exit class.

So there’s my rambling aside, which hopefully gets you thinking about exit objects…

#9

If your gonna do this, just use final integer variables. No need for an Enum.


public static final int NORTH = 1, EAST = 2, SOUTH = 3, WEST = 4; // etc...
#10

Ugh. I can’t say I like that method, but then I’ve been raised (And trained) to treat constant ints like that as though they’re plague carriers. I mean, in a simple case, replacing them is probably nothing to really worry about. In other cases, especially if you’re going to be using the Constants elsewhere, it’s probably a better idea to make use of the enums.

#11

This is a text adventure, not a roguelike – some rooms are going to have exits with odd names. There is just no good compelling reason to hardcode them into constants or enums.

#12

Hmmm, true enough about the hard-coding. Though, keeping a list somewhere will definitely be needed. Though, that’s more book-keeping than anything else.

#13

An enum is certainly heavier weight but I would argue it’s a better idea as it’s easier to maintain. Limes and lemons, though. :stuck_out_tongue:

#14

If you use integer, use a mask then.


public static final int NORTH=1, EAST=2, SOUTH=4, WEST=8; // etc...

public boolean containsExit(int exit)
{
    return ((roomExits&exit)!=0);
}

All depend on how data are organised.

#15

True, my suggestion of hard coded ints was based on the OPs source which has only 6 values (N, S, E, W, U, D) for exits. I definitely wouldn’t suggest it if your going to have unique exits for each map instead of just a few set exits that are used for every map.

As for having a list of exits, I would suggest doing this if your going to have a lot of unique exits. I just have an Exit object (because Java doesn’t have structs >_>) that reads it’s info from the map file, for whatever map is loaded, and keeps track of the exits position, the name of the new map to load, and where to place the user on the new map. That way all you have to do is check the user’s position against the exits. When you find a match load the specified map and place the user at the specified position. Of course some of this is overkill for a text RPG, all you’d need to keep track of is the exit’s position and where it exits to.

#16

Why would you mask? You can only ever move in one direction at a time.

#17

I suspect the mask was to encode the exits into single bits so the whole list would fit in one int. Make of that what you will, I think my opinion on that sort of parsimony is pretty well known already.

#18

I’ve found this post both informative and amusing at the same time.

The solutions to a simple problem seem to get more complex in their implementation each time - in an attempt to come up with the most compact and minute solution with each iteration.

I liked sproingie’s bool method because not only was it flexible enough to solve the problem, and extensible in the event of needing room for other value types, but also because it was readable and uncomplex.

I’m not an expert in Java, or any programming language for that matter. I’m not too bad though, either. But it does strike me sometimes that people are constantly trying to find the most one-line solution to everything, when sometimes just something readable (if perhaps more verbose) will do the job just as well.

I only recently found out about the ternary operator (usable in many languages, I believe). I was astonished at how much it can reduce lots of brackets and newlines in if-else statements.

However, I found that it made the code harder to read weeks down the line when I needed to fix something, even with comments.

I just think that the most efficient solution is not always the most elegant from a legibility and comprehension perspective.

Just my two bits :slight_smile:

#19

That said, I have to say I was very impressed by the broad range of offered solutions and responses to the OP’s thread.