People seem to plan them all the time, but still no-one ever seems to actually use them, so I wonder - could an RPG/tilemap (i.e. a library sophisticated enough for RPG development but also simple enough for regular 2d sidescrollers) library addon for Allegro ever succeed with you people?

If it's solid, fast, and most of all CUSTOMIZABLE enough, sure. The last part, which is by far the most important, is all too often overlooked. I want to be able to customize literally EVERYTHING. Unfortunately, this is also often hard to accomplish.

Well, here's my plan for mine; there's a flag in the file format that specifies whether that particular file uses bitmasks or just solid/walkable, whether it has animations, whether it's got its own tileset (it could use an external one provided by the user), etc. Since I want to be able to use it for a variety of stuff, customization is important to me too Perhaps I'll add support for multiple tilemap layers like the KQ editor and Mappy do (right now, you need multiple tilemaps). Maybe I should look at the Mappy file format for ideas ...

Don't look at the Mappy format - Mappy is WAY too inflexible. Can I customize/have any of these features with your engine?

• Different tile sizes

• Section layers (layers smaller than entire map)

• Parallax layers (tiled as well as pictures)

• Different tile sizes in each layer

• Different tilesets in each layer

Those are just a few of the things I'd consider bare minimums for something like this ...

> Different tile sizes
Not at the moment (32x32 is hardcoded) but it should be easy to change.

> Section layers (layers smaller than entire map)
I don't see why not. It doesn't support multiple layers at ALL right now, but if it did, it shouldn't be hard. My level editor uses tilemaps of different sizes at the same time, and lets you move them in relation to each other. Not hard.

> Parallax layers (tiled as well as pictures)
Parallax pictures? Anyway, my tilemaps have "speed", so a map with 0.5 speed will move half as fast as one at 1.0 speed (the default). I'm doing that now in the game

> Different tile sizes in each layer
Didn't think of that, but no sweat ...

> Different tilesets in each layer
Doing that now in the game Good ideas; I'm logging these ...

I could have, for instance, a background with a sky and some clouds in them. These can get somewhat complex, and I'd hate to have to break them into hundreds of tiles and then put them back together again in the editor.

Right; I've thought about that too. I guess it could be a 1x1 map with 640x480 tiles

I also check for hardware acceleration for blitted and masked tiles, plus I've got transparency, and I have plans for animation.

You can see these in many old console games, effectively it just means being able to set scroll offset per tile layer per scanline to get an effect exactly like the floor in Street Fighter 2. I've seen this in, off the top of my head, Sonic 3 on the MegaDrive and California Games on the old Master System.

Another thing; If you're going to make a general map editor, make sure to let people write their own export routines for their own map formats; either through plugins or some other system. It's not always fun being stuck with a file format you don't like ...

Absolutely, but I'm still unclear how to go about that. Someone suggested a Lua way; perhaps writing my own little scripting language for that would be easier ...

There's a difference between making the all-purpose map editor and making a map editor (among other tools) for an RPG. The all-purpose map editor shouldn't impose much on the user that can't be changed. I would argue that the type of map itself (hex, square tile, isometric) should be editable and configurable via plugins. The user should be able to hand, and edit, application specific data off of a tile position or a tile-type via plugins. And, of course, the export of data should happen via plugins as well.

Now, a tilemap for use by an already built RPG engine is a different story. Since this is a full RPG engine we're talking about here, the user won't be quibbling over file-formats; no exporter plugin. However, adding additional data to the file format is important. As such, the user should have plugins that add data to tiles and tile positions, and this data will be automatically loaded by the game engine and made avalaible for immediate use in code/scripts.

As for the thread's main question, such a library could catch on, but probably not for Allegro users. Regardless of the flexibility of the system, most Allegro users tend to be far too unwilling to look at, let alone use, any moderately high-level library. And such an engine would provide the game loop and so forth, so coding for it would be a matter of deriving new classes and writing new scripts for those classes. I doubt many Allegro programmers are willing to use an engine that has that much of the code written for them.

Also, in order for such an engine to be useable, it must have excellent documentation. Since it is an application framework that controls most of the game internally, it is important for the system's behavior to input/function calls to be very precisely documented.

Chris - are you writing an RPG too? Your work-rate knows no bounds!

I think that writing a 2d tile-map engine for an RPG is easy; it's the actual gameplay bit that's hard (hence lots of RPG projects start and never finish)
There's always RPGmaker2000 and it's friends which do the whole lot.

Pete

Korval: Yup, I know - I sort of got the impression that 23 wanted it to be more all-purpose than strictly RPG (his current game isn't even an RPG ...).

Not actively Besides the plot and gameplay I've been working on off and on for several years, I'm just keeping an eye on the future while writing my platformer classes. I should be able to make a shooter very easily with my current game's engine, for example

I had a thought, and it kind of comes from how KQ does things. The map is the same as always, but you could give tiles that trigger scripts an ID number. Then, when you create the tilemap object, you supply a callback function that the tilemap calls with the tile number (and maybe the tilemap ID or something?) when the player walks on it, which does all the cut scenes and stuff. You could even make it a Lua script like KQ. All we need is your uber-GUI and we're set!

Adding the ability to edit the tilemap's ID numbers would be cake. In fact, I could almost call KQ's a "general tilemap editor" and it can apparently handle RPG's just fine

I'm just throwing this out, so feel free to point out anything I've missed ...

I'm not sure if this is worth the effort, actually.
If you do it, you should take it one step further, add lua and make it a higher level game engine. Not just a tile engine.

The reason is that the engine will be pretty complicated. So newbs won't understand it, and the vets will code their own engine in the time needed to learn / customize the tile engine.

KQ has a 3-layer 'visual' tilemap, plus a shadow layer, plus an obstacle layer, plus a zone layer. It's the zones that trigger the calls to script functions. All these layers are independent.
This gives flexibility but in a sense it's unintelligent because some tiles are always obstacles, and some (e.g. the bookcases) are, or should be, always zones (they trigger a book-reading response). Are you suggesting that certain tiles should automatically generate zones for actions? It could be done that way, maybe in the map editor, that there is a default assignment which can be overridden.

Pete

If you're talking to me, no. Well, you could, but I figure assigning a "script ID value" to each tile might be more flexible, in case you want the player to find a certian book in a library. Suddenly all bookcase tiles can't do the same thing, right? OTOH, that callback function I mentioned before could also take the coordinates of the tile, which could be used for specific instances like that. And of course not all floor tiles can trigger events, though some will. Maybe instead of having a zone layer, the tilemap object could keep a hash table or something of the zones. Beats keeping a 60x60 array for 3 script triggers

This reminds of what I used to do with my RPG tilemap ... three tile layers, one flags layer and one zone layer. The flags layer had obstacle data. Now, the zone layer was just a byte for each position in the map. Then, you could define up to 256 triggers per map, and an activation type for this trigger (on step, on activate). Then, each tile which was flagged with this zone would activate that trigger when stepped on or activated, depending on the activation type. These triggers then had scripts associated with them.

That's what KQ has, I think. Script ID value == zone number, doesn't it?

Maybe you can define an XML format for tilemaps. Then, it would be trivial to write XML to binary converters. For example:

<tilemap width="55" height="100"/>
    <row index="0">
        <tile index="1" tileset="zelda-stage-1.xml" opaque="true" animated="false"/>
    </row>
<tilemap>

Ugh ... it would be a NIGHTMARE to design maps in such a way, IMHO.

Hence why you'd have a MapEditor IMO XML isn't a human readable format. You should always use tools to munge and grep it.

Right, which makes the XML bit sort of moot ... I doubt the use it would have, even as an intermediary for conversion.

If you're always going to use tools to access .xml files, what's the point of making them text? It may as well be binary; it loads faster and takes up less memory on-disk. You may as well be using a well-structured tagged binary format.

Korval: I totally agree with you.

XML is just hype.

Right, I couldn't get the original URL to work, but ... read this if you haven't before.

X-G: . That was awesome.

"Bite ME!". I'm dumb!.

"Even LISP pulled itself out of the pond to throw loopy hands around XML's throat, but only managed to choke its ownself." ^2

Don't ask me; you're the script guy I just make the pretty pictures ...

simplep: I've never used XML, but that's certianly not what I had in mind. Though I would not be adverse to someone demonstrating a good way to customize the file format (as I've no clue) ...

Hi again! By shear coincidence I just found Open tUME which is the open release of a map editor that has been knocking around and being updated since 1989 and during its history has been used for some commercial projects along the way.

Surely XML is overhyped. But it is not entirely useless, in my opinion. The point of XML is:

1) as a text file, it can always be modified with a simple text editor like Notepad or vi

2) a generic XML tool like XmlSpy can be used

3) it is a structured format; allows very easy representation of trees

4) it is as human readable as much as the tags allow it. If the tags are obscure, then the whole XML document is obscure. If the tags are clear enough, then it is quite human readable

5) it is almost self-documented; you can come back a year later and remember just by reading the XML document what its data are; if you have binary format only, there should be documentation around

6) it carries itself around different architectures; no need to worry about little/big endian

7) since it is self-documented, new external tools can be easily programmed either by the original author or by others.

Your point is correct though that it takes too much space. Since it is text, it can be compressed quite well. It is also correct that it takes a while to be loaded and parsed. But, remember, it is for tools.

In the place that I work, we have successfully used XML over a variety of products. It have solved quite some problems, especially data exchange between different architectures.

I don't think XML will work, here, though - the individual tags might be readable, but to a human, it will most likely be impossible to get a good view of what the tilemap looks like from the XML.

That's true. You can't see how the level is from the file. But neither you can from the binary format. From my point of view, XML has more advantages than disadvantages. It is worthy enough to give it a try.

I forgot the biggest advantage of XML: flexibility. A small set of tags may be defined today; future tags will not break backwards compatibility; the XML files may specify additional information, but they will be still loaded from older applications. Imagine a situation where you would like to extend your tilemaps with new attributes. With a binary-only format, you would have to re-compile the tilemap editor in order to support the new format; by using XML though, you can specify additional attributes for each tile, and the tilemap will still be loadable by the tilemap editor. This makes a huge difference. And by making the tilemap editor expandable by plug-ins, you can always provide additional processing for the new attributes.

Of course all these can be done with binary only, but more difficult. I think XML makes my programming life quite a bit easier.

We've covered human-readability already ... some counter-points, then:

• Size. Binary files would be much smaller than XML files.

• Speed. Loading a reading in a binary file is faster than parsing a whole XML file.

• Bloat. A tile editor doesn't require the flexibility of XML.

• Keep It Simple. XML is too complex for this task, I feel. It just seems like overkill to use XML - the advantages do not outweigh the disadvantages, IMHO.

• About endianness ... Allegro is already endian-independent.

As for external tools ... see readability again. Tilemaps are too specific, and require some really peculiar display of the information for it to be any useful. Thus, any convential XML tools are essentially worthless when dealing with tilemap XML.

If you do it right, you can do a loader that would load binary data of future versions: for each chunk of data, store its size at the beginning. If a chunk in version 1.0 has 4 variables stored, with a size of 16 bytes, and, in version 2.0, you add 2 more variables, making a total of 24 bytes, an old version capable of loading only 1.0 files, would read the first 4 variables (16 bytes) and skip the two variables that doesn't recognize. It's some work, but may be worth it.

Even better; Divide the file into chunks, and store version info in each chunk along with the size of the chunk. Then, the editor can choose only to read those chunks that it knows how to handle, and can skip the rest.

Compare .psd (photoshop's internal format) file sizes to .tga's, .bmp's or any other format. Compare .doc files to .txt, or even .rtf files.

The internal format of any editor is supposed to be large; it has all kinds of information that the "object" formats don't need.

We're talking about the tile editor's internal format, yes? If so, there's an entire undo-stack in that file (if there isn't, there should be), containing arbiturary information. Information that can change frequently as the tile editor is developed. And if the editor has plugins, their actions have to go there too.

Flexibility is important in the internal format of a plugin-able system.

In theory. In practice, using something like Xerces to write/read an .xml file is simplicity itself. It's not like you have to write an .xml parser or something.

Allegro's .dat files are "endian-independent", for formats that it understands. But storing and retrieving arbiturary data in them (as a block) isn't.

Considering that this debate is solely on the internal format of the tile editor (which I didn't realize at first), arguments about file size are irrelevant (unless they're extraordinarily huge). Thanks to freely-avalaible .xml parsers, arguments about the ease-of-use are equally irrelevant. The only real question is, "Can the text be parsed and loaded fast enough?" That's a non-trivial question, depending on how fast you would like your loading to work.

What you say doesn't have anything to do about binary vs text files. Don't compare what it's stored in a .psd file (you can have a lot of layers, just to mention something) to what's stored in a .bmp.

What program do you know that stores the undo stack in the file?. Photoshop, Word, 3DS and all I've used I can remember don't do it: if you close the document, you lose the undo stack.

And what about pack_iputl and pack_iputw?

I agree that parsing a XML file is not difficult, either using an already written parser, or writing your own.

The point I was making is that saying, "A text file is larger than a binary file" is not a valid argument for not using .xml as an editor's internal format. The reason is that the internal format of most large programs is larger than the external format. As such, the file size of the internal format is irrelevant (unless it pertains to speed).

I think it was Max I saw doing that. I can't be certain, though. I know I used some program that went so far as to save the undo stack.

Those functions store a single word, not arbiturary data. Sure, you could put your data together into words and save/load them with these functions, but that's hardly "arbiturary data".

I think any try at a rpg lib is doomed. it will grow too complex.

if you want to go through all the hassle and also make it flexible enough, it is better to make it an engine. make the source code open so one can customize it a bit, then put all basic functionality in scripts.

OpenOffice's gzipped XML files (its native file format) are significantly smaller than MS Office's .doc (on just about every document I converted). I don't believe the .doc contains any additional data that isn't present in the XML conversion.

I have a simple XML parser on my site, written in C. Uses callbacks to parse, and depends on well-formatted XML docs.

too add in a bitter comment; a document can be allowed to be 10% of the size of the program. but in case of open office and msword, that is still a lot >:E

Who set that rule and how badly do I get punished? MapSlapper is 220KB and one of my files (which includes the tileset images) is 85KB. I expect that number to climb when I add animation, "stamps", etc.

I'll look at Bob's parser, but my file format considers all parts optional (like the palette in .bmp files), with a flag at the begining which details what's there and what's not (tileset, bitmasks, animation, etc). It won't save the tilemap in anyone's predetermined format, but it's versatile enough for me

I don't think that an RPG is a great game to make a library for. It just seems like it would be too hard to make it so customizable. I could see a scripting library that specializes in RPG stuff, or a tilemap library (it would come with an editor, and have some functions to load/save maps and stuff), but not an RPG library.

How much more would you need? About the only thing that can't be handled is the combat engine, and depending how generic you want to be, even that's debatable.

It's a good idea if only because RPG's tend to be the hardest genre to program. A little help getting started would be nice. Alternatively, if someone were to write a tutorial and provide a lot of souce code with many different ways of doing things, that would be helpful as well ...

tilemap_engine + scripting_engine != rpg_engine
If it just had that, it really couldn't be called an rpg library...just a set of helper functions for the basic map and scripting system. I think it's easier to make your own stuff anyway...that way you know exactly how it works, and you don't have to learn a scripting language.

Yeah, that'd work much better than a library.

A library is not an engine. There's nothing wrong with helper functions. As for knowing exactly how it works, I'm all for fully documented source code. If you want an idea what I mean, read my third STL article on my site and see if you can easily follow what's goin on in the code (I write several pages outlining it). Assuming you know C++, of course A library would be documented even moreso; in fact, for those quibbling over tilemap file formats, I can tell you now it would be less than effort to modify the Save and Load functions in my editor. I've ben doing it quite often myself, actually

Why not?

If you take a look at the basics of a square-tile based RPG (as opposed to isometric-tiles), you will find quite a bit of commonality.

In general, you have one (or more) overworld maps that link you to towns and other "enterable" structures. You can engage in combat, usually done by going to another screen (though the fighting engine could accomodate not doing so). You may, or may not, have some kind of GUI that is constantly on-screen. You will, however, have a pause menu that provides access to most of the different configurable features of characters, inventory, etc. You have a bunch of NPC sprites running around that interact with the player. And, you have some form of way to take control of the game for a cutscene (either script or code-based, or a mixture of both).

This all screams "Class Library" to me. Or, better yet, "Class-based Framework Library".

Ugh; I'm not.

There's nothing worse than having to read through someone elses source code just to accomplish something. I'd much rather have stand-alone documentation that gives you very specific paths for extending the functionality of something (like a class to derive from with specific virtual overrides, etc).

By code documentation, I include the notion of stand-alone docs (again, see my third STL article for a rough example). A readme outlining the files and what's in them. When you find the file with the functionality you want to alter, you open it and find the exact code, which is commented further. If you can imagine it being documented in some way, it will be; let's put it that way

I could see where it'd be great, but what about the RPGs that are still square tile based, but have completely different gameplay? I guess my main argument would be that you'd lose a lot of customization ability when those things are done for you. But! if it was done right, it could be nice. It definatly couldn't have battle system functions...maybe basic stat changing functions...

So? My tilemap editor makes tilemaps I can use for my platformer, shooter and RPG. Doesn't get much more diverse than that. Remember; this is a library, not an engine

You'd need a versatile tilemap editor, a versatile scripting language (rip off Lua or something ) and some GUI/dialog functions. That's a big chunk of your RPG engine done for you, and doesn't rob you of a whit of "customization ability".

Whatever. I wouldn't use it...I've spent too much time on my own engine.

Personally, I don't think a universal tile map editor could catch on. Mainly because of customizability, and the fact that if you build it yourself you know everything about it.

I love making map editors
If you do it yourself, it causes less pain in the end because you know how to use it. If you have problems, it's a breeze to go through your own code (most of the time.. heh) and change it to your liking. When you're going through someone elses code everything is much more difficult, at least in my experiences.

There's also the problem of bloatiness.
If a universal tile map editor were to exist, it would need to have tons of features. It would need to cover everyone's needs... but at the same time, it would be impossible for one user to utilize all the features...

(I skipped lots of posts, so some of this was probably mentioned! been fairly absent from the forums for the past week.. playing catchup)

While this is true, I stand by the idea of fully documenting source code and writing an external guide to the code classes/structs, functions, etc. Reading is faster than writing IMO

I dunno; I'll save my comments until my editor's next release (I'm shooting for this weekend). I'm going to document the living snot out of it, so we'll see how level I can make the learning curve ... just to see if it works in practise