Thursday, September 10, 2009


I have been working on Lost Horizon for the past few days now and for the most part, everything is going quite smooth. After I finish working on scrolling code, Im going to dive into how I plan on dividing up the world. I will be using an overlay of zones, color coded for the engine.

The way it will work, is instead of loading up the entire world and having the engine keep track of it, only load what is in the "green" zone, or immediately surrounding the player, and a bit of the adjacent "zones". Anything outside of the adjacent, or "blue" zone, wont be drawn and will be considered the "red" zone. I havent worked out the exact sizes of the zones them selves, but a good rough idea is the "green" zone would be the size of the game console. The "blue" zone would be half of the size of the "green" zone, and would act as a loading buffer. Once the player reaches the blue zone in one direction, the engine will unload the blue zones in the opposite direction, and turn them into red zones.

The exact implementation of how I am going to do this is a little fuzzy, and is still a bit up in the air. I could have the entire zone overlay follow the player and constantly load and unload parts of the map as new ones become available.

The other way would be to stamp the entire world with the zone layout. Each with the large size zone and half sized zones attached to them across the entire world. Same as before, I would only load blue and green zones. But since every place on the world would have the buffer zones, I would have to add a color into the scheme. Green for the zone the player is in, and blue for the adjacent zones to green zones. Red zones would follow blue zones, with the buffer zones for the red zones being black. This would prevent me loading buffer zones attached to red zones, but not attached to green zones.

For wilderness areas, anything outside of town, I will have monsters get created on the fly in the blue zones, that will wander around. Any monster that wanders into a red zone will be removed, and ones that wander into the green zone will engage thier AI for when they see a player. Hopefully this will give the illusion of the world being alive, and provide "random encounters" that seem like wandering monsters.

The reasoning behind doing these zones is it doesnt matter what is happening on the other side of the world, if the player cannot see it, and if the player cant see it, why load it? This will allow for better performance of the game, and allow me to use that saved performance for things like better AI, better spell effects or anything else that the player would enjoy.

The last thing I would like to address in this post, is town zones. This zoning system will work out differently than the color coded zoning. Since I plan on having randomly generated worlds and static towns, I am going to associate each town with level zones. The town, and the surrounding area will have the levels of the monsters and loot controlled by these zones. Since I plan on having the player start out in the same town regardless of how the map is generated, I need to control the level of the monsters around these towns to prevent a newbie town from being dominated by higher level monsters that the player has no chance in defeating. These zones will also control the level and/or amount of random dungeons generated in these zones.

I will hopefully have a rough system set up within the next few days, depending on how finishing up this scrolling code goes. I will test both color zoning ideas to see which one works out the best.

Feel free to post any comments or suggestions!

Stumble Upon Toolbar


  1. I don't know how exactly you are planning on doing it - but I originally had 3 different "magnifications" -whatever the actual word is for it- world, region and local - and I had memory for 4 adjacent region and 4 adjacent local maps and one for the world map. But then I started to run into some problems and rewrote that part so I could potentially load all of the maps into memory at one time and set the actual program architecture up more realistically = like the localmaps were actually within the regionmaps which were in the worldmap - as opposed to previously when I had all the levels separate and existing within the "universe." That way I can save the previously visited areas at any time - put the previously visited levels in a save-when-waiting-for-input-queue or whatever.

  2. Well, I currently have it about half done. The way I plan on doing everything, is to have a world map, where 1 "tile" is equal to one 75x75 map, that the player walks on (basicly a Player Map). Each Player Map consists of 9 World Map tiles (3x3 area) making the player map its self 225x225 tiles. The player will always be in the middle tile. I plan on keeping track of 2 sets of co-ordinates that the player will have. One set will have World Map co-ords, telling the game where on the world the player is, and the other set will be where in the 225x225 Player Map the player is. When the player reaches a certain part of the player map, going west for example, when he reaches the next sub-map I will cut off the east 3 maps, and draw the next west 3 maps, and set the player map co-ords back 75, putting the player on the east side of the middle map (but still in the middle of the screen). I will also add a sort of buffer zone so that if the player walks back one tile, it wont rebuild the map again. This probably sounded kind of confusing but I will be going relatively in depth when I finish it up. I also do not plan on doing any Fog-of-War stuff, just plain old line of sight so it feels more natural so I wont have to remember where the player was.