I'm programming an RPG in java. It's text based, so movement is more or less from "room" to "room." In the case of cities, they will generally be one room, with some sub rooms for important shops and things.

I have classes for locations, but where should the programming for each individual location be done? A bad idea would be to create a bunch of New Location()s in the main method. Another idea I had was to define all of their attributes in a text file (or maybe something like JSON) and then reading it in when needed. Or should it go in a class file somewhere?

  • \$\begingroup\$ hey I think this might be a little to general / opinion based problem to warrant a formal question on the site, however seems like a perfect topic of discussion for the chat chat.stackexchange.com/rooms/19/game-development \$\endgroup\$ – Joe Sep 8 '14 at 20:07
  • 2
    \$\begingroup\$ Show us what you mean by classes for locations. \$\endgroup\$ – user15805 Sep 8 '14 at 20:29
  • 1
    \$\begingroup\$ This is very opinion based with no right answer. The only "right" answer for this question is "Do it however works for you in your situation." \$\endgroup\$ – Eben Sep 8 '14 at 21:31
  • \$\begingroup\$ I guess I'm not sure of what any right answer would be. This seems like a simple problem, but I'm kinda stumped. \$\endgroup\$ – ArtiMo Sep 11 '14 at 19:29
  • \$\begingroup\$ @Alex My locations class so far has fields for sub-location, connected locations, NPCs contained in the location, and I might add one for events triggered in the location. \$\endgroup\$ – ArtiMo Sep 11 '14 at 19:32

A good rule of thumb is to have your content be data driven. You would store this data externally and create a class to load in the data.

There are lots of reason to do this, such as

  • You don't have to recompile when your data changes
  • You can use Excel or a text editor to edit the data.
  • The data load can be abstracted from the data itself

I'm currently writing a text-adventure myself and choosed the following (unoptimized, clumsy ect.) approach. Why is explained in the conclusion of the answer. For the short version, skip to the end of the answer.

My game is structured in areas which contain locations. A player can have roles which allow him to do something (or disallow him from doing so).

Whenever a link in the following answer is mentioned, it is a ONE-WAY-Link. If two different links link each other, that may look like a two-way-link, but they are actually one-way-links which happen to point at each other.

When I say type contains type, I'm refering to ''contains the file name and location''. This will should be understandable from the attached pictures.


An area is a folder containing four types of content. These are exit-points, entry-points, locations and dungeons.

  • exit-points An exit-point contains another areas entry-point which it links to. An exit-point can be accessed by locations and entry-points (though later doesn't really make sense). If a player leaves a location through an exit-point, he will be transported to the entry-point of the linked area.
    An area can have multiple exit-points (imagine you leave a town (area) through it's east-gate (location) to the mountains (another area) or through the west-gate (location) to the meadows (another area) ).

  • entry-points An entry-point contains one location within the same area. Entry-points can only be accessed from another areas exit-point (or from the game-engine, to drop the player in the world for the first time at game start). If a player access an entry-point, he is immediatly redirected to the specified location.
    An area can have multiple entry-points (imagine a town (area) where you can enter from the east-gate (location) or west-gate (location) ).

  • locations Locations are folders bundling content-files (simply some .txt). A location has a describing text, an interaction list and at least one location-exit-point (and some other stuff not important for this question).
    The describing text is simply the text that is shown when a player enters the location.
    The interaction list contains (in a specified syntax) the reaction Y to the players action X.
    Example: LOOK AROUND can in one location simply display the describing text again. In the next location, it would trigger a change to another location (because the player fell in a trap).
    More often than not, the describing text already contains hints (or big signs, when it comes to this) what is possible in a location. If the describing text says there is a huge river next to the road, the player might want to FISH.
    If an action is not possible in a current location, then the default message for this command is displayed ("You throw out your fishing pole and it lands on the ground. After a short time, you realize that without water, you can't catch anything").
    A location-exit-point is basically the same thing as an area-exit-point, but can only link to locations and area-exit-points inside the same area. This is simply to shorten path-names.

  • dungeons These are sub-areas to have less clutter in an area-folder. To everything inside an area, they look like locations, but are areas. The only special thing is that they can have at most 1 (ONE) entry-point.

A little picture (sorry for my Paint-Skills): And another fruitless attempt to create something understandable in Paint.NET

Shown is the way my linking works. Note that Entry C.B is not accessed currently. An Entry-Point without a corresponding exit-point can exist (for example for future expansions).


The programming is basically done in the interaction-list of the locations. The player issues a command, the interaction-list says how to react to it. Of course, the possible reactions have to be coded somewhere. Up until now, I managed to do everything with static methods, because boiled down, there isn't much a player can do (look, skill, talk, leave to another location).

Valid question. I'm wrking with two non-programmers. They are responsible for the story and stuff, I do the coding. I had the choice to teach them how to programm a location, or simply read textfiles they give me. As they were somehow resistent to learning, I got stuck with the textfiles. Today, I'm happy with this.
Need a new entry-point? Throw in a new file with the specifications.
Another interaction, but can't edit the basefiles (because we're modding, and basefile-edits are bad!)? Throw in a new interaction list with a running number, because the parser only checks if the file starts with interaction_list_.
Add a whole new town into the landscape? Throw the area-folder next to the others and add some exit-points to the existing regions.

All in all, this might not be the best approach, but it will definitly ease your life when your world gets bigger, because not a single line of code has to be touched anymore!

Thanks for your patience with me.

  • \$\begingroup\$ I am sorry that I had such a long run to get to the conclusion, but I got somehow carried away, and didn't want to delete it all, because I felt it makes the understanding a bit simpler. Greetings, Larethian (PS.: Potato) \$\endgroup\$ – JFBM Sep 12 '14 at 10:32

Cities are the same as the rest of your environment. How do you define it?

I think your 'rooms' are styled different - some with treasures and some with monsters. So your cities have some rooms with shops and some with parks. For me, it is the same approach.


Ok the question is pretty vague in that it reveals nothing about your game design but here's my take on any form of "game world":

You painted a picture of this in my head ....

public interface IArea 
     public void Enter(Character newChar) { ... }

public class World
      public List<City> Cities { get; set; }

public class City : IArea 
    public List<Room> Rooms { get; set; }
    void Enter(Character newChar) { ... }

public class Room : IArea 
    public void Enter(Character newChar) { ... }

So in answer to your question ... Inherit one of these and create any custom code you need, then add your room implementations in to a city and your city implementations to a world to build your virtual world.

How you actually write the code is then entirely up to with regards to implementation details, and i'm sure you can think of many more ways to improve the IArea interface right :)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.