some questions about game development

General Discussions
#1

Hi. I’ve been trying to develop a 2D game. But I’m having trouble deciding how I should store data like maps and sprites. When I save a map 3x128x128 (foreground, background, and roof) to disk as xml using a xml encoder it
saves a map that’s 8 megabytes large! when I save using object serialization it’s 500 kilobytes, so I’m trying to make a decision between flexibility and space. For example, if I were to use object serialization, what if I add more information to the map, such as triggers and npcs, etc… as I add these things won’t previous class files become outdated and cause me to lose maps I’ve made?

I wonder if it’s how I store the layers, they look like this

class TileLayer {
LinkedList[][] layer;
}

I used a linked list thinking I could conserve space, is this incorrect?

One last question about game development is how should I deal with guis in fullscreen exclusive mode using java 2D?

Any help would be greatly apprechiated as always.

#2

Storing raw data in XML is pointless. I’d elaborate, but I need to run… just don’t do it :wink:

EDIT:

Ok, tiles… if you’re only going to have a certain set of tiles (i.e. a few for grass, a few for rocks etc…) just assign each one a number and store this in the file.

Is your map going to be changing size during game play? If not, just use an array, it’ll be faster and easier to manage.

128x128x3 = 49152, assuming you’re going to have no more than 65k tiles, you could store each tile index as a short giving you approx 100k a file?

Kev

#3

GUI’s in fullscreen mode shouldn’t be an issue, just use them like normal. However, if you’re using accelerated graphics mode it gets a little more tricky since you’ll have to turn repaint off on each component (i.e. setIgnoreRepaint(true)) and actively draw each component yourself.

Kev

#4

Personally, I’d use XML to store the map data, and have a utility that turns map data into a serialized object.

Write the resource loader to accept either .xml or .ser, and you can effectively ignore the problem until you’re ready to ship, as long as you keep the Serialization code up to date.

#5

XML for maps? Whatever next? Computers for pets? Robot friends?

Cas :slight_smile:

#6

XML is evil. Very, very evil.

#7

Thanks for all the feed back!

I’ve made a prototype of a map with shorts and without the linked list, and serialized it, what I found is it’s only around 175 kb! thanks kevglass.

I was thinking about what you said about the tilesets. I had the idea to serialize an arraylist along with the map, containing the paths to images that the serialized map indexes. When the map is loaded in the game all the images will be resolved from this extra serialized object and the game can index this array using the map file to obtain the correct tiles.

I decided that I would just get the program up and running with serialized objects and each time I update a class just record that class and label it with a version in case I want to convert some legacy maps to a newer version. It might be a lot of book keeping, but I don’t know another way to do it other than parsing a text file which seems to be a lot of work or xml (which seems to not be very popular from what most of you are saying).

So I think I shouldn’t worry to much about file formats and just serialize everything until I get it up and running.
I’ll worry about it when I actually start making maps and sprites.

Thanks again for all the feedback.

#8

Meh. Ignore the heretics. ;D

XML is great for storing user-edited resources. I don’t recommend writing XML of the form <cell x=“3” y=“5” contents=“grass” … />, but as a way of getting hand-tuned slightly-structured Strings into an application without having to write your own parser, it’s fine.

Note that I don’t condone the use of XML for non-human editable data, nor do I condone shipping data to the client still in XML form, unless they’ll be editing it as well.

Remember kids, friends don’t let friends process XML documents in speed-critical, resource-starved environments.

#9

XML is great for what it’s supposed to do :slight_smile:
Storing maps definitely isn’t one of those things!

However: using XML to store metadata about maps, and even the map data itself as a CDATA section is not a bad thing, provided one remembers to use SAX to parse it which is much more lightweight than DOM.

Cas :slight_smile:

#10

I don’t know a lot about xml. But I’ve seen sax requires a lot of setting up compared to dom. So maybe for small metadata files it would be okay to use dom? For example to use dom for the paths to tiles referenced by the map.

#11

Very very offtopic:

Could someone explain to me why the industry seemingly blindly decided to go with a format that requires each tag name to be entered twice even when there’s no chance of conflict?

Eg instead of “<long_tag_name data=“wooo”>contents</long_tag_name>”, why not use “<long_tag_name data=“wooo”>contents</>”, or even prettier “long_tag_name(data=“woo”){contents}”

XML seems designed to waste as many bytes as possible.

#12

Its about human readabilty, while it’d be easier enough write a bit of code to close bracket count it’d be hard to see what close was linked to with the naked eye.

Kev

#13

And on top of that, XML is a subset of SGML, which was not designed with brevity in mind.

Edit: But hey, it’s a text file. Repeated sections in text files compress really well.

#14

Kevglass: Are you having problems seeing where blocks start and end in java?


<printHelloWorld>
  <while condition="keepgoing">
    System.out.println("Hello world!");
    keepgoing = false;
  </while>
</printHelloWorld>



void printHelloWorld()
{
  while(keepgoing)
  {
    System.out.println("Hello world!");
    keepgoing = false;
  }
}

I don’t know about you, but to me it seems that the last one is far more readable, has less chance of being wrong (only one place to typo “printHelloWorld”), and takes up far less space.

Oh, and XML being based on SGML is exactly WHY it is evil in the first place. :wink:

#15

Markus = developer, used to blocked structured languages

XML Reader = not always a developer or even a particular technical person.

Its an aid to readability, look at old/scripting languages that have constructs like “while” “endwhile”.

Kev

#16

[quote]I don’t know a lot about xml. But I’ve seen sax requires a lot of setting up compared to dom.
[/quote]
Yeah, I’ve seen that the earth is flat, too. I mean, it never looked curved to me :P.

Be careful about random things you see/hear; spend 20 minutes following tutorials for each and make your own conclusions. With a proper IDE it takes around 30 seconds to get all the setup code for SAX done. And there’s zero runtime setup cost.

SAX reads and parses XML directly, streaming it into your app just like an InputStream, whereas DOM reads the whole file in one method call AND parses the whole file (which could easily take millions of milliseconds) and then - eventually - lets you start interacting with it.

#17

another example:

<?xml version="1.0" encoding="UTF-8"?>
<Recipe name="bread" prep_time="5 mins" cook_time="3 hours">
  <title>Basic bread</title>
  <ingredient amount="3" unit="cups">Flour</ingredient>
  <ingredient amount="0.25" unit="ounce">Yeast</ingredient>
  <ingredient amount="1.5" unit="cups">Warm Water</ingredient>
  <ingredient amount="1" unit="teaspoon">Salt</ingredient>
  <Instructions>
   <step>Mix all ingredients together, and knead thoroughly.</step>
   <step>Cover with a cloth, and leave for one hour in warm room.</step>
   <step>Knead again, place in a tin, and then bake in the oven.</step>
  </Instructions>
</Recipe>

?bml(version="1.0",encoding="UTF-8")?
Recipe(name="bread",prep_time="5 mins",cook_time="3 hours")
{
  title{Basic bread}
  ingredient(amount="3",unit="cups"){Flour}
  ingredient(amount="0.25",unit="ounce"){Yeast}
  ingredient(amount="1.5",unit="cups"){Warm Water}
  ingredient(amount="1",unit="teaspoon"){Salt}
  Instructions
  {
   step{Mix all ingredients together, and knead thoroughly.}
   step{Cover with a cloth, and leave for one hour in warm room.}
   step{Knead again, place in a tin, and then bake in the oven.}
  }
}

(“bml” being, of course, “better markup language” ;D)

#18

btw, I’m not terribly serious with this. :wink:

xml is good enough for what it was designed for. It’s not perfect, of course, but I recognize that that is almost a religious issue, so my opinions are just that… opinions.

#19

Those verbose closing tags aren’t that bad, consider how well XML compresses, the ending tag in the compressed format is at worst a back reference to the full text of the starting tag. Usually the tags are repeated enough that most instances compress optimally.

Also, your examples are all fitting on one page. I do have problems matching braces in Java for large methods that don’t fit on one screen with heavily nested blocks. Ignore for the moment the argument that such methods are “too big” ;-). You often see people putting comments by the closing brace just for the purpose of identifying what it goes with.

Anyway XML is a heck of a lot better than some of those icky unix shell things where ‘case’ blocks are closed off with ‘esac’ or some other silliness. :slight_smile:

#20

[quote]Very very offtopic:
Could someone explain to me why the industry seemingly blindly decided to go with a format that requires each tag name to be entered twice even when there’s no chance of conflict?
[/quote]
Easy to parse with parsebots. Easy for creating a excerpts from lots of a completely unknown data, thus create meningless databases. Improvements, and rigidization of HTML. Rigidization is for some math brains nice things, I don’t think so. Simplification of a unclosed tag problem. Hype. Buzzword. And other reason somewhat similar to UML reasons.

What if you’d like to have a nice block of tags plugged into each other? If you’d have a simple programmer convention for closing braces it might be impossible.