Level Editor

[Germanunkol]

A level editor would be nice, and not too hard to make. If we make one, we should offer an "upload" feature, which uploads the level automatically, and the game should check for new levels online. It could be a really simple up-and-download feature, maybe even just using http/php. I've coded downloading features using background threads before, so it should be no problem to do that. Since we don't run any code in the level files, there is no security issue, either - we'd just download the .dat files.

I have recently rented a server with fixed ip - I could offer that for this feature. (In fact-I'd be gald if we used it, since right now it's just sitting there, doing nothing much.)

I think this feature would really increase the re-playablility of Bandana.

[michalove]

Cool idea. I am excited for the playtester-feedback on this.

The .dat files are lua code, so there is a potential security issue. But we either change the level format to cvs or somthing or we implement some sort of sandboxing for the loading of the level.

And here is some brain-storming for the leveleditor:

• There should be a function such that the user does not have to place the individual tiles of the wall (black line position), but instead he should be able to just paint "concrete" or "soil" and the tiles should be places correctly.
• An own editor allows us to set object properties(speed, fire rate etc.). Right now this is not possible and I had to have multiple copies of some objects in the object palette. This will be a nice improvement.

[Germanunkol]

Uh, I didn't know the .dat was lua code. I thought it was parsed manually... bad me. Should've looked closer.

Yes, we should definately use this editor as soon as possible, if people want it. I would love that "paint concrete" feature!

[Germanunkol]

If you want a level editor, I think this should be the next step. Otherwise we'll probably have to re-make all the levels when we decide to create one... and if we get it done soon and do it right, it'll speed up level-making.

In case we decide to make one, here's some points that I think we'll need to consider_ Level editor:

• People won't want to worry about layers. Everything should be placed on the correct layer automagically.
• Background objects should just be in "categories". Maybe it's possible to create sprite-sheets based on categories (trees, houses, ground types)? I think we should make it possible to inter-mix all the worlds' tiles. Is this possible?
• As you mentioned before, when drawing ground, it should automatically adjust depending on the tiles around it (goes for ground, walls, wooden bridges)
• Should use the mouse. I can't imagine a leveleditor without the mouse. This breaks the style, but I don't think that's so bad.
• Should have a "test" and "upload" button.

General:

• Uploading in a background thread (non-blocking!)
• Rating system (Idea: whenever a user has played a user-made level, at the end (after or during the level-win-screen) a five-star display appears, so the user is "pushed" to rate the level right after playing it.
• Add button to world map for downloading levels, or add a seperate menu entry for "player-made-maps" or similar.
• Should it be accessible from the menu or should it be a seperate .love?
• We could add an "authorization" tool, so that uploaded levels are not automatically on all other player's download list. Instead, one of us has to "authorize" it manually (i.e., test it, see that it's possible to play, then click the ok-button on the online interface) and only then can players download it.

There. I wanted to get that noted down, before I forget. What do you think? Do you want a level editor, or is it too much work?

[michalove]

I am definitely pro level editor. I will definitely take time, but I don't have any other project in the future. So let's go for it. I see some more benefits:

• We can equip objects with properties. For example firerate for enemy spawners. That way, we can do much more fine tuning and the code gets cleaner (For example for the fixed cannon I made 16 different once)
• The lines for sliding down can be placed more flexibly and possibly as a poly-line.
• ATL is not supported any more so we will have to switch or find a solution anyway.

Good point about layers. We can probably split things into "tiles", "objects" and "decoration".

The editor should be available in the main menu (shovel symbol?) Probably we can also put together the tiles of all worlds into one big spritesheet. At the moment the images are very high but not very wide. That would also remove redundancy (grass tiles in world 1 and 2).

It is probably best, if only one of us starts programming the skelleton of the level editor. When the basic functionality is there, we can both work on it. Do you want to do it?

And here are first steps:

• Rethink the map format. The game itsself needs to know what parts to draw where and the collision table. But in what format shall the maps be stored?
• Write a "writeMapToFile" function.
• Maybe it is possible to have the in-game maps and the level-editor maps in the same data structure (which is called Map right now). Then writing and reading is the same and from the editor it would be easy to just run the level.

[Germanunkol]

All right, then let's do it!

I can do the rough structure, yes. I'll propably start this weekend.

I agree on all points, but one: You said we might be able to put all sprites into a single image - I don't think that's a good idea. I'm not entirely sure how löve handles images and sprite batches, but I know that there's a maximum size for images, depending on the graphics card. I believe this applies to sprite-batches as well (though, again, I'm not sure), so I think we should limit them in size. Putting everything onto the same sprite sheet will probably make those very big. Right now, we already have a sprite which is 512x2368 pixels, which is more than the 2048 pixels many graphic cards allow. So I think we should seperate into:

• All walls into one sheet
• Background types into multiple sheets. Either by category (Houses in one, Plants in the other etc) or by World (Village, Forest etc). I prefer the first. Either way, in the editor, they should be displayed by category.
• Objects (Enemies, Ninja, Goal, Wind etc) into one.

[michalove]

That is what I meant. Sorry for unclear formulation.

I was thinking that we could maybe also divide the background into objects-like and tile-based. The house is definitely tile-based, but for example many things are images consisting of multiple tiles that always appear together (plants, dragon, trees). I could imagine handling these as background objects. That would mean that each of these background objects can have an individual size and the placement on the map could be arbitrary, without restriction to the grid (but optional grid snapping). That way we could also put overlapping trees on the map.

And two other things:

• Currently the collision map is stored in each map file. I consider this data as "implicit data", because it is actually redundant with the map content. So for the future I suggest we do not store the collision map for each level, but generate it from the data on loading.
• The spike images need to be drawn on top of everything else. That is why they are in the foreground layer. Also they have an own value on the collision map (which makes them collide with enemy normally, but kills the player). This is a technical issue. Handling-wise I suggest putting the spikes into the same category as walls, such that they can be drawn, by "painting" an area.

[Germanunkol]

Last things first: I agree with the spikes being handles like walls in the level-editor. No need to complicate it for the player. Also, they replace walls (walls can't be in the same place), so it makes sense to put them together with the walls. I was actually thinking about putting spikes and walls (and wooden bridges) on a thin panel on the left, which is "always on", i.e. you can't disable it. On the right side, I'd make another panel which is thicker, where you can choose a category. this panel might collapse when the mouse is not over it, so that players have more space to see the actual level, yet have lots of space also when choose objects from the list. But those details aren't important yet. I'll just try it - if you like it, we'll leave it, if not, we can change it.

I really like not having to store the collision map. That way, the map file format would only have to store two 2-dimensional arrays: one for the walls/foreground and one for the background.

Now, for the first part - I was actually thinking something similar: objects should be handled as single objects in the editor. But your idea with the handling of multiple objects is pretty interesting, actually. But how would we draw them? In a seperate rendering pass? And would they just be used as full single images? Or also batch-based? And would they be infront of or behind the tile-based layer? Also, how do we stop users from placing way too many objects? If we add them all as individual images, it would allow us to also add animated ones (waterfall, butterflies, waving cloth etc) which would make the world much more alive... But the latter could also be objects.

[michalove]

Background animations, cool idea. If we only have a few of them, we can implement them as normal objects. The windmill is done this way.

Static background images: Ad hoc, I'd say, that we can put all background objects into one large image. As it is now. But instead of generating the quads automatically in rows and columns ("tiles") we can create a list of rectangles (maybe hardcoded). If we do so, we have many quads for possibly different sizes. We can then draw all of them with a spritebatch in one function call. That should be efficient enough (comparing with the map itself, which consists of a large number of quads). The graphics pipeline for new background objects then is:

• Draw new object into the object cataloque (objects may not overlap rectangle-wise)
• Add a line with the coordinates of the new object to a data file. This could look similar to the animationDB, but with different data.

I have an additional feature request: For objects the user should be able to select different alignment-options on the grid: centered, left, right, top, bottom, left+top, right+top etc.... For example walking objects should always be bottom aligned.

And for the ingame objects, it should be possible to set parameters (fire rate, angle ...). We will probably come up with a new data type called "editorObject" or something, which contains an image, a list of adjustable parameters and a pointer to the in-game object it belongs to.

Once we started the editor, it should probably split all these ideas into single issues (not now). I suggest, as a naming convention, start the issues with the tag [LE].

[Germanunkol]

I just noticed that - if we make the level editor callable from the main menu - it will be weird when the user comes back to the menu and suddenly can't use the mouse any more. I don't really like the option of making it a sepperate .love, though, so I think we'll have to live with this "break of flow"...

[michalove]

Breaking the flow is the smaller "pain", I think.

Maybe we can support this break in flow by also slightly changing the graphics. Instead of using the wiggly-lines we could make a more simplistic interface (no contour lines, only colored rectangles). This could possibly make the separation of the level editor more clear.

[Germanunkol]

I simply used the same boxes for now. I copied the code from the menu scripts, so we can always just change that later. Also, I wanted to ask you if you could make me some button graphics... I used placeholders for now. Maybe wait a bit longer, though - till we know what else we need. Maybe you could also redo the shovel menu entry? Its not that great yet...

[michalove]

Sure. I will make some graphics.

[michalove]

I close this, because we created all the other, more specific issues.