I'm making a very basic online RPG (2d, and instead of sprites I use characters, like a roguelike) and I still haven't figured out how to store and retrieve maps. Until now I used a text file that are stored on the server. Should I store the map in the database and retrieve it as the player moves around? For example, if the player is in the position [x, y], load all the tiles within a 15 tile radius.

Or maybe dividing the map in "sections" and then, depending on the player's location load a given section? Which is the best option?

Also, if I was to save the map in the database, which is the best data type to store it as a bi-dimensional array? BLOB maybe?

  • 2
    \$\begingroup\$ If you're using BLOB, you can just as well use files instead of a DB. \$\endgroup\$
    – bummzack
    Feb 15, 2012 at 10:01

3 Answers 3


It would be better if you knew what kind of change will be involved. If your world is quasi-static you would like to distribute the basic map to all your clients and to comunicate the changes only to player that visit an area: this allow you setup map distribution services that don't use the same bandwith of your game server.

In this case you can validate the client version at login and redirect the user to the map sources if major changes to maps where happened since the last login.

The story is completely different if the contents are fully user generated.

In both cases you have to split the world in chunks: you probably do not load the whole world in memory when you render it. Don't do the mistake to size the map chunks tailored to the client needs, changes to client should not affect the server: add a level of indirection, the client probably have to load a few of chunks to work smoothly.

If you are on the web and you like to let your users to generate a lot of content, you may try to use couchdb as database backend. Using Couchdb you get a rest json based api, filtrable change notifications and using indexes you may look up the data fast.

The main advantages are the unstructured data and the near real time scalability. The first one let you to add data in a way that client can process only if they know how to, backward compatibility or ligth/full compatibility for example; the latter let you build a system that can grow from a couple of user to thousands.

This comes at the price of system design, the changes need time to propagate and collisions may occour so you have to think about this kind of advanced problems in the earlier stages of design: is the game worth the candle?

Intermediate cases exists, here you can try to mix the two strategies up so if immutable or near-immutable content exists, you should separate it from the rest of the contents and distribute them in an appropriate manner, while using from semi-structured to structured data provider for the contents more subject to changes.

  • \$\begingroup\$ Very informative answer, also thanks for your advice on using Couchdb + JSON, I'll look into that. \$\endgroup\$ Feb 15, 2012 at 21:08

It depends what exactly you mean by "maps". If you are just talking about the tile layout to display, then that's probably not necessary to put in a database. A database is meant for a massive quantity of data that needs to be sorted, like all the users of a website; for the relative handful of maps that a typical game has you can just store those as flat files and have the game use a plain old URL to retrieve them. In other words, what you're already doing (a text file stored on the server) is fine.

Now if you are talking about dynamic and persistent data about what is going on in the maps (eg. where other players are) then that data should go in a database. Similarly, if the maps are user generated then that's a whole different enchilada, because players will generate a lot of content; again, massive data that needs to be sorted goes in a database.

  • \$\begingroup\$ Interesting insight.. What's the point of storing a static file in a map in the database if it's not meant to change? In fact, if it was stored like a file it would be cached by the user's browser and it would lessen the server's bandwith. The problem is that I'm planning on making the "layout" or map dynamic, and sensitive to what the players do, in a near future. That's why I'm asking which is the best way specifically \$\endgroup\$ Feb 15, 2012 at 1:24
  • \$\begingroup\$ Well that was my point: if it's just a handful of static files then a database is overkill. \$\endgroup\$
    – jhocking
    Feb 15, 2012 at 3:08

I've written a few games myself, not an RPG but wargames and this is how I do it (not necessarily the best way but it works).

As you state, store map data using x and y coordinates, so you might have the x and y and then terrain type, ie swamp, forest, castle etc.

Then you get the characters location and do some database query in a loop, you'll actually need a nested loop (loop for x and y).

Then display this on the screen, I find are useful for displaying map "tiles".


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .