DOORS

Hey guys,
I'm currently making my first game after doing only experimentations with plotscripting and textboxes so far.
Now I'm still hoping I'm missing out on something, but I wondered if there is not a more direct way of making the hero move from one map with a long open edge to pass to the next one, other then creating loads of doors and linking them individually??
Say I'm letting my hero go to the right edge of the map, I'd love have him automatically enter the next map starting on the left edge with the same y-position.
Also is there anyway to make door broader than just 1 tile?

Unfortunately there is no way to make a door bigger than one tile.

If you want to link the entire edge of a map with another map, you have to use a plotscript. The easiest method would be an each-step script.

How would that look like? A while-loop with certain x/y positions where the player could be at and then gets teleported accordingly?
Thanks for the quick answer as usual.

A while loop could work, but I would not suggest it. That could interfere with other scripts.
The each step script will be run each time the player completes a step, and it automatically gets arguments containing the hero's current tile x and y positions



I haven't tested this script, but I think this method will work.

The downside is that if you have a lot of maps you want to connect this way, the scripts can get pretty complicated.

The script would be simpler if you do not care about preserving the heroes location-- say you have a town with 4 edges that you want to lead to the world map, or something.

Then the (untested) script would simply looks like this:



(door 0 would be a door linking to where you want to go)

Note that you could use both implementations on the same map for different circumstances, and also that you can add further checks to make a map link to multiple other maps on a single side.

These are the simplest ways, plotscripting wise, but you can also make a more dynamic system that would be useful if you want to do this A LOT: Basically converting zones into large doors, passing arguments which tell the game which map to go to, and whether to use the heros X/Y value or pass a new one.

If that doesn't make any sense, don't worry too much-- the simpler implementations will work just as well. The only advantage of this is that you would only need to make one script, which knows what to do by using arguments passed by the Zone Extra Data of the current tile's zone.

Something like this (untested) code, which would work on any map:
(this is somewhat more likely to have a bug than the other one...)



Also note in this example and James, the mapwidth (map)--2 is to get you off of the edge tile of the new map. For the top and left tiles, instead of passing 0 you may wish to pass 1.

Also note that this implementation does not need to be used in any specific location-- you could have a 3 tile wide door to a barn or something. If you are using this a lot per map, you may want to make the number of dedicated door zones larger than 10, this can be done easily by changing the values in the if statement.

If you want the script to work even when there are multiple zones on the tile, you'll have to make a while loop.

For larger door tiles, feign it with invisible step-on activated NPCs.

---

dOn'T MiNd mE! i'M jUsT CoNtAgIoUs!!!
Play Orbs CCG: http://orbsccg.com/r/4r6x

Chronoboy Adventures uses a chunk-based map system... Think along the lines of Zelda's world map. Each map chunk was the exact same size, making it super simple to keep the player's location intact. A single plotscript was used in every map to control the map changing behavior, in the step script mentioned by Bob. The only difference, is that each map had an "autorun script", which set-up exactly 4 global variables. This chunk of code could be copied and pasted super easy for every new map chunk created. If the player couldn't pass in a specific direction, the variable was assigned "-1", so in the "each step script", it checks if the player is on one of the edges, and sees if the global variable was greater than 0, if it was, then it just switched the map and placed the player on the opposite side. Here is the exact script used for "each step":



You could even write a script to set these global variables even easier. The key to making this work super easy is to create a "Template map", which is the size you want all these map types to be, and has the "each step script" already set. If you wanted to do it exactly how I did it, then create a single "master autorun script", which checks the current map and sets up the global variables. This way, you can preset all the scripts in the "Template Map", so all you need to do is create a new map using the "Template Map" for every screen your building.

Oh and Bob, wouldn't a feature like this built into OHR be a good idea? There are lots of old NES RPGs which don't use a single or dual doors to exit a town. Rather the player walks as far as they can out into the grass or a predefined tile. This could be an extension to "Use default edge tile", so if the player happens to walk onto this default edge tile, she is teleported to the specified map. It's seems like a worthwhile feature, as it will work just like one large door, anywhere the player walks out of bounds would use this door. Even more worthwhile for those attempting plotscript-less games, or games with an old skool NES RPG feel to them.

Doors which are larger than a single tile seems to be something that's requested quite a lot, so I think it could be a good feature to have built-in (though it's pretty low priority since it's so easy to do with a script). Then there wouldn't be a need for a separate edge-of-map-doors option.

I quite like the map chunk system.

Then would you consider a proposal for a new map type which uses a chunk system?

I know this is off-topic for this post, so I'll try to explain it briefly:

Essentially, instead of placing individual tiles onto a map, the tiles are placed into a chunk palette. These chunks can be things from common pieces of building(think corner and edge pieces). The chunk size is fixed for a particular map, say having chunks of 5x5 tiles. Then in a chunk map editor, you would place down entire chunks from your palette of chunks. This would speed up map development for areas like towns and dungeons where there are lots of edge and corner pieces.

This technique was used in lots of old PC RPGs where memory was limited, as this allowed vast land masses to easily be stored in memory. Instead of storing 24132x24132 tiles, the map was divided into chunks, and the map file instead stored references to each chunk. At any given time, only a few chunks(those around the player) were in memory. As the player walked around the map, chunks were swapped in and out of memory along with the tilesets needed for those chunks. This saved a large amount of memory, and allowed lots of old DOS PC RPGs to have very large persistent and interactive game worlds.

I see this type of feature being more useful for building towns and dungeons in OHR.RPG.CE. With the added benefit of saving chunks instead of tiles to the map file, you can easily edit the map to and or remove pieces as needed.

This is nothing like the idea of placing multiple tiles at once, it's far from it and this is far more useful and can allow our RPGs to have vast maps that could be built fairly quickly. I know how lots of people complain about how tedious map building is, well this might be a good solution.

This can be implemented a new map layer type. Builders can either use the current tile-by-tile layer type, or a chunk-based layer type. Being able to combine both types can really show it's power.

Well, those are several different things, all different from the type of chunk system we were talking about before.

I partially disagree, and think editing a chunk-based map would be more difficult and less flexible than doing so using a collection of 'stamps' (cloned brushes), which is what I want to implement. It adds the complexity of editing the chunk palette separately, having to line up the boundaries, and makes unique formations or customisations harder.

As for allowing huge maps: I wanted to support huge maps with hundreds of millions of tiles, I would use a transparent compression scheme. Meaning the in-memory map data is compressed any way I want, and the tile get and set functions transparently handle that. It may very well use automatically selected chunks. In fact zone maps already do transparent compression like this. Also memory these days is cheap. The maximum map size is currently 100,000 tiles, which is an arbitrary limit. One byte per tile, 8 map layers plus wallmap and foemap comes out to a maximum memory consumption of 1MB. That's frugal even on a cellphone!

That said, if someone were to implement a chunk-based editing mode for the map editor and submit a patch, I would probably be in favour of accepting it.

A chunk-based map would be an option along size of the current map type.



That's good to hear. I haven't dived into the source code much, someday I may look into this, or I may even attempt to implement such a system using plot-script. Can you read another map from within plotscript? Say the player is on map 7, and I want to read a tile from map 3. Can I do this? The reason I would want to, is that map chunks would be stored on separate maps. The game would take place on a single map, and plot-script would read in the chunks from the other maps as the player wandered around. The single map would be set to wrap and also be small, but large enough to hold a few map chunks in. This could simulate a very large seamless world, where the player thinks they're walking around for ever, but in fact their always in the same 32x32 square map. A global variable will handle their real X and Y positions in the world. And if arrays were implemented, the actual chunk references would be placed in a multidimensional array. I'd love to create a proof-of-concept of this to show it's potential.

You can't read from other maps. And it seems like you may run out of global variables if you want a large world or lots of chunk templates. A kludge is to store data in strings instead, since those have no length limit.

Supporting NPCs would seem to be tricky though.