Data storing in MIDP
Author
Hi all,
I''m currently working on an RPG using MIDP. I have a question about storing the data (stats) of various objects of the game, e.g. the hit points, attack, defend, etc.
Which one is better:
1. Store all of the data for all objects in a file.
2. Store each object''s data on a file, i.e. a monster will have a file, the second monster will have a file, etc.
3. Hard code all of the data.
Thanks a lot for your attention.
I would say that each object should have a file and you would have one large file containing all the other small ones.
So, in a large file objects.dat you might find
blob.m
skeleton.m
...
potion.i
longsword.i
That way you can have a simple editor (written in any language) that stores information in a file. So, you won''t have to go in and change your code every time you want to update your item database.
Of course, it CAN be hardcoded. But with a lot of items/monsters it becomes very hard to read.
So, in a large file objects.dat you might find
blob.m
skeleton.m
...
potion.i
longsword.i
That way you can have a simple editor (written in any language) that stores information in a file. So, you won''t have to go in and change your code every time you want to update your item database.
Of course, it CAN be hardcoded. But with a lot of items/monsters it becomes very hard to read.
MIDP tends to see much more hardcoded game data than other platforms, simply because your resources and file access are so limited. Since you have to preverify and package your midlet each time, having to go in and change your code is a relatively minor consideration. With that said, if you do end up hardcoding your game data, a utility to generate the code in question is indispensable.
"Sneftel is correct, if rather vulgar." --Flarelocke
"Sneftel is correct, if rather vulgar." --Flarelocke
I completely agree with Sneftel, although there is one thing I don't agree with. You actually save more space by making your own binary file and supply it as a resource file in your JAR, than by hardcoding it in the java file, which of course, takes more space.
Although, there is a balance to everything. Take my newest game for example (it's up for publishing soon, damn all who do not buy it), it uses a mixture of both. My levels are generated with a map editor and stored in my own binary format. When compressed they go down to a few bytes in size and then we are talking about a level that is 1600 x 1600 pixels. Although, all events on a level are hardcoded (such as textboxes, monster generation, veichles, etc...) since they really aren't that much smaller if put in a separate file.
Also, listen to sneftel about the code generation, that is indispensable. Even IF I hardcode event data into my files, I still have a generator that creates the .java file for me.
[edited by - biovenger on April 18, 2004 5:08:04 AM]
Although, there is a balance to everything. Take my newest game for example (it's up for publishing soon, damn all who do not buy it), it uses a mixture of both. My levels are generated with a map editor and stored in my own binary format. When compressed they go down to a few bytes in size and then we are talking about a level that is 1600 x 1600 pixels. Although, all events on a level are hardcoded (such as textboxes, monster generation, veichles, etc...) since they really aren't that much smaller if put in a separate file.
Also, listen to sneftel about the code generation, that is indispensable. Even IF I hardcode event data into my files, I still have a generator that creates the .java file for me.
[edited by - biovenger on April 18, 2004 5:08:04 AM]
I''d go with binary files. More flexible. However, if you do use watch out for case sensitivity :-).
Firstly I''d like to dispute the use of the word "file".
As MIDP does not support any kind of file-based IO, I find it rather dubious at best.
If you are talking about predefined data inside the .jar, then yes, you should store it all in one file. This is because the "file" is compressed into a zip, and a single large file compresses much better than small ones. But you don''t get random access (really) to it, you can only read and skip bytes.
I would be severely tempted to go with pseudorandom monster data generation; storing information about every bad guy sounds like a bad idea. AFAIK, even PC-based RPGs don''t do this very much (bosses, perhaps, but not individual baddies)
You can get it so that all your monsters will be identical in each run of the game (if that behaviour is desired) without storing data about individual monsters; simply generate them according to the same random number seed each time. It also saves a lot of space by not having to store them at all.
(Obviously you would include some factors into the randoms, f.e. monsters get harder with each successive dungeon)
Mark
As MIDP does not support any kind of file-based IO, I find it rather dubious at best.
If you are talking about predefined data inside the .jar, then yes, you should store it all in one file. This is because the "file" is compressed into a zip, and a single large file compresses much better than small ones. But you don''t get random access (really) to it, you can only read and skip bytes.
I would be severely tempted to go with pseudorandom monster data generation; storing information about every bad guy sounds like a bad idea. AFAIK, even PC-based RPGs don''t do this very much (bosses, perhaps, but not individual baddies)
You can get it so that all your monsters will be identical in each run of the game (if that behaviour is desired) without storing data about individual monsters; simply generate them according to the same random number seed each time. It also saves a lot of space by not having to store them at all.
(Obviously you would include some factors into the randoms, f.e. monsters get harder with each successive dungeon)
Mark
quote:Original post by pkelly83
I''d go with binary files. More flexible. However, if you do use watch out for case sensitivity :-).
As far as I''m aware, names resources loaded from a Java .jar are ALWAYS case sensitive regardless of the underlying OS. The only problem happens if you try to unzip it on Windows or something - I don''t think any emulator or other MIDP implementation does that.
Mark
quote:Original post by markr
Firstly I''d like to dispute the use of the word "file".
As MIDP does not support any kind of file-based IO, I find it rather dubious at best.
It supports file-based ''I'' just fine. I agree that the whole RMS setup is pretty stupid, though.
quote:If you are talking about predefined data inside the .jar, then yes, you should store it all in one file. This is because the "file" is compressed into a zip, and a single large file compresses much better than small ones. But you don''t get random access (really) to it, you can only read and skip bytes.
Don''t see why you would put quotes around "file" here. And how is skipping not good enough for "random access"?
quote:
I would be severely tempted to go with pseudorandom monster data generation; storing information about every bad guy sounds like a bad idea. AFAIK, even PC-based RPGs don''t do this very much (bosses, perhaps, but not individual baddies)
You can get it so that all your monsters will be identical in each run of the game (if that behaviour is desired) without storing data about individual monsters; simply generate them according to the same random number seed each time. It also saves a lot of space by not having to store them at all.
Procedural generation is a good idea where possible, yes. Just watch that the extra code isn''t bigger than the data it replaces (could happen
).My findings have been that large arrays of data should very definitely be put into files rather than hard-coded. Even with an obfuscator going over your code, and using a byte array, the hard-coded array will take up several times as much JAR space as the plain data. You can save almost all of that overhead by using Strings instead of byte[]''s, but you end up doing weird conversions and there''s still unneeded overhead. Just write code that will load a byte[] (or a byte[][]) from file. You''ll need to add information to the file to indicate array lengths, of course.
For more "structured" types of data, like statistics for a monster - you can pack/unpack the data into byte[]''s using a simple (and fairly well-documented - search around for it) trick with (ByteArray|Data)(Input|Output)Stream pairs. But you should probably still generate as much as possible procedurally.
There is no real text vs. binary file distinction to be made. For MIDP I strongly recommend thinking about your file data the way that UNIX does.
And yes, have generating code for hard-coded data, if you need it. Also have scripts to produce nice efficient data files. Say you write your map editor on a PC and use a nice easily-patched-up text format for that data, you''ll want a Perl script or something to reduce it to one byte per tile (assuming you have sufficiently few possible tile states).
quote:Original post by Zahlman
Don''t see why you would put quotes around "file" here. And how is skipping not good enough for "random access"?
Skipping is good enough for random access, but is not the *same* as random access. Because I suspect that the implementation stores the resources still inside the .jar (i.e. zipped probably), then skipping bytes involves decompressing data and throwing it away. It''s therefore slower than true random access (although for small files, probably still pretty fast).
It''s what I use on my current MIDP game.
quote:
Say you write your map editor on a PC and use a nice easily-patched-up text format for that data, you''ll want a Perl script or something to reduce it to one byte per tile (assuming you have sufficiently few possible tile states).
That''s pretty much what I do. Except I use text files for my tilemaps (i.e. level data). The Perl script mangles them into a byte array system.
Just one thing to watch out for - Java expects ints to be in big-endian format, so ensure that if using Perl, you use pack("N",whatever) to pack the data.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
