User Interface

[Charilaos]

Intended for all things UI related, to keep these designs and their discussion separated from the in-game artwork.

[Charilaos]

Gigantic UI update!

Part 1/2: In-game UI

General

• Click the images to see them full-sized!
• Interactive elements (such as the pause button) have a dark gradient that is carefully chosen to not conflict with any in-game element
• The backgrounds of all UI cards and panels are translucent black, indicating when there's content behind them. When on a black background, they completely fade away (as seen in the example above)
• The typography is fresh, readable and designed to age less. The font is Montserrat, found on Google Fonts for free

In-game status card (above)

• Placed in the bottom left corner as opposed to the old game: our reading direction and therefore preferred hierarchy of organized information is from left to right
• Notice the interactive element is colored according to the difficulty level
• When too many gems are destroyed: the required gem points counter strobe-flashes white/red. This saves space and continuously reminds the player of the situation

Tutorial card

• To guide the player in a non-obtrusive way, small tutorial cards in the bottom right corner can appear in a few instances
• 1 The arrow keys tutorial shows up in the very first level
• 2 The control tutorial shows up in the first level where the player needs to grab something
• 3 The shift tutorial shows up in the first level where the player needs to detonate a dynamite
• The tutorial cards always show up in those 3 specific levels and fade away directly after the action is performed: moving, control (and actually performing a grab action), shift (and actually walking away so the dynamite sets off).

Steps card

• The steps card is present during 3 different modes: demo/replay, single step mode, and undo/rewind
• No controls are shown on screen, but when playing a demo or when using undo the arrow keys can control the playback speed and even playback direction (forward/in reverse).
• In the screenshot, 2 arrows are shown next to the "now" line pointing forward, which means 2x playback speed. In case of undo where the level plays, it starts by showing an arrow backwards and to the left of the "now" line.
• When pausing during demo, single step mode or undo, the exact same pause menu is seen as when pausing during regular gameplay

Pause menus

• The pause menu has 4 versions: regular, finished, died, too many gems destroyed.
• It appears out of the in-game status card as it grows vertically
• It is in a corner so you have the maximum available screen space left to investigate your next move in the level
• The “demo”, “single step” and “undo” (which I exploringly called "Rewind" to clarify) features are bundled together and called Assists.
• The “finished” version of the pause menu should state that a level is finished with assists, if used.
• The image with the 4 versions of the pause menu shows the smartly chosen default selected actions

The Countdown feature

• This is new and helpful in many cases: when you hit play, the pause menu shrinks back into the in-game status card with a 3-2-1 countdown which takes exactly 3 turns.
• No "0" or "Start!" is shown after the 3 turns: at that point, you're already playing, and the "1" turns directly into the in-game status card.
• 3 turns is rather short, and perfect for when you already want to walk a certain direction from the first turn / after pausing.

[Charilaos]

Gigantic UI update!

Part 2/2: Level Selection

Levels by difficulty

• The levels menu slides in from the left side and is a full-height, scrolling list view (rather than a multi-column view)
• In the space to the right, instead of showing demos, it utilizes the ability to practically instantly load the levels for a very relevant visual preview.
• Ideally to make it as "live" as possible, animating game tiles should animate even in this mode: Player eye winks, gem shines, acid, converters, swamp, other pickup items such as keys/dynamites/tnt's, and maybe even base enemy animations.
• The level details are also present on the right side with the play button pre-selected.
• Important nicety: once a level is selected, hit enter (or click) only once and you’re playing without a second confirmation (that is, after the countdown that is now shown in the levels menu that slides away).
• The level editor and settings are always instantly accessible from this menu, as is the back button (also tied to the right arrow key and escape) to go to the top level.

Completed levels

• Once a level is completed, the category icon is filled with a low opacity shape
• Not entirely decided on whether it feels better to start with empty icons and fill them upon completion, or the other way around. We have to test this

Top menu

• One level higher is the top menu that serves the purpose of choosing “what kind of levels” you want to play.
• Choose a difficulty (the way we're used to), or choose a category.
• The top part holds 2 new items, we’ll discuss those in a moment.
• Regarding the categories: I thought about a new set that slightly better reflects the level genres. Science is gone since in practice these levels are (science themed) puzzle levels. Speed and Survival (as opposed to fighting) are added.
• Regarding the difficulties: I tried to make sense of having less difficulty levels as 11 was overly granular. Not entirely sure about the names, but the ones removed are Tutorial, M.A.D. and Unrated. "Tutorial" only makes sense for some campaign levels as the game itself (not the player's own levels or other levels) should provide a complete set of tutorials for all the game mechanics. Hard probably shouldn't be the hardest (it doesn't sound challenging enough, something like Insane would do (M.A.D. isn't so obvious)).

Levels by category

• Here’s the levels menu when a category is selected. I think this view makes a lot of sense for those who are specifically interested in certain categories.
• In the top level menu, it is pushed below the Difficulty selection, and the game should start in the easiest difficulty (rather than any category) for a proper tutorial and because people should at least try the awesome variety of genres
• Yes, for consistency I created difficulty icons;)

Back to the top menu

• The logo doubles as a button that shows info about the game including version number/release date and of course the credits.
• The selector below that shows “Campaign” allows you to switch between a number of level sources: the built-in levels, your own levels, globally shared levels, and your favorites.

Top menu ALTERNATIVE

• From a logical perspective, it doesn’t make sense to preview levels when selecting level difficulties and categories, so you can take the top menu fullscreen and enjoy more overview
• You can even insert more information such as the amount of levels per difficulty/category, which also makes it clearer that you’re switching between level sources
• This alternative still requires some thought, as there are downsides: it’s harder to scale across multiple screen sizes, and there kind of isn’t enough UI to justify a fullscreen view (which is of course is a good thing)

Globally shared levels

• A global database of levels will greatly increase the replay value if you’re done playing most of the bundled levels, and it adds one more reason to create your own levels (and share them!).
• The amount of levels can however explode, so choosing wisely which variables to sort on is crucial so players can find the most relevant levels easily.
• My thought so far was: FEATURED so we have a way to curate great levels hand-picked from the masses. MOST PLAYED to automatically surface the levels that seem to have replay value. NEWEST to guarantee a stream of levels you haven’t played before. RANDOM for shits and giggles (actually the only way to explore potentially bad levels and hidden gems).
• And very importantly: FAVORITES for not losing track of levels you liked.
• I've thought of Search functionality: start typing characters to search any level source you're in, but really not sure if necessary. Certainly a nice to have, but maybe not as nice as releasing earlier;)

All level selection info cards

• There's the regular info card during Campaign level section: plain and simple
• Then there's the info card for levels made in the level editor: added is a button for editing and a switch to share/unshare the level globally
• And finally the info card for global levels: it has a switch to favorite/unfavorite the level, so you can bookmark your favorites

Level Editor

• The level editor design is progressed but follows later after completion and for the sake of keeping this post within sane proportions

Really looking forward to hear some feedback!!

[c0pperdragon]

This is absolutely FANTASTIC! I totally love every single aspect of your designs.
It is specially nice that this will adapt perfectly to nearly all imaginable device sizes (beyond a certain minimum size of course) and input methods. You covered pretty much everything here.

About redefining difficulty and categories and having 8 of each: I agree that this makes the whole thing look better organized. I have made a quick check about how many of the currently (the latest java-based work in progress) built-in levels fall into each:

5 Simple 47 Easy 38 Straight (formerly Moderate) 67 Normal 57 Tricky 47 Tough 26 Difficult 33 Hard 10 M.A.D.

28 Fun
23 Travel
57 Action
52 Fight
73 Puzzle
45 Science 48 Work 3

Reduction to 8 difficulty levels is straight-forward: Integrate Simple into Easy. But I am not sure now about my previous choice to rename Moderate to Straight. Maybe I should revert to the old name. I surely want to keep M.A.D. Not only resembles this the name of one of the favorite magazines of my youth, but somehow the explicit abbreviation dots makes me think of S.W.A.T. And levels in these difficulty surely need very special tactics indeed ;-)

The categories are much harder to decide upon. I don't want to follow your proposal to join Puzzle and Science because there are so many levels there. The science category should indeed by used for levels that need a different approach to solving than just combining well-known game elements. But I guess it would make much sense to reorganize the categories Action,Fight into Fighting, Speed, Survival. All three things lay stress on being fast in some way but with slightly different flavor:

Speed - just being fast to achieve the goal without enemies overly present Survival - avoid being killed by enemies without much fighting back Fighting - live and let die

About globally sharing levels: This is one of the benefits of making an online-only game. I am not quite sure about how to organize these, tough. I am not very fond of the idea of actually curating levels because it will require some constant effort on our side even if the game is all finished and I want to turn to other projects more. Maybe just having automatic rankings on the base of novelty or most played or most loved or such is good enough. I am not sure about how to handle potential abuse (swearing or other stuff in the level names and descriptions), but I will leave this out for now.

[Spacerat]

Hi from a random outsider / longtime fan who's been following this repo for a while 👋 this looks incredible! I love the clean/modern look of the panels and I particularly like the instant level preview. Showing demos in the background was fun, but I often only figure out whether I want to play a level after seeing it, so this would make browsing a great deal smoother.

r.e. handling potential abuse, I reckon you could get by using a bit of regex, plus a user flagging system, plus maybe something like this to flag possible abuse for inspection by an admin https://www.paralleldots.com/abusive-content . You'd only have to pay for it if you get past 1000 new levels a day, which would be a great problem to have.

[Charilaos]

Hey, first if all thanks for the kind words @ both!

Good point on the difficulty levels. How come there are only 5 simple levels? Keeping the original spirit on the difficulties sounds like a plan! Moderate sounds just fine and clear. And cool to hear a little backstory on M.A.D. :) It took me quite some time to figure out it meant Maximum Acceptable Difficulty. I like the mysterty about it. And even if people don’t get the abbreviation, its position after Hard, its color and its icon should speak volumes.

About the categories: again great to get some backstory on Science. It wasn’t entirely obvious at first, but it sounds like a clear distinction. And about re-categorizing Action levels into Fighting, Survival and Speed: love it! Should be very doable. I’m glad spending an afternoon playing all the Action levels. By the way, what are those 3 uncategorized levels?

Also very reasonable point about the featured levels. Active players would start to expect a regularly updated list. 3 alternatives I’ve thought of that also could make sense (and aren’t seen in the design) are: most loved, (your) recently played, or all levels. I don’t think swearing is very likely to occur given the expected audience. This is pure speculation, but I assume for every person that starts abusing the level names, at least one fan will reach out to us here.

There is however a bigger issue that is inherent to a pure online game. While people can create levels, fill in an author name and flip the switch to make it globally available, the lack of account creation makes the following impossible:

• access to your own levels after clearing the browser cache or moving to another device
• have a continuous experience of created levels and completed levels across multiple devices
• taking offline levels you had previously made available online, and vice versa.

In an ideal world, players would have accounts, you could follow other authors that make great levels, and even find their newly created levels in a feed. While that’s a lot of work, there are 2 simpler solutions:

• A simple account so players at least have a way of keeping their progress and levels, and/or:
• Create an Electron app version of js game, that can be downloaded so people have a standalone copy on their computers

Finally, if the game artwork and UI is exported as regular PNGs (as I posted it here) it looks good on regular displays, but very out of place on high density displays such as retina displays and scaled displays on Windows computers (especially since fonts are always crisply rendered). So there’s a decision to be made on whether we use PNG’s (booh), SVGs (guaranteed to look good but also tend to cause glitches on several browsers and are the least performant), or doublesized PNGs that are rendered the same size as normal (recommended, should look good everywhere without performance or render issues).

[c0pperdragon]

Actually I very well plan to let users create accounts. The usual mail-address & password scheme. But this is optional for nearly everything in the game: You can have anonymous accounts for instant start and as long as you don't lose the startup-key you can use the game indefinitely. You only really have to sign up with mail-address if you want to publish some of your levels.

About the graphic assets: You are right that the 60x60 images would look quite out-of-place on retina displays. Since the program runs with OpenGL rendering which should be fast enough on basically every relevant system, we could indeed switch to 120x120 pixel images. Probably I will do some post-production downscaling to provide smaller images also for devices with less system resources (mobile phones). But the overall approach stays the same: the .PNGs simply contain strips of images, organized from left to right for animations, with the leftmost image being the "base" appearance.

[Charilaos]

Good to hear, I’ll bake the account flow into the design early next week.

[Charilaos]

UI Refinement

General

• The refinements we discussed are now baked into the design
• The missing screens are added to the main menu
• Higher res images this time
• And a few new ideas!

Top level menu

• Removed Difficult, added M.A.D. Why not remove Simple instead? I tried removing Simple on the other end, but something terrible happened: all difficulties moved down one position, which changed the colors of all difficulties as we know them :(. Hope is not lost though: we forgot there are enough Tutorial levels that can be moved to Simple, which currently has a negligible amount of levels
• Removed Action, added Science. I spent too much time on that icon.
• Removed Featured, added Most Favorited (not seen in this screen, still not decided whether a fullscreen view for the Top menu is preferable)
• Settings rebranded into Profile. Settings wasn't anywhere near as important as Profile in this online version. Also, if you look at the settings in the old game, most of them are irrelevant by now. It's worth trying to eliminate them all, if possible. The few settings that are still worth considering (thought of: music and sound volume, artwork size, language) can easily be seen as "personal" so they're not a weird fit in the Profile.

About

• Logo, name, version & release date, a short about text (you remember this one - might need a slight update), and finally of course the credits after that

The "incentive" dialog

• This dialog aims to increase engagement. All features that require an account are visible in the UI, but upon trying to use them this dialog pops up.
• The title of this dialog is variable, based on what account-only feature the user tried to use.
• Idea: email as a user ID is easier to remember than "Name". Therefore, Log in should ask for email + password. However, by requiring "Name" for account creation, it can serve as an automatic "Author" name for all created levels. The Level Editor won't need an Author field since it requires an account. More importantly, with levels easily being shared online, you don't want people changing Author names so easily. (Still possible to change name in Edit Profile - it's a nickname anyways.)

Profile (logged out and logged in versions)

• Logged out version is a direct derivative from the incentive dialog
• Logged in version is fairly straightforward and as simple as possible

[Charilaos]

Level Editor!

• Spacial arrangement of elements, clear selection
• Thought about categorizing elements with section titles such as “Enemies” or “Walls”, but there are not enough elements to justify a longer scroll
• The level dimensions took a serious beating. It's simplified to increase/decrease in all directions. This replaces 3 old controls: "Level width/height" values (that worked from the top left), "add border" and "move contents". At the same time, it's more powerful. For example, you can now easily increase the level by 3 rows on the top. For advanced controls, see Controls section below.
• If you look at the level settings in the old editor, almost all are outdated except: gem points needed, gem points destructible and swamp growth speed. For those, I made contextual options in the bottom right corner. More about this later.
• Yes, that's a converter down there with animating colored lights!

Controls

• Move the cursor to the sides or scroll horizontally/vertically to pan around the level (if too big to fit the screen)
• Use the arrow keys to select elements and the buttons on top
• As usual: click in the level to place the selected element, click and drag to "paint"
• If you press control (win)/command (mac), clicking and dragging in the level should create a rectangle of the selected item (when released)
• control/command+z to undo, control/command+shift+z to redo placement actions
• Press shift while clicking on the level resize buttons to increase/decrease level size by 10
• Bonus: click and drag the edges and corners of the border around the level to quickly resize, the same way you would resize a window on the desktop (win/mac). When hitting the border of the screen, don't automatically pan and resize behind it.

Contextual options

• For the gem point options: should be shown upon selection of any of the four gems, and maybe even the player and the exit door. Note that "gem points destructible" has an "off" state below the values 0 and higher.
• If possible, set smart defaults: off for gem points destructible, automatic count of placed gems for the gem points needed
• Swamp growth speed: added the word "growth" for clarification. The logic of the values should be inverted here: 0 is no growth, 1 is very slow, up until 10 (?) for very fast growth. Not sure about the default here.
• I'm going to propose to reintroduce the yamyam remainders. It goes against the updated philosophy of “eveyrhing should be predictable”, but that’s the whole feature. Their distinct ability is precisely to break that philosophy. Why? because this added tons of fun to the old game, in terms of exploring the surprise in every yamyam level, and in terms of creating your own levels to surprise others. I renamed the remainder to explosion debris for clarity. It should have something as a default debris, and there's a nice limitation to manage predictability: one debris slot, so the effect is consistent in each level. Most of the old yamyam levels should once again be possible this way.

Level info

• Title, Description, Difficulty, Category, Music.
• Author is automatic by means of the account, which doubles as the author name with which you share levels globally

Level actions

• Test, Save (same as in Level editor menu), Cancel (discard changes), Duplicate and Delete.

[Charilaos]

Tiny additional update:

• Slightly reworked category icons and rearranged the categories to make more sense
• Totally redone the Travel icon and while at it, renamed the category to Adventure, highlighting the fun part of travel (otherwise it sounds like a lot of moving without too much happening)

• Reworked the order of the pause menu buttons: makes more sense now
• Tiny change: moved the text underneath the selected button closer to the button (otherwise in some menus it comes too close to the big title underneath, such as the save button above the "Level editor" title)

That's it! The biggest task left now are the element animations. There are quite a lot of them. I'll post updates of those in the Graphics and Gameplay issue.

[c0pperdragon]

Hi!

I finally got the time to go through your designs in detail and give some sensible answer on the various parts:

Level categories: I am fine with "Adventure". So we would have (as shown in your design already): Fun, Adventure, Puzzle, Science, Work, Speed, Survival, Fighting I would prefer to present them in this order (going from lighthearted to more and more serious)

Level difficulties: "Tutorial" does not really make sense, because the tutorials of the old game varied in difficulty. And the very few "Simple" levels now just do not justify an own level. But "Difficult" really does. So, we will keep Easy, Moderate, Normal, Tricky, Tough, Difficult, Hard, M.A.D. About coloring these, I you can not find a suitable shade of orange for Difficult, I have no problem in shifting the colors. With "Tricky" being bright green then. Somehow this feels no so bad, because "Tricky" is just what could be solved by a casual player after several tries. Everything beyond that starts to need a serious effort.

YamYam debris: OK, lets re-introduce this. If it is only one common setting for all YamYams in a level that is not such a big deal. Actually I also want to re-introduce the speed parameter for the robot. As it is now, the robot is not as fun to use as it was previously.

About account registration. Yes, it is currently widely used practice to just use the email-address to specify the account. I will follow this. I would not even require an account name here. Upon publishing levels, the user may opt to publish them under a pseudonym instead to keep the email-address private.

I very much like your various icons. But I am not sure about how to implement the rendering of these. It seems to me that they are all rather simple vector-shapes that can be rendered with various colors. For these purposes I have 2 possibilities: Directly render them as vectors (which would be a bit demanding on the CPU because of the many vertices), or use the mechanism I already use for the text rendering. I already guess the second is better, but then I need all these icons (including everything on buttons and such) very super-high resolution to pre-process them into a distance-field image (like I did for the font). The mechanism would even allow to make the strokes thicker or thinner at runtime or apply adjustable edge antialiasing.

For the next steps to do, I want to consolidate the work I have already done with javascript and concentrate to improve the following things first:

Level artwork: This is currently a complete mess because the program now just uses the existing graphics in the way it should be organized in the future. If you already have usable graphics, it would be perfect if you could start to push stuff into the game/tiles folder which I have just created to receive graphics tiles in 120x120 image strips (everything .png). You should have the required privileges to do so. You probably need to install a git client if you have not done so yet. To make this as simple as possible, I want to organize the images as follows:

• Still images for all game elements: This will often just be a simple 120x120 png. For game elements that have some kind of "highlight" or also perpetual animation, the .png should contain 15 images from left to right: First is the key frame image, with the animation frames following. After the last animation frame the key frame will be shown again. With 15 animation frames per move and 4 moves per seconds, this matches a screen frame rate of 60Hz. To provide slower animations (like the bubbling acid), it is also possible to have 30 animation frames for form a longer sequence, but the first and the 16th frame must be the identical key frame (to allow rendering of game key frames without consideration of the current time). Please create individual PNGs also for the various context depending appearances for the acid or the earth tiles.
• Animations: Whenever a moving action can not be done by my opengl-renderer, a special .PNG is needed. The renderer can do the following things in code: move, rotate, shrink, revert animation.
• Morphing: This of course needs a specific animations. Please try to use file names that make clear what is going on in each case.

Sound and music: For development I want to just reuse the existing stuff to actually get the program working, but soon I need proper sounds too (I guess this will be Jürgens part then).

Game icons: The game/gfx folder does not contain much stuff right now. Please put game icons there in a sufficiently very high resolution as monochrome .png (like 200x200 for the category icons) . I will need to perform some post-processing to convert this to a "distance field" representation (like I did for the font.png).

For unifying the rendering, I will also replace the big sapphire image directly with vector drawing commands. So the only thing that will be used then are the tiles for the game elements, and distance-field images for all fonts and icons.

[Charilaos]

Shifted difficulties and adjusted categories: sounds good! (it isn’t worth trying to fit yet another hue in the warm end of the spectrum, it gets too red-heavy). Here’s what it looks like:

Robot speed back: if swamp speed is there, robot speed makes sense. I wasn’t too bothered by the robot being so tough, but obviously with only top-speed it wouldn’t be possible to make easier levels with robots. I would suggest for both the swamp speed and robot speed to have the values “off” and 1 through 10 ( as in the level editor), where 10 is the maximum speed. Also, small tweak: Remember that you adjusted the robot — when it only had one speed — to walk toward where the played moved FROM, instead of where the player is heading? Maybe turn that back so the robot at top-speed is even deadlier, now that we re-introduce the option for slower robots?

By the way! by re-introducing robot speed and 1 yamyam debris, quite a few of the old levels you removed are possible again. (Such as Needful Things).

About removing the pseudonym/author name from the account creation: it makes sense to decrease the amount of steps necessary to create an account. However, this one step of adding a name (call it Nickname to instantly make clear it doesn’t have to be your real name) saves us from quite some additional UI, and saves users from extra interaction and cognitive load. To be precise, by not asking a nickname during account creation: 1. a name would need to be asked the first time you “toggle” a level to be shared, and 2. even for privately created levels, people would like the “by [author]” field in each level to be filled by some (nick)name, not their email address. So probably, by not asking a name in the account creation you’d need to add that name field in the level editor anyway, which makes people more likely to change it every now and then. Ideally people should be actively discouraged to change that name often. Recap: nickname as one extra step in account creation saves us all time + effort. Nickname allows for automatic level authors, users will never have to deal with it in the main UI (unless they go to their profile and manually change it there).

I can provide all icons used in buttons in any crazy resolution imaginable. Aren’t you going to use them more or less the same way as the game artwork? I can easily export them as, say, 200% sized PNGs that will look good on about every display. Alternatively (and probably the best option), we could just use SVGs which would look the best on any display, and you’ll be able to change the colors on the fly (there are a lot of icon-color combinations). Performance-wise this shouldn’t be an issue. I’ve seen countless js apps exclusively using SVGs. Our UI shows about 20 icons on-screen simultaneously, or 30 on desktop monitors.

Alright, I can definitely prep some artwork! Next week I can populate the folder as most elements and some animations are already finished. 2 questions:

• What is morphing? Do you mean all animations that aren’t done by opengl (move/rotate/scale/revert)? In that case, that’s pretty much most animations, except picking up items and rotating enemies.
• About the artwork delivery. There are I think 3 kinds of element animations: 1. still elements with no animation at all, 2. constantly animating elements and 3. elements that are sometimes still/sometimes animating. About this last kind: I assumed these elements would have a separate PNG for their still state, and strips of 15 frames for their animations. I designed it this way because it makes sense for a timestep perspective: it either shows a static PNG or the strip of 15 frames. Especially since some elements have one still state but several animations (example: sapphire breaking/falling/shining etc). So at the moment, the animation frames I’ve made so far don’t include the static element image (which is separate) and would require a fair bit of work to recalculate the frame differences if they did. Is this proposed organization ok or shall I change it?

[c0pperdragon]

So, OK, we will request the nickname at registration. I do not expect too many nickname name conflicts, so the registration should be rather painless. Changing nickname later on: This will also lead to all published levels to be shown with the new nickname from then on. So, exported levels will not have explicit author information.

About icons: I want to avoid using vector graphics in the game, because it will be very cumbersome and slow to make a vector renderer in javascript. For the texts I am using a bitmap-based approach with a very clever way to still get high quality using the opengl fragment shader capabilities (which can offload a huge amount of work into the GPU to keep it from the javascript program). Since the texts letters are so very much like your icons, I will use the same rendering technique for them also - basically just treat the icons as any other letter. For this I make a preprocessing step that generates the necessary images at deployment time. This preprocessing can as well use vector graphics files, because performance is not an issue there. So I guess it would be easiest for you to just provide me with some SVG for the icons and I will merge then together with the font to get these data. Please put these SVGs into the "gfxdesign" folder which was already meant to receive graphics files that are not directly part of the game, but rather some form of raw or design files.

With "morphing" I meant things that I could not handle with simple scaling or rotation, like opening bags or breaking sapphires or the like.

For organizing the files: To keep it simple we can follow your idea to provide single still images for the game elements (a .PNG with 120x120 pixel). When a game element has multiple appearances depending on context (earth, walls), you could provide them in a single .PNG as we already did. I will figure out what is what. The animations are a bit more ticky. The game will run at a designed speed of about 60 frames per second or exactly 15 frames per turn (when the program is not able to keep this pace, it will start to drop frames). So at every turn (each taking 0.25 seconds) there is always the starting situation (consisting only of all the still images of all game elements), then there are 14 animation steps and then there is already the starting situation (again consisting only of still images) of the next step. So basically all animations need exactly 14 frames to serve as in-betweens for the still images (which you could imagine as "key frames"). When the player uses fast-forward or fast-backward no animations will be played at all, but only still images are shown in rapid succession (giving a 15:1 speedup). Following this scheme, it is still possible to provide a kind of "slower" combined animation for acid bubbling and such: Each animation still has only 14 in-between steps and only lasts for 0.25 seconds (including the stills). But you can provide an animation that shows the first half of a periodic swing (from "zero" position to "zero" going through positive ) and also another animation for the second half of the period (from "zero" to "zero" going through negative). Maybe you get the idea - I am thinking about how a vibrating string returns to its center two times in every cycle. Please make 2 animation .PNGs with 14 frames each for such cases.

To keep things simple for the various appearances of the acid pool, we will keep using the overlay to paint the container (has context depending appearance) and the acid (has animation).

If you already have created animations that consist of 15 frames, we can only use them if one of these frames is the still image already (I can ignore this frame at loading time). Otherwise I can not fit 15 in-between frames into the 14 in-between frames of the game engine smoothly. I hope there is not too much work lost by my unclear specification.

[Charilaos]

Hadn't heard of the distance field technique but it sounds great! If it all ends up in PNGs, I'll export all UI icons in 400% sized PNGs. Artwork at 200%. Here's to performance!

Thanks for the background info on dropping frames and fast-forward. Makes a lot of sense why the initial image in strips of 15 frames has to be the still image. Don't worry about that, I'll change the animations accordingly. All left-to-right, 15 frames per turn, and if possible I'll try to create a great anim for the acid without requiring 2 turns (for the love of simplicity). However, the multi-turn animations should still be supported for the explosions.

[Charilaos]

Quick update: refined a lot of the artwork again, so in less than a day I'll upload: the artwork set, UI icons, specification for most UI components, and 1-2 animations to test with.

[Charilaos]

Updated the /game/gfx folder with 3 icon packs in folders with self explanatory names (category, difficulty, menu). Also provided a UI specification sheet with global styling that should cover the majority of the UI as seen in this thread.

If you start implementing the UI, to avoid extra work it's safest to start with anything that's not on this list (as these are the smaller UI todo's I still need to pick up):

• clarify the sharing switch / add a private state icon
• a general pop-up: "Are you sure you want to [delete this level]?"
• in level editor, if no level title entered and user tries to save, go to level info screen so missing title can be entered first
• cursor in level editor
• an overlay in level editor on enemies to show their starting movement direction
• In the Profile and About pages, use a regular Back arrow to go up one level (back to the main menu), the same way it's done in the level editor (level info to level editor)
• a way to close/cancel the fullscreen "account needed" pop-up
• robot speed settings in level editor
• export solid icon versions of categories for completed levels
• export huge sapphire logo
• export tiny UI icons such as on the in-game status bar, VCR movement etc.

[c0pperdragon]

Level editor woes...

Hi Charilaos!

I have worked on the level editor and it turns out that I am a bit clueless on what do do with it. In the current version you can start the editor for a built-in level by pressing "e" in the main menu..

The editor is very unfinished and only allows simple piece placement - no level settings yet. Please give it a try to see what I am talking about in the next paragraphs.

I already have troubles to make the program work satisfactory in all possible conditions. I want it to be usable with mobile devices and to keep complexity down, this means it should work with a single-touch interface. This then will work on desktop devices with a mouse without additional efforts, but then only a single mouse button is supported (or both buttons doing the same thing).

While I have managed to work with this restriction in the game itself, this becomes a pain in the level editor. Mainly concerning one detail: Scrolling around in the map. While I can scroll the tool bar by dragging the mouse, I can not scroll the map in this way because this action must result in painting the selected piece. In normal desktop/web programs this could be easily solved by using the second mouse button or the mouse wheel or some control key or whatever. But here I don't want to use all this.

Maybe you have some ideas on this topic? To make the thing even worse, I would also like the program to work with only the barest minimum of key controls. Like in the game: A directional pad, one select button (grab), one auxiliary button (bomb) and an escape/pause/exit button.

If you want to use the level editor nevertheless to work on the built-in levels, you need to do the following: Edit levels by pressing "e" in the main menu. After you are finished, you can press "w" in the main menu to write a printable version of the level to the javascript console (press F12 in most browsers to open this console). Copy/paste the definition into the proper level pack file. If you need to change level settings also for this, you need to modify the level pack file with a text editor as usual. I hope I can build the settings dialogs in the next days or so. When you want to take care of the broken demos, you can check the whole set of built-in levels by pressing "t" in the main menu. This gives a problem list in the javascript console.

That's it for today, Reinhard

[Charilaos]

It works! And I see. The challenges become quite clear once you fire up the level editor. Part of the problem is of course that on desktop, there is a distinction between scrolling and "click and drag", while on mobile there isn't. I'll jot down a few ways we can achieve the functionality along with a rating for usability. Then you can judge the right balance between usability and implementation complexity.

• There is a workable solution seen in Verto Studio, which is a 3D modeling application that is super cross platform with similar UI for editing (Windows/Mac, MS hololens, and iOS). On either platform, you actively choose what clicking/dragging (or tapping/swiping, if you will) does. For SY, this would translate into choosing between a painting and a panning mode. See screenshot above taken from my phone - works quite intuitively, downsides being more UI required on screen + regular switching between modes. Usability rating 7/10.

• This option seems funny at first, but it works cross device, it's an efficient way of editing and has a relatively small learning curve. Click and drag pans the screen by default, but a small delay after tap/mouse down starts painting. When people swipe/drag, they usually do this immediately - not holding their finger/click down first. However, wait for about 300ms and you're painting, drag from there to paint more of the same. Users can learn this as follows: On click down, show a little circular progress bar around the click, which when full will paint the selected object. If the user drags directly to pan, remove the circle immediately (as it's unrelated to panning. Example above.) Doesn't have the downsides of the previous method. Usability rating 8/10.

• You've probably come across some mobile websites with Google Maps embedded. It requires 2 fingers for panning around, because one finger is already reserved for scrolling the page. This interaction model differs from desktop because the input methods differ so vastly. This principle leads us to the "fully optimized" model. On desktop: scroll either direction (or press the scroll wheel on certain mice) to pan around. Click and drag to paint. For desktop that's the clear winner. On mobile we'll have to test the ideal way: 1. the method described above with hold-to-paint. 2. drag to paint / arrow keys to pan. 3. drag to pan, have a "sniper target" in the middle of the screen and a "shoot" button in a thumb corner, which you hold to paint in the target spot (while using your other thumb to pan around for painting more). Example above. Usability rating: best possible.

• Both mobile and desktop: Permanent arrow keys on screen for panning, click/drag to paint. Low complexity, easy learning curve, but rather cumbersome on desktop and obscuring valuable screen space on mobile. Usability 7/10.

Editing permissions It's been there in the original SY and now it's here too, but I'd recommend against it: users being able to edit built-in levels. I believe the players should only be allowed to create and edit their own levels. Just like it wouldn’t make sense to edit levels shared by other players, editing the built-in levels doesn't feel right. (That's why in the screen designs back in this issue I only included an edit button on the player's own levels.)

Check this out! Go ahead and download Lode Runner 1 from the play/app store (free). It's a remake of the old original that's specifically designed for mobile and it's really well done. Notice 2 things mainly:

• The on-screen controls are unusually good and they give me hope SY can be equally good on mobile. I've always thought SY is fundamentally a desktop game (because of input speed, input precision and added screen real estate). This game kind of proves this wrong - even though I have to say many games on mobile with similar controls just don't feel as good.
• The UI for creating and sharing levels, and how to play shared levels. Simple rules for sharing, quite a nice editor UI, and maybe not enough ways to discover shared levels but that's about the only downside. Some screens below to get a feeling:

Looking forward to this week. Kept the evenings free for artwork improvements and maybe a few level designs. I'll respond to the gameplay issue tomorrow.

[c0pperdragon]

Hi!
I did more work on the level editor and I implemented your solution #1 for panning: switching modes. It is not as cumbersome as you would think, because many levels are small enough to fit into the screen. And when working on the big ones, you normally stay on the same spot for longer periods of time.

I have also added the button (bottom left) to open up the menu just like in the game screen. Please let me know what you think about the workflow in the editor. The game main menu is still a pain to use and the keyboard actions to "edit" and "write" the levels to the console are just intended for us developers. In the released games these function will be disabled, as well as viewing demos will only be allowed after a certain time delay.

I will surely check out lode runner to see which kind of controls they implemented. Nevertheless I still like my touch/mouse-based approach to draw the walking path. It feels quite natural on a touch device.

[c0pperdragon]

Hi! I have finally tried out Lode Runner. And yes, they did an amazing job in bringing keycontrols to a touch screen. This snapping to the latest finger position is a very clever solution. Still there were quite some situations where the control pad lost proper track of my finger and missinterpreted my intentions. Maybe I could implement something like that as a third option (besides true keys and the path arrow).

[Charilaos]

Takes some getting used to but I think this'll work! I'll slightly redesign the UI I did for the LE for the menus to be layed out a bit more logically. Any chance you could make the "New Level" working next up so I can really test the LE without having the feeling of ruining the existing levels? ;)

[c0pperdragon]

Hello!

As you may have noticed I have completely reworked the main menu to now follow your design for selecting category/difficulty and then the individual level. I have not implemented your preview card on the right side because I want a solution that also works on very small screens. Please try out the newest version and tell me what you think. There is no mouse/touch control implemented for this menu screen, but using the keys already works pretty well.

One more info about key input: I no longer use the "Ctrl" key for anything because that it is also used for various browser functions - especially changing zoom levels. Now I have streamlined the whole keyboard input to work with just 8 keys like a standard game controller: 4 directions and 4 action buttons: Enter/Space (Affirmative and Grab), Shift (drop bomb), Esc (back), Tab (switch input modes).
I guess I will some day buy an actual game controller to get this working there properly.

[Charilaos]

Big update I see here, great, I do have some thoughts.

Browsing levels is a breeze now. The level preview really is instantaneous. Seeing a list of levels that are precisely your chosen difficulty or category is very clear. There is one user experience issue however with the sorting. While alphabetical sorting is generally very logical, we might want to cheat in the “Easy” difficulty so we can provide those levels in a hardcoded order that makes sense from a first timer learning perspective.

On the level previews: I purposefully designed those to be actual size and screen-centered (so position nor size changes when entering the level). I get the temptation for a zoomed out view, but planning how to play in such an overview is (cheating and) less fun than discovering by actually playing. I'm eager to see how this will work with the 3-turn countdown mechanism, as described in the first posts of this issue. Another great addition would be the 'live' animations of elements (such as swamp, gem shines and acid) during level selection and the pause menu.

I don’t think people will likely be using game controllers for this so it doesn’t make too much sense trying to align the key bindings - but the new input keys are awesome! I especially like the space bar (after some serious time re-adjusting muscle memory). This works great on Macs, where the Control key is in a slightly different position, and most users would even expect the Command key instead. Wonderfully solved with the space bar.

My honest opinion about this game on small (phone sized) screens is that it doesn’t work. On desktop, controls are tactile and don’t obstruct the screen (together with your fingers), and screen real estate (in terms of how many tiles shown) starts being sufficient on mid-sized tablets. And then there is the browser UI eating up another 10-20% of the already tiny phone screens. And many UI problems arise on phones, not just the bottom-right level details pane in the level selection. The level preview will have the same problem, as does the VCR UI (for replays, demos, undo and single step). The same goes for those “hit shift to drop a bomb” tutorial UI, that normally has the same bottom-right placement as the VCR UI.

Given this, I believe the best option would be to have a minimum screen size, below which you could display a message along the lines of “Try this on a bigger display - it’s worth it!”. For current UI, I strongly suggest 720x720px. To illustrate all mentioned gameplay and UI constraints, here's a scenario on 720x720px:

Later, if live and people love it and crave for playing it on their phones, we should optimize for that experience. That's usually a combination of hiding some elements, moving others (such as key tutorials and VCR), and making smaller versions of some components only on small screens. Even then we need a minimum size, as hell sometimes freezes over: smartwatches are gaining web views these days.

Lastly, one little thing seems unintended. When completing a level, there's no action possible other than exiting to main menu:

Other than that, 3 people over here love the changes already!

[c0pperdragon]

Hi!

On the topic of small screens: Of course it is better to have a bigger screen, but I would never prevent anyone to use a small phone. If it can run the game and the user wants to have it that way, I am fine with that. But probably I will do some adjustment of the default-scaling in that case, so that the game will show at least 7x5 game elements: This is the "Mission Possible" format and also approximately the width of the pause screen. In this size, the game is fully functional and even the level editor can be used, although with extensive scrolling of course.

I am still not sure how to do the level-previews. Currently I have no "start" action in the level selection screen, so if the user presses "Enter" on a level he enters the game with the pause menu open where he then can start the game. If I had the level previewed in full scale, there would nearly be no visual difference between the level selection and the game screen. I myself got a bit confused when navigating between these different screens.

And I fixed the pause menu after finishing a game. It now shows also the option to continue with the next level.

[Charilaos]

Sounds good. The level preview, if at full scale, would look much more reasonable if you implement the 3-2-1 countdown feature, from level selection to game, and from pause menu to game. Additionally, having a transition animation from the game to the pause menu (and the level selection) would further clarify user actions.

The problem with hiding UI (such as the level info panel or steps VCR on the right), is that you might lose functionality. For the provided levels - in that info panel - there is only info + a play button, but for your own levels there should be an additional button for Level Editor, plus a switch button for shared/private. For community levels, there should be a button to favorite/bookmark a level. Fundamentally, if this panel is hidden, but we still need this basic functionality, some other place in the screen would have to make space for those buttons anyway. I think it's still easiest to create the best experience possible for most screens, and in a final stage of development have a look at how to perform a few effective optimizations for smaller screens.

[Charilaos]

Hi! I've been looking closely at the UI to summarize which things we need to improve.

Regarding polish of the UI: the most notable thing is that many elements appear smaller / more crammed together than intended. Especially the icons — which are rendered below the intended 24px size — don’t look precise as their lines fall in between pixels, making them appear blurred. I updated the UI specification document, with notable changes marked in bold. If you follow these instructions, the UI will breathe some air and look more precise.

Sapphire Yours UI Specification.pdf

A few smaller points that will improve the user experience:

• Flash the gem points counter when too many gems destroyed to continuously indicate failure (red/white once every second, 2 second full cycle)
• I updated the icons for the difficulties (stars better aligned to pixel grid) and the shield icon for the survival category to be nicer
• I included " Completed" versions of the icons for all completed levels (both for categories and for difficulties). Bonus: would be neat if even the icons in the top-level menu would change to the Completed version if all levels they contain are completed.
• Use the WASD keys instead of the RDFG keys to control the second player. It's the industry standard, and they're further away from the primary player's arrow controls.
• Here's an older idea worth adding for the cool-factor: animating (but not actually moving) elements in level previews, paused levels and in the level editor (including the sidebar). Examples: player eyes, acid, swamp, gem shines, enemy animations, conveyor belts etc.
• I would suggest we get rid of the Level Info panel when starting to play a level, because it breaks the continuity. Players don't expect it after browsing the levels and hitting Enter (especially since we now have a 'live' preview in the level browser). The scenario when you complete a level and want to progress to the next one is even more cumbersome: you need to press Enter twice every time. The player can always hit pause if he/she is curious to see the level name and description.

And finally, it's time to show some love for the true first-timers by implementing the tutorial tips. The boxes are 32048px, text is Montserrat 14 medium, white, 20px line heigh, 16px margins left and right. The illustrations (8040px and 172*40px for the arrows, vertically centered and 4px from the left side) are exported and found below:

Tutorial Assets.zip

Best would be to hardcode the walking tutorial to "Basic Mining", the grab tutorial to "Collect by Grabbing", and the timebomb tutorial to "Dynamite". It becomes clear that we need to make an exception for the Easy levels: they should be ordered manually instead of alphabetically to control learning progression. This level pack should start with Basic Mining and the walking tutorial, definitely not with "A box full of dynamite" ;)

[c0pperdragon]

Hi Charilaos!

I have decided to no longer hold back our work from the public. Even if not all issues are solved completely, the game is now good enough to be used.

In the last days and weeks prior to this release, I have changed the following things (party due to your request):

• Flash gems points if goal can no longer be reached
• Use WASD keys for the second player
• Support a game controller (first player only)
• Slightly modified user interface key functions to support the controller better.
• Tutorial levels are prefixed with a number to bring them to the start of the list
• Info panel will not be shown when starting the level, except for the tutorial levels.
• Use your style specification. I can simply not translate all this webpage styles to my openGL rendering. Maybe you can tell me specifically what I need to change (like: make this font a bit bigger, make this distance a little smaller, etc.)

What I could not do:

• Use your additional difficulty/category icons. It seems, they have some alpha transparency which I can not support in my font rendering engine (the icons are handled exactly like text letters).
• Pixel exact alignment of text or icons. My font rendering uses a distance field representation for the letters and icons. With this I can easily do scaling and even turn everthing thin/plain/bold. But doing pixel alignment is totally impossible.
• Show earth animation when digging while standing. For some intricate reasons to complex to explain here, I just was not able to tweak my level rendering engine to show this properly. The main problem is that the surrounding earth tiles would get rugged edges too early. This would really look stupid.

The problem with incomplete animations and missing tiles could have been a problem I already fixed last time. Bascially I allocated the texture buffer too small so not all tiles did fit.

I hope you are not angry with me for rushing the release, but somehow this unfinished state of affairs started to get in the way of all my other projects. And paying for the domain www.sapphireyours.com for 1.5 years already without any use and purpose did not help either.

all the best, Reinhard

[Charilaos]

Hi Reinhard! So the unthinkable happened after all! A very fine decision I'd say.

Wouldn't expect that sizes and paddings couldn't be defined in pixels. Especially since you managed to render the game tiles pixel perfect, independent of system scaling.

I'll post my list of level updates/improvements in the Levels issue in a moment. If you have some time, they're worth looking into.

Are you still in to tweak some things every now and then? There are only two things really missing at the moment: the explosions still render incorrectly (we once had their animations running more smoothly), and in Safari on desktop sound is missing altogether. If done, I'd like to post a notice that it's publicly available on the old forums, maybe some youtube videos and twitter. :)

[c0pperdragon]

The explosions look better now, but I don't really know how to proceed with the sound issue. I have no Apple device myself and can not debug the game on Safari. Maybe you can have a look at the javascript console to see if there are some suspicious error messages appearing.

Reinhard