Graphics and Gameplay

[c0pperdragon]

This issue will be used as a communication channel.

[c0pperdragon]

Lets start by looking at what really needs to be done:

• Better main menu. The huge selction screen with that many level names just isn't right. This directly overwhelms anyone. I guess, make a two-level system is better: A list of level packs and after selecting one you get to the list of levels. Also a good background graphic is needed here.
• Backoffice systems to store the game progress for each user (mainly my part). I want to have a super-minimal way for a kind of account creation. I have something in my mind, but I need to try if it makes sense.
• Completion of the artwork and animations. This will probably mainly be the part of Charilaos. When using vector design tools, smooth animations could probably be done without too much effort. For the finished game I still prefer .png files containing a whole image series.

[c0pperdragon]

Second, give a thought on visual enhancements:

Last weekend, Jürgen showed me the game "Ori and the Blind Forest". The whole graphics is based on multiple layers of individually scrolling scenery. This looks very like the set on a old-school real live stage theater production. And in my opinion this so very much better than all the 3D scenes so many games have without any real purpose. I would love to give sapphire yours a tiny bit of the same feel. Maybe a backdrop layer that moves a bit slower to give the game more depth. Nothing too fancy. Or same of particle effects while digging. Nothing too distracting, but just enough to make it feel more complete.

[c0pperdragon]

One thing about the target technology: I think current browsers will now be more then capable of handling the game even if it is written in javascript. It is really witchcraft how much the developers improved on the raw execution performance of this once very slow language. Combine this with WebGL and the browser can do basically everything a game designer may ever wish for. I think, this should even work on decent mobile devices. I also believe that the touch input is actually a nice way to play most levels (not the time-cricital fight or action levels, but everything else).

[Charilaos]

Nice one on Ori and the Blind Forest. Used to play similar games such as Limbo and Trine, same beautiful 3D rendered sidescrolling style. Artwork wise it's easily possible to add a background layer: void can be transparent and so is the whitespace around other elements. We can even add slight opacity to objects like glass or gems. Potentially we could add a layer on top with smoke and glow from explosions, acid and the like.

I'll make a good start on the basic artwork next week.

[c0pperdragon]

As I have seen, the message notification works. I have invited you as a contributor to the repository, so you can push content there. You can also upload your working files into the folder gfxdesign, so they are kept safe in case of hardware failure or other misfortunes (but they will be publicily visible - if you don't want this, do not upload anything).

I have also just registered the domain sapphireyours.com and put a placeholder message there.

[Charilaos]

Nice. I'll use gfxdesign for all latest exports of the artwork (I won't change the names after the first push so the game won't break after you pull).

I think that UI is best done by example designs of all screens accompanied by specification for the visual properties and behaviour. We'll handle that later as we pin down the functionality in the game and menus.

[Charilaos]

Coincidentally just uploaded... https://youtu.be/oTUnA_0C6z8

Actual part about SY starts at 4:30

[Charilaos]

Started creating the vectors full-speed ahead! What you see is still very rough at this point. So far both producing and changing the shapes seems way faster than it was a few years back. As you can see in this image, there are shapes in a background layer that are blurred. I was testing several backgrounds and it turns out only heavily blurred and dark content looks good (both esthetically and by not distracting the main layer too much).

[c0pperdragon]

This looks very nice already. About the background: We will have to try this with things really in motion.

But one thing with your design seems a bit weird to me: The solid rock has a visual appearance of being much more massive than the the brick wall. But I guess we want to keep the fact that the brick wall is more robust against explosions. This was probably the intial reasons we had for the "rocky" wall - to make something looking more fragile.

By the way: I guess it would make sense to finally change the format of the animations and the file structure to something more natural. I want to keep the 60x60 image size and having filmstrips with images in a horizontal sequence is still ok. But at least I want to change the order from left to right. Maybe always have a dedicated image for a resting object (with optional glitter or idle animations).

OT: Convering the game code to javascript turns out to be much more work than anticipated :-(

[Charilaos]

Hi! Late response here. I'm fully on it. How's it going?

About your remarks:

• kept it 60x60
• "resting object" images and left to right animations (15 frames): great!
• tried a lot with moving backgrounds (I use interactive prototyping software): they unacceptably distract the actual game, unless really blurry and faded. We're better off using a foreground layer to increase depth without making it cheesy, where temporary smoke and other effects happen (i'll send some examples shortly)
• about the walls: these and everything else is (very) unpolished at this point. I wanted to have a complete set first so I can now create more correct, consistent shapes with a unified color palette. I already made small improvements to the walls as seen here:

Along with the rest of the progress:

Also, the company I work for is full of JS programmers (cross platform being the reason), some of them making games specifically. If you have any pressing questions about the conversion, a colleague of mine is happy to help out.

[c0pperdragon]

Hi! Work in the conversion is a bit slow right now, because these are the hardest parts: Creating the libraries to do the webgl stuff. But I have done 3 of 4 of the necessary renderer classes, so I guess I will manage it eventually.

I like most of your artwork already. Especially the colorful gems/doors/keys which their perfectly matching colors. I actually never thought about this, but the addition of the yellow gem now really makes the game somehow "complete" in this respect. Your idea to give every moving enemy a facial expression (all pretty grim) is a nice touch. If I remember correctly, we decided to switch the role of the mining lorry and the beetle, so that the lorry now leaves behind the treasure - which are 8 emeralds and 1 sapphire. So, the lorry should probably carry an emerald around instead of a citrine.

I am looking forward to have all this graphics in a running game.

[Charilaos]

Good to hear, I'm sure it'll be really sweet once it comes to life in webgl.

Indeed, my thought was to consistently give the enemies eyes, and while at it, give them a touch of personality. Thanks for reminding me of the changed logic on the lorry. If I remember correctly (and see for yourself if you like this logic):

LORRY: kills on touching, 3x3 explosion, 8 emerald/1 sapphire drop BUG: kills on touching, 3x3 explosion, no drop YAMYAM: kills on collision, 1x1 explosion, 1 citrine drop ROBOT: kills on collision, 1x1 explosion, no drop

As for a bit of visual fun, added organic edges to the swamp:

[Charilaos]

Update time! Most elements are pretty much designed and kind of refined at this point. Here's a little showcase of some of the changes. The one thing that's really making me mad is the Earth tile, which we expect to be grainy but in practice this hits one of the limitations of vectors.

Also! 2 element simplification proposals:

• How about removing the Emerald Stone? There are already a lot of ways to get emeralds: the emerald itself, emerald stonewalls, the bag, the safe, stones in converters, lorries.

• We now have a lot of pushers: left, right, up (elevators), up-left and up-right. Maybe it's too much to have those new elevators that drop to the sides once they hit a ceiling? But! I'm thinking of something similar that's more notably missing: conveyor belt elements, a left-rolling and a right-rolling one. They're quite similar to the side-pushers, but not exactly the same because they don't move themselves. What do you think? The radical option: they could easily replace the regular side-pushers, there are only a few levels that need changing.

I think it's best if we insert them all at once in the game, it will make more impact than the small iterations we were doing last time.

If you have a playable/testable version of the game, tell me!

[c0pperdragon]

Sorry for the delay. I am really busy with my job right now which consumes most of my 'processing power'.

I really like your new designs. Do not worry about the earth tiles. They look actually pretty good. Also your new solution for the exit makes sense even to me (being absolutely no racing sports fan). The one point that I previously mentioned, still remains: The destructable walls look much more solid than their harder twins.

About your suggestion for the game logic: The Emerald Stone is probably really too much. I think there are not many levels that actually make use of it. We could as well leave out the side pushers. Somehow they do not quite fit into the mining theme anyway. But yes, conveyor belts would. I am not sure how to simplify the whole elevator mechanics. The reason for the side-throwing elevators is of course that I want to have perpetually circulation objects. But maybe I can join the side-moving aspect of the pushers with the upward moving aspect of elevators. So the side-throwing elevators would be suitable to create a conveyor belt all by themselves. I think, it would suffice to make the elevators actively pushing the object to the side, even if there is no hole for the object to roll into by itself. With a series of these elevators with no headroom above them, an object would just be transported to one side. You could then even make a level where the miner needs to walk above a transported object to prevent the elevators from lifting it...

About my work progress: Slowly, slowly. I have managed to program all the atomic WebGL rendering primitives. This is very, very far from a working game. If you want to see the test screen (nothing much yet), clone the repository and start the file game/launch.html using the firefox browser (starting the game from the filesystem does not work with chrome - there are some weird security restrictions).

I hope I can speed up my work a bit in the next time, Reinhard

[Charilaos]

Meanwhile, been working quite a bit but also quite silently, so I thought it's time for an update!

Summary

• Elements in nitpicking phase
• Been making most of the variations that some elements have (such as earth and walls)
• Made a ton of the animations. About half-way through all of them. The rotating gems are insanely hard to create, especially with this many frames. Will be fine though.
• Started thinking about the new UI (based on the current one)

Elements Most changes are small to better align the art style where possible. The most notable one might just be the reworked color palette, which I wanted to do forever and has 3 goals:

• deeper colors
• friendlier colors
• more consistent throughout

The walls You've told me before that you perceived the brick walls as more fragile than the stonewalls. It's an intriguing problem. I designed the brick walls to make the impression of being stronger: they're brighter, more structured and have a continuous texture from tile to tile to look more like a mass. I asked a few friends for their intuition, and they all found the brick walls to be less likely to scatter upon explosion. It is of course up to you if you want to turn them around or try to make the stonewalls more fragile.

The elevators I think the easiest solution would be to keep only the 3 pushers in the screenshot of my last post. They look the same except for their orientation, and they can accomplish all movements together. The up-then-side elevator can be done like this:

In 1-2 weeks time, the UI will be far enough to show screens from throughout the game!

Also had a friend play the version we made 3 years ago, he was hooked for hours. Really heartwarming to see him struggle and enjoy the Mission Possibles. He quickly wanted harder levels to play, but clearly there were enough levels that needed more skills than he could make in a few hours. He also confirmed what I always liked best about SY: the variety and the cleverness of the levels.

[c0pperdragon]

Thank you for the update. As I am not an artwork specialist myself, I can not perceive the subtle differences in colors and hues as clearly as you do. But maybe even I notice the new palette to be a bit more colorfull still (but I already liked the old one). Of course I leave this decision completly to you. Same thing holds for the appearance of the stone walls. If other persons also consider the irregular structure to be more brittle, I am fine with that.

About the pushers/eleveators: I am not so happy with having too many different types of machinery. But also your proposal for a combination of elevators and side-pushers does not look that elegant either. I really have to try this out in a working level, so we need to postpone the decisions until I get the javascript version working. But please do not get too unpatient with me. There is quite somethng going on in my job currently...

[Charilaos]

Don't worry, hope all goes fine! I still have a lot to do anyways. Tiny update: 2 existing levels to see the new artwork come together. Also started polishing the Miner (thought of completely different player figures but having a miner makes so much sense).

Here's the all-time classic, with some gems during animation:

And here's Leo V, naturally with a great variety of elements:

[Charilaos]

Artwork once again updated, now even more vibrant and more consistent. Apart from earth and quicksand that need some work, all other elements now form a solid basis to redo the animations.

Few remarks:

• The elements that only have animating artwork - such as stones and acid - I left untouched for now as the animations need work.
• But! To test a few new animations, I threw in the 4 colored door animations and the gem shines. (note: the doors have the still image as the first frame, the gem shines unfortunately still are 15 frames of animation + a separate still [gem].png. I'll use the [gem].png in the next update to include the shine animation so we can get rid of the existing shine animation pngs)

There are 3 folders for the design assets, I'll use them as follows:

• /game/art: artwork
• /game/gfx: UI assets (mainly icons) + specification
• /gfxdesign: please delete this one to avoid confusion

And for some fun, here is the complete set of stills:

[c0pperdragon]

I am switching to this issue for the discussion about the game tiles and animations.

Very good work on the high-res tiles and animations!

I have tried to integrate a few of these into the program and immediately run into problems. It seems not a good idea to have high-resolution textures when the game itself only shows them in lower resolution (as it is when not having a retina display). This causes serious performance issues and also some rendering glitches like hair lines between earth tiles. I guess the solution can only be to scale down the tiles at loading time to get a pixel-perfect match with the screen resolution. I am not sure if the scaling should be automatically chosen or if there should be some user setting for this.

Also to keep the thing as perfect as possible, the 15-step scrolling (necessary for the 4 steps / second speed on a 60 Hz screen) imposes some restriction on which true tile sizes could be chosen:

120x120 , 60x60, 30x30 would work flawless in both respects 45x45, 75x75, 90x90, 105x105 allow perfect scrolling, but will probably not scale well - especially 105 could lead to reduced sharpness, I guess.
@Charilaos Maybe you could try out some of these scaling factors in see if the result is still OK.

I am not sure if the very low resolutions make sense, even on mobile devices. As it occurs to me, any mobile device that would support webgl in the browser needs to be quite capable already and will provide a resolution of 720x1280 at the least (https://deviceatlas.com/blog/most-used-smartphone-screen-resolutions-in-2017). So having 60x60 as lower limit for the tiles seems sensible.

For integrating the UI artwork, this will take a little longer, I am afraid...

[Charilaos]

I’ve also experienced some issues when testing directly after updating the artwork to 120x120 versions. Both devices I tested on were retina, both rendered everything twice as small (shouldn't be the case), one had terrible performance the other was fine, and all 120px tiles are rendered twice as large as the 60px ones (showing only the top-left quadrant of each tile) instead of being twice as sharp. Without any adjustment in code this would be expected behaviour.

To keep things as simple as possible:

• We should only use artwork of size 60 or a multiple (120). Ideally we'd only use 120 artwork that is forced to be displayed in a 60px squared area (CSS pixels, that is). This way, on all displays (regular density and retina) everything should show up the same size. On retina displays it would be twice as precise, not twice as large.
• Afaik, in CSS a pixel isn’t an actual pixel, but a point (as Apple likes to call it) or a density pixel (as Google likes to call it) and as such, independent of the actual device size. The same applies to mobile, which means that a 7201280 device that is retina/200% dot scaling has an actual screen real estate of 360640 CSS pixels/density pixels/points. (If I'm correct, the browser sees this CSS pixel resolution, rather than the actual display resolution including the scaling.)
• You could, of course, detect it's a phone-sized screen and then display the artwork in a 30px squared area, otherwise with 60px artwork phones would only display about 6*11 tiles on their small displays.

If forcing 120px artwork to be displayed in a 60px area (or 30px on phones) proves too problematic, I can think of 2 fallback options that have a higher chance of succeeding:

• I export the artwork in both 120px and 60px versions. With JS you can effectively detect whether the display is a retina display or not (https://stackoverflow.com/questions/19689715/what-is-the-best-way-to-detect-retina-support-on-a-device-using-javascript), and render the corresponding artwork set. This has long been the most common way of managing and rendering PNG assets on iOS devices (until more recently: the pixel densities on all devices now vary so uncontrollably that some folks gave up on PNGs and use SVGs instead, which is cool but holds a performance trade-off we probably don't want in SY).
• We just stick to 60px artwork, which is guaranteed to work fine.

Side note: small acid prep needed. I completed the acid animations (not uploaded yet) and baked in the corners so we have 4 flavours of acid (middle pieces, left-edge pieces, right edge pieces and both-edge pieces). This also means we can remove the overlaying acid tub corner pieces.

[c0pperdragon]

This whole scaling issue was a pain already before the apple guys decided to invent retina displays. The big problem there was that they wanted to try to hide the fact from the web developers and now requesting a canvas with a given pixel size gives you twice the pixel size on a retina display. When you then draw into the canvas, the drawing operations are also scaled to fit this wrong resolution. But somewhere all this attempts to fool the programmer fail and what we have then is a terrible mess. I am pretty sure I can sort out all this in my program, but it is tricky because I have no actual retina device to test my solutions.

About the asset sizes: We keep 120x120 for the tiles, but keep compatibility with any resolution. The program will decide by the image height how big each tile is and how many tiles are inside the image (tiles must be square for this approach to work). Upon loading I will scale the tiles down to fit the native pixel resolution (the true native resolution, so I have to find a way to reliably see through apple's deception). For a start I will provide 120x120 90x90, 60x60, 45x45 true pixels tile sizes (30x30 is probably too small for any recent phone)

[c0pperdragon]

I just did a bit or research, and it seems to me that the main point of confusion, namely the 'backingStorePixelRatio' functionality Apple introduced in Safari 6, was again removed again in Safari 7. So, I guess I can keep the implementation simple and just ignore any glitches that could arise on Safari 6.

[c0pperdragon]

Now I know what to do with the overall scaling! I will allow browser scaling in the game (Ctrl-+, Ctrl-- in chrome and probably in other browsers as well) and this will normally also keep the scaling settings between sessions. For this, I will keep the backing pixel canvas to always have the size of the true screen pixels (to avoid aliasing and hair lines). So changing zoom level will not affect the size of the backing buffer.
But the zoom level will effect the rendering of the UI elements, since they are designed to scale easily and they should not create performance issues because there are only few visible while the level is being played. On the other hand, the zoom level will effect the game tiles in a more indirect way. The program will calculate a sensible real pixel tile size that allows smooth scrolling and scales the tiles to this size on loading. Probably I can get away with just reloading all tiles on zoom level changes, so I don't need to keep the original tiles in memory.

[Charilaos]

Keeping the actual canvas size steady sounds like a good way to control the resulting sizes and preventing glitches. Try to only zoom in/out of the artwork, not the UI. The reason being you want to be able to scale the artwork to see "enough" of the level. But the UI needs a fixed size to guarantee usability (readability of text and clickability of buttons). Otherwise, if you scale the UI along, you end up with something unusable/unreadable like this:

For this, there must be a way to estimate / guarantee a certain size on display for the UI that is more or less consistent across devices. Ideally, the UI is defined in a fixed amount of pixels, multiplied by the display scaling factor.

[c0pperdragon]

I have actually done some coding on the issue and the state of affairs is basically this: The game will show all the UI elements in a size that is defined in CSS units, so on a retina screen everything should initially look normal. And you can easily use the zoom function of the browser.

The actual tiles of the levels are currently draw in a fixed true pixel size of 120. This is hardcoded right now in the file Game.js by the line this.pixeltilesize = 120;
You can experiment with this value to see how it looks in various circumstances. The tiles in the texture buffer are scaled to this value at loading time.

In the future this value will be calculated from the displays pixel density and the zoom level. When the user changes the zoom, the tiles will be reloaded to allow new scaling.

For your convenience I have included a minimal web server you can use to load the game from your file system with other browsers beside Firefox. You need to get a node.js installation and just start the webserver.js program in the webserver folder.

In my setup the game runs quite smoothly (60Hz) with chrome, but with terrible tearing. I will try to somehow improve on this. The performance in Opera is similar to Chrome. Firefox is very slow with a big window. Internet explorer is not that great either.

Would like to hear about performance on Safari,

Reinhard

[Charilaos]

There, I’m hooked again!

Absolutely love the update. Just ran it locally on Firefox on a retina macbook (4y old and no dedicated gpu to accelerate webgl). Works flawlessly. No tearing, no framedrops, a perfect 4 turns per second. The tiles (opd and new) are shown at exactly 60 CSS pixels so the size is very predictable, 1:1 with the intended size they’re designed for. The updated 120px tiles are razor sharp at a 1:1 ratio with the native resolution.

Also tested on a regular display and of course, this looks rather huge on a non-retina display:

Left: This is what you see on a regular pixel density screen (and this is a rather large one). Right: this.pixeltilesize set to 60. Works fine! If there were any way to detect whether system scaling is, say, <200%, this would greatly help.

Excuse the Christmas decorations and lights.

UI Scaling seems to work fine too. I'll test soon with webserver.js and on Safari.

Meanwhile, lots of animations in the making. Have a nice weekend!

[Charilaos]

If you pull you'll notice I pushed quite a few new animations! Some are unfinished placeholders just to make things look a little more finished. Some will require slightly new logic in the near future (example: a continuously animating open exit).

But for now, only a few small things need to change in the code with the current update:

• The bug has a bug: please correct it by rotating it 90 degrees clockwise so it looks in the right direction
• The robot animation is meant to be played continuously (it only animates when moving now)
• You can stop animating falling stones: "Stone.png" now holds a single image
• I've unified the falling and pushing animations of the bomb again into one animation, which is now found in "Bomb.png" (it's also updated in "Bomb Falling.png" and "Bomb Push.png" so you can already see how it should look, but these aren't needed anymore)

To be deleted The following assets can be deleted (after applying the todos above) as they're not used anymore. I've done some testing and it should work fine after deletion.

• Emerald Shine.png (shine integrated in Emerald.png)
• Sapphire Shine.png (shine integrated in Sapphire.png)
• Ruby Shine.png (shine integrated in Ruby.png)
• Citrine Shine.png (shine integrated in Citrine.png)
• Acid Edge Left.png
• Acid Edge Right.png
• Acid Edge Both.png (all three replaced with animating acid tiles for all occasions)
• Swamp.png (Swamp Move.png is already used for stationary+expanding swamp)
• Bomb Falling.png
• Bomb Push.png

[c0pperdragon]

I have used a few free minutes during a night-shift and adjusted the program to use the new graphics.

While doing this I have again noticed that the use of the Bugs and Lorries is currently quite wrong, as Bugs actually leave behind gems and Lorries don't. This should be completely the other way round, because in the new artwork you can actually see the gems. So the sensible thing would of course be to just swap lorries and bugs. This would be easier, if they were not mentioned in quite some level titles. Nevertheless I will do this soon.

Another thing I thought about: There are quite many animations for the miner, and there are absolutely identical animations for the second miner also. The only difference is the coloring. This fills up precious texture memory and slows loading. So, maybe I should just apply some color rotation while rendering the second miner. From the performance perspective this is no issue, because it appears only once.

[Charilaos]

We're steadily getting there!

Sounds very reasonable to swap the two enemies. Going through the levels to identify the names that mention the enemies won't be an issue. What might be an issue is that lorries are left-hand followers and bugs are right-hand followers. Swapping them means either a some levels have to be slightly redesigned to accommodate the changed moving direction - or (and this seems an easier option) - you also swap their moving direction. This way, no levels break functionally: we'd only have to change a few titles, and I'd have to change the animation of the lorries that is very directional.

About reducing the miner assets: very creative thinking there. I started experimenting and it seems a little unfortunate: the miner looks very ill and the colors don't fit within the rest of the color palette at all. Here's the result:

However! Looking closely at the animations, I think we can easily get rid of the actual mining animations. The earth feels so lightweight because the miner walks through it at the same speed as walking through void. Walking through earth wouldn’t look out of place. Walking and pushing are of course still needed, but this already saves us from 8 animation strips that would've been significantly larger than the ones they replace.

Updates

• Some nitpicky updates to the stone walls, and a big update to the Emerald Wall. It even has a shine animation! Doesn’t work out of the box of course, so I tested locally by replacing the swamp with it. Should have the same shining frequency as other gems.
• Gun animation added. You can remove the old "Gun Fire.png"
• Neatly rolling stones! I noticed you aren't using "Stone Left.png" so I put all necessary assets for the stone in "Stone Right.png". This means you can safely delete "Stone Left.png" AND "Stone.png"
• Slightly more emphasized shine animation when passing through doors
• Fixed a few laser glitches that makes them look cleaner and more continuous

Other Remarks

• You can safely remove the shine animation for sapphires as you did with the other gems
• (complete deletion list: Sapphire Shine, Gun Fire, Stone and Stone Left)
• Did you intentionally continuously shine the falling gems? It actually looks quite good! I think we can keep this as is and get rid of the 3D rotating gems. Saves space, some work and actually better fits the look and feel.
• The bag roll animation looks good but it rolls the wrong direction when pushed in either direction
• I noticed a little bug that only occurs on retina displays. Both lorries and bugs are hidden when moving in a specific direction. Unfortunately can't test which direction that is at the moment - but I think it is when moving to the right. Any clue what could cause them disappearing?

That's it for today!

[Charilaos]

The animation work continues with (finally) the miner, the basic swamp animation, the converter, smoother stone animations and more.

Question: how does "Earth Right.png" work exactly? Is the black part of the image simply overlayed on top of the earth? I've been experimenting with it and I have a feeling it either skips the first or last frame somehow. The animation is also still reversed (right-to-left): if you change that I'll upload a left-to-right version asap.

About the converters: "Converter.png" is the default image. Its animation should be played continuously (like the old converters did). "Converter Working.png" (new) is the lightshow for when items fall through.

[Charilaos]

The odd one out was the swamp and now it's growing and dripping! Have a look at Return of the Swamp and Great Dropping.

• Swamp Grow doesn't seem to be used! (I think it's only for growing up in void)
• Drop Left and Drop Right are for now simply reversed so swamp spreads more naturally until I have made these too.

[c0pperdragon]

Hi Charilaos!

I have been quite busy today to integrate your graphics and animations and to fix most bugs in the program related to this. Especially the explosions were a bit tough to get right.

I very much like the new swamp grow animation. I was even possible to eliminate the Swamp Hit animation because this can easily be created in the program by combining the drop with a grow animation.

"Earth Right" now works like all other animations with the frames being ordered from left to right. So it now looks wrong until you fix up the image.

Totally swapped the roles of Bugs and Lorries. I will have to adjust the level names and info a bit to make it fit. It is now totally natural that the Lorries leave gems. But you need to modify the animation (Lorry.png) because the wheels are now on the wrong side.

I want to say a few words about the new miner:

• Yes you are right. Color rotating the image to get the second mind just does not work.
• The pushing animation looks quite unnatural. You don't expect to have much leverage when your center of gravity is so far back.
• The animation for the arms and legs needs to be done differently: I want to have two halves of a full arm/leg swings which I will show in an alternating fashion. Each animation starts from a neutral center position and the first one swings the arm forward and return to center, and the second animation swings the arm back and to center again. By this we can have a fluid walk cycle that takes half a second (two turns for two steps - one step with left foot and one step with right foot). All key frames will then be in neutral position.

I this same trick can also be applied to properly bring the sloshing of the acid to a 1/2 second period. I am currently breaking the various Acid animations into two parts each to do this, but since it was not designed for this it does not look that great. Maybe you could provide acid animations that have some neutral position in the begin and in the middle so everything joins up correctly?

What do you think about some animations for the various keys? I could easily implement resizing or rotating with the program. For shine or other complex effects we would need animations graphics. I think it would be good to not overdo it by providing permanent animations. For shine animations, a random animation like for the gems somehow makes sense. Other animations (like the key telling you "I am here! Get Me!") should be done more predictably.

Next big things for me to tackle will be programming the UI elements you have designed. And afterwards (or partly in parallel) to interface to the data server to store user data (login, game progress, levels, etc.). Luckily, my brother Ronald has taken over the task to actually program the data server necessary for this and is basically finished now. :-)

[c0pperdragon]

I wanted to talk about one last thing with the animation that bothers me like since forever: The bag rolls just too fast. I really would love to have a solution like for the rocks with their triangular shape. Maybe you have an idea for this problem - and it would also be even better to find some visual appearance of the bag element that actually gives some excuse why on earth it is possible to open it by dropping a rock on it.

[Charilaos]

Hi Reinhard, I see, great news!

Quickly reversed Earth Right to make it all more playable.

Explosions look much better indeed. The order of successive explosions looks fine and the animation plays sequentially. However, it looks like the animation starts half-way, when the explosion is at its fullest. (In case you intentionally wanted to create this effect of more immediate impact - I was planning to make explosions appear more quickly and decay more slowly)

Swamp Hit: nice! I wanted to tell you exactly this but it seems I completely forgot to write that in my last post.

The swapped bugs and lorries make more sense indeed. I identified a little problem with lorries: they should be rotated 180 degrees as they're now dragging their gems along their path while having their wheels in the air. There is also a little issue with either lorries/bugs or the explosion: when a bomb/stone falls on them the lorries/bugs are now rotating 1 turn before they actually explode. I can't remember this being the case before. Both issues are nicely illustrated in Bugs Contain Gems.

Miner animations: good feedback! I was unsatisfied with the pushing animation for the exact same reason. No worries, that's why the concept of iteration is born. Regarding 2-turn walking animations: sounds like the right thing to do. I actually started creating the walking animation as a full 2-step cycle in a single turn. This way, the miner's feet were moving at the correct pace compared to the ground, but the animation turned out hysterically fast. Hence I ended up with the 1-step animation in which the miner (if you look very carefully) kinda moonwalks forward. A calm movement pace is more important than perfect correspondence with the ground, and a 2 turn animation will make it look even more natural as it allows for the full step cycle. Same accounts for acid, I see you already stretched it to 2 turns.

Keys: of course they need animations! I've had this idea forever that anything the player can pick up needs a subtle animation to draw attention - including TNTs and timebombs having a subtle shake as frequently as gems shine. For TNTs and timebombs I'd suggest this animation in code: rotate ccw 9 degrees, then clockwise 18, and ccw another 9 to get back to the original state. I'm still figuring out the ideal animation for keys.

Bags. Definitely true. Every design decision answers a "why". In case of the new bags, they're rounder and bigger because of 3 design goals: fill a larger part of the grid position, better justify a rolling animation and better justifying that huge emerald inside. But the rolling animation is indeed suffers because of the diameter/gridsize ratio now. A diameter of 60/pi = 19 would roll perfectly, but that's way too small for the bag. Interestingly, some older games such as Emerald Mine and Diamond Caves (if I remember correctly) have nuts instead of bags. Of course you'd use stones to crack them open! But then why the hell does a gem come out? And that's why I guess SY has had bags forever. The remainder makes sense, at the expense of discoverability of usage. That reasoning I believe is entirely fine, because the player is taught several times how to do this:

So while the discoverability issue is pretty much solved by every level involving bags, there's still the animation. Unlike stones - which are heavy and only moveable by rolling - bags can probably do with a sliding animation (in which they subtly deform) and look natural doing so.

Have a nice weekend!

[c0pperdragon]

Hi!

I have spent my Sapphire Yours Friday on much work on the game logic. Now there is support for custom remainders of the YamYam beast, but only to a certain extent. The only things that can be specified here are: Gems, bags and keys. This limitation comes from the way explosions are handled by the game logic now. But I guess these things are the most needful things in the game. And with the laser gun I already have created a way to replace the old YamYam-powered laser batteries. A nice side effect of this restriction is that there is always an upper bound of gems to be found in a given level. So the automated warning sound makes sense in most situations.

Also the robot speed can now be set like the swamp speed: 0=no movement, 1=fastest movement, 2,3,4,... slower movements. I have set up an experimental level pack to play with these features.

Finally I also fixed the sound effect playback which had some strange issues all the time.

Generally I must say that the game itself reaches a state of completeness that I spend more and more time on actually just playing some levels and less time in working on the program. I guess this is not an inherently bad sign: The game is still really nice to play and the levels are just brilliant. More so because I don't remember most of the solutions.

I guess my next thing should be to create the level editor to work on the built-in levels: Specify correct categories, re-evaluate the difficulty rating, bring more of the old levels into the new game now that the YamYam and the robots offer more possibilities. Maybe other persons would also like to work on this topic?

So that's it for today, Reinhard

[Charilaos]

Hey, thanks for the update!

I missed your last commit of one week ago. Unfortunately I’ve been ill for 3 weeks straight and not been able to do any work lately. But now I’m starting to recover, and so will the work to get SY closer to completion!

I also noticed it’s getting more tempting every week to actually play the game as it feels more complete.

Good thing the missing sound effects are back! And it’s nice to see the new UI being shaped up. Also: clever trick on the swamp growing sideways into earth! Of course it has to rotate back into the correct orientation after the animation, but it happens so fast you practically don’t notice.

Swapped lorries and bugs: will take some time getting used to, but the debris feels better! But! Maybe it’s a good idea to change the lorries in “Money rules the world II” back into bugs? (For cosmetic reasons, and more contrast. Will make the level a tiny bit easier).

The Yamyams however, I believe the restriction on debris defeats the point of custom debris, which is creativity. Gems, bags and keys seem too predictable and limited. One might want a stone in there to go with the bag. Or a safe to open with a bomb that exists somewhere else. There’s an element of curiosity and surprise, along with tremendous creativity. Sure, we have the laser gun which is an elegant replacement of the swamp-yamyam-ruby setup, but so much more is possible. Yamyams trapped somewhere and killed can spawn earth and walls, rearranging your walking path. Think of the continuous chaos caused in Lightmare. Sometimes you’ve got to be careful where to kill the yamyam, as it’s debris could be dangerous. Or its death should be strategically timed for the harder levels. I feel that limiting yamyams this way is taking away their fun and surprise too much. What’s your view on this?

Many weeks ago (maybe 2 months) I noticed the game runs a little slow on older computers and a bug where Armageddon II would freeze. Not sure if related. Since one commit later: both problems resolved. The current release is again slower compared to the past 2 months on the same older computer (5yo macbook pro, still decent but not 2018 fast) and Armageddon II is freezing again. I digged a little into the freezing issue: happens on every computer. Also happens in Kill the YamYam Beast and bio Recycling. Reproduce: kill a yamyam, make sure some of the rubies can fall down (if all rubies held in place by earth it doesn't freeze). After one turn, the game freezes (also in demo mode).

Levels! I've been doing some work on them in the background. I made a fairly exhaustive list of levels from the original SY that can now be brought back because of the updated game logic. Also started designing a few new ones, as I feel some of the introductory levels of the game are not as fun or cleverly designed as the more advanced levels. Last but not least: I made notes about a few levels that are broken. Remember Overroll, where you could simply roll the bag underneath the stones before we added the little wall? Another example: Firewall. Wonderful level, very broken. You can grab the gems and finish the level with no fear of the bombs exploding the exit - no need to prepare the power laser. I kept many more examples of levels that can be fixed really easily.

We should create an issue “Levels” to discuss optimizations in learning curve, changing level difficulties/categories, making sure there are enough levels in each difficulty and category, and mostly: creating new levels, especially a few more that use the newest elements / elements that are not used frequently.

We should probably ask in the forums (for those who are not aware of the discussion here) to contribute their best levels. Maybe it's even worth sending emails to the ones who originally contributed new levels on the old website - although I'm not sure how many of them would still check their AOL mail.

[c0pperdragon]

I did a bit of work recently to get the game logic in better working order and this fixed the freezes you mentioned. Also I have completely redone the way the YamYams move and explode and they behave more like bugs and lorries now, with the same blast radius and trigger distance. So it feels much more consistent now. Of course this broke basically all demos in levels with YamYams.

About the possible YamYam debris: This is a real problem because of the way the game logic works right now. I try to explain it a bit: Every field in the game is represented by a numerical value from 0 - 255 (a good old Byte, you could say). This numerical range is mainly caused by the way the modification buffer works (a much more complicated matter into which I will get here). So everything that happens in the game world must be flattened down to changes of this matrix of numbers which can only stay in this limited number range.

You could say that having 256 possible different things on each spot would be more than enough. Unluckily it is not when considering explosions. To make the explosions leave behind some extra stuff, I need to reserve 4 different numerical values for the explosion progress. I already need that many values for all gems, keys, bag, which is 4x17 = 68. I have a little more numbers to spare (about 30 now), but this is nowhere enough to allow a full custom debris definitions. As I want to keep this system, we could squeeze in just a tiny bit more possibilities. Maybe just some more mobile objects: Rock, Cushion, Safe. I guess, with the Safe alone you could create a very complex multi-staged puzzle to turn YamYams into emeralds (maybe using YamYams to blast the previous safe and releasing the necessary rock to also open the bag...).

[Charilaos]

Had some trouble finding a couple levels, I noticed you started migrating them between difficulties. The ones I could find made total sense.

More importantly, the game definitely runs more solid now!

The Yamyams? My 2 cents is they don't feel convincing now. If the current game logic is the limiting factor for full freedom in YamYam debris, we end up with a Yamyam that has an identity crisis. This way, you’re going through the trouble of supporting variable debris, in a way that doesn’t allow for full creative freedom, nor the predictability of having a consistent remainder. If we go for the former solution (consistent debris), at least we’ll have sufficient headroom in those 256 slots for possible future additions. (conveyor belts, fire, a switch to (de)active whatever’s next to it, a robot that walks in random directions, teleport stones etc.)

The collision logic is quite deadly in certain levels now but the consistency is definitely worth it - I think for new players it would feel like expected behavior as lorries and bugs are triggered the same way. Maybe give the robots the same treatment for complete consistency? (I have a feeling there aren’t that many levels with robots anyways and most of them are hard - only the tutorial level needs to get a little more breathing room.)

Some artwork updates that need attention:

• Elevators will look a little better if you don't show the animation when they go back down.
• The pillows are now replaced by new ones. Especially the animations are more pleasing, but I noticed "Pillow Move.png" is not used now, as "Pillow.png" is used for both pushing and when other objects fall on top. I tested both and it's definitely worth keeping both animations.

[c0pperdragon]

Oh dear! Again I experienced the programmers laziness and I considered my efforts good enough. It is really good luck that you did not easily accept my excuses ;-)
So now we again have custom YamYam remainders: Gems, rocks, walls, acid, drops, TNT, YamYams, whatever. The only restriction is that you can only define one set of remainders for each level.

Yesterday I found the solution how to do it: Instead of having a explosion-debris-chain for each possible piece of debris (which would amount to several hundreds of values in total), I now just have 36 of these intermediate objects: 4 for each section of the yamyam. This now fits comfortable into my 256-number space and I still have about 30 to spare for future expansion.

[Charilaos]

Amazing news to hear about the Yamyams!!

You might have seen I did a commit with new gem break animations. I was working on a very satisfying crush animation when the stone crushes the sapphire (or citrine), but then I kinda forgot that the same animation also plays when the citrine breaks by falling - and there it looks odd. Before creating yet another animation for that - I'll try to let the "Break" animations crumble the gems instead of squeeze them.

Please don't forget the 2 bullet points from my last post for artwork updates. I'll delete "Wall Dark All" and "Gun Fire" as they're unused, to clean up a bit.

Also! the one asset I haven't replaced in ages (and therefore isn't high res yet) is the Earth tile. The asset I made 3 years ago isn't the kind of thing you do in vectors, nor does it perfectly fit the more vibrant and solid feel of the newest artwork - but it has this quality of looking nicely neutral. I'm finally getting to a new style for it that's shaping up to be a worthy replacement. What do you think?

[Charilaos]

Since we didn't agree we owe each other a beer every time we break something... I'm breaking the Exit door. But! It's for good reason: I made an animation for the open exit.

I kept the filenames "Exit.png" and "Exit Closed.png", otherwise the game wouldn't launch. However, it would make sense to rename "Exit" to "Exit Open". They're both animations now.

Also, the textures and edges of Earth fundamentally don't want to be vectors, but I finally created Earth tiles that are comfortably replacing the old one (and look way better than the example I sent in my previous post).

On to some exciting stuff. I remember you wanted to create some depth layers to make the game more alive. I've looked into this. Background layers distract from the gameplay, no matter what. Foreground layers however, add a nice touch so I came up with 2 scenarios:

Explosions with hovering smoke (fades out in a few turns) add just the right amount of cool-factor.

The Exit door, that's where the real visual improvement shows. With the new exit, I've had the design goal to make it look like a portal to heaven. Another design goal was to completely open the entrance, because otherwise it looks like the miner wouldn't fit in. But: the outline still needs to look rounded, as objects should still be able to fall off. While these goals are satisfied, the overlay animation with rotating lens flares in the 4 colors of the gems will draw the attention of the player to the exit when opened:

How do you think we can best implement these overlays? Since the animations are way larger than the 60px game tiles, creating them in webgl might just be the easiest option. Exporting them as large png animations is of course another option.