#114019 - rodif - Tue Jan 02, 2007 9:58 pm
Hey,
So I've been working on a 2d tile level editor for my rpg gba game. I'm trying to make it generic enough to be used in more than one type of game. The editor isn't a full 'game maker' where you define the full game inside the editor and launch a embeded engine. Basically it just lets you define boards/tilesets/items export them for what ever engine you want. Basically its a mix between and IDE and a paint program. I plan on creating a plugin api to allow developers to write plugins for their specific engine.
I am intrested in working with someone who has a 'good' game that needs a level editor. I would be willing to change my product to intergrate with their workflow. It would benifit us both.
Some screenshots can be found here:
http://www.stormweavers.com/me/tgb.php
PS.
I plan on integrating this product with a 3d level builder i worked on in the past for some DS projects I have in mind.
http://media.putfile.com/paco-test
Last edited by rodif on Tue Jan 02, 2007 11:37 pm; edited 1 time in total
#114020 - Peter - Tue Jan 02, 2007 11:26 pm
Hi,
I don't think the world needs another tile/map editor, but I know it needs a Level Editor!
I don't know of any free powerful level editor for tile based games. Most editors are map editors, which are not really helpful if you want to create a game, because a game has more elements than a scrolling background.
MapEd from Nessie is a nice map editor, it's very easy to use but still pretty feature rich. It just lacks of support to add custom entities / game-objects, but that's probably because it's called MapEd instead of LevelEd.
If your level-editor comes with the features found in MapEd and some from Mappy (e.g. tile-animations), plus support to place custom entities / game-objects, walk/control-paths etc in the level, it would be probably the most useful tool on the web. :)
#114021 - rodif - Tue Jan 02, 2007 11:36 pm
Exactly as you described this will be a level editor, not a map editor. Placement of 'items' and having user defined attributes for the items is one of the big reasons i started this.
#114022 - Peter - Tue Jan 02, 2007 11:41 pm
| rodif wrote: |
| Exactly as you described this will be a level editor, not a map editor. Placement of 'items' and having user defined attributes for the items is one of the big reasons i started this. |
Excellent! I don't have a game in development, but I can provide some feature suggestions if you need some.
#114033 - Ant6n - Wed Jan 03, 2007 1:43 am
I think this is cool.
What are your intended features?
How are your entity and map data structures set?
#114078 - rodif - Wed Jan 03, 2007 5:52 pm
Peter: cool, if you want send me a PM with you're email and we can talk about details and I can get you a demo so you can give me some feedback.
ant6n: I can put together a features document and a UML of the object model. I'm currently trying to get some features done on my GBA game so give me a couple weeks to get it together, ill post in this thread.
#114086 - gauauu - Wed Jan 03, 2007 8:41 pm
A simple suggestion, based on my good/bad experiences with tools:
If you make it use text files for it's data files (saving in-progress maps, etc), then it opens tons of flexibility for people who want to use it, but would need to adapt it to their game.
I've used so many level/map editors that save things in one format, and can export to text, which is just rather annoying -- I'd much rather have my in-progress files be text, which means I can write a script to edit tedious parts of my maps. I can check in the text files to version control, and be able to easily diff them by looking when I make changes. I can have my build system do the conversion from map-editor format to the format necessary by my game.
All of those things are difficult if things are saved in a binary format while being worked on.
Anyway, enough ranting. You get the idea. Text is everything.
#114087 - rodif - Wed Jan 03, 2007 8:58 pm
gauauu: Thanks for the suggestion, currently the files are stored as xml. I also hate dealing with binary so that also was a requirment of mine.
The save format will always be in xml, currently i am using a java serilization library http://xstream.codehaus.org/, to save my object model. It has served all of my needs so far but if it ever fails i'll just go to simple sax parsing. Since the format is generated by this library sometimes its hard to follow but i have on many occasions manual edited the xml and it works nice.
Along the same lines of source control and concurrent editing, i break my save files up into separate files, the idea being more than one artist can work on the game w/out having to worry about overwriting changes. Also at some point i thought it would be cool to intergrate some source control features into the IDE.
#114316 - Peter - Sat Jan 06, 2007 4:36 pm
| rodif wrote: |
| The save format will always be in xml, currently i am using a java serilization library http://xstream.codehaus.org/, to save my object model. |
Depending on how the data is structured into XML, it could be a lot slower than a binary loader. And once the level gets bigger, it's also tricky to navigate through the XML with a text-editor, so it has only little advantage over the binary format in sense of human readability. I think the primary format should be binary. If it can export XML too, fine.
| rodif wrote: |
| Along the same lines of source control and concurrent editing, i break my save files up into separate files, the idea being more than one artist can work on the game w/out having to worry about overwriting changes. |
I really doubt that more than one level designer will work on the same level for a 2d tile-based game. Having the level split into 10 different files, it makes it even harder to work with:
| Quote: |
Hey buddy can you check-in the .map and .object files?
Ermm, I just work on the .map, ask John for .object.
Where is he?
I guess he is at Claire's, because he needs the .tile file!
|
| rodif wrote: |
| Also at some point i thought it would be cool to intergrate some source control features into the IDE. |
This is something I would add to the very bottom of the TODO list.
Last edited by Peter on Sat Jan 06, 2007 8:01 pm; edited 1 time in total
#114333 - gauauu - Sat Jan 06, 2007 7:34 pm
| Peter wrote: |
| And once the level gets bigger, it's also tricky to navigate through the XML with a text-editor, so it has only little advantage over the binary format in sense of human readability. I think the primary format should be binary. If it can export as XML too, fine. |
But the real gain is the ability to use something like perl to easily make batch modifications to all your level files.
#114615 - sgeos - Tue Jan 09, 2007 3:58 pm
An XML level editor? Sweet. I've wanted one for a long time. How are you handling in game objects and whatnot?
I did some thinking about this and, although this may be goofy, I came up with a file format that looks something like this (from memory):
| Code: |
Map
Header
Name
Dimensions
Palette File
etc...
Body
Layer Set
Layer
Layer Head
Dimensions
Parallax
...
Layer Body
Cell (2d array)
...
Object Set
Object Set Head
Object Count
...
Object Set Body
Object (list of objects)
... |
| Peter wrote: |
| Depending on how the data is structured into XML, it could be a lot slower than a binary loader. |
Games are made on PCs. I can't imagine slowdown being a problem for a level loading routine, even if it uses bloated XML. It's not like you need to load all of your stages at once.
| Peter wrote: |
| And once the level gets bigger, it's also tricky to navigate through the XML with a text-editor, so it has only little advantage over the binary format in sense of human readability. |
Use XML Path to navigate the file unless you are on a loan system with no software.
| Peter wrote: |
| I think the primary format should be binary. If it can export XML too, fine. |
The ROM data should be binary. It's 2007. XML is a Good Thing.
-Brendan
#114616 - tepples - Tue Jan 09, 2007 4:00 pm
Why aren't PNG files in XML?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#114618 - sgeos - Tue Jan 09, 2007 4:05 pm
| tepples wrote: |
| Why aren't PNG files in XML? |
Because they are network graphics, and network graphics need to be compact.
-Brendan
#114619 - keldon - Tue Jan 09, 2007 4:09 pm
SVG files are in xml.
#114625 - sgeos - Tue Jan 09, 2007 4:34 pm
I think SVG is my new favorite graphics format. =) Evidently SVG 1.2 even supports masking.
-Brendan
#114661 - Peter - Tue Jan 09, 2007 10:33 pm
| sgeos wrote: |
| Peter wrote: | | Depending on how the data is structured into XML, it could be a lot slower than a binary loader. |
Games are made on PCs. I can't imagine slowdown being a problem for a level loading routine, even if it uses bloated XML. It's not like you need to load all of your stages at once. |
Well, I've seen an implementation where each cell was stored as seperate node. It took about 45 seconds to load a map (1000x30 tiles or so) on a 1.8ghz computer. Obviously this is inacceptable, so I wanted to bring this up.
#114666 - rodif - Tue Jan 09, 2007 11:18 pm
| Quote: |
| And once the level gets bigger, it's also tricky to navigate through the XML with a text-editor, so it has only little advantage over the binary format in sense of human readability. I think the primary format should be binary. If it can export XML too, fine. |
Then you use editors that dont load the whole file, vi for instance, i even think notepad doesnt load up the whole document if it is too big.
| Quote: |
| Quote: | rodif wrote:
Along the same lines of source control and concurrent editing, i break my save files up into separate files, the idea being more than one artist can work on the game w/out having to worry about overwriting changes. |
I really doubt that more than one level designer will work on the same level for a 2d tile-based game. Having the level split into 10 different files, it makes it even harder to work with: |
Exactly, currently each level is in a different file which lives inside of a project. The project will have multiple levels, tilesets and metatdata for the game as a whole.
| Quote: |
I did some thinking about this and, although this may be goofy, I came up with a file format that looks something like this (from memory):
|
Currently the xml file will be the default output from the xstream library, it serves as a simple way to do my save/load. I might change the xml serialization in the future.
If you want to process the data manually, you will be able to export the data by traversing the Java Object Model and spit out any text/binary you want. Which will be exposed thru a plugin or by a simple template system using a scripting language. These will be able to be invoked from a commandline.
| Quote: |
| Games are made on PCs. I can't imagine slowdown being a problem for a level loading routine, even if it uses bloated XML. It's not like you need to load all of your stages at once. |
This is exactly my argument.
| Quote: |
| Well, I've seen an implementation where each cell was stored as seperate node. It took about 45 seconds to load a map (1000x30 tiles or so) on a 1.8ghz computer. Obviously this is inacceptable, so I wanted to bring this up. |
This seems more of an issue with poor code than xml parsing. Even if you had 30k tiles, using an xml library to parse 30k nodes shouldn't take 45 seconds. Basically i'm not too concenred with load time right now but if it becomes a serious problem then i'll adress it. It is not as if you are loading over and over again.
#114672 - keldon - Tue Jan 09, 2007 11:47 pm
One issue with saving files to any type of project that makes use of other files is when you have to keep track of what is used in your project.
Sometimes it is useful to be able to save your entire project with your entire 'pool'(or selected items from it) in one single file. Saving into a file with its own file system (that can include the xml file) might be useful; or like jar files an archive.
#114708 - sgeos - Wed Jan 10, 2007 7:10 am
| Peter wrote: |
| Well, I've seen an implementation where each cell was stored as seperate node. It took about 45 seconds to load a map (1000x30 tiles or so) on a 1.8ghz computer. Obviously this is inacceptable, so I wanted to bring this up. |
This could be anything. Was it swapping out to virtual memory? How was it loading the stage?
At any rate, if you want something with a binary save format, why not use any of the good map editors that already exist? The world doesn't need another map editor with yet another proprietary binary format (most likely poorly documented).
XML is implicitly portable, not that I expect the level designers to work on different OSs, although I could see the *files* used on different OSs once you start batch processing them.
| rodif wrote: |
| Currently the xml file will be the default output from the xstream library, it serves as a simple way to do my save/load. |
That is fair. Do what you need to do.
| rodif wrote: |
| I might change the xml serialization in the future. |
A well thought out structure will probably be better than whatever the xstream default is. This isn't the most important feature. If it's XML, it can be worked with. It can even be converted into different (XML) documents with [url="http://www.w3.org/TR/xslt"]XSLT[/url]. I think an XML based level editor is very exciting. (poweruplist.xsl =)
| rodif wrote: |
| ]Exactly, currently each level is in a different file which lives inside of a project. The project will have multiple levels, tilesets and metatdata for the game as a whole. |
Fantastic. Is all of this documented?
| Code: |
| Sometimes it is useful to be able to save your entire project with your entire 'pool'(or selected items from it) in one single file. |
make zip (not that that would really help, but... =)
It's not high on my priority list. I'd rather see "real" level creation featurs.
-Brendan
#116433 - cosmic4z - Thu Jan 25, 2007 6:45 pm
#116457 - gauauu - Thu Jan 25, 2007 10:56 pm
| cosmic4z wrote: |
| Any feedback on Level Mapper? |
I couldn't handle it. Development tools (which include map makers) shouldn't, in my opinion, ever have to run fullscreen....I want my map maker to be a standard windowed gui app, with standard menus/etc. The learning curve of a new style of interface, combined with with the hassles of going fullscreen, make it entirely unworth it for me.
Is unworth a word?
#116471 - tepples - Fri Jan 26, 2007 1:13 am
| gauauu wrote: |
| cosmic4z wrote: | | Any feedback on Level Mapper? |
I couldn't handle it. Development tools (which include map makers) shouldn't, in my opinion, ever have to run fullscreen |
Even if your screen is 640x480 pixels? What about 256x192 pixels, that is, development tools that run directly on the target hardware?
| Quote: |
| ....I want my map maker to be a standard windowed gui app, with standard menus/etc. |
Which take up how much of the screen? Not everybody has a 2 megapixel (1920x1080 or 1600x1200) monster.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#116481 - HyperHacker - Fri Jan 26, 2007 5:13 am
I imagine his post assumes a decent resolution, e.g., at least 800x600. Having personally developed a level editor for a game, I know that by simply implementing zooming and scrolling well, you can use it at just about any screen size. Maybe for 640x480 you'd need to start zooming out to like 50% and hacking away status bars and menus to fit it all on, but I think pretty much every PC now runs at least 800x600, and the DS's lack of any sort of OS would likely mean rewriting most of your GUI anyway.
(FYI, I realize the editor shown there is not friendly to small resolutions, having the tile selector built in, no zoom option, and hacky scrollbars. This is a really old version and the next fixes all of these issues; it can be trimmed to as little as a map, title bar, menu bar, and status bar, and I'll probably add options to disable the status and possibly menu bars in the future.)
Somewhat off topic, just how common are editors running on the target system? The DS and Wii would be decent for this since they have a nice pointing device input system, but older consoles didn't. The only console game that I know used this was Zelda: OoT, in which the camera flybys when you first enter an area are defined using an in-game editor (debug version only :-(), and some debug text in Mario 64 hints at such a thing being used there, but that's it.
| gauauu wrote: |
| Is unworth a word? |
You might be thinking of worthless.
_________________
I'm a PSP hacker now, but I still <3 DS.
#116521 - gauauu - Fri Jan 26, 2007 3:36 pm
| tepples wrote: |
Even if your screen is 640x480 pixels? ....
Which take up how much of the screen? Not everybody has a 2 megapixel (1920x1080 or 1600x1200) monster. |
That's the point...I want the size of the editor to be adjustable, like every other normal window. If I have 640x480, I will maximize the window. If I do have a 1600x1200 monster (like I do), I don't want to waste all that space on my level editor. That's the beauty of normal windowed apps...the user has control. With a full screen app, it takes over all your real-estate whether you like it or not. I don't even mind the option of a level editor with the OPTION of running fullscreen. I just don't want it to HAVE to. Non-game apps running in fullscreen feels like the days of DOS 6.22.
I'm ignoring the case of running it on a different platform, but that's ok, we're talking about normal dev tools.
#116591 - tepples - Sat Jan 27, 2007 5:46 am
| gauauu wrote: |
| With a full screen app, it takes over all your real-estate whether you like it or not. I don't even mind the option of a level editor with the OPTION of running fullscreen. I just don't want it to HAVE to. |
If a program uses the Allegro library, changing its video mode it can be as easy as writing an allegro.cfg file. If I remember correctly, the syntax looks something like this:
| Code: |
[graphics]
gfx_card = GFX_DIRECTX_WIN
|
| Quote: |
| Non-game apps running in fullscreen feels like the days of DOS 6.22. |
Define game.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#116607 - sgeos - Sat Jan 27, 2007 8:10 am
| tepples wrote: |
| Define game. |
| http://dictionary.reference.com/browse/game wrote: |
| 3. a competitive activity involving skill, chance, or endurance on the part of two or more persons who play according to a set of rules, usually for their own amusement or for that of spectators. |
Of note is that in the case of computer games, the computer counts as at least one person in so far as this definition goes. Games can also be played for money, although perhaps that is a special case of amusement.
-Brendan
#116649 - gauauu - Sat Jan 27, 2007 10:40 pm
| tepples wrote: |
Define game. |
Are you serious, or are you trying to troll me? I think it should be obvious what I mean....you may disagree with me about my points, but the difference between a game and a tool used to make a game seem to be something that anyone with your technical and game-related knowledge would completely understand.
Anyway, sorry to hijack the thread.....
#116860 - cosmic4z - Tue Jan 30, 2007 11:37 am
So in summary ...
Most of you feel running a level editor tool, full-screen, using a custom GUI, isn't such a hot idea?
I'm guessing you're gonna say, just stick to a regular windows APP eh?
Custom GUI is a bad thing? (unless it's intuitive and looks like a regular windows APP).
#116864 - wintermute - Tue Jan 30, 2007 1:26 pm
Forcing a GUI application fullscreen is the bad part, we all have the ability to run more than one application at the same time these days. It's really annoying when one of them decides to behave like it has complete control of the system.
Have a look at MapEd ( http://nessie.gbadev.org/ ) There are fairly custom elements to it's GUI but it still behaves nicely and can be resized to use as much or as little screen real estate as the user desires.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#116872 - tepples - Tue Jan 30, 2007 4:35 pm
| cosmic4z wrote: |
Most of you feel running a level editor tool, full-screen, using a custom GUI, isn't such a hot idea?
I'm guessing you're gonna say, just stick to a regular windows APP eh? |
If using a game programming library makes scenes in the editor look more like scenes in the game, then use a game programming library. Just make sure it can run in windowed mode.
| Quote: |
| Custom GUI is a bad thing? (unless it's intuitive and looks like a regular windows APP). |
Custom GUI can run in a window. Even a game for Windows can run in a window.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#117478 - sgeos - Mon Feb 05, 2007 2:05 am
How is this cominig along? I don't suppose it supports line/circle based collision?
-Brendan
#122975 - cosmic4z - Sat Mar 24, 2007 2:14 am
| tepples wrote: |
| cosmic4z wrote: | Most of you feel running a level editor tool, full-screen, using a custom GUI, isn't such a hot idea?
I'm guessing you're gonna say, just stick to a regular windows APP eh? |
If using a game programming library makes scenes in the editor look more like scenes in the game, then use a game programming library. Just make sure it can run in windowed mode.
| Quote: | | Custom GUI is a bad thing? (unless it's intuitive and looks like a regular windows APP). |
Custom GUI can run in a window. Even a game for Windows can run in a window. |
Yep, I kinda got the feeling the 'forcing full-screen' wasn't being well recieved. To be honest, I only coded it that way because I don't know windows API stuff (plus, I figured it would run slow, with multiple alpha blended layers etc). Much easier to just take over all the screen and do with as you will, mwhaaa haaa.
#122983 - tepples - Sat Mar 24, 2007 3:10 am
The Allegro library lets a program pretend that it's taking over the full screen, even when it's just rendering to a 640x480 (etc.) pixel window.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#123003 - cosmic4z - Sat Mar 24, 2007 10:24 am
Sounds simular to PTK, you can code your app as if it's full screen and easily switch to windowed mode (and minimize etc). Only problem is that it would mean using non-standard (i.e. roll-your-own) buttons and menus for the GUI.