Is it worth it to make a built in tile editor?

[fyregryph]

With things like Tiled that look like quite nice editors, is it considered bad practice to make your own built in editor?

I'm trying to put together a platformer base/engine type thing for some of my game ideas and I've been trying to keep everything organized instead of quickly hacking things together as in my other löve games. So I've been going down lots of tangents of "how should this or that be" designing class hierarchies and such, trying to lay down a decent foundation so it can grow without becoming super convoluted.

So on one hand a built in editor could end up being a pretty nice thing to have if it grows, on the other hand it might just be better to use a powerful separate tool like Tiled.

[zorg]

Probably depends on how much free time you have, and how dedicated as a person you are.

Built-in editors are always a nice idea, but developing that takes away from the time you could spend actually coding your game itself; i should know, i never really finished any of my projects because of this reason.

That said, there are probably people who can pull it off, so decide for yourself whether you're that kind of person or not.

[MrFariator]

I am developing a platformer with a built-in level editor. My thought process was that I wanted to invite my friends to later design stages with the same set of tools as I, meaning they just need to grab the game executable to have a go at it. This would then extend to any players who would want to make their own stages after beating the main game. Another reason was that I wanted to better learn how to make GUI driven applications, and this was a perfect excuse just for that.

However, I wanted to keep things fairly simple and straight-forward (though I am planning things like in-editor scripting API), but without a doubt I have so far spent more time on the editor than actual gameplay or content. One bonus though is that because my editor is generic enough I could easily just take the visual assets and make whatever 2D game with it, from platformer to top-down games.

In the end though, it really depends on your available time, as zorg said. Shovel Knight developers just went with Tiled, and so do a plenty of other developers, particularly when they just want to like, make a game.

[Jasoco]

I find it a lot of fun to build your own editor. Lets you be more flexible in map structure. But it's a lot of work.

I too had a level editor in my shelved platformer engine. And am now making a similar one in my current engine.

[fyregryph]

@MrFariator Wow, that is quite an impressive level editor! I can see why that'd take up more time than the game itself, designing UI components and editing tools to that extent.

@Jasoco That's basically what I'm thinking, that it would be more flexible and be cool to make even if it's not as good as something dedicated to tile based editing. All my löve games have been learning tangents anyways And I'm wanting to involve my non-programmer sister in making some games too so I think some sort of editor would be good.

...Actually I keep toying with the idea of trying to make a sandbox game in the spirit of Terraria, with this being kind of a testing the waters thing making a bare bones WYSIWYG editor.

[kikito]

I did an editor once, in the past. It took a loooot of time and effort. So much that I didn't have any energy left for actually implementing a game for it.

Nowadays I strongly favour easily parseable text files. If I can make it a .lua file, so I can directly load it with loadfile, I do just that. And I design levels on a text editor. Maybe I got burned by that first experience.

An alternative that I have seen some people use, which I have not tried myself, is using image files as levels. If your level is 100x100, you use a 100x100 png image, where each pixel represents a tile, and its color codifies the type of tile it represents: green pixels are platforms. Red pixels, spikes. And so on. That seems relatively fast to implement, and would make designing levels quite straightforward. It might not be enough for all kinds of games.

[scissors61]

An alternative that I have seen some people use, which I have not tried myself, is using image files as levels. If your level is 100x100, you use a 100x100 png image, where each pixel represents a tile, and its color codifies the type of tile it represents: green pixels are platforms. Red pixels, spikes. And so on. That seems relatively fast to implement, and would make designing levels quite straightforward. It might not be enough for all kinds of games.

Hi kikito. This alternative sounds interesting. Can you share a reference of how they do it?

[Jasoco]

Notch did it with his old 24-hour jam "Prelude to the Chambered" game.

To create the levels you'd use an image editor. Use a different color for each tile. Then to load them into your game you'd load the image as ImageData then use ImageData:getPixel(x, y) or put it on a Canvas and use Canvas:getPixel(x, y) to get the RGB data of the pixel and use some checks, like some if/thens or a lookup table to figure out what tile to use for that color.

[zorg]

You could also use the separate color (and alpha) channels for different "layers" in your world; e.g. the red channel could hold 256 background tiles, the blue channel 256 foreground tiles, the green channel 256 technical tiles, like warp points, save points, etc... and similarly with the alpha channel. How you partition those up is up to you, of course.

That said, it'll take a bit more work when 0.11 comes around and the numbers will be normalized to [0,1].

[MasterLee]

That said, it'll take a bit more work when 0.11 comes around and the numbers will be normalized to [0,1].

Hopefully there will be an workaround for that. It is already hard enough without texelFetch in shaders so why make preparing textures even harder?

Code: Select all

    extern vec2 size;
    extern sampler2D image;
    extern sampler2D karte;
    vec4 effect(vec4 color,Image texture,vec2 texture_coords,vec2 pixel_coords)
    {
      pixel_coords.y=love_ScreenSize.y-pixel_coords.y;      
      return Texel(image,(mod(pixel_coords,16)+Texel(karte,pixel_coords/128).rg*4096)/size.xy);
    }