Data maps v/s external maps.
Blitz3D Forums/Blitz3D Programming/Data maps v/s external maps.
| ||
| what are the considerations for choosing a programming template for level maps? we have those maps that are created with data and restore commands and in other hand we have the ones created with a level editor and saving the map as an independent ".map" file. can you give me your comments about it? matt. |
| ||
| Initially I use data statements to get things working and test gameplay features. Obviously it's considered sloppy and more times than not painstaking to create new levels quickly. Map editors are ( to me anyway ) a complete chore to develop... boring as hell to test .. but well worth it in the end!! Remember that if you do not intend to bundle the editor with your product then it can be as sloppy as you can get away with .. as long as it works. Probably bad advice but there you go!! A major tip is in deciding on the features which will be included in the saved file well in advance. If you decide at a later date that a new feature is required then it can be a bugger implementing as the likelyhood is that none of your older levels will be compatible with the new format. At this point you'll either need to re-do all the old levels or develop a program/ function which can convert from an older format to a newer one. Prefixing your .map file with a version number would be a smart way of handling this. I think that using a format such as xml could potentially eleviate these issues as they'll be more dynamic and easier to add featurer after the fact. Never tried it myself though ;) Stevie |
| ||
| If the levels are simple and small then data statements are a quick and easy way to build them...for example a dungeon master game lends itself well to being designed in data statements because the levels are grid-like. I guess it is mainly the complexity/size of the levels that governs whether you use data statements or .txt like files or a full blown level editor. |
| ||
| Never ever ever use data/restore to store map data (other than for earlier feature testing), it totally kills any kind of scalability, external map files are the way to go. |
| ||
| ok, understood! scalability is very important these days. thanks for all. matt. |
| ||
| I use data/restore for initial maps, but as has been well said by Stevie G, an editor is your ultimate friend for getting maps going for your game (I have an RPG in mind). You can make your editor more versatile if you make it able to store the dimension elements that define the map size/depth. By this I mean, suppose you have an initial test map created via Data/Restore statements for a 32x32 grid map. Now, you want to expand the maps to 256 x 256. If you make sure you define variables for the map width and height dimensions, then store those first in your save file for the map, and then when reading in a map, those elements are read in first, and the map can be sized accordingly. In other words, this kind of variability allows for maps of various sizes, i.e. 32x32, 128x128, 1024x1024, whatever. Your outdoor world might be 256x256, and a town might be 64x64, and a house that your hero entered might be 16x16. The editor can do them all. Of course, dimensions don't always have to be square, where both dimensions are the same size, so you could make a map that is 128x512, 32x200, or whatever (you don't even have to use powers of two, either). Just make sure that both your save routine and load routine are written to accommodate the size variability, if this kind of feature as I have described is something you want to do. |
| ||
| I see from your posts on your enemy code that scalability is something your bumping into at the moment... you might want to take some time to read up on object oriented programming concepts, tho be aware that it doesn't apply to blitz in quite the same way as it does to say C/C++. Unfortunatly I don't really know where to point you but this link could be helpful. http://en.wikipedia.org/wiki/Object-oriented_programming |
   |