Andrew Davie

Here's a short video showing some of the conveyor belts in operation. The upper one shifts objects right. The lower... left. I can see a sort of "mechanical world" where there are grinders. crushers, conveyors, taps, etc. Not sure if it's going to stay; still needs some work... but it's interesting at least. WenHop_20230421@23_54_18.bin

I have a 160 MB 'dragonsLair.mvc' on my machine but I'm not setup anymore to do these. I have put a small snippet of a screen recording up. But it's rather dim, sorry...

The grinders would also work as gears, and I had a couple of thoughts around this. The first was that the "gears" start up non-animating, and a "chain" of gears snaking up the screen could be connected to some sort of sliding (vertically or horizontally) barrier. For example, gears could be connected to a heavy door. As you somehow turn the gears on, the one you turn on starts turning, which turns on the one(s) beside it, etc., etc., and eventually they raise the heavy door. Another thing I though of is a conveyor belt. Not sure what it might be used for - perhaps to simply transport inaccessible dogeodes to where you can actually get them. You'd need to turn the conveyor belt on. Here I have implemented a preliminary test-version just to see how a conveyor belt might work in the game. It's OK. This leads to the idea of a "mechanical world" where there's lots of underground machinery (crushers, grinders, doors. platforms. conveyor belts) and you need to somehow hook up or activate them in the right sequence to get through it or access the dogecoin. WenHop_20230416@00_40_54.bin

Sorry for the delay. Thanks for the suggestions/ideas. Thought about that. Because of the animation in this, it's actually quite expensive to define a whole block of duplicate characters to get that effect. There are 3 characters in the animation, each 30 bytes + table pointers (3 ints) + new char type entries (3 bytes) so maybe 120 bytes given everything I'd need to do for this. It's still a possibility, but maybe down the track. The impassable wall is workable. As it stands the water is already impassable. I could have a secret entrance in one of the impassable waterfalls, for example... like a cave you need to get into but can't. I'll have a think. In the latest version I hope it looks more water-like. It's not easy to get good looking animations in 5 pixels wide Yes. Bombs are a definite candiate for a tool you could have/use. If we had a huge block of rock, for example (kind of like the conglomerate of dogeoids slot together to form one mass. well perhaps we could have a mass of boulder which is essentially un-mineable. Or it takes forever. I could make the rock take 10 digs to break (one of them) whereas the dogeodes take 3 and you "mine" the whole lot of them in one go. Breaking through a rock barrier could be extremely tedious. So you use a bomb. I already have screen shake which would look good with that. Thanks for the ideas on the bomb. I'll remember this and come back to it. I'm a one-button fan and basically too lazy to learn other interface/hardware. It's going to be one-button and I have no plans/intent to do anything new there. That's a pretty neat idea. I'll get around to doing that sometime, for sure.

I haven't posted many videos of the normal chronocolour display - my preference being the interleaved (iCC) version. Here's a video update of how things are looking using normal chronocolour. It's not too bad, actually. I put a slerg in, and made a minor change to the grinders; now there's a bit of a chance of a grinder knocking something that's sitting on top of it off to the side. WenHop_20230415@20_45_27.bin

Does anyone wonder how all of this is done? Let's look at the grinders. There are two "characters in the grinder, each being 5 pixels wide and 30 scanlines deep. Those scanlines being grouped into "trixels" 3 scanlines high of the iCC triplet-colour format. But how, if the game frame rate is about 10Hz... do the things on screen animate at 60Hz? Well, there's an inbuilt "auto-animate" capability. Each character has an innate "type". For example, the two grinder characters are "TYPE_GRINDER". This type is retrieved by a lookup in a table called "CharToType[...]". So, every single one (of the 120 different) characters in the character set is associated with a type. There are currently 38 different types. But, back to the grinders as an example... So every frame the code calls an "animate" subroutine. This subroutine runs a tiny little "program" for each of the types. There's a table called "animate" which (for each type) points to a little animation program, or contains 0. If 0, then nothing's done. But if the entry points to an animation program, then the animate function "executes" the program. Here's a sample "program" for one of the types... static const char AnimateGrinder[] = { CH_GRINDER_0, 12, CH_GRINDER_1, 12, ANIM_LOOP, }; So, what's happening here? Well, the first line is saying "display the character called CH_GRINDER_0 for 12 frames". And the next line is similar for the character called CH_GRINDER_1. And the ANIM_LOOP is a command to restart this little animation program from the beginning. Pretty simple. So let's get to the screen draw, which happens every frame.... When the draw grabs a character number to draw (e.g., a CH_GRINDER_0) from the board (the 40 x 22 grid of what's what that you move around), it doesn't actually draw the character CH_GRINDER_0. What it does is look up the type of the character (which is TYPE_GRINDER), and then it looks at the animation program (if non-zero) for that type, and retrieves the character to draw from the current animation pointer. So what will happen is that anything in the board containing CH_GRINDER_0 (or, for that matter, any character which resolves to TYPE_GRINDER) will go through that animation program and ***every single character on the screen of that type will display the same character from the animation program for that type***. This is a limitation but also a blessing. It means you can't individually animate characters which are the same type, but it also means we have essentially free animation for everything of that type, at a frame rate of 60Hz. Another way of looking at this is that these simple automatic animations are inbuilt into the 60Hz draw system and cost almost zero processing time to do. There are independent systems running at 10Hz which allow you to animate things independently (that is, individual cells in the 40x22 board can make their own "decisions" if the everything-of-the-same-type-all-at-once system is not useful). An example of those other systems is the lava, the water, boulders, all the typical gameplay stuff. Things that use the automatic system are obvious in the animation table, shown below... const char *const AnimateBase[TYPE_MAX] = { // indexed by object TYPE (def: ObjectType in attribute.h) // =0 if object does not auto-animate // Note that the type number is an ID, not ordinal. That's because the continuity may // be compromised by the conditional compilation. Beware. 0, // 00 TYPE_SPACE, 0, // 01 TYPE_DIRT, 0, // 02 TYPE_BRICKWALL, 0, // 03 TYPE_OUTBOX_PRE, AnimFlashOut, // 04 TYPE_OUTBOX, 0, // 05 TYPE_STEELWALL, 0, // 06 TYPE_BOULDER, AnimPulseDoge, // 07 TYPE_DOGE, 0, // 08 TYPE_HUSK_PRE, AnimRockford, // 09 TYPE_HUSK, 0, // 10 TYPE_PEBBLE1, 0, // 11 TYPE_PEBBLE2, AnimGrab, // 12 TYPE_GRAB, 0, // 13 TYPE_DUST_0, 0, // 14 TYPE_DOGE_FALLING, 0, // 15 TYPE_BOULDER_FALLING, 0, // 16 TYPE_DUST_ROCK, 0, // 17 TYPE_DOGE_CONVERT, AnimSwitch, // 18 TYPE_SWITCH, 0, // 19 TYPE_PUSHER, 0, // 20 TYPE_PUSHER_VERT, 0, // 21 TYPE_WYRM, 0, // 22 TYPE_BOULDER_DOGE, 0, // 23 TYPE_BOULDER_DOGE_FALLING, AnimConglomerateMid, // 24 TYPE_BOULDER_DOGE_CRITICAL, 0, // 25 TYPE_LAVA, 0, // 26 TYPE_PEBBLE_BOULDER, AnimateGravity, // 27 TYPE_FLIP_GRAVITY, 0, // 28 TYPE_BLOCK 0, // 29 TYPE_PACMAN_DOT AnimateGrinder, // 30 TYPE_GRINDER 0, // 31 TYPE_HUB 0, // 32 TYPE_WATER AnimateWaterFlow, // 33 TYPE_WATERFLOW 0, // 34 TYPE_TAP 0, // 35 TYPE_OUTLET AnimateGrinder1, // 36 TYPE_GRINDER1 }; In summary, every time I add a new "thing" that does different stuff, I add a new TYPE to the system and I also add new characters to the character set. Another really interesting thing is that each TYPE of object has a bunch of attribute flags. The attributes describe how objects behave -- do they participate in explosions, are they treated as blank space, do they have the awesome "rounded corners" of the dirt (and I should explain how that's done sometime - remind me), etc., etc. Here's the rather large and impressive attribute table... const int Attribute[TYPE_MAX] = { // see attribute.h "ObjectType" #define _ 0 // LAV = Object immediately turns into lava bubbles when below lava line // QUI = Quiet object. No noise genrate when things fall onto it // HRD = Hard. Boulders create dust when falling onto // ACT = Active object that must be processed every frame // BNG Explodes in lava // CNR = surrounding space fills in corner // PAD = do the corner padding for this creature type // SHV = the pushers can push this object if next square blank // MLT = melts when in lava -> CH_LAVA_00 // PUL = object pulled by lassoo // // PH1 every nth frame processes... // PH2 // PH4 // GND object can be "grinded" // 21 // 22 // 31 30 29 28 27 26 25 24 23 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 // CNR PAD SHV BOU DGE MLT DIS PUL PH* MIN DRP RKF LAV QUI XIT HRD SQB BNG GRB DRT SPC PER XPD ROL // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ _ |PAD| _ | _ | _ | _ |DIS| _ | _ | _ | _ | _ | _ | _ | _ |RKF|LAV|QUI| _ | _ | _ | _ | _ | _ | _ |SPC|PER|XPD| _ | _ , // 00 TYPE_SPACE, CNR| _ | _ | _ | _ | _ |DIS| _ | _ | _ | _ | _ | _ | _ |DRP| _ |LAV| _ | _ | _ | _ | _ | _ | _ |DRT| _ |PER|XPD| _ | _ , // 01 TYPE_DIRT, _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |DRP| _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 02 TYPE_BRICKWALL, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 03 TYPE_OUTBOX_PRE, _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |XIT| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 04 TYPE_OUTBOX, CNR| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |DRP| _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 05 TYPE_STEELWALL, _ |PAD|SHV|BOU| _ | _ | _ |PUL|PH2| _ |GND| _ | _ |MIN| _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 06 TYPE_BOULDER, _ |PAD|SHV| _ | _ |MLT| _ |PUL|PH2| _ |GND| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG|GRB| _ | _ | _ |XPD| _ |ROL , // 07 TYPE_DOGE, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 08 TYPE_HUSK_PRE, _ |PAD| _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ |QUI| _ | _ |SQB| _ | _ | _ | _ | _ | _ |XPD| _ | _ , // 09 TYPE_HUSK, CNR| _ | _ | _ | _ | _ |DIS| _ |PH4| _ | _ | _ | _ | _ |DRP| _ |LAV| _ | _ | _ | _ | _ | _ | _ |DRT| _ |PER|XPD| _ | _ , // 10 TYPE_PEBBLE1, CNR| _ | _ | _ | _ | _ |DIS| _ |PH4| _ | _ | _ | _ | _ |DRP| _ |LAV| _ | _ | _ | _ | _ | _ | _ |DRT| _ |PER|XPD| _ | _ , // 11 TYPE_PEBBLE2, _ |PAD|SHV| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |RKF|LAV|QUI| _ | _ | _ | _ | _ | _ | _ |SPC|PER|XPD| _ | _ , // 12 TYPE_GRAB, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ |RKF| _ |QUI| _ | _ | _ | _ | _ | _ | _ |SPC|PER|XPD| _ | _ , // 13 TYPE_DUST_0, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 14 TYPE_DOGE_FALLING, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ | _ , // 15 TYPE_BOULDER_FALLING, _ |PAD| _ | _ | _ |MLT| _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ | _ |XPD| _ | _ , // 16 TYPE_DUST_ROCK, _ |PAD| _ | _ | _ |MLT| _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 17 TYPE_DOGE_CONVERT, _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |GRB| _ | _ | _ | _ | _ | _ , // 18 TYPE_SWITCH, _ | _ | _ | _ | _ | _ | _ | _ |PH1|PIP| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |ROL , // 19 TYPE_PUSHER, _ | _ | _ | _ | _ | _ | _ | _ |PH1|PIP| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 20 TYPE_PUSHER_VERT, _ |PAD| _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 21 TYPE_WYRM, _ |PAD|SHV|BOU|DGE|MLT| _ |PUL|PH2| _ |GND| _ | _ |MIN| _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 22 TYPE_BOULDER_DOGE, _ |PAD| _ | _ | _ | _ | _ | _ |PH2| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ | _ , // 23 TYPE_BOULDER_DOGE_FALLING, _ |PAD|SHV|BOU|DGE| _ | _ | _ |PH2| _ | _ | _ | _ |MIN| _ | _ | _ | _ | _ |HRD| _ | _ |BNG| _ | _ | _ | _ |XPD| _ |ROL , // 24 TYPE_BOULDER_DOGE_CRITICAL, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ | _ | _ | _ |SPC| _ | _ | _ | _ , // 25 TYPE_LAVA, _ |PAD| _ | _ | _ | _ |DIS| _ |PH4| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ |BNG| _ | _ | _ |PER|XPD| _ | _ , // 26 TYPE_PEBBLE_BOULDER, _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ |BNG| _ |DRT| _ |PER|XPD| _ | _ , // 27 TYPE_FLIP_GRAVITY _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 29 TYPE_BLOCK _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 30 TYPE_BLOCK _ |PAD| _ | _ | _ | _ | _ | _ |PH4| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |ROL , // 31 TYPE_GRINDER _ | _ | _ | _ | _ | _ | _ | _ |PH4|PIP| _ | _ | _ | _ |DRP| _ | _ | _ | _ |HRD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 32 TYPE_HUB _ | _ | _ | _ | _ | _ | _ | _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ | _ | _ | _ |SPC| _ |XPD| _ | _ , // 33 TYPE_WATER _ | _ | _ | _ | _ | _ |DIS| _ |PH1| _ | _ | _ | _ | _ | _ |RKF| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |XPD| _ | _ , // 34 TYPE_WATERFLOW _ |PAD| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 35 TYPE_TAP _ | _ | _ | _ | _ | _ | _ | _ |PH4|PIP| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ , // 36 TYPE_OUTLET _ |PAD| _ | _ | _ | _ | _ | _ |PH4| _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ |ROL , // 37 TYPE_GRINDER1 // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ }; So, in the main processing loop... I can quickly determine what things an object needs to do without a whole bunch of conditional code. I simply load the character from the board, convert it to a type, and look up the attribute I'm interested for that type... for example, this code is used by the grinder to determine if the character above the grinder should be destroyed... if (Attribute[CharToType[up]] & ATT_GRIND) { ... we don't need lots of conditionals (is it a boulder, is it dogecoin, dogeode, or any other of the 120 characters)... just a single lookup for everything. That's it for now.

Things were running slow. Mainly because of inefficiencies in processing lava. I've cleaned all that up, and addressed the speed issues. Also a few gameplay fixes here and there. It's all super-busy here; I'm just pushing the systems at load to make sure all is running properly. Seems OK. WenHop_20230414@21_21_17.bin

It's like one of those image-ident / captcha things I SO HATE. "please select all the squares with Wen Hop" Put all together like that -- pretty cool for a '2600 game.

At the end of watching a YouTube video, the algorithm feeds to me a grid of potential other videos I might like to watch, in the form of thumbnails. The one it presented to me today was pretty interesting - a grid almost entirely Wen Hop screens. I do like the effect of seeing these all together!

Prelim grinding action drop dogeodes on 'em -- and also when you bump into 'em. WenHop_20230413@23_02_48.bin

First appearance of the grinder. Graphics by @TIX. Doesn't do anything yet - just checking out the visuals/animation.

I'll take this recent comment, left on one of my YouTube Wen Hop videos, as an unintended compliment...

Very nice; TY. I will put these in soon. Let's call the one on the right "the grinder". Looks great.

Your animations have given a whole new life/look-feel to it. Things that I could use - a "reaching-over a long way" kind of frame/animation for turning on/off the tap. I still have to think of a way to "turn on the tap below you", too. At the moment it's horrible because the player is a very long way from the tap when he's above it. I could extend the tap upwards but it wouldn't look the greatest.

TY. I live for feedback. Good and bad. Yes, maybe. I want to have a vast pool of things to choose from when I have to whittle things down. TY for the report. Interesting one. I think I may have found/fixed this. See attached binary. If it's fixed, I know kinda what was happening but not exactly why. It's to do with the drawing of the tool "menu" going off the screen boundary. Shouldn't have happened; I've not looked too closely. Will investigate, but as noted I think the attached will be OK. Objects other than the player are restricted to " character" boundaries -- that is, they can only move in chunks of 5 pixels horizontally and 30 pixels vertically. Pretty clunky, which is not going to work for "floating" objects. I'd have to, instead, use an overlay draw system -- like the butterflies on the title screen of BoulderDash#2... which I don't really have processing time for. Possible, but not going to happen here. The other major issue with this is freeform movement comes with additional complexity of handling collision detection with things in the background - a whole different kettle of fish, so to speak. So, not likely to happen. I hope you are feeling better soon. Space is tight - about 1K left and I have all sorts of things that I want in the game currently disabled. So in reality it's oversize for 32K which means at some point I have to convert to CDFJ+. and at that point space won't be an issue at all - I can keep evertyhing, add a gazillion frames of animation.... sky's the limit. The only real limitation would be my ability to ever finish such a game. Finishing stuff isn't my strong suite. WenHop_20230410@21_26_55.bin

Perhaps my updates are too frequent. It seems like a lot of work for only a few views. On the one had I like keeping things rolling and doing lots of small little things that I can share (even though some of them are actually quite major)... on the other hand it seems like I'm working with an audience of just one or two. Thing have been really zooming along recently, trying out all sorts of ideas and now it's a long long way from Boulder Dash. At least I think so. And more to come. I was thinking about how to work thxe controls - at the moment you just walk in the direction you want, and if you hit a mine-able object then out comes the old pickaxe and away you go. No thinking required, really... and for me it seems to be working really well. That leaves the button - and in this version you're "laying pipe" whenever you press the button. It's a bit buggy, but essentially just hold button down and move, and there will be pipe left wherever you go. There are complexities regarding where to join up pipe, etc -- solvable but what's there is just a what-if so I'm happy enough with it. Well, let's say that's what the button does - lay pipe. So that doesn't leave much of any room for any other actions. Many can be inferred by context, depending on what you're pressing against, for example. But I have plans for more "actions"... and so I've introduced a "tool menu". The idea here is that you'll have a bunch of "tools" and you first double-click to bring up the visual menu/icon lower right -- and then you choose which tool you want, click the button, and the tool you have selected is on the joystick button. In this binary (and the video), it's a mockup and doesn't actually change anything - but the icon represents a plumber's pipe wrench... hence laying pipe. Additional tools could include a bomb, the lasso, a gun, a call button to call your ship down from orbit, etc. So, that's the update for today. Remember -- button + move lays pipe, and double-click brings up your tool "menu". WenHop_20230409@22_52_52.bin

What else would you expect from Wen Hop, than "laying pipe" being one of the things you have to do. Careful, or I'll put chickens in that you have to catch with the lasso, and thus you'll also have to be "pulling chicks" Anyhow, here's a bit of an experiment to see if "laying pipe" would work. I think it does. I could build this into game mechanics.

Another study in pipe/water animation. This one is OK - surprisingly it doesn't seem to matter much that the water isn't blue... it's more the animation and impression of movement that matters. This one is OK. Last for the day. WenHop_20230409@02_21_38.bin

An experiment/study in alternate water animation...

Last for today... The piping now has a functional tap, and you can turn it on and off to start/stop the flow of water. In this video I just muck around a bit, looking at the various visuals and playing with the tap. I have the initial stream falling in slow motion just for checking out the operation here - it will be much faster in actual play. This all leads to the idea of a network of pipes with on/off junctions, and you need to feed the water to a preset place. Completely new gameplay opening up. Hmmmh. The controls aren't debounced, so very touchy. Very early days for this, but you can play with turning the tap on and off. The water below will not start rising until you turn on the tap for the first time. It keeps going after that, even if you turn the tap off -- will fix later. Still deciding if this is "good" - but at least it's totally different. A few things of note; the "hub" beneath the tap now shows the on/off status of that hub. I envisage a network of piping and hubs and you need to run around and turn on/off taps to get the pathway for water to a particular place. Might not work, as you can't cross pipes. But we shall see. The tap also shows the on/off state, of course. WenHop_20230408@23_55_51.bin

So, based on the observations above... I wanted a feeder pipe and flowing water. First appearance of a feeder pipe, pumping water into the mine. I can't change the colours from what the mine colours are, but it doesn't look too terrible. Kinda. This was just a prelim "what if" -- I can change the visuals of the falling water to be a bit less awful. Perhaps put some spray, etc. The idea here is that we'll have a switch/tap on top of the pipe junction, or maybe on the pipe... where you can turn on the water flow. You might have to solve puzzles to get to it. For now, I'm re-using components so when the water level gets above the pipe exit, the pipe suddenly thinks it's a crusher! Easy to fix; this was just a quick 'n dirty. WenHop_20230408@21_51_51.bin

A note on the observed differences between gameplay under lava, vs. under water. Both lava and water dissolve blocks of dirt, causing anything above the dirt to fall downwards into the water. However lava also *melts* some objects, such as dogecoin and dogeodes. This melting process is slower and random, so eventually under lava most objects will just disappear. In water, the objects remain, allowing you to build vast hoards of dogecoin to collect. This will balance of course by some sort of oxygen limit. My point, though, is that they are both *significantly* different in feel/gameplay. Because water "concentrates" dogecoin at the bottom of the screen - you effectively get access to all the coin on the planet just by going back and forth at the very bottom, underwater... water planets are a huge bonus for collecting doge. So it's going to be useful having some sort of valve or piping where water can be introduced to a planet to help you mine.

More work on the underwater stuff. Note the bubbles and breathing Came out pretty good. Not sure about the wavy-type lines, though. Edit: I dumped 'em. WenHop_20230408@19_21_04.bin

Well, it's analogue hardware being pushed to the very limits of exact timing. There are analog components involved which are going to be affected in "performance" by variations in manufacture/materials and temperature. I'm very much not surprised a hairdryer could trigger something that was "right on the edge" in the first place. Happy to have found/demonstrated it. So yes, it's normal behaviour. But mostly software doesn't push things right to the edge so it's never seen. That's my view on what's up.

The beginnings of underwater stuff.