Questions about creating a level editor.

       So many times while I have been creating a game that has no need for a level editor, I've wanted to create one. Now I'm stuck on what would be the best way to implement this or how. I figured it would be best to have the level editor in the game so that players could easily create their own maps, but then I thought about how I would create a standalone map creator for it. Then I went even deeper and tried to figure out how I would save the maps and so on. I've yet to make a game where game progress is saved and so I have no clue how to do so, or if even making your own custom file type is something that could easily be defined. I figured a level editor would be much easier in creating, then hard coding every single interact able NPC, Even trigger,  and object. So could someone point me in the correct direction for Level Editor Creation, Saving such levels that you created, and loading them into the game?

You possibly don’t need a stand alone map creator. I find it easiest to code level editors into the game. The level editor is basically exactly the same as the game, except that it doesn’t update the game logic and you can place objects with the mouse. It will probably need extra gui elements for selecting and altering things. Just build it up step by step, it doesn’t need to be able to load/save everything right from the start. Saving the map is a good starting point, just loop through the map and write something to a file describing each tile. There are several different ways of writing data to files and making your own file format is as simple as just ordering your data however makes sense to you and your levels. An advantage of a built in editor is that it grows as the game grows, so you don’t have 2 separate projects to maintain.

This is really going to depend on the type of game you’re creating, how you want users to interact with your level editor, how you want to load files, how everything fits into your head as a programmer, etc. There isn’t a single one-size-fits-all solution, so there isn’t a great answer for you. It’s like if an artist asked “how should I paint this picture?” There are just too many possible answers, and the whole point of painting is that it’s up to the artist.

I will say that saving your own file type is trivial. Just output Strings to a text file the same way you would any other text file, and give it whatever file extension you want. Then read in those Strings the same way you would any other text file.

Another approach might be to look into serialization.

Hm, Interesting. Like I said I have no idea on how to read and output to a file so i’ll have to research that extensively. Another question I have is, is it possible to have the level editor output from a file but also have many of the game parts to be serializable for easy game saving? Or is there a better option for saving game data?

That’s step one. Googling “java output text file” or “java read Strings from file” return a ton of results.

[quote=“MrPork,post:4,topic:54043”]
Is it possible? Sure. Better? That part really depends on your preferences more than anything.

Saving stuff as text files has the benefit of being human-readable, so you could “hack” the file just by opening it in a text editor and changing the values. That makes debugging easier. Saving things as serialized Objects makes it easier to read/write more complicated Objects, but it requires that everything in the Object tree also be serializable, which isn’t always an option. You also have to be careful with different versions of serialized objects- old serialized files won’t work if you update the class- although you’ll have a similar issue with backwards compatibility with the text files as well.

As always, the best thing to do is just dive in. Maybe start by creating small example projects- one that tests out writing to and reading from text files, and one that tests out serialization. See which one works better for you.

I found that Databases provide an organized way to save game data. Would that be a viable option for a small game or should I just stick to text files? I just want something that a player could not easily break or cheat by changing its text.

Well, like I said: most of this depends more on your personal preferences than anything. I would maybe argue that if you don’t know how to write files yet, then it might be a good idea to start with something simpler first- walk before you run and all that.

But there are plenty of ways to use a database in Java- you run SQL calls directly, or you can hide behind something like Hibernate. Some people would use a database right away, other people hate database programming. So it’s really up to you.

I will say that nothing on the client side is 100% “secure” from tampering by a player. A player could even decompile your code and modify it. So I’m not sure you should waste a ton of time worrying about that aspect of things.

The concept of using a premade “level” editor like the TilED editor is really alien to me because you never have the flexibility and its hard to combine it with your specific game / engine.

I should probably make a full thread showing my map editors and their features at some point.
When your map has interesting stuff like event and story flags, npcs, shops, savepoints, items, tiles that simply behave differently fall or break or animate, enemy placement and AI, placing lights and hitboxes

in short, I have no idea how anyone builds a sophisticated game just using TilED and not making their own tool.

Organize your gamestate in some kind of model with your dynamic runtime specific objects like renderers and such as transient fields where needed and use xstream to load and store this model as json or xml. This is simple to set up and quite powerful. If you really need to hide the savegames from your users, you can wrap the in and outputstreams in some kind of obfuscator or encryption later. Trust me, you’ll want to have human readable savegames during development.

I don't really understand that either  ;D ! Making your own seems so much flexible to me such as having a trigger event area that can have different options like wether to do something after a sound has finished or after a few seconds. I would love to be implement things like this :D

I’m currently in the process of making my own level editor (albeit for a totally different sort of game), and I must say that you should try avoid doing this.
The problem is that every time you want to change one thing in your code, you have to change it in both your game and level editor, you have to add GUI functionality in your editor to support this new feature, and you have to write a converter to convert all the levels you’ve already made into the new format.
It’s waay too much hassle, I would not recommend getting involving with such a task. It’d be easier to use something like Tiled and just make some hacky things with it (like have an overlayed invisible tile that acts as a trigger).

NegativeZero: You could put common code in its own jar and then use that with the two applications, only tweaking one project :slight_smile: The converter is also not really too much of a hassle, just have a reader class and writer class for both formats, with a common object, and then just read from one format and write to another (of course the readers and writers may need minor tweaks for conversions, but the general concept is there). Still a much cleaner solution (in my personal opinion) than making hacky things in Tiled.

Don’t even use separate jars, just have all the code in the same place, with the editor classes removed by a build script. Run the editor from the IDE. All code modifications are now simultaneous in game and editor, as they are the same codebase. Could also technically automate the level-reformatter in the script as well, but that’s approaching or past the ‘not worthwhile’ threshold.

I can absolutely see where you are coming from, but I have been using Kryo even for development. But I made it so that missing fields are ignored so it doesnt break the savegames

@ Editor and game in one, common code, dont separate otherwise you have to change things in 2 places… Well
I will comment on that when making my own thread I guess but all in all I can say that this is always something you TRY to do but most of the times fail so you have to compromise. Fact of the matter is the editor simply doesnt operate the same as the game in many cases, especially depending how your tile engine and all that stuff works