Hey Guys,
i am currently trying to implement a level editor into my little 2d sidescrolling jump n run.
I got it working since yesterday, but i dont know how i should save the levels.
What the level editor is doing:
i draw rectangles with my mouse ingame and those ectangles are getting saved in an rectangle-arraylist.
How can i save that Rectangle arraylist in an txt document or something so i can reload my levels?
thx 4 ur help
moep
The easiest way is to use java serialization
OK thank you i will look into that tomorrow.
Another question:
how can you “blockify” ur world?
I mean games like minecraft or terraria have everything seperated into blocks.
I think handling everything in blocks is making some stuff easier.
How can i achieve that?
Greetings moep.
Yeah, serialization is the best way.
Any objects of classes that you make that need to be saved should implement the Serializable interface. This marks the class so Java knows that objects of that class might need to have a “snapshot” taken and tucked away in an encrypted file. What I mean by that is that it will save the state of the object, so it remembers what values your variables were set to.
You don’t need to override any methods for the Serializable interface. It’s just a flag for Java. Any objects that are inside Serializable objects also need to be marked. If you look at the javadocs, most classes implement Serializable.
Let me know if you need an example of saving/loading these files.
“Blocks” are good and common ways to do platformers.
Try making a Block class that has an Image and a size in it. Then, your levels can be a 2D array of Block objects! Experiment with that, see how you like it.
ah ok that sounds nice.
I will try serialization and that block thingy tomorrow or the day after tomorrow and give feedback then.
You can post an example of saving/loading if you want to, but as i said i cant test the next 2 days.
Thanks for your help =)
Greetings moep.
The block thingy is called Tile based games.
Ok thank you^^
Im sry this is my first game and im programming it since about 2 weeks so im not that experienced yet =)
For tile based games, take a look at Tiled: http://www.mapeditor.org/. It’s written in C++, but has a java library included to load the created maps.
Terraria has basically made a huge grid. Each “block” in the grit has a id (e.g. stone,silver etc. or maybe numbers like 02,05).
The game then starts to render the gameblocks according to the grid. The player in Terraria moves freely, and only interacts with the blocks on the grid, not the grid itself.
Sorry to bump.
I’m working on a slightly more advanced level editor for an action RPG. Serialization works fine if you only have one type of object or world element. What happens when you want to introduce different types of terrain objects, objects that you can interact with, fixed-location enemies, and pickups, all with various fields, into your level file?
Serialization seems a bit crazy at this point because all of those different types of game objects come with their own set of fields that we want to define in the editor (initial stats for a fixed position enemy for example). Additionally “Event-type objects” like switches or buttons, which need to be placed and scripted in this editor, are a lot more complex than simply storing a bunch of tile data for blocks.
EDIT: If anyone is still reading this thread, I’ll give a bit of an update on how we are attacking the problem.
Essentially the types of objects we can add to the game are constructed with primitives or things derived from primitives (A string tells our texture loader what image the entity should have, for example). If we know everything that goes into constructing our object, and those things are primitive, we can (safely?) serialize them without fear of locking ourselves into a certain class architecture. We simply write out a collection of “things” we need to rebuild the object in order, and have static builder methods for the few types of things we need to build that know what order to expect the serialized data to be in. Not much different from serialization, but instead of a new version of the class that requires new fields to be imported completely breaking our system, we just output an extra field when we save the object data, and provide a default if the “builder” method is loading an older version for which that field was NYI.