I'm trying to create a text-based movement simulator for my little pet MUD project. It consists of six classes:
Room.java: Instance variables for x-y location, list of mobs in the room, name, short descriptive narrative, etc.
Grid.java: Instantiate an ArrayList<Room>, create two Rooms and add them to said arraylist.
Mob.java: Contains the framework for your basic player or creature unit. All the instance variables including the now-relevant currentRoom and x/y integers, and the perhaps later relevant attackStrength etc. Also behavioural methods like move(String direction) and look();
Input.java: Contains the method directory, which tests player input against various different possible commands.
GameHelper.java: Knows how to capture keyboard input.
Tester.Java: Instantiates all the above classes, loops GameHelper.getUserInput() and Input.directory().
For the most part, the code works (save for the fact that when you move the wrong look() is reported, due to setLoc() not being utilized yet, due to the fact that I don't know how to access my list of rooms from Mob.java, because it was instantiated in Tester.java), but it's terribly clunky, and I know it. Grid.java for example only contains two rooms, because it's system for implementing rooms is a huge hassle.
Basically for any and all advice on how to tighten my code up, so that I can get a better practical understanding of Java. Thus far I've learned up to and including interfaces in the Head First book, and I feel like I understand most of the concepts which I've learned thus far, but as far as implementing them...well...I can tell I'm missing a few tips and tricks.
Hi, I think I would suggest thinking about how your objects interact with each other. Start with teh simple case, what does a room need to know about itself? does it need to know its location on the grid, or does the grid need to know this information?
Same for the Mob object, thats an awful lot of data, could some of it be split in to delegate objects?
One thing you could think about is the rleationship between grid/room/x,y.
I think I would go for something like: Room has an unique id. Grid keeps a hashmap of rooms (using the id as the hashcode??) A mob has a unique id. Grid keeps a hashmap (or perhaps a different collection) of mobs and the room id they are in.
This way your lookups might be quicker, you assign a room id to each exit, and when the user types go room X you can do a look up against the X in the hashmap rather then search though the array list for the room.
Thanks Gavin! I haven't learned anything about HashMap yet, so I looked it up in my book and found that it isn't taught for another 200 pages Rather than skip ahead I figure I'll just quell my curiosity for now. HashMap, however, sounds like a very apt solution to my dilemma. Even from my very-cursory understanding of it
One question: I instantiate Grid.java in Tester.java, but I also want to be able to access Grid.getRooms() from Mob.move(String direction) so that I can Mob.setLoc() before I Mob.look(). Thus I would recieve the correct room's description when invoking Mob.move(String direction).
Now, as soon as I learn a bit more, including HashMap, it sounds like my current code will become defunct and this question obsolete. But, for now, and for my own education, is there any way I can set a reference within Mob to the same Grid object that Tester instantiates? Otherwise I have to instantiate a whole new object, just for that getRooms() function, and that seems like a waste. The only way I can think of to do it is to make Tester's Grid reference an argument that I throw to Mob, but that seems like more work than it's worth. I'd have to throw it to every instance of Mob, right?
Mourning Global Variables, Alex [ June 02, 2008: Message edited by: Alex Birmingham ]
I've been working on a similar project lately. It's probably the fifth time now that I've started a text-based mud from scratch, and this time I'm determined to make it work. I have a functional design, but I don't think it's quite right because it's going to be difficult to add objects that you can pick up and use... But anyway, just to give you an idea of what I've done with the map system: I have Rooms set up as an enum, and they have a description, boolean exits for north, south, east, west, and then an x and y coordinate for their location. Then I have a Map class that stores each room in a 2D array (for now, but it will be 3d). I could post code later, but right now I'm not at my home pc... Anyway, the most important thing is to start with a good design... otherwise, eventually, you'll run into a problem you can't really solve (without wrecking your brain at least, and maybe some existing code). I think, like Gavin said, Map (or Grid) should keep track of Rooms and Mobs. I'm not 100% sure my design is rock solid... but it's given me a good functional start so far...
Studying for SCJP 6
Joined: Jan 01, 2007
Taking sometime to think about how the various objects, Grid/Room/Mob interact is really time will spent, it will help you to sort out what Objects should be holding what information. However here are some of my thoughts:
You should NOT keep two different instances of grid, trying to keep them in sync, would be a nightmare in a full MUD.
Thinking about what the function of look() is. Could it be moved to Room or Grid and perhaps be renamed Examine? I havent had a chance to look though the code properly.
I think a Mob, should always have a reference to there current location, this also saves them from having to know their x,y. So you would do something like:
Then look code be a "pass thrrough" to description or what ever:
Then moving between rooms can be as simple as assigning the room to Mob , grid should slipply keep track of how rooms are connected.
An alternative I have considered is that each room has a list of Exit objects, and they have a reference to the Room they are an exit to.
If Exit were an interface you could in theory assign the exit "property" to any object, so a pipe (for Mario fans) could be an Exit.
With all those codes im sure you found the help you needed!
Joined: Jan 01, 2007
Hi, I have taken a closer look again. One of the things I had noticed was that the Player is Called Mob, I would rename this Player, you could go one further and create a class/interface tree, with Charactor as the root and PlayerCharactor and NonplayerCharactor as sub-classes/implementations.
Also, you shoudl generlise when using Colections, so rather then
you would use
Sorry this has been delayed, hope it is still useful.