MichaelSinsbeck / platformer

A ninja platformer written in LÖVE
7 stars 0 forks source link

[LE] User interface #106

Closed michalove closed 10 years ago

michalove commented 10 years ago

I was thinking a bit about what actual buttons we need in the level editor. If you have ideas already, feel free to ignore this.

The content is divided into four categories:

The interface should reflect that. There could be four according modes in which only one of the four categories can be edited. This should hold for drawing and erasing.

For drawing walls I would like to have a point tool (what we have now), a line tool and a flood fill tool. However, lines could also be done using ctrl+mouse click to make a straight line between the last drawn point and the current one. We could also have another modifier-key (e.g. SHIFT) to switch from drawing to erasing. Or we introduce a void-ground type that acts as an empty tile.

We should also consider adding some context help or such to communicate available keys to the user.

Germanunkol commented 10 years ago

We could display a tool-tipp above the current tool layer. This tool tipp could tell the user about all the ctrl and shift keys, when hovering over the pen tool.

I'm not entirely sure how to do the different "modes" yet. Open for suggestions. At the beginning I was going to add a second panel on the right, which grows when the mouse pointer is over it, for example, to display all the background objects etc. Depending on the mode, this panel would then display the objects, background objects or the backgrounds (in small version).

For the wall tools: I assume you only mean orthogonal lines? We could use bresenham's algorithm to draw other lines, but that wouldn't make much sense for us... In gimp, one draw straight lines by using the shift key and the pen tool. Then, alt would make sense for erasing ("alt" for "alternative", I believe). Additionally, we should probably map keys to the tools and display them on the tool images.

michalove commented 10 years ago

I suggest lines in arbitrary angles, because I want it to be easy to fill larger areas. If I want to fill a large rectangle, I can then first draw four lines and then fill them.

A growing panel is a good idea. Ad hoc I don't know how to organize everything. Maybe instead of having the panel growing (takes time) we could also have just three buttons for the different modes on the right. Then when one is pressed, an almost full-screen panel opens up with all object in it. Both solutions are possible.

Key-mapping is important for a quick workflow.

Additionally, I think an "Current tool" indicator would be good. Just a box with the current tile/object in it and - if we have this in the end - the drawing mode (draw, line, erase...). So that the user know what will happen, if he clicks somewhere.

michalove commented 10 years ago

I have an idea for the tool tip. Expand the "Clickable" class so that each clickable has a tooltiptext.

Instead of showing this text in a box above the cursor, show it in the bottom line of the screen, similarly to the text in the main menu of the game. If the cursor is hovering any button, then its text should be shown, otherwise the text of the active drawing tool (last one clicked) should be shown.

Germanunkol commented 10 years ago

Couldn't we also highlight the "current tool" by changing the button images? It would save space. To make it really simple, we could just add a glow to it (i.e. draw a brighter, blurred version of the button image before drawing the button, but at the same place). Or we could change the mouse pointer.

michalove commented 10 years ago

Okay.

Germanunkol commented 10 years ago

I was thinking: Maybe we should add a category to the above: Background walls. Background objects and plain walls act quite different - the walls need large areas while the other background elements (trees, houses) don't. So we could add a column of background buttons next to the walls, which is always visible?

Or should we just leave the background as an "object"?

Or is "background" what you mean by that? Then I got confused, I thought "background" was the parallax background image.

michalove commented 10 years ago

Oh. I haven't thought about the parallax background yet.

By "background" i meant all the background images that should be handled as tiles on the grid. That is exactly what you mean by "Background walls".

Germanunkol commented 10 years ago

Ah, all right, thanks, then we're talking about the same thing.

I think the easiest thing for the parallax background would be: A button in the tool bar (maybe with some mountains and a sun on it - for "backdrop") which, when clicked, pops up a window with the available backdrops displayed, in a small version. Then, when clicking one of those, the window disappears and the background in the level is set to the chosen background. Simple enough...

Germanunkol commented 10 years ago

I noticed it is very annoying that you never know what mode you're currently in, when working in the editor. Once we have all the buttons and functions figured out, would you mind making some sort of highlight version for each button, when it is "active", or maybe a glow for behind it? I imagine it like so: When you're drawing grass, the pen is highlighted and the grass tile is highlighted. When you switch to editing objects, the edit-object button gets a highlight instead...

Germanunkol commented 10 years ago

Ah, on the other hand, I'm not really using the "On" images for the buttons atm. We could use those instead, so we don't need to make more...

michalove commented 10 years ago

Yes, why not use the "on"-image. The other option would be to make a semi-transparent white glow (that is fuzzy at the egdes) and draw this on top of the current button. That would technically be a bit different (additional images on top, instead of replaced image). so go with whatever solution you like more.

Germanunkol commented 10 years ago

Hm, I tried the on-image. You can see the result in the newest commit. I also tried the hover image. I like neither... I think we'll have to add a glow...

Germanunkol commented 10 years ago

I gave the UI a bit more thought: I think it would look right if we seperated the "tool" panel (bottom) into two: One for the general file functions (save, load, test, exit, new) and one for the tools. We could put the file functions up the top, for example, and move the tool panel over to the left (and make it half as wide).

Also, more generally: I really like the blue boxes and their "crumbled paper" look. But I don't think the green, very straight buttons fit with it. How about we give the green boxes some jitter as well? We could either do it manually in inkscape, or "simply" add the possibility of adding a mesh to the visualizer: By distorting the mesh, we can add the jitter to the buttons automatically. So we'd need to add a function Visualizer:createJitterMesh() and modify Visualizer:draw and we'd be done.

What do you think?

michalove commented 10 years ago

Good idea for the layout. Let's do it that way.

The green boxes are ugly indeed and they don't fit well. I like the idea with a mesh. Then we should separate the button into two parts, the box and the icon. The icon should not be jittered. Additionally it would be cool to show the button shortcut-key on the button. That would probably make the buttons a bit bigger (taller but not wider, maybe?). Then a button would consist of three visualizers: the box, the icon and the shortcut-key.

Germanunkol commented 10 years ago

I attempted the mesh way of making the buttons. The way I do it: When loading an image in the animationDB, I give one additional parameter stating whether meshes should be generated as well as quads. When creating buttons, for the ones where I want the images to be "jittered", I added another parameter.

Then, I call Visualizer:useMesh() on those buttons. This tells the Visualizer to use Visualizer:updateMesh and Visualizer:drawMesh instead of Visualizer:update and Visualizer:draw from now on. Those two functions simply render the meshes instead of rendering quads. I don't think we need to split this into 3 visualizers for this, the icons are almost not distorted at all. I think it looks nice. However the code might be somewhat cluttered.

It works. But I'm very guilty of passing many flags as arguments. Frankly, I didn't know how to avoid this without making many, many more versions of the functions...

Tell me what you think. I won't be dissapointed if you say "it sucks, let's do it from scratch", cause this might not at all be how you imagined it...

Germanunkol commented 10 years ago

I've been thinking that the interface of the editor and menu looks relatively boring. I watched a video from Concerned Joe's editor, and it just looks so much better...

Here's a new idea: We use bamboo-style interface, for the menu and editor panels. This is a very quick illustration of what I mean - it would need much more work. Ideally, the cloth would look less like a hide in a stone-age game, and more like a bandana. Or we could add multiple-color cloth on it, to make it look even more like bandanas, maybe hung up for drying. I haven't really thought this through yet, just throwing out ideas. image10244

Alternative: g10736

Note: all of these can easily be put together using quads. I imagine it like this: Similar to the blue box we currently have, we'd write a function box:new( x, y, width, height) which creates a new one of these boxes by placing the correct quads (bamboo can be nicely split up into segments). Then, we'd just have to call box:draw() later on...

As I said, this is not really thought through, but I like this much more than plain blue boxes. What do you think?

And one more idea, using less space for borders: image10245 With a bit of work, we could make the button images look like they're drawn on the cloth.

(P.S. The images above are supposed to be editor-images, but are using an ingame-screen as background - which might look confusing...)

michalove commented 10 years ago

Good idea. I like it. The bamboo image is so simple (in style) but one immediately recognizes it as bamboo. I think the cloth should have the same color everywhere, but we could draw it in white and then color it by code, so we are flexible here. I like the idea of saving space, but the example image you made does not look right to me. The cloth should not overlap the bamboo so much. Maybe we can find a way to make the bamboo thinner.

From a interface design perspective, I think everything that is not part of the game world, should be drawn onto such bamboo frames (the menu, all buttons, the level names inside the game). That makes for a clear distinction.

Germanunkol commented 10 years ago

Good point. I was going to add ropes or something, that show how the cloth is connected... then it would be clearer. It was just a quick sketch, it certainly needs more work. Glad you like the idea, though!

Germanunkol commented 10 years ago

Hum... brown or green?

bamboocolor

michalove commented 10 years ago

I'd go for the brown one.

Germanunkol commented 10 years ago

bamboo Here's a new version. Please let me know if this is going into a direction you like... I kind of like the background but I'm not convinced by how the fabric folds over the bamboo and is connected by ropes. Open for suggestions. image102452 I imagine the fabric to wave the slightest bit, as if there was a very soft breeze. It is starting to get a little more involved (when speaking about how to put the pieces together), but I imagine with a mesh for the background (holding the fabric) and quads+spritebatch for the frame, it should still be simple enough... At this point the bamboo is not tileable yet, I'm still playing around with ideas.

Germanunkol commented 10 years ago

Maybe more like this? bamboocolor2

michalove commented 10 years ago

I like this last example most. It might be slightly illogical, how the fabric is attached to the bamboo, but nobody will notice. And too many details might become distracting. I think this solution is perfect.

For the tileability: It is probably okay, if we cannot resize the frames continuously, but only in "steps". Maybe we could have standard bamboo tiles and for the end piece have different versions of 2 or 3 different lengths. also I think it is no problem, if the bamboo protrudes a bit at the corners. Maybe could even use these so that the signs are not floating on screen but are held to the window borders (like the last image above could be used on the bottom of the screen).

Good work so far!

Germanunkol commented 10 years ago

Okay, so I added the bamboo-boxes. I like the bamboo itself but the canvas/fabric is not too great yet in my opinion. What do you think?

I was thinking that maybe I should remove the moving of the canvas and reduce the opacity of the "folds". I could then re-add the moving using a shader, but this time the buttons and everything else drawn on the fabric would move with the background, making it look like it was stitched to the canvas... I think I'd like that more. And this effect could off course be switched off using the settings menu.

michalove commented 10 years ago

In case, I haven't said that yet: The bamboo looks awesome!

At the moment, the moving shades effect is subtle. I did not notice right away. It would be consistent to move the buttons, too. But I am not sure, if this is not distracting. Maybe, if it is only moving a tiny bit, that might work. We probably just have to test it and have a look.

Germanunkol commented 10 years ago

Thanks! :)

Yes, I think it should only move very, very slightly. Maybe we should enable/disable it with the effects using the settings menu. This way people who find it annoying can just switch it off.

michalove commented 10 years ago

Okay. Cool. Go for it.

michalove commented 10 years ago

I looked at the progress today, after two weeks of vacation. First of all: Nice to see so much progress! I almost feel bad for not having contributed lately.

One thing I noticed when I started the editor was that the GUI takes quiet some space from the actual view. Can we move the bamboo frames further outside, such that each frame has only three sticks of bamboo visible? Right like in the second picture above? We'd have to find a new place for the tool tips then. Or we use the left, right and upper border for the GUI and the lower border for tool tips? What do you think?

Germanunkol commented 10 years ago

Yes, I'll move them. How about putting the tool tip at the very top? That space is still free. Or, as you said, we could move the tools to the top and then have the tool tip at the bottom.

michalove commented 10 years ago

I moved the panels. What do you think? I let the frames overlap. The only issue is, when you switch from ground to background (B and G hotkeys) then the frame changes, but has the same size. That looks a bit wrong. Not a big deal, though. Besides that: I didn't adapt the edit-properties-panel yet. Should we also just put it to the left? Maybe have it permanently open, even is no object is selected? I just had this case: I clicked on an object and right on top of it, the panel opened, blocking the view to the object. That is why I suggest having the panel open all the time. Do you agree?

Germanunkol commented 10 years ago

I haven't replied yet because I didn't really know a solution to this. I must admit I don't like it too much when the panels partly leave the screen. To me, it always looks like I should be able to pan in that direction, in order to see the rest. I thought about adding a second kind of border, which is thinner and gets displayed on the side which leaves the screen, but I don't really like that either. You're right about a few things:

Situation Left side Center Right side
Level-Editor-menu Menu
Ground Tiles Tool Panel Grounds Panel
Background Tiles Tool Panel Backgrounds Panels
Place Object Tool Panel Object choosing Panel
Place Bg Object Tool Panel Bg Object Panel
Edit Object Tool Panel Properties panel (always visible)

Since the screen is much wider than it is tall (usually), this should give the user a much better view of the canvas - since there's nothing (besides the tooltip, maybe) that's displayed at the top or bottom.

Germanunkol commented 10 years ago

Update: I implemented the idea posted above. I think the only real drawback is that the user now has to press escape before pressing F1-F4. But that's not too much of a problem, I believe...? What do you think?

michalove commented 10 years ago

I like the new menu and the new layout is very clear. I personally would like to have an immediately button for testing the game (saving and loading is not so important so they can stay in the menu). So, imo it should be moved to the panel on the left.

And then, it would be nice, if the editor warns the user, if you exit the editor without saving. After all, the exit and the save button are in the same menu. Just add one more menu with the three options "back", "save" and "exit", that only pops up, when the current level is different from the last saved one (how do we know if a change has been made?)

Germanunkol commented 10 years ago

I've finished the last two points you mentioned. If you agree, let's close this issue as the main UI is done. There might be minor tweaks here and there, but let's create seperate issues for that - this thread will become too bloated if we add more...?

Edit: As a side node, I've decided to remove the small movement of the cloth on the UI panels. We might be able to make it look much better (right now I'm not really convinced), but even then it feels like a break in style to me: We have nothing in the level that moves with the "wind" at the moment, so I think it looks a bit out of place.

michalove commented 10 years ago

Let's close it. (I opened one new issue, but that should be done with a few lines of code)