Sign in to follow this  

Creating a map editor (tiles, objects, triggers, etc)

This topic is 4832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi! I was working under editor for a mobile top-view shooter for a 6 months, and it was my first "big" project. It was able to set triggers, objects, put tiles and had an inner monster editor. After this editor, i created a tileset editor (to define "windows" of tiles into the tileset), and other tools. Now, we decided to create editor2. The first idea was to create a cool plugin system, it will cost a lot of coding time, but we could just add a new DLL file into the editor to implement a monster editor. - this could take a lot of time, but if we will make another styled game, it will be easy to change editor (really?). The second idea is to make the only plugin like "render.dll" and use it in other editors. What way should i choose? The project is not too big. I don't think that it is possible to create a plugin-like system to create editor, that will be not hard to re-code top-view editor to side-scrolling.

Share this post


Link to post
Share on other sites
Is there something wrong with just adding on more features when you need them, then making a new build of the editor? If it's only you using it, then it shouldn't be that much of a problem: I'd only use plug-ins if you're going to distribute it to a lot of people before everything is done.


Mushu - trying to help those he doesn't know, with things he doesn't know.
Why won't he just go away? An question the universe may never have an answer to...

Share this post


Link to post
Share on other sites
You should keep adding features to the editor you have. When you add a feature, and you realize that there's a better way of structuring things once the feature is in, you stop adding new features and re-arrange the code to better suit what it's doing.

Stopping and re-factoring at points where the editor works well with the features it has is the right thing to do, because you will notice if you break it. If you re-factor in the middle, it's hard to know whether a problem is because of re-factoring, or because of feature bugs. Also, unit tests will tell you whether you broke some fundamental building block.

If you haven't cleaned up and re-factored after each new feature until now, you will notice that you have a large debt of factoring. If you haven't been writing unit tests for your code until now, then you will notice that you have a large deficiency. To overcome this, it's important that you don't do everything at once. Instead, incrementally make it better. Add a new feature. Make sure you add a unit test for that feature. Make sure you add a unit test for some sub-component used by that feature. Do a little bit of factoring, if there's some low-hanging fruit. Repeat.

In the end, you end up with a living, breathing, STRONG code base. Building strength takes time, persistence and patience, which is in pretty short supply in the world -- that's how you can distinguish yourself :-)

Once you have a factored code base, you'll note that you probably have some interface to each tool, and some set of interfaces to editor internals (world state, UI, etc). At that point, you can wrap the internal systems into a single master interface (big struct, or whatever), and separate out all your tools into their own source files, and configure the tools with the master interface struct. At that point, breaking tools into separate DLLs should be trivial. Similarly, when the systems are separated out, they will form logical components, which you can move into DLLs should you wish to. But don't do it until there's an actual need -- if you don't already have a need for a specific feature, don't write it, because You Ain't Gonna Need It.

Share this post


Link to post
Share on other sites
Having worked on several projects myself, I think you'll find the need to reprogram the editor (or make quite a lot of changes) for future games. Keeping with one editor and making new plug-ins will probably not be enough unless you know you'll be making very similar games in future. You really have to plan for features you've not thought of! My advice is make one editor for your current game and make the program easy to modify in future instead of using plug-ins.

Mark
Bytten Independent Games Magazine
http://www.bytten.com

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
2hplus0603

>You should keep adding features to the editor you have

I have to write a new editor from ground zero, because the first editor is too slow in rendering, and it's "bad-coded".

I think that the best way is to split only rendering system and maybe the map format.

Is it a good idea - if i want to split, for example, a render system, i first code it inside my editor code, and after that i split it into the DLL.

Share this post


Link to post
Share on other sites

This topic is 4832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this