Built-in Level Editor

Hi!

Wasn't there some talk a while ago about improving the level editing in construct? This would really take construct a step ahead of other game-making tools since right now everything is a hell to make levels with, and a hell to make level editors with.

I'm thinking about a "level edit-mode" or something. I'm sure people could come up with really good ways to handle tilesets, private variables (which would be good to have in the level edtor) and practical tools (like simply a way to pick a sprite and draw with it on a grid, or a flood fill).

Right now it's a hell to make levels.

(and making levels is a big part of most games. That results in "making most games with construct is a hell" and that's not good, since it limits the games that most people make to: Value('all games')-value('most games') and what's left isn't as many games as we would wish to have...)

I don't find it half bad. with snap to grid and control+drag it's actually pretty easy.

This would really take construct a step ahead of other game-making tools

I think it's already a few steps ahead.

snap to grid and ctrl+drag is in mmf too, so in this area it's not one step ahead, and this is an important area.

I gotta agree with Attan on this one. As far as "level editing" is concerned I don't think Construct is one step ahead of other tools. I'm not knocking Construct on the whole because I think it is amazing, but I think other tools are just as easy or easier to use for creating levels.

That being said I don't think its that hard to make levels, but it could be better. Working with tilesets seems to be a weakness of Construct. For example, there is a video on youtube on level creation

. It "seems" to be easier than the way Construct works, but maybe I haven't used Construct enough yet. This is probably a 2.0 feature though... or a plugin.

I used Game Maker for years: has the BEST tool for level editing. Tiling is SO easy, the grid is better than Construct: I can make an entire big city in a hour with all the functions the level editor gives to me. The Construct level editor is just the simplier level editor I've ever seen (attention: i'm not saying it is a bad level editor), so this NEEDS a big change, a more advanced level editor.

I agree, too. Editing levels takes more time or work than it seems like it should.

Being able to click/drag to add or change tiles in positions like that would speed things up greatly, I think. I mean, I would prefer it.

A plugin or feature for this should check for square or rectangular regions of the same tiled object, and combine them into one where possible. It'd also be nice if it could stretch certain sprites (such as the ones some use for collision). Oh, and the plugin/feature ought to have an optional setting where you can choose to add these collision blocks with the blocks you draw. Maybe. Though that could be done manually, too. Also, one would still want to be able to cut out holes in the collision afterward for hidden tunnels and things.

True, dragging stuff around in Construct right now takes a lot of time and is pretty awkward. The Gamemaker tile-based editor is a lot easier to create levels in.

http://sourceforge.net/apps/mediawiki/construct/index.php?title=Keyboard_shortcuts

I've seen those things, and sure it helps, but still.

(btw. David, i love your little videos! keep making them, even if it's not super important, it's still usefull to see how you work with things.)

Those are really sweet features and make it much easier to create levels. However, what if the sprites were not separate, but in a tile sheet? Especially a tilesheet that isn't in a perfect grid (has extra space, etc that you don't want to import). It is MUCH easier to import these in other tools than in Construct. Using the import frames feature, under animations, in Construct doesn't seem to work well on many tilesheets. For example, you have to manually determine what size the sprites are by using the picture editor. It would be nice to have that feature built into the import tool. Also, I'd love if someone showed an easy way to import a tileset into Construct and have it where you can use the tiles in many different objects.

For example, a tileset that has three characters with 4 pictures per characters. All I know how to do is to import the tileset automatically into one object using the import tool. Then cut and paste the different animations into new objects. This way isn't terrible... but is there a better way?

Im still not hearing much else about something Construct cant already do.

Other than the "painting" feature lets have some feasible suggestions.

Like the ability to change frames via a context menu when the object is right clicked.

Also a hint for something that's not on the keyboard shortcuts list:

If you have multiple objects selected, you can deselect one by one by pressing the shift key and clicking the object you want deselected.

scidave

You should probably preprocess the images in an image editor, Gimp, or Ps.

But in all honesty making up your own is the best bet.

I think there are lots of things that could be made for easier level editing, but the painting option alone would be a big improvement. And that can't be very hard to add.

Actually I prefer Control+v to a painting type of action, as painting will often add multiple objects all in one place.

Other than the "painting" feature lets have some feasible suggestions.

How is adding a simple coordinate system to the import tool not a feasible suggestion? It would save time determining size of sprites, and it is already done in the picture editor so I can't imagine it would be that hard to do.

scidave

You should probably preprocess the images in an image editor, Gimp, or Ps.

This (adding more flexibility when chopping up tiles) is a common task when bringing in tilesets so why not have the capability in Construct? Since Construct already supports splitting the tiles why not make it a little better? I don't see the reason that this should be done in GIMP... it can't be that hard to implement.

But in all honesty making up your own is the best bet.

Why?? Why should I spend hundreds of hours making cool graphics when I can spend a fraction of that time making a game? You are essentially alienating a large percentage of the casual developer population that doesn't make all their own graphics. Not everyone is trying to make the next big commercial game.

> Other than the "painting" feature lets have some feasible suggestions.

>

How is adding a simple coordinate system to the import tool not a feasible suggestion? It would save time determining size of sprites, and it is already done in the picture editor so I can't imagine it would be that hard to do.

How would that work per layout?

Anyway like i said the chance of duplicates is annoying.

> scidave

> You should probably preprocess the images in an image editor, Gimp, or Ps.

>

Since it solves a headache that probably wont be solved till 2.0... if ever, and the tools/ scripts to do those kinds of things already exist in programs that just about everybody already has. Plus I'd rather the devs worry about game features rather than graphics problems, that again are solved with standard programs.

This (adding more flexibility when chopping up tiles) is a common task when bringing in tilesets so why not have the capability in Construct? Since Construct already supports splitting the tiles why not make it a little better? I don't see the reason that this should be done in GIMP... it can't be that hard to implement.

> But in all honesty making up your own is the best bet.

>

Why?? Why should I spend hundreds of hours making cool graphics when I can spend a fraction of that time making a game? You are essentially alienating a large percentage of the casual developer population that doesn't make all their own graphics. Not everyone is trying to make the next big commercial game.

I'm not saying don't use them, they have their place, but when you make your own you don't have to worry about all the other stuff, like size, tile maps, etc. Plus you'd be surprised how easy it is once you get into it.