(i had been told that serialization was the best way and the only option if i plan to allow players to play multi-player if they want, but this explanation contradicts that, and seems to actually explain it a bit more then others did.)
"Serialisation" has a technical meaning in Java in terms of the java.io.Serializable
interface, but it also has a more general meaning
. ctomni231's comments are largely orthogonal to the question of serialisation. I would break it down instead as:
Top-level choice: build the levels with code or deserialise them from a string or byte.
If you build them with code then making changes requires recompilation. I would say that this is rarely the correct option.
If you serialise and deserialise, you have two further choices to make: what format to use, and where to store the data. ctomni231's answer addresses where to store the data: in code (has the same downside of requiring recompilation, but Java4k developers tend to do this because it keeps things simple); in a file; in a database; or fetched across a network. (The latter options overlap).
tyeeeee1's answer addresses the serialisation format. The questions you have to ask when deciding on a format are 1) What do I need to store? 2) What might I need to store later? and 3) How am I going to edit the levels? If you just need to store a 2D grid and don't expect to add anything then (lossless - e.g. PNG) image files make convenient formats because you can edit them in any image editor and deserialise with javax.imageio.ImageIO
. But you might want to represent a complex structure, in which case the choice is between using Java's serialisation (simple but brittle) or creating your own format (flexible, but requires investment of time in writing your level editor and debugging the custom serialisation/deserialisation).
One additional comment I will make is that if you do decide to create your own format, make sure that it has a version identifier at the start.