Register
I typically use all eight for all my maps, and all of those tilemaps are pretty much filled up with tiles. But that's just me, and I'm weird like that, heh.
Being from the third world, I reserve the right to speak in the third person.
Using Editor version wip 20170527 gfx_sdl+fb music_sdl
Fri Apr 26, 2013 7:18 am 
Fri Apr 26, 2013 3:48 pm
Huh. I guess I do tend towards smaller maps, now that I think about it.
I also use slices for all sorts of stuff, ex. tree tops-- easily made from large enemy graphics, and posted dynamically to the map by reading the top tile of tree trunks. Easier to draw that way, too, and less dealing with the map editor, ha!
I wrote a script a while ago for easily animating slices, basically it was based off of your (Pepsi Ranger) old walkabout animation script, but it stores all of the instructions in the Slice Extra Data, and animates them dynamically based off of a timer, for all children of a defined parent slice. Once the animation ends, if its not set to loop, it frees the slice.
It's super useful, but I can't find it to share... Ha. Oops.
Seems like, for weather, a version of this script which pops up 4 animating backdrop slices--parented to the highest map layer-- around the player and dynamically adds and deletes them based on player position would be nice, and could be scripted in a way that all you need to do is call updateWeather (type) or something to change the weather, and *should* have a very low memory footprint. Or it could grab the camera pixel position and fake being parented to the map layer that way, and then add and delete the relevant backdrops whenever the camera hits the edges of the 640x400 block. Might be more economical to use a bunch of Hero graphics, actually, because I think changing frames is easier on the engine that loading a whole new backdrop slice...
But I'm assuming, from reading your articles, that you already have a ton of timers running and other stuff going on, so maybe thats not very feasible for your situation.
Personally, I'm not a fan of weather without alpha transparency. It seems to distract the player from seeing the important gameplay elements more than anything, but I guess if you handle it tastefully it might not be an issue. In terms of world believability, I think some simple master palette changing can go a long way.
So there's like four random tangents, before realizing the whole point of the OHR is to be easy to use... And I guess I've changed my mind. More map layers! Woo!
I also use slices for all sorts of stuff, ex. tree tops-- easily made from large enemy graphics, and posted dynamically to the map by reading the top tile of tree trunks. Easier to draw that way, too, and less dealing with the map editor, ha!
I wrote a script a while ago for easily animating slices, basically it was based off of your (Pepsi Ranger) old walkabout animation script, but it stores all of the instructions in the Slice Extra Data, and animates them dynamically based off of a timer, for all children of a defined parent slice. Once the animation ends, if its not set to loop, it frees the slice.
It's super useful, but I can't find it to share... Ha. Oops.
Seems like, for weather, a version of this script which pops up 4 animating backdrop slices--parented to the highest map layer-- around the player and dynamically adds and deletes them based on player position would be nice, and could be scripted in a way that all you need to do is call updateWeather (type) or something to change the weather, and *should* have a very low memory footprint. Or it could grab the camera pixel position and fake being parented to the map layer that way, and then add and delete the relevant backdrops whenever the camera hits the edges of the 640x400 block. Might be more economical to use a bunch of Hero graphics, actually, because I think changing frames is easier on the engine that loading a whole new backdrop slice...
But I'm assuming, from reading your articles, that you already have a ton of timers running and other stuff going on, so maybe thats not very feasible for your situation.
Personally, I'm not a fan of weather without alpha transparency. It seems to distract the player from seeing the important gameplay elements more than anything, but I guess if you handle it tastefully it might not be an issue. In terms of world believability, I think some simple master palette changing can go a long way.
So there's like four random tangents, before realizing the whole point of the OHR is to be easy to use... And I guess I've changed my mind. More map layers! Woo!
Fri Apr 26, 2013 6:03 pm
I would actually be fine with using slices for weather if I thought there was a sensible way for locking it to map coordinates rather than screen coordinates and producing the weather locally for specific sections of a map, which can drift and dissipate based on the need of the map (I'm sure there is a way and any moment TMC will jump in and explain how).
Anyway, I hope my maps answer the question of why map-making sucks.
Place Obligatory Signature Here
Anyway, I hope my maps answer the question of why map-making sucks.
Place Obligatory Signature Here
Fri Apr 26, 2013 6:20 pm
Actually, yes! There is a nice way of attaching a slice to a screen coordinate. Just parent it to a map layer. For the purpose of weather effects, you will want to attach to the topmost layer
Code:
plotscript, single cloud example, begin
variable(sl)
sl := load large enemy sprite(10)
# Attach the slice to the topmost map layer
set parent(sl, lookup slice(sl:map layer7))
# center the slice on tile x=125 y=47
set slice x(125 * 20)
set slice y(47 * 20)
set horiz anchor(sl, edge:center)
set vert anchor(sl, edge:middle)
end
plotscript, single cloud example, begin
variable(sl)
sl := load large enemy sprite(10)
# Attach the slice to the topmost map layer
set parent(sl, lookup slice(sl:map layer7))
# center the slice on tile x=125 y=47
set slice x(125 * 20)
set slice y(47 * 20)
set horiz anchor(sl, edge:center)
set vert anchor(sl, edge:middle)
end
Sun Apr 28, 2013 6:15 am
Ugh, I've delayed replying to this thread for too long
Yes, exported maps will always have 3 layers. It's not a great fit for the OHR.
Regarding more map layers: another good reason for lots of map layers is Sonic the Hedgehog-style layered parallax backgrounds. I do mean to raise the limit to 16 or more, it just wasn't terribly pressing. Anyway the only good reason I see for having those sorts of limits is to indicate to people that they are probably doing something wrong if they require dozens of map layers.
I would like add 'map objects', the ability to add slices which are optionally obstructions to the map in the map editor. However this adds complexity to things. Imagine a new user learning about maps, and unsure whether they should place map objects or tiles or npcs, use layers or overhead tiles, wallmaps or zones or obstructing map objects or npcs, foemaps or zones...
Also, this still isn't a great solution for what you wanted. Slices aren't really designed for hundreds of thousands of slices per map.
Actually I would like to add this. However the meanings of zones vary by map, so you'll need to 'standardise' zone ID numbers across maps.
This was added in Beelzebufo. I guess the way to select a rectangle isn't obvious enough.
I'm willing to look into importing from Tiled but it might be a poor match for the OHR. I hope that higher/variable resolution and mouse support will make it into the Catoptromancy release.
BMR wrote:
Question though, how would TileStudio handle layers? I've read some of the documentation, and from what I've seen it only does three layers.
Yes, exported maps will always have 3 layers. It's not a great fit for the OHR.
Regarding more map layers: another good reason for lots of map layers is Sonic the Hedgehog-style layered parallax backgrounds. I do mean to raise the limit to 16 or more, it just wasn't terribly pressing. Anyway the only good reason I see for having those sorts of limits is to indicate to people that they are probably doing something wrong if they require dozens of map layers.
Pepsi Ranger wrote:
3. By pixel setting. This is probably the most unreasonable request
I would like add 'map objects', the ability to add slices which are optionally obstructions to the map in the map editor. However this adds complexity to things. Imagine a new user learning about maps, and unsure whether they should place map objects or tiles or npcs, use layers or overhead tiles, wallmaps or zones or obstructing map objects or npcs, foemaps or zones...
Also, this still isn't a great solution for what you wanted. Slices aren't really designed for hundreds of thousands of slices per map.
Pepsi Ranger wrote:
4. Zone by tile. Just like attaching default walls to specific tiles, it would be nice to have the option to attach default zones to specific tiles.
Actually I would like to add this. However the meanings of zones vary by map, so you'll need to 'standardise' zone ID numbers across maps.
shakeyair wrote:
And someone mentioned using a backdrop as tiles. I think what they really want is the ability to pull a rectangular selection of tiles from the tileset, and placing it as a single brush.
This was added in Beelzebufo. I guess the way to select a rectangle isn't obvious enough.
shakeyair wrote:
EDIT: All I want is to import map data from Tiled OR the map editor to run in a higher resolution with added mouse support.
I'm willing to look into importing from Tiled but it might be a poor match for the OHR. I hope that higher/variable resolution and mouse support will make it into the Catoptromancy release.
Re: Why does mapmaking suck?
Mon Apr 29, 2013 10:00 pm
Mogri wrote:
See title. Why is the map editor so awful to use? I can't be the only one to feel this way. I'm actually to the point where I'm thinking about programmatically generated maps just so that I won't have to do it tile-by-tile.
Bonus: what can be done to make the map editor easier to use? One change that I imagine would be fairly easy to implement is to allow saving map changes from within GAME so that you can use plotscripting to fill in some blanks, automatically do edge tiles, whatever and so forth, then keep the changes you've made. It would also allow some interesting new gameplay options: imagine a game that grows and changes over time.
Bonus: what can be done to make the map editor easier to use? One change that I imagine would be fairly easy to implement is to allow saving map changes from within GAME so that you can use plotscripting to fill in some blanks, automatically do edge tiles, whatever and so forth, then keep the changes you've made. It would also allow some interesting new gameplay options: imagine a game that grows and changes over time.
I actually brought this up while I was developing Chronoboy Adventures a few years back, and guess what? I built a random generator using plotscript, mainly to add trees and debris on the ground. I believe I used the plotscript command to save the map state, then I copied this map state file directly into my RPG directory's working.tmp and saved the file... It worked! That is why in that game, that the ground in the parallel universe looks so detailed and random(do you seriously think I'd take hours to make it look so good?), after I generated one section, I used it as a map template when I built future chunks of the world. This is why each world chunk is divided as it is, so that I don't have to run the plotscript every time I want to have random trees and such. I think I wrote somewhere, either on this forum or my old blog how I did this. I did ask James to add this feature, but unfortunately it was shot down(can't recall the exact details, I'll dig up the old thread).
Edit: Hmm, well I guess it wasn't really shot down per say, I thought it had some sort of response. Anyways, here's my mention of it a few years back:
http://www.castleparadox.com/ohr/viewtopic.php?p=83768&sid=1043bdc7220873b9beb93ed8627c20e0#83768
Looking at my old files from Chronoboy Adventures, I found a file called: map7_t.tmp. I believe I brought it up to James, as I was looking for a way to take plotscript generated maps and use them in my game without needing to use the plotscript each time. I created a script which would generate forests and debris on the ground, then used "save map state" to create that file, then I took that file and overwrote the map file in my working.tmp, and it worked like a charm. Sure it was a hack, but it got the job done. I'll search through my emails next, as I swear I brought this up with James a few years ago...
Edit 2: So it wasn't shot down at all, just forgotten about. Here's part of an email conversation with TMC dated Dec. 7/2010:
Quote:
> I plan on
> adding(very soon) a "chunk ability" to the tile editor. It will allow
> designers to place a pre-made tile chunk onto the map. Such as two tile
> trees on two separate layers. Just place the tree chunk on the map, and the
> editor will take care of the rest. This will speed up map
> design incredibly. I also plan a randomize tile feature. Select a tile to
> change from, then select a range of tiles to randomize to. This will allow
> designers to easily add depth to their maps by ways of debris on the ground
> and such. Perhaps if map design was more quicker, we could finally see an
> addition to the Wander Hamster Classic hit RPG from the late 90s.
These are all (except for the randomisation feature, hadn't thought of
it) things we want to include in the map editor, but things just get
done so slowly when you've got so much existing code to maintain. I've
been meaning to get the map editor running at a higher resolution for
a few months now. It's great that someone else has done it instead
because I was too slow
> I plan on
> adding(very soon) a "chunk ability" to the tile editor. It will allow
> designers to place a pre-made tile chunk onto the map. Such as two tile
> trees on two separate layers. Just place the tree chunk on the map, and the
> editor will take care of the rest. This will speed up map
> design incredibly. I also plan a randomize tile feature. Select a tile to
> change from, then select a range of tiles to randomize to. This will allow
> designers to easily add depth to their maps by ways of debris on the ground
> and such. Perhaps if map design was more quicker, we could finally see an
> addition to the Wander Hamster Classic hit RPG from the late 90s.
These are all (except for the randomisation feature, hadn't thought of
it) things we want to include in the map editor, but things just get
done so slowly when you've got so much existing code to maintain. I've
been meaning to get the map editor running at a higher resolution for
a few months now. It's great that someone else has done it instead
because I was too slow
If your curious, the conversation was regarding a map editor I built for OHR(still incomplete). I am debating on picking this map editing project back up, I'm sure the code will still work.
Tue Apr 30, 2013 10:34 am
Wait, that actually works? I didn't think it would.
BMR runs off to experiment.
Being from the third world, I reserve the right to speak in the third person.
Using Editor version wip 20170527 gfx_sdl+fb music_sdl
BMR runs off to experiment.
Being from the third world, I reserve the right to speak in the third person.
Using Editor version wip 20170527 gfx_sdl+fb music_sdl
Tue Apr 30, 2013 7:51 pm
BMR wrote:
Wait, that actually works? I didn't think it would.
BMR runs off to experiment.
BMR runs off to experiment.
You need to make sure when saving the map state, that you only save the tilemap, not the NPCs and other data. The saved file needs to be a raw tilemap, then you can replace the one in your working.tmp, but ensure you replace the correct maptile file.
Quote:
save map state (whichdata, customid)
Saves the state of the current map to a temporary file which will be loaded (unless the map is set to ignore that particular data) when you reenter the current map, in the same way as a map set to save (remember) NPC or tile data: the saved state will be used instead of the map data in the RPG file. Both arguments are optional and are only for advanced uses.
Map state is not saved in saved games, and the temporary files will be deleted when you load or start a new a game!
save map state (whichdata, customid)
Saves the state of the current map to a temporary file which will be loaded (unless the map is set to ignore that particular data) when you reenter the current map, in the same way as a map set to save (remember) NPC or tile data: the saved state will be used instead of the map data in the RPG file. Both arguments are optional and are only for advanced uses.
Map state is not saved in saved games, and the temporary files will be deleted when you load or start a new a game!
For information on the tilemap file in your working.tmp consult the source docs:
http://rpg.hamsterrepublic.com/ohrrpgce/T
For example, if you save the map state of map 4, then to save the plotscript modified version back into your game, replace this file in working.tmp(make a backup first): ohrrpgce.t04
Interestingly, you can copy map data outside of working.tmp when testing out new features your not sure you will keep. Say you want to test out a new interaction, but are unsure if it suites the scene. You can copy out all the files for that particular map, you can find a list of filenames in working.tmp which are related to maps here:
http://rpg.hamsterrepublic.com/ohrrpgce/Map_Format
Also, if your not aware, you can actually turn your .RPG single file into a directory, and it will remain a directory. This makes is super easy to back-up specific things if your testing new features or plots. To first create this directory, you either need the UNLUMP.EXE tool, or open your RPG in custom and copy the working.tmp to your OHRRPGCE directory. Then rename working.tmp to awesome.rpgdir, make sure that you don't have another RPG file with the filename awesome. Then open up CUSTOM and it will appear in the list of games you can edit... When you open it, it will make a copy of your RPGDir into working.tmp, so that the Do not save and exit function still works, so if you want to make live changes to your RPG files, you still need to do it in working.tmp. However, if your in GAME.EXE and export a map state file, then you can easily copy this into an RPGDir when Custom is closed.
The main advantage of using an RPGDir over a single large RPG file, is that you can use revision control to back-up your games online to services like GitHub or BitBucket, and it will only keep track of what you change in that single session, like maps, tiles, or other information. When your ready to distribute, you can use RELUMP tool to recreate that good olde RPG file we all know and love. Using a service like GitHub can also allow game collaboration, where one person solely works on the graphics, one person works on the maps, and another works on the character dialogue. I haven't tested this type of development process yet, so try it at your own risk.
Wed May 01, 2013 7:24 am
BMR wrote:
Wait, that actually works? I didn't think it would.
You missed me saying so earlier in the thread.
Chronoboy wrote:
You need to make sure when saving the map state, that you only save the tilemap, not the NPCs and other data.
Actually there's no need to do that. Save everything and anything as long as it includes the tile/passmap/zone data you want.
Chronoboy wrote:
Using a service like GitHub can also allow game collaboration, where one person solely works on the graphics, one person works on the maps, and another works on the character dialogue. I haven't tested this type of development process yet, so try it at your own risk.
Proceed with caution. If two different people edit an rpg file/rpgdir it's quite likely that there will be lumps changed by both people: the .gen lump holds a lot of misc data including the number of maps, graphics, attacks, etc. Luckily (most of) these counts are corrected when you open a game, so it's frequently possible to just used one version of the .gen lump without merging changes. At a bare minimum make sure both people are using the same version/nightly, and don't both modify the same type of thing (attack, hero, etc).
Mon May 06, 2013 6:22 am
TMC wrote:
You missed me saying so earlier in the thread.
BMR wrote:
Wait, that actually works? I didn't think it would.
You missed me saying so earlier in the thread.
I did? Oh, oops, hehe.
Just gave it a shot earlier, works like a charm. Map making will be so much simpler now that I can gust generate maps and then save the results before fine-tuning everything.
Being from the third world, I reserve the right to speak in the third person.
Using Editor version wip 20170527 gfx_sdl+fb music_sdl