gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Announcements And Comments > Generic Game/Map Editor

#152890 - rodif - Sat Mar 22, 2008 6:12 am

Hey all,

It has been a long time since my last update. Here was the first post, I'm starting a new one because that one had gotten off topic.

http://forum.gbadev.org/viewtopic.php?t=12070&highlight=

So basically what I'm working on is a game designer that will allow you to define most of the meta data that goes into your games. This product is a cross between a tile map editor (mappy) and a full game maker (rpg maker). There are a lot of features that will be built in to this editor (tile boards, maps, sounds, paths, regions, triggers). Each editor will have customizable meta data and customizable runtime features associated with it so you can customize the editor to fit your game. It will also expose a api so you can write your own modules if one of the builtin ones doesn't suit your needs.

This editor will never be a game creator studio; you will need to write your game engine from scratch. This tool is designed for developers who have or are going to develop their own game engine. To access your data you will have a few choices:
1) write export scripts - currently these scripts can be implemnted in a java scripting language named groovy, but i will support more java based scripting languages... and batch (shell execute) type builds.
2) along with export scripts groovy has a simple template syntax that you could use to generate text files
3) write a java plugin to access the data directly
4) xml, as i mentioned in my previous post, the save files are stored in xml. Although the save files are xml they are not easy to parse, the editor uses a java serialization library called xstream. There would be nothing to stop you from reading the xml directly, but there would be no direct support for it. I'm currently tossing around the idea to break down and write custom xml serialization, but even then the storage structures will be pretty generic and would be hard to re-implement the parsing logic to pull out the data.

Along with the export scripts, i will be supplying some api's to get the data out in common ways. Convert input images to gba images, creating a new image from all of the used tiles on a board or generate new tiles based on 2 tiles overlayed on top of each other.

There is still a lot of work to be done especially on the api/export side. I don't know exactly how I'm going to handle the release of this product yet. Most likely it will be free (or cheap) for homebrew and some fee for commercial offerings.

I am working with a small game developer building out a PC game (although it will cross compile with gba and ds eventually). So all of the art you see is from that project. Anyways, here is the preview:

http://www.stormweavers.com/tgb/movies/simple-demo.html

Let me know what you think.

-rodif

#153783 - sgeos - Sun Apr 06, 2008 7:21 am

From a technical perspective, RPG Maker is evil in that it is:
A) Hard to work with (potentially preexisting) external data
B) Hard to work with a team of developers
C) Uses embedded strings by default (i.e. hard to localize content)
Given what RPG Maker is designed to do (capitalize on people who want to make RPGs), none of these are a problem for Enterbrain.

It does not sound like you are on the wrong path, but I certainly hope editor does not share the "features" listed above. I did notice what appeared to embedded string use in your movie, although it looks like a message ID or even a script could be typed in, so that does not look like anything major. If all of the messages can be dumped as a table, there is not a problem, in any case.

For what it's worth, I'll review your product in exchange for a free copy if you are interested. =)

-Brendan

#153848 - rodif - Mon Apr 07, 2008 5:16 am

Thanks for the feedback,


A) I started working on tools that allow you to import a map based on a rendered version. They kinda worked but they were going to need a lot more features if they were going to be functional for a real import. But, I cant see any specific reason that this couldn't be used with an existing project.

B) Currently most things are stored in separate files, this should allow multiple developers to work concurrently. With minimal communication you shouldn't step on toes too much. I do plan on tackling a real multiple users solution sometime. (locking, svn, chat?... i don't know what features will be included)

C) all of the strings, types, properties (basically all metadata) that you see in the editor are controlled by either the config file for the project or were actually typed in the editor. There will be no strings or properties that you will inherit. I do think it would be helpful to implement a strings table module to help with localization.


I do plan on working with a couple projects to get feedback and ideas for new features after i get done with the current one I'm doing. Offering support and development for new features (given some level of commitment and quality of the existing project).

Do you have a specific project that you would be interested in using it for?

-brad

#153852 - sgeos - Mon Apr 07, 2008 7:12 am

rodif wrote:
A) I started working on tools that allow you to import a map based on a rendered version.

I guess when I was griping about A, I meant complain that it is hard to export data in way that is useful to other projects. Either way, migrating both to and from a tool are somewhat related, and any top quality tool will make things easy in both cases. Afterall, sometimes you need or want to go over same data with multiple tools. (Photoshop + GIMP, etc.)

Seeing as most everything probably gets exported to data tables eventually, being able to import/export table would fantasic. Even if the tool can't know enough to do this automatically, it should not get in the way. Some sort of custom IO module system would be wonderful.

rodif wrote:
B) Currently most things are stored in separate files, this should allow multiple developers to work concurrently.

Excellent. So I imagine I could have 5 people making maps at the same time if need be? (Assuming all the other resources are through the development pipeline.)

rodif wrote:
I do plan on tackling a real multiple users solution sometime. (locking, svn, chat?... i don't know what features will be included)

That could be nifty. Is there any reason why standard version control systems can not be used with the editor as is?

rodif wrote:
C) all of the strings, types, properties (basically all metadata) that you see in the editor are controlled by either the config file for the project or were actually typed in the editor.

That sounds interesting.

rodif wrote:
I do think it would be helpful to implement a strings table module to help with localization.

At this point are any strings attached to game objects? I could attaching both strings and scripts to game objects, including maps and spawned objects.

rodif wrote:
I do plan on working with a couple projects to get feedback and ideas for new features after i get done with the current one I'm doing.

What is your timeline looking like?

rodif wrote:
Do you have a specific project that you would be interested in using it for?

The offer stands to review your product and tell you what I think of it, both good and bad. I am in planning phases of a project, although the platform has basically been chosen. If the editor looks like it can do what I will need it to do, I'll probably use it for a future project.

-Brendan

#154114 - rodif - Fri Apr 11, 2008 8:33 am

again, thanks for the feedback.

Quote:
I meant complain that it is hard to export data in way that is useful to other projects.


ahh, yes in my first post i mentioned the different ways to access the data. The whole design is to allow programmer access to all of the data in the editor.

Quote:
Excellent. So I imagine I could have 5 people making maps at the same time if need be? (Assuming all the other resources are through the development pipeline.)


yup.

Quote:
That could be nifty. Is there any reason why standard version control systems can not be used with the editor as is?


no reason at all. we are using svn in the project I'm working on atm so any potential issue will probably would be flushed out if we find one.


Quote:
What is your time line looking like?

Probably another few months, we can move this conversation off the forum to setup some dates.


Quote:
The offer stands to review your product and tell you what I think of it, both good and bad. I am in planning phases of a project, although the platform has basically been chosen. If the editor looks like it can do what I will need it to do, I'll probably use it for a future project.


sounds good, we'll chat offline on specifics.

#154155 - sgeos - Sat Apr 12, 2008 12:52 am

rodif wrote:
sounds good, we'll chat offline on specifics.

Either send a PM, or an email to sgeos (splat) hotmail {cot} com.

-Brendan