Honestly I just use .txt files, unless you're planning on actually releasing your game to the general public, I see no reason to do anything more complex. If you are going to release it, and are worried about modifying of the files, use a byte format maybe?

Honestly, I have no idea. I have never actually played either game :/ I imagine they have their own file format though. I haven't dealt a lot with file systems besides .txt files, but I'd recommend googling about file formats that are compatible with Java!

There are 3 options, and really, there are only 3 options that cover how everyone deals with file storage.

1) Hard code it

Store all your level design and objects hardcoded within the game. It completely alienates a lot of users from modding your game and makes it a little more difficult to do a quick fix in your levels. But, hey... the people will have to crack your entire code base in order to crack the game.

Java has a special serialization method that allows you to save states of its classes. It is a compromise between this option and option 2.

2) Put the data in a text file

This method takes your game data and puts it into a text file. Keep in mind, the extension does not have to be .txt. You can name the extension whatever you want. Also, you do not have to store the data as UTF-8 characters. You can store the data as a mixture of bytes, chars, and longs. As long as you are able to read the data back into the game you are fine.

This covers a lot of ways to store data, and is by far the one used by most indie and development companies working on large games. It includes most scripting languages like Lua, JSON, and XML. It also includes just writing your data into a basic text files under .txt and picture files like jpeg and png. You can also use this method to store data into binary.

The most important aspect is that you are able to read the data in and out of any format you put in the text file.

3) Store it online

This is really an extension of Option 2. But there is a few tools like MySQL and data servers where you can store all your data online and have the clients read off the server data. Of course, your clients will be out of luck if your system goes down, but MMORPG's and other online gaming outlets all use this method of storing data.

Conclusion

Best way to handle it is possibly Option 2. It takes a little bit longer to write code that'll be able to allow for custom objects and level design in the game. In the end though, it makes it a lot easier to expand your game to make more levels and objects.

I've just always used txts when I didn't hard code my levels (now that i read this, perhaps I shouldn't be giving advice ^^)Does it just not feel professional to use a text file? Or are you worried about security, and the user editing the level?

You approach the entrance to THE WILDS. A man wearing nothing but a hat greets you with an enthusiastic handshake.

There are 3 options, and really, there are only 3 options that cover how everyone deals with file storage.

1) Hard code it

Store all your level design and objects hardcoded within the game. It completely alienates a lot of users from modding your game and makes it a little more difficult to do a quick fix in your levels. But, hey... the people will have to crack your entire code base in order to crack the game.

Java has a special serialization method that allows you to save states of its classes. It is a compromise between this option and option 2.

2) Put the data in a text file

This method takes your game data and puts it into a text file. Keep in mind, the extension does not have to be .txt. You can name the extension whatever you want. Also, you do not have to store the data as UTF-8 characters. You can store the data as a mixture of bytes, chars, and longs. As long as you are able to read the data back into the game you are fine.

This covers a lot of ways to store data, and is by far the one used by most indie and development companies working on large games. It includes most scripting languages like Lua, JSON, and XML. It also includes just writing your data into a basic text files under .txt and picture files like jpeg and png. You can also use this method to store data into binary.

The most important aspect is that you are able to read the data in and out of any format you put in the text file.

3) Store it online

This is really an extension of Option 2. But there is a few tools like MySQL and data servers where you can store all your data online and have the clients read off the server data. Of course, your clients will be out of luck if your system goes down, but MMORPG's and other online gaming outlets all use this method of storing data.

Conclusion

Best way to handle it is possibly Option 2. It takes a little bit longer to write code that'll be able to allow for custom objects and level design in the game. In the end though, it makes it a lot easier to expand your game to make more levels and objects.

Thank you, thank you, thank you. this explanation just saved me so many questions (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.)

"Text file" is very misleading. All a "Text file" is a File (and all a File is a collection of bytes) which bytes are ordered in a way (codec/protocol/charset) that is familiar with most text editing programs.

An mp3 music file is a text file if you open it with a text editor. But the bytes are ordered in a way that text files can't make sense of so you get a bunch of gibberish text.

The only reason you get a music player or a text editor opened up when you double-click/open a music or text file is because the suffic is either .mp3 or .txt - this suffix is only there to tell your Operating System which program (music player or text editor) it should try and open the file with (It essentially has nothing to do with the contents of the file).

(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.

Nethack mostly does, but has several pre-made levels with a fixed map. But even a procedural map is something you have to figure out how to save, since the random seed alone won't account for alterations afterward.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org