Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
I was wondering if someone could explain to me how to implement a seemingly dynamic infinite map like the one at http://wordsquared.com/
My main issue is really generating new tiles in any direction when the user drag the board.
I'm also trying to figure out how to handle the coordinate system, and actually what/how to store the map in a database.
Regarding the coordinate system:
In order to address individual tiles, you will need some kind of origin (a 0:0 point). In order to allow the playing field to expand in every direction, you will also need negative values. This will give you a world which stretches from -2.147.483.647 to 2.147.483.647 in both directions, which is "large enough" to seem infinite for most sane players (depending on the game concept, of course).
To allow an even larger world you could use floating point numbers. But the disadvantage of floats is that you can not rely on their accuracy. This might introduce some strange and obscure bugs when you reach extreme distances from the origin, like in minecraft.
Regarding storage:
Saving the state of 2^64 tiles is more than any database can bear, so you should only save those tiles which are worth saving (those which are already discovered and changed by a player). To avoid infinite growth of your database you might consider to discard the state of tiles which were not visited for a considerable amount of time, but that's a gameplay decision.
But how do you save them?
Saving the whole world in one huge data structure would mean that the whole world needs to be kept in memory all the time. When the world is extremely large, this could result in unacceptable memory usage. But storing each tile individually in a database would mean that you need a lot of database queries all the time, which can become pretty inefficient.
A good compromise is to work with squares of uniform size of 16x16, 256x256 or whatever is appropriate for the specific use-case and store and retrieve each of them as one entity in the database. Such sections of the map are usually referred to as "chunks".
Regarding the procedural generation:
An interesting aspect of pseudorandom number generators is that they always return the same sequences when they get the same seed value. When you use the coordinates of a chunk as the seed value to generate it, it will always look the same. That means you don't even have to save the static information about a chunk anywhere, because you can just re-generate it on demand. Only the dynamic information (in this example, the letter tiles) needs to be stored in the chunks. When a player just visited a chunk without leaving any traces behind, you don't even have to save it at all.
The default random number generator of Javascript (Math.random) unfortunately doesn't allow you to set a seed, so you will have to implement your own RNG. But that's easier than it seems, because you can just use one of the many stock algorithms. See this question for some options.
The approach described by Phillipp is essentially what you'd do.
I would build the world in "blocks". Suppose you have one block, say 50x50 tiles, then you can pseudorandomly generate it (using the offsets from the origin as a seed). You can then keep these tiles in memory until the player walks too far away, then discard the block and regenerate it again.
Because a player expects adjacent areas to be "similar" - for example, a swampy area would not have a desert right next to it, you can use some kind of smoothed noise function (again pseudorandomly seeded, so it's always the same) to determine the terrain type for a given block.
To generate pseudorandom numbers in my web game, I used the "seedrandom.js" library by David Bau (Google it).
