This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi, I have been working at this problem all day now, I'm trying to write a somewhat simple text adventure "engine", although right now I'm hard coding everything just to get the concept down... I'm having trouble particularly with objects inside of rooms: I can't easily change the state of a given object without writing TONS of code. I'm looking for maybe some advice as to a better approach (object oriented) not code, just a more clear idea of how to approach the design of the problem. Here's my setup:
I have a class for the game, which I'm calling Gnome Mansion. Then there's a class for Room, which is not used, only extended. Also there's a class for RoomObject, also never used, only extended. For each room I create a new class and fill in the description and list of objects. Example:
Room by the way holds an array of RoomObjects, and there is a preset number.
So basically from my GnomeMansion class I make an array of Rooms, then populate each location with the actual rooms. I have a player class but don't seem to ever really need it... Then my parser calls an appropriate function based on the input. Here's the problem: If there's a lamp in the room, I can't just say room[x][y].lamp.turnOn(). However, that's the simplicity I'm looking to achieve. Currently I have to pretty much re-parse (if that's a word) some of the input. Let's say I want to turn the lamp on, I say "turn on the lamp" and the parser grabs tokens, finds "lamp" and "on" so it then attempts to turn the lamp on. Now I know this is a horrible way to do this, it seems, but I am calling a performActionOn() method that takes an object and a string that says what kind of action to perform.
As you can see, I'm obviously not making good use of polymorphism because I'm writing all this treacherous code just to perform small, simple functions. And imagine if my lamp had one more property... More and more nested if statements, that's what. Does anyone have any advice? I really appreciate any time spent looking at this. And sorry for the long post, I am just trying to be as clear and concise as possible... it's just turning into somewhat of a large project (at least for me).
What else is there to explain? Read about text adventure games: READ Or study the Java language on the Java tutorial. Google it. [ April 14, 2007: Message edited by: Eric Daly ]
Joined: May 16, 2005
Actually I am new in this area. I did get some Sun certificates. I learnt about Java Design Patterns. I think if you try Command Pattern for your example, the code might be simpler. Here is the website for this pattern:
Originally posted by Eric Daly: I can't just say room[x][y].lamp.turnOn(). However, that's the simplicity I'm looking to achieve.
It seems to me that naming your instance of lamp1, object, kind-of runs against the grain of what you want to do. I can see reason to have an array of objects for the room; but ... it's just a thought really.
Following the train of thought in this thread, I think I can agree that it might take a little more thought about what you're going to do with objects and what the circumstances are when you do them. When would you not have a handle on a lamp when you're turning it on or off? Power failure? I guess then the effect of the lamp could simply be made not available.
Correlation does not prove causality.
Joined: Jul 11, 2006
@Roger F. Gay: I don't mean to offend you, but I don't understand a word you said... I tried out the command pattern (I think), but it doesn't seem to help simplify things much. It's more of a slight change it seems. I guess I need general help thinking through the design of this program rather than a specific area of my code. Or maybe I haven't come to realize that this is a much bigger project than I imagined it would be. I mean, code has to be written to take into account every little thing that happens, and the more interactive the environment is, the more code that has to be written. Although, if anybody is interested to see what I have so far, I'll post it soon (just as soon as I get back into my Windows environment). It is functional, for the most part, but either I'm gonna have to find a way to simplify my code so that it's easier to add rooms and objects, or this is going to be one insanely short game.
I do a lot of code on MUSHes and MUDs, which are obviously text based games, they are essentially object oriented databases. I imagine an explanation of the way they work might help you?
Every object on a MUSH is given a database number by the server, which looks something like #20, or #52, or #1005.
Every object on a MUSH is one of four types - THING, ROOM, PLAYER, or EXIT.
Every object bar a room has a location (an attribute).
Every object bar a room as a 'home'. this is usually ignored on a MUSH for things and players, but for exits the home is the far side of the exit.
So there you go, you have your rooms and your things in the rooms. There are a few functions provided like lexits() (return the numbers of all exits in a given room), lcon() (return the numbers of all things or players in a given room). With those two you can shape what the player sees in the room, so a description of the room itself, followed by the names of all players and things, followed by the names of all the exits.
Its quite a nice system because rooms/exits/players/things are all fundamentally exactly the same thing. Its possible in a MUSH to be inside a thing (for example, a car, or a backpack) as well as a room, for example.
...as MUSHes are object oriented every object can be parented to another object, and you can store commands/attributes on them, but I guess thats probably more than you need. In terms of the real basics I figure a system like that should work, right?