Level Editor?

Newbie & Debugging Questions
#1

Hi there,

I was wondering if there are any good tutorials for writing a basic level editor.

Cheers
Wolfner

#2

I’d just try to learn Java Swing and then decide the format your level files are going to be saved/loaded in. Otherwise it’s up to you on what’s best for your game.

For saving files, take a look at ObjectOutputStream and ObjectInputStream, they’re probably the easiest and most powerful methods.

#3

I disagree. I’d output the contents in a text format, like XML, and then read it back in to recreate the objects. I believe there is an XML parser in the Java API, but I’ve not used it. The reason I don’t recommend serialization is because it breaks the moment you alter the classes, which limits how maintainable it can be.

If you do save your levels as plain text then you might find their size becomming quite bloated (like in the magabytes). This can be especially true with all the tags in an XML based format. If this happend then I’d recommend compressing the contents when saved and decompress when you load as plain text compresses very well and should solve this issue.

#4

Well you don’t want to write MyCoolEntity directly to the disk, you want to write SavedEntity to the disk that contains information on how to construct the desired MyCoolEntity. As for altering the classes, all you need to do is declare a serialVersionID (paraphrasing the variable name) for any Serializable and then just keep it the same. That will avoid any issues reading old save files unless you drastically change the data. If you’re still worried about losing data across versions you can use Externalizable instead of Serializable, but it’s quite slow and fairly annoying to use in comparison.

IMO the reason not to bother with text is because it’s too easy for people to mess with and ends up with a bloated file size. It’s also slower to read and to write. But that’s not to say I haven’t made text-based level file systems many a time before, because I have.

#5

Text is generally better because it is easier to see what is going on when something doesn’t parse. The stored data is likely to change over time, so this will happen. Also, obviously hand edits can be done easily. Text compresses well enough.

Java’s built-in serialization sucks for many reasons, so I would avoid using the Serializable interface even if you want to go with binary. Using DataInputStream/DataOutputStream is an ok way to go, but you will have to manually write code for each piece of data you want to save. You might check out Kryo for an easier way to go:
http://code.google.com/p/kryo/

If you don’t mind another shameless plug, I would recommend YamlBeans:
http://code.google.com/p/yamlbeans/
This writes/reads Java beans to/from a nice, human readable text format without you having to write the code to serialize each bit of information. It can write an entire object graph, so you can still have nice OO level storage.

#6

Either save the output in a text form (SGML, XML) or a binary form which can be reconstructed to form the level structure.

For a binary structure, the structure will most probably analogous to the following:


 <4 bytes> - Number of objects
 Repeat Number of objects {
  Object information
 }

which is analgous to this in a XML structure:


<Objects>
 <Object1>
  <Attr1="Something" />
  <Attr2="Something>
   <SometingInsideAttr2="Something Else" />
  </Attr2>
 </Object1>
 ...... And so on
</Objects>

Binary will probably be faster to load, but XML will be easier to edit, (well that depends on how good your Level Editor is.)

I wouldn’t really recommend ObjectInputStream and ObjectOutputStream, you might encounter problems loading old levels with a new version of the game.

#7

Give a look at the level editor of JME 3 and maybe at JFPSM :wink: