Good File Engine For RTS Map Editor
Post: #1
Hello Everybody. This thread is also an announcement for my new game "Ground Zero" (working title) it is an RTS using an isometric tile engine and allows the user to give his units custiom (or even create his own) weapons and armor.
Anyways, on to my question. I was wondering if any of you know where to find good information on creating resources to hold map information from the map editor or weapon damage & range. what I was thinking to have it do was to create a new resource with a resource called something along the lines of WeAp, or MaPd, with a DWord to store the array of the map information. My main question would be, How do you write data to that particular resource in the resource fork of the map or weapon file? All of you guys ared great!! This site has really helped me grow as a mac programmer!! Thanx
Anyways, on to my question. I was wondering if any of you know where to find good information on creating resources to hold map information from the map editor or weapon damage & range. what I was thinking to have it do was to create a new resource with a resource called something along the lines of WeAp, or MaPd, with a DWord to store the array of the map information. My main question would be, How do you write data to that particular resource in the resource fork of the map or weapon file? All of you guys ared great!! This site has really helped me grow as a mac programmer!! Thanx
-CarbonX
Post: #2
You really shouldn't use resources anymore.
If you don't mind users being able to edit your files, I'd consider saving them out in a text-based format, perhaps even using XML.
If you want your file format to remain proprietary, then you'd just use the standard File Manager or Unix file system calls (i.e. fopen(), fwrite() ) to write out your binary data.
Wade
If you don't mind users being able to edit your files, I'd consider saving them out in a text-based format, perhaps even using XML.
If you want your file format to remain proprietary, then you'd just use the standard File Manager or Unix file system calls (i.e. fopen(), fwrite() ) to write out your binary data.
Wade
Post: #3
And even if you do mind your users editing your files, you won't be able to stop them if they really want to. I'd second using a text-based format - it's an awful lot easier to debug.
Really, don't bother with the resource fork. It's just a pain.
Really, don't bother with the resource fork. It's just a pain.
Post: #5
If you have an array of tiles called MyArray, and want to save that to a resource, what I would do is (sorry this is Pascal):
EDIT: Made some changes to the code. A DisposeHandle snuck in there, and I fixed up the resource removing code
EDIT: fixed it up, yet again
Code:
procedure SaveMap (TheTiles: TileArray);
var
Data: Handle;
Err: OSErr;
begin
{make sure that there isn't anything in the resource}
Data := GetResource ('MaPd', 128);
if (ResError <> resNotFound) or (Data <> nil) then
begin
RemoveResource (Data);
DisposeHandle (Data);
UpdateResFile (CurResFile)
end;
{create a handle from the tiles}
Err := PtrToHand (@TheTiles, Data, SizeOf (TheTiles));
{save the handle to the resource (MaPd, 128)}
AddResource (Data, 'MaPd', 128, 'My map data')
end;EDIT: Made some changes to the code. A DisposeHandle snuck in there, and I fixed up the resource removing code
EDIT: fixed it up, yet again
"Programmers are tools for converting caffeine into code."
Post: #6
XML does sound useful but I don't think you really got what I was saying. what I want to do is write a tool for drawing maps to a file such as the map editor for starcraft and various other RTS games. if you are not familiar with this concept what the map editor allows you to do is visually draw the map with some sort of paintbrush tool and then when you save the file it saves it as a .map 'MapD' file. then you can load that particular file into your game. I would gladly use XML if somebody could show me how to do that with it. I am really short on cash right now so I cant afford any more books ( I just recently bought Mac Game Programming) thanks
-CarbonX
Post: #7Quote:Originally posted by CarbonX
XML does sound useful but I don't think you really got what I was saying. what I want to do is write a tool for drawing maps to a file such as the map editor for starcraft and various other RTS games. if you are not familiar with this concept what the map editor allows you to do is visually draw the map with some sort of paintbrush tool and then when you save the file it saves it as a .map 'MapD' file. then you can load that particular file into your game.
It doesn't really matter what kind of program you're writing - map editor or otherwise - because you can choose any way to save and load the data you like. You can have a map editor with paintbrush tools and save your data as XML (or anything else) if you want.
Quote:I would gladly use XML if somebody could show me how to do that with it. I am really short on cash right now so I cant afford any more books ( I just recently bought Mac Game Programming) thanks
It's not really difficult, but it's a bit tricky to describe the complete process of working with XML in a brief forum post. You could look at www.xml.com for relevant free information, and if you want to use TinyXML as I suggested earlier, some documentation is supplied with it. However, if you'd like to see a brief example of some XML (from my uDevGame entry):
Code:
<?xml version="1.0" standalone="yes"?>
<animation name="Bullet" texture="Particles">
<sequence name="Punch" delay="1.0">
<frame index="3"/>
</sequence>
<sequence name="Bullet" delay="0.05">
<frame index="0"/>
<frame index="1"/>
</sequence>
</animation>It's just a way of associating pieces of data with names and attributes in a hierarchy. It's a bit wordy, but it gives you lots of flexibility and is easy to type in by hand where necessary. With TinyXML, I create a TiXmlDocument object, tell it to load the file, then call methods on it to iterate through the elements in the hierarchy. When you want to save some data, you create another TiXmlDocument, call methods on it to assemble the hierarchy and tell it to save it.
That might sound like a lot of work, but believe me it's a lot easier and more extensible than trying to code a binary loader yourself.
Post: #8
Binary loaders aren't that hard to write, but making them robust is a little harder.
IMO, first have your app save everything into a text file (or text files) so that you can conveniently edit them later -- effectively granting a command-line interface for your game data -- and exporting or converting them with editor-internal routines or -external utilities when the data is closer to being finalized, or you're dinking around with handwritten editors.
-"Sta7ic" Matt
IMO, first have your app save everything into a text file (or text files) so that you can conveniently edit them later -- effectively granting a command-line interface for your game data -- and exporting or converting them with editor-internal routines or -external utilities when the data is closer to being finalized, or you're dinking around with handwritten editors.
-"Sta7ic" Matt
Post: #9
That sounds good I will check out http://www.xml.com and will more than likely end up using TinyXML.
-CarbonX
Post: #10Quote:Originally posted by CarbonX
That sounds good I will check out http://www.xml.com and will more than likely end up using TinyXML.
If you get stuck with it, I can probably give a better explanation or tell you what's wrong with your code. Give it a try, and feel free to ask!
BTW, there is one problem with the TinyXML source code when you first download it. In tinyxml.h, change the line which reads:
Code:
TiXmlDeclaration::TiXmlDeclaration( const char * _version,
const char * _encoding,
const char * _standalone );...to:
Code:
TiXmlDeclaration( const char * _version,
const char * _encoding,
const char * _standalone );...or it won't compile. Apart from that, it should be very easy to compile into your project.
Post: #11
Just a quick question. Does XML support custom file icons?? and if so how would I go about getting them put onto my map file
-CarbonX
Post: #12
Allow me to be a spoilsport. Forget xml... at least for now. Write your editor. You are handwringing over the format and delaying writing the app. XML is great - but it sounds like a regular text file will work just fine while you are starting up your development - and maybe just fine for the finished product. Start writing the editor - as you construct your classes (or structs) you will get a feel for what data you need saved and in what order. Maybe your map file will just be a set on numbers like
5 5
0 1 5 20 14
14 23 22 10 9
0 1 5 20 14
14 23 22 10 9
14 23 22 10 9
where the first two numbers give the dimensions of the map - and the rest of the numbers are the tiles. Then a separate file explains what each tile number represents.
But really - my suggestion is dont spend so much time researching xml that you dont start coding. As your app progresses you will get a better feel for what the file format should look like.
good luck, Codemattic
5 5
0 1 5 20 14
14 23 22 10 9
0 1 5 20 14
14 23 22 10 9
14 23 22 10 9
where the first two numbers give the dimensions of the map - and the rest of the numbers are the tiles. Then a separate file explains what each tile number represents.
But really - my suggestion is dont spend so much time researching xml that you dont start coding. As your app progresses you will get a better feel for what the file format should look like.
good luck, Codemattic
Post: #13Quote:Originally posted by CarbonX
Just a quick question. Does XML support custom file icons?? and if so how would I go about getting them put onto my map file
Any file format can be given a custom icon. The traditional way to give your data files icons was to give each file the creator type of your application and a type code to identify the file, then give the application a 'BNDL' resource to identify all of the file types it supports. I can't find any documentation on Apple's website to explain this, unfortunately.
Nowadays you're supposed to use your application's Info.plist file to associate file types or extensions with files. This page from the Core Foundation documentation gives an overview of the keys you need to add to set up your Info.plist correctly, and you could also look inside other applications to see how they do it.
Quote:Originally posted by codemattic
Allow me to be a spoilsport. Forget xml... at least for now. Write your editor. You are handwringing over the format and delaying writing the app. XML is great - but it sounds like a regular text file will work just fine while you are starting up your development - and maybe just fine for the finished product.
You make a good point, but when I was faced with the same choice I still went for XML. My reason was that by using XML (specifically, by using the TinyXML library) I could reduce my file handling to a bunch of really simple API calls instead of having to chew characters with stdio/iostream. I found it considerably more difficult to write robust, tolerant file handling code with built in C/C++ library functions.
But you're right, CarbonX should write the editor first, then worry about the file format!
Post: #14
I have already started coding the map editor and am just asking these questions on the side
-CarbonX
Post: #15
If I had my say, I'd go with an XML-based format. It's easier to extend than a straight ASCII or binary dump of parameter values; one can add attributes and tags without disrupting existing code.
This should be good until (1) one has a large bulk of data or (2) one's data format is reasonably stable.
But even if one decides to go for a binary format, there are ways to make it extensible. The tag approach can be extended to binary:
<tag>
<number of bytes>
<data>
and tags can have subtags embedded in them. Tags are usually 4-byte strings like 'PNTS' or 'LITE'. One can extend this format by simply defining new tags.
A variant is the "wad" format used in the Marathon series for level data:
<header>
<each level>
<directory>
The header contains the location of the directory in the file (how many bytes from the beginning), and the directory has an entry for each level -- an entry that contains the location of the level data in the file.
In the Marathon series, each level's data is handled with tags, as described earlier, with a blank tag ending the sequence of tags.
This should be good until (1) one has a large bulk of data or (2) one's data format is reasonably stable.
But even if one decides to go for a binary format, there are ways to make it extensible. The tag approach can be extended to binary:
<tag>
<number of bytes>
<data>
and tags can have subtags embedded in them. Tags are usually 4-byte strings like 'PNTS' or 'LITE'. One can extend this format by simply defining new tags.
A variant is the "wad" format used in the Marathon series for level data:
<header>
<each level>
<directory>
The header contains the location of the directory in the file (how many bytes from the beginning), and the directory has an entry for each level -- an entry that contains the location of the level data in the file.
In the Marathon series, each level's data is handled with tags, as described earlier, with a blank tag ending the sequence of tags.
