I've been making a text-based game to practice Java. Basically the player moves around a 2-D grid and different stuff happens on each space.
I keep track of where the player is using row and column values. I then feed those values to a method to make whatever is supposed to happen on a particular space happen.
All sorts of different things might happen on a space. The player might fight a monster, have a dialogue, or there might be nothing there. To complicate things further different things might happen different times a the player moves onto a space (random).
However, the grid has 36 spaces so that is a lot of if statements. ie: if row = 0 & column = 0 ; if row = 0 & column = 1; ........... if row = 5 & column = 5. So, this will end up being a really long-winded method.
Here is an example of what some of the code looks like right now:
I'm pretty new to Java and just trying to learn the most conventional/cleanest way to do things. I'm fine having a huge long list of if statements but I don't want to show this to a professor or employer and have them tell me how foolish I was to do it that way, hah.
I havent really got down to code this idea but I am going to state it in a conceptual way:
Each square of the 2-D grid should support call back mechanism, which means that it should keep track of the code to execute when someone reaches/uses that square. The way you provide this code is that you have a general Callback interface and then provide an implementation of that callback interface ideally in the form of anonymous inner classes. So you have each square of the 2-D code its associated block of code to execute. This block of code to execute is the one which is present in your if-else condition.
Using this approach you need not even worry the row and column values of the square which your game is tackling. You just need to have the instance of the square and then invoke the callback registered for that square.
Just an initial observation. You test for 'column == 0' multiple times, you could move those to a single enclosing if() statement. The remaining 'row == 0' etc should be if/else if's. Hard to give feedback without more info. Also 'if( xxx == true )' should be written 'if( xxx )' by convention.
Mohamed, I like where you are going with that and conceptually it mostly makes senses but I think the implementation is a bit over my head right now. So I'd have all of the squares as a collection of objects, but how would I keep track of where I am without row and column values?
Carey: Thanks for that suggestion, I could clear up some code by instead of testing for 'column/row == x' multiple times using nested if/else if statements.
What other info would you need for feedback? Also, thanks for the convention lesson, it is actually really helpful.
Maybe this info will help things make sense:
So I have a Class that keeps track of the player position using integers. It is fairly simple -- the player starts at row 0, column 0. Various methods move the player up (-1 row) /down (+1 row) /left (-1 column) /right (+1 column) on a grid I've made (which displays as an array of characters).
The player's position is then fed to the grid(map) which displays where the player is on the grid:
The updateMap method is similar to the room method in my first post in that it is basically just a big long block of if/else if statements, although there is more code in the room if statements because there is more going on.
When the player is on a particular space (which the program knows because of the row and column) stuff happens. I guess I'm just trying to figure out if there is a more elegant way to write the code? The way I'm doing it works, but is there a prettier or more standard way of doing it (that isn't super advanced...I've only taken 1 semester of Java).
Piet Souris wrote:Since each field represents some action to happen on that field, one possibility would be to first define some interface for each field.
@Hans: And what Piet describes is the Object-Oriented approach to problems like this.
What you have written (lots of if...else or switch statements) is called "dispatch code" and it's usually a red flag to an experienceed programmer that they haven't sufficiently analysed the behaviour of their objects. It isn't always the case, but you'd be surprised how often it is; and in those cases I would definitely look at a polymorphic alternative such as Piet described.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here