Small subscripting based map system

demos and examples
1

Hi all,

This is probably going to become a core NVGT include at some point once it is more polished, however it is at least usable.

This is a simple map parsing system that uses subscripting for it's map loading, which means that maps can be created with dynamic loops, variables and functions.

Attached to this post is both the map class and a small example of using it.

Code is zlib licensed, just like the rest of NVGT.

Questions and suggestions welcome!
map.nvgt (7.6 KB)
map_test.nvgt (1.1 KB)

7 Likes
2

thanks for this class, Sam!
I was wondering: does it support both 2d and 3d map creation?
-Rory

3

Hi,

Right now it only supports 3d, however I can set any z parameter in functions to 0 for example string get_tile(float x, float y, float z = 0) which would basically allow 2d maps to function.

Thanks for the idea!

4

Greetings. Any news on this? Any updates you haven't released yet? I plan to use this include and would like to be up to date :smile: )

5

Also, how would I add other objects to my map?

6

Hi,

I don't think I've updated it yet since posting here, here is the latest though just encase.
map.nvgt (7.6 KB)

So basically, it's all about making a new function in the map_functions namespace. Or in otherwords:

namespace map_functions {
 void on_tank(vector position, float tannk_health) { /* add tank to map */ }
}

The add_tank function can do whatever you want in your code, just that putting it in the map_functions namespace exposes it to the map scripts that are loaded.

Hope this helps, I can clarify anything else still confusing!

7

Can I put that name space where ever I want? So could I make an extra include for example? So if I update the map class it won't just overwrite? And also, when would you use your own class, like you did in that example, and when just use this? And last one :): what is the seed thing used for?

8

Yep, namespaces are additive which is why this works so well. In any file you can just add functions in that namespace, and the namespace just gets extended and the functions within are magically registered with the map loader.

As for when to inherit from the map class, that really depends on your existing code structure. Say you have an array of pits, like pit@ pits; just globally and you only load maps one at a time. Your map function which adds a pit might just insert something into this global pits array if that's easier in your case, then when the level ends you clear the map and the pits array. If you want to make sure everything is compartmentalized though in a situation where you might load multiple maps, it might suit you better to inherit from the map class. That way you can do my_map@ map1 = load_map(...); my_map@ map2 = load_map(...); and map1 and map2 can both have different descriptions.

The seed function has to do with random number generation and allows you to easily make much more randomized maps that also never change. So for example at the top of your map file you could do seed(44444); then you could do tile(r(10, 15), r(15, 20), ...); and the tile would be placed at a random location, but because the seed was set, that location will be the same every time the map loads. Then if you don't like that layout you can just change the seed value, and all random numbers magically change for the next map load. So long as any people share the same seed, the map will look the same for them all.

1 Like