Tile Editor

I've got an idea that would really make this program a jump above the competetion.

A built in tile editor.

As it goes now with certain WYSIWYG game creation software (MMF cough) you have to write up your own tile editor just to make a decent looking game in a timely fashion.

How much better would it be if you could select a picture, determine the size of the grid to overlay on that picture, and draw tiles from the picture directly into the construct application itself.

This would make game construction quick and dirty, like it should be. Not to mention it would greatly improve this already beautiful application.

Tell me what you think.

I personally think it would be cool if there was a tile -object- to blit tile maps from an array and source bitmap onto the screen (and handle things like collisions and individual tile checking too), but integrated tile editor? nahhh <img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" />

The current editor should do a good job for those quick and dirty things, and there's a plethora of neat external tile editors you can use (and get to be the first to write a parser for their map formats) ;3

I have the same belief in the picture editor -- there's some nice external tools, Construct just needs to interoperate with them more streamlined and we're in business

If you think about the same thing as i'm thinking about, im thinking about that too!

I'm thinking about an object where you can draw sprites with diffrent images depending on if there are sprites around them. For example, ground sprites would get grass around the edges that are not surrounded by ground.

I think i suggested a "Level Editor" to construct too. Both construct and it's concurents are terible to use for level design, and an in built level editor, where you can ad the objects you want, and use diffrent tools like fill, pencil, or just klick out the objects would be wonderful.

Well, no offense, but I don't think there's a need to hard-code it into Construct. It's already possible without going in and making a whole new set of tools, so why put this feature in just to save some time? Personally, I've been working on such a system since the early start of Construct, but that doesn't mean I want it coded into Construct to make it easier. If there were a suite of tools added in, it might be useful, but in the same way it would probably be more restrictive than just doing it yourself. In the end anything with any real quality is always going to take quite a bit of time.

Anyways, that's just my opinion.

A tile editor doesn't have the same global use as other tools in Construct. Since many people are making non-tiled games, having a tile editor wouldn't be justified 100% of the time, especially considering the amount of work that would go into it.

I agree that a "Tile Blitter" object like the one nobuyuki described is a better idea, but there's just one problem... which tile map format would you choose to work with? As soon as you decide on this, you'd have people screaming at your for that or the other.

Currently in the klik community people who have need of tile editors write their own custom ones for their games. I suppose it would be possible to make a generic one that would work in conjunction with a Tile Blitter object, but it would take a lot of work to get enough features into it to satisfy people using it. Perhaps some enterprising samaritan would be interested in tackling that...?

Well, I don't think it would be a particularly difficult thing to hard code into construct. And if you don't want to use it, you don't have to. Just like grids and snap to.

But for those of us who need it, it would be nice. Otherwise you have to code a level editor, load up your tiles into arrays, and then populate the game with those tiles on load time.

Takes a heck of a lot of time just to do something that could be easily worked around with a simple addition of one tool.

What I like the sound of is different tools for duplicating objects. For example, a Brush duplicate when grid is turned on could allow you to 'pen in' tiles with a certain object, by dragging the mouse. If you went over an object already in that tile, it'd delete it (so it doesnt stack unnecessary tiles on top of each other), but you could turn that off for overlay tiles (treestumps on grass etc). Then we may as well throw in rubber-stamp duplication. I think these two ideas are general enough to apply to lots of types of games.

That's EXACTLY what I'm on about.

Sounds perfect. <img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" />

Flood fill would be nice too. Actually, the more tools the better, but Paint Brush and flood fill is probably the most needed. Being able to resize the brush would be nice too.

Flood fill would be nice too. Actually, the more tools the better, but Paint Brush and flood fill is probably the most needed. Being able to resize the brush would be nice too.

Are we still talking about a tile-editor interface? Because I was under the impression that it would simply be a "click in or drag across gridspace to place tiles" type of thing, so brush size wouldn't really matter...

Flood fill makes sense, though.

Flood fill is array paste, no?

Not necessarily... array paste needs info entered into a dialog. Flood fill would work on a single click. Also, array paste is limited to rectilinear areas. If implemented properly flood fill would fill an irregular area of grid spaces.

It might not be totally necessary to have a flood fill, but would be a little different.