onpon
|
|
Posted on: September 12, 2014, 04:08:16 pm |
|
|
Joined: Feb 2010
Posts: 102
|
I recently released a library called "ulvl", which defines some generic level formats that games can use: https://gitorious.org/ulvlThe idea is, rather than level editors being directly tied to a particular game (as is the case for most level editors) or engine (as is the case for LateralGM's room editor), any game can read the format, and then game developers using any engine or graphics library can just get on with making their levels without having to make a level editor first. I'm writing a generic level editor from scratch in Python, but thinking about it, LateralGM's room editor can fit the bill perfectly. Rooms could be saved as JSL (JavaScript Level) files very simply: - Each LateralGM instance in the room can be a level object in the JSL file. - The JSL file objects' IDs can be the "object" name in LateralGM. - The JSL file objects' "option" values can be set to the LateralGM instances' creation code. - The LateralGM room width and height can be assigned to a 2-value array "size" meta variable in the JSL file. - Other room properties can optionally be assigned to arbitrary meta variables in the JSL file. - The room creation code could be repurposed as a way to define other meta variables. Alternatively, another format (maybe one based on XML?) could be added to ulvl, and then that could be supported by LateralGM. Would anyone be interested in adding this option to LateralGM (to save and load at least one of the ulvl level formats)? I could probably do it myself, but I am very inexperienced with Java. It would be too big of a project for me. Someone familiar with Java could probably do this much more easily. However, I would be glad to define another format (e.g. one based on XML) if it's helpful. By the way, I'd prefer this to be in the main distribution of LGM, not in a separate fork, if possible. Done correctly, this feature wouldn't interfere with LGM's usual work. It would just be two additional buttons and/or two additional menu entries.
|
|
|
Logged
|
|
|
|
edsquare
|
|
Reply #1 Posted on: September 12, 2014, 06:55:53 pm |
|
|
Location: The throne of ringworld Joined: Apr 2014
Posts: 402
|
Why not add it to the Qt-Python IDE?
|
|
|
Logged
|
A child of five would understand this. Send someone to fetch a child of five. Groucho Marx
|
|
|
|
edsquare
|
|
Reply #3 Posted on: September 12, 2014, 07:47:15 pm |
|
|
Location: The throne of ringworld Joined: Apr 2014
Posts: 402
|
Oh, there's a Python one? I should do that, then! Where's it at?
Still, LateralGM supporting it would be nice.
The Full array of ENIGMA IDEs is here : http://enigma-dev.org/forums/index.php?topic=1476.0Yes it would be great to have it in the main IDE but this way you can iron out any bugs that may intrude while integrating library to ide and then maybe someone will have done the same with LGM. I'm interested in an alternate ide since I dislike java for some stuff and Python is easier to learn so maybe you could improve that ide since it's been left behind by LGM after the flurry of new functions and improvments of the last few months.
|
|
|
Logged
|
A child of five would understand this. Send someone to fetch a child of five. Groucho Marx
|
|
|
Goombert
|
|
Reply #4 Posted on: September 12, 2014, 09:46:39 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
In the future extending LateralGM will be much more simple, to the point of being able to plop JavaScript extensions right from the preferences panel and create your own editors, this will require Java 8's Project Nashorn but is an ultimate goal of mine.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
edsquare
|
|
Reply #6 Posted on: September 14, 2014, 02:56:54 pm |
|
|
Location: The throne of ringworld Joined: Apr 2014
Posts: 402
|
Well, damn, I won't easily be able to run that Python one until I upgrade to Trisquel 7, so I'll have to hold off on adding the feature to that until then. (I could edit it without testing it, but especially considering my lack of familiarity with Qt, that seems likely to produce buggy results.)
You could try with a liveusb with persistence, just saying
|
|
|
Logged
|
A child of five would understand this. Send someone to fetch a child of five. Groucho Marx
|
|
|
onpon
|
|
Reply #7 Posted on: September 18, 2014, 09:31:40 am |
|
|
Joined: Feb 2010
Posts: 102
|
You could try with a liveusb with persistence, just saying
Yeah, I could, but it would be a lot less convenient (especially with my slow Internet connection, having to download an image several hundred megabytes in size), it's not urgent, and it's not as if there aren't other projects I can work on, anyway. Side note: I added an XML-based format to ulvl ( ULX), so that might be useful for adding support for this in the non-Python editors.
|
|
|
Logged
|
|
|
|
IsmAvatar
|
|
Reply #8 Posted on: October 01, 2014, 03:08:28 pm |
|
|
LateralGM Developer
Location: Pennsylvania/USA Joined: Apr 2008
Posts: 877
|
Project Lead of LGM here (in case you didn't know me). A universal level format is a neat idea, and implementing the json version should be pretty easy. My main concern is what exactly that buys us. Does anybody else use this format? If not, what purpose do we have for adding additional code to LateralGM to support a format that benefits nothing and nobody else is using? We already have EGM, which mandates that all non-binary resources (such as rooms) be in a text-friendly format (currently I believe Josh is doing work in rewriting that, as we didn't actually honor that mandate before, and improvements - to keep the story short), so it certainly doesn't buy us that - it just adds one more format we now have to support.
That said, if you have a working room editor that uses the format, this format would buy us access to an external alternative room editor for LGM. I can see value in that, and we should be able to find some way to accommodate your format and editor.
|
|
|
Logged
|
|
|
|
|
IsmAvatar
|
|
Reply #10 Posted on: October 01, 2014, 04:18:13 pm |
|
|
LateralGM Developer
Location: Pennsylvania/USA Joined: Apr 2008
Posts: 877
|
We never had a good format definition for rooms that an external editor could use and hook into. Scripts are easy - export the code to a file, and launch the editor. Sprites are similarly fairly easy - just export the sprite to some sort of compatible image format, such as apng, and launch the editor. The difficulty for rooms is that they have dependent data. Objects populate the rooms, and objects are represented by sprites. What about backgrounds and tiles - will the room editor support those, and if so, we now have dependencies on backgrounds too. To export all the dependent information - sprites, backgrounds, objects, and rooms - at this point you're exporting most of the meat and bones of the game file - might as well just export the whole file in some sort of easy format and pass it to the room editor. EGM comes to mind.
|
|
|
Logged
|
|
|
|
|
onpon
|
|
Reply #12 Posted on: October 01, 2014, 04:52:23 pm |
|
|
Joined: Feb 2010
Posts: 102
|
My main concern is what exactly that buys us. Does anybody else use this format? If not, what purpose do we have for adding additional code to LateralGM to support a format that benefits nothing and nobody else is using?
I'll be blunt: it's not likely going to benefit ENIGMA or LateralGM in any way, unless perhaps you add ulvl functions to ENIGMA and support loading rooms as external files. (Maybe that would be useful for some cases; I don't know.) I designed the format so the same level editor could be used for multiple game engines. In particular, the format is meant to benefit the SGE Game Engine, and might in the process have the potential to benefit other 2-D game engines that don't have dedicated room editors or level editors. Basically, I'm trying to take the idea of Flexlay and generalize and simplify it further. That said, if you have a working room editor that uses the format, this format would buy us access to an external alternative room editor for LGM. I can see value in that, and we should be able to find some way to accommodate your format and editor.
That might be a potential point of benefit. I doubt it, though. The editor I'm working on probably isn't going to be any more advanced than the LateralGM one (actually, I think it will be far less advanced), and it obviously won't automatically sync with an ENIGMA file's object database. The difficulty for rooms is that they have dependent data. Objects populate the rooms, and objects are represented by sprites. What about backgrounds and tiles - will the room editor support those, and if so, we now have dependencies on backgrounds too. To export all the dependent information - sprites, backgrounds, objects, and rooms - at this point you're exporting most of the meat and bones of the game file - might as well just export the whole file in some sort of easy format and pass it to the room editor.
Right. The solution I've come up with is to simply not address these things; their definition is left to the game engine and level editor, perhaps with the help of some meta-data in the level files. JSL and ULX files are not meant to be standalone by any means. They are meant to allow both a level editor and an unrelated game engine read the same file. (ASCL is meant for a similar purpose, but where the "level editor" is a standard text editor.) An example of how I would use LateralGM along with exportation of JSL and ULX files might be this: first, I write a game with the SGE, defining all the images, origins, and behaviors. Then, in LateralGM, I create much simpler object definitions that only include image and origin information (and I save this as an EGM file, so that I can come back to it later). Finally, I use the LateralGM room editor to position all the objects, and I export a JSL or ULX file. My game can now easily read these files. In theory, if there were other useful ulvl-compatible level editors, LateralGM would be able to offload level editing to them, with approximately the same type of process I would like to be able to follow with the SGE and LateralGM.
|
|
« Last Edit: October 01, 2014, 05:12:04 pm by onpon »
|
Logged
|
|
|
|
|
|