Numbers that appear in the headings column indicate areas of interest where it's possible to change angles within a scene, or even manipulate the environment in some rare cases. Entering 'h' will briefly show what these numbers relate to.
This bench for instance is a common convergence spot for wide-throat Galenoes and Cardinals. Entering '1' into the parser brings the user to a better vantage point.
Unfortunately there are no birds here now. The only input available here is '0' which returns the user to the previous angle.
I like this idea of using the numbers to indicate places that you can interact with. I might make the 1 a bit smaller but that's just a minor detail. What I wanted to mention is that from a programming perspective, it would be good to think about this from the perspective of the game's "state". You will most likely want to have a class that represents the entire game, and the class will need to have a state. This state can include the player's current location, any vantage point they are taking, and anything else (for example, maybe the player is injured, or maybe they are hungry).
ReplyDeleteSo anyway, when you are creating your class, I would think about what variables can be used to define the games state. You may want the player's name, location, vantage point, health, or whatever. This is especially important if users are going to be able to save the game, since then you'll need to save the entire state to a file, as well as implement methods to load a game state from a file.
I would also think about the best ways to keep track of the player's location. Is the map just a square grid, or is it some other shape? If it is just a square grid, you may be able to define it using a 2d array, but that still may not be the best way of doing it. Will the user know the layout of the whole map from the start, or do they need to explore in order to discover places on the map? This would have an implication on the issues involving state that I mentioned above.
One pretty solid way of implementing the locations may be to have a location object which has a north, south, east, and west location pointing to its respective neighbors. What I mean by that is basically this:
public class Location {
Location north, south, east, west;
boolean explored = false;
// other variables needed to define state of location...
public Location(Location N, Location S, Location E, Location W) {
north = N;
south = S;
east = E;
west = W;
}
}
The player class could also have a location object corresponding to the player's current location. This is just one potential solution though... there are also other ways of doing this. It may be a better idea to do it differently depending on the needs of the game.
Sorry it removed the indentation in the code :/
Delete