Jump to content
IGNORED

Wen hop? The Search for Planet X


Andrew Davie

Recommended Posts

1 hour ago, Prizrak said:

Gave it a run on real hardware because the emulator on my phone won't do it any justice. Love the astronaut suit vs regular guy because it better fits the theme your going for. Using the left/right to break rocks and get dogecoins is intuitive and makes sense. I'm gathering there's no use for the fire button with the multi-ray weapon yet? Playing on my phone I never got past the first level but I found it pretty easy to do on my system. The addition of the crushers makes things interesting and avoiding them can certainly be tricky as you remove a lot of the dirt between them. The worms are interesting are and a nice departure from butterflies and other cave creatures we are used too. It may be a cave game, but it doesn't feel like BD in any way to me. 

 

TY - appreciate the feedback!

 

  • Like 1
Link to comment
Share on other sites

So, working some more on game mechanics I'm settling on the notion that dogecoin are unstable.  The challenge on any planet is, of course, to get enough dogecoin as fuel for your hop to the next planet.  Last binary I added dogecoin disappearing in a puff of disentanglement.  This one also introduces the concept of dogecoin stable-state. That state is, of course, when we have the dogecoin embedded in rock.  This version adds a small tweak that when any (bare) dogecoin is next to at least two rocks, then the dogecoin is converted to rock. And that has the follow-on effect that that rock and the (at least two) it was besides... become an entangled dogecoin mass (which you mine, of course, to expose the dogecoin for collection). Another item added is that dogecoin mass is also unstable - but less-so than bare dogecoin. So occasionally one element of that mass also disintegrates.  But not to a coin, just to nothingness. And of course there are the slergs going around eating any dogecoin they encounter.  This makes for a rather complex sequence of happenings that makes it quite tricky to get "sufficient" dogecoin, and has excellent visuals. I added the "explarkes" (exploding sparkles) of doge uncertainty whenever these events happen, so it's very busy graphically. It does need tweaking, but leave the screen long enough and all the rocks disappear and there's no chance of collecting any more doge. I like it. Also, slergs are really annoying.




 

WenHop_20230315@16_05_51.bin

Link to comment
Share on other sites

I have a "pool" of 12 reusable pixels, so to speak. These are individual pixels (white only) that can be given a speed and direction. I've added use of these to various parts of the game during gameplay, like when a dogecoin is collected by a slerg, or when you grab one, or when the crusher impacts something. I've also put in various gameplay tweaks like the dogecoin converting to dogeblocks with embedded coin whenever a dogecoin is beside two rocks. The completely entangled dogecoin inside dogeblocks also use the white pixels to indicate their unstable state. Dogeblocks also randomly unentangle and disintegrate. The crusher now, literally, crushes the dogecoin too.  It's all very busy and showing off the system capabilities. Somewhere in there, there's a game. I have a rather neat "pixel recycling" system going on here, so although it looks like there are more than 12 of those resuable pixels happening at some times... there's only ever 12 maximum.

 

 

WenHop_20230315@19_37_16.bin

  • Like 1
Link to comment
Share on other sites

On 3/14/2023 at 6:08 PM, TIX said:

Here is what I have so far,

more to come !

 

astronaut-guy-sheet-v1.png.0201badda3bf8bed18aa55d4bcad23d2.png

 

 

TY for this - these look great.

Apologies for the slow response;  I will need to write a small utility to do the conversion to my internal format.  Doing it by hand would work, but slow and I'm sure I will need to re-do things at some point so better to put in the effort now. I haven't been up to that for the past few days; may try and tackle it on the weekend. I do have a day job, these days... so finding time for all the things I want to do is difficult.

Thanks again.  Nice job.

 

  • Like 2
Link to comment
Share on other sites

Today I thought I'd have a stab at the utility to convert the image that @TIX made, with the animations. Was about to make a start when I thought "mmh, I wonder if chatGPT could do it?" so off I went, and typed in the following...  

 

write a python program to read an image file, dividing the file into a grid of 4
across and 9 deep equal-sized areas. For each of the areas, iterate all the lines
in the area and for each line iterate each pixel. Where a pixel is non-background
colour, output "X" and where it is background colour, output "_". At the end of
each line in the area, output a new line. Between each of the areas, write a 
comment indicating the area number identified by x,y position in the original
image.

 

And, believe it or not, that generated a functional python program that actually worked!  I only made a few small modifications to put commas in here and there, and I now have a tool that directly converts the above file of animations. So, easy peasy to update whenever required. It's quite amazing. Programmers are endangered.

 

So, I've dropped a few of the frames in place of the original.  It's great, but clearly I need to tweak things. Particularly the movement/scrolling combined look very jerky now - probably because the white/black is so stark that it doesn't disguise the clunkiness that was there. Remember I have to improve the movement so that it's compatible with 5-wide chars (it's still calculating for 4).  But anyway, the real point of this update is just to give a preview of what the new sprite design looks like.  Pretty awesome.

 

I have the "stand still" frame animating through the walk sequence, just for debugging purposes to clearly show what the walk frames look like.

 

 

 

 

WenHop_20230316@20_09_07.bin

  • Like 6
Link to comment
Share on other sites

I've updated the movement to the new char size, so this one looks LOTS better...

BUT... I'm aware everything feels a bit sluggish and unresponsive. That's because I've loaded so much into this and so much is happening onscreen... it's just pushing the system further than it comfortably goes. I either reduce complexity, or switch to one of those cool-sounding dual-CPU boards from @batari and then I never need to worry about speed ever again.

 

 

WenHop_20230316@21_39_00.bin

Link to comment
Share on other sites

Now that the movement is more in sync I can see the spritework is awesome!  It has character - which is hard to do at this resolution.

 

I feel like he had a challenge at the mid section (arms/backpack).  Sometimes the backpack and arms kinda blend in and/or are only partially recognizable.  But, that's hardly noticeable. 

  • Like 1
Link to comment
Share on other sites

Not much of an update, really. Experimenting with a colour change for the helmet. Cleaned up the offsets during some of the animations. Made sure all the sparks are generated from correct offsets (I really like the hammering sparks BTW). The longplay video below shows lots of rocks and dogeblocks in action... pretty cool.  Everything still feels a bit clunky though.. will have to see what I can do; not sure if I need a frame rate speed (which is problematic in itself because with higher frame rate -> faster player movement. But with slower frame rate, rocks drop slower too.  We'll get there).
 

 

 

WenHop_20230317@18_50_48.bin

  • Like 2
Link to comment
Share on other sites

Looking better already, but due to the block movement the run animation kind of disappears.

If you don't intend to incorporate the up and down run, at least when he is stationary you should display the front facing standing frame,

all idle animations begin with this anyway.

 

Edited by TIX
Link to comment
Share on other sites

1 hour ago, TIX said:

The movement looks better already, but due to the block movement the run animation kind of disappears.

If you don't intend to incorporate the up and down run, at least when he is stationary you should display the front facing standing frame,

all idle animations begin with this anyway.

 

 

Because I'm the all-time world's best player at this game I forget how "fast" it's running sometimes, and that it really doesn't need to be zooming around.  In the attached version I've dampened everything down to a more reasonable speed, which highlights the animation.  It's gone from a base frame-rate of 5 to a 9, which is essentially from 12fps to about 6.6 fps.  I've also added the front-facing frame as you suggest.

 

I've been meaning for a while to explain some of the systems/limitations. This mention of game speed has prompted me to make a few notes.

 

There are asynchronous systems running here.  The main game loop is where we need to process every single thing on the "board" -- which is a grid of 40 x 22 characters.  Scanning through the board top to bottom, left to right... takes a fair whack of time.  For every cell in the board we need to decide what to do. A cell contains a character (such as a rock, or dirt, or rockford.  Based on the *type* or the *character*, we execute an action for that cell and replace the contents of the cell (and possibly contents of other cells) with new stuff. To prevent things being "double-processed" - that is, if we just move something into an adjacent cell and that happens to be the next cell we look at, we don't want to process that cell this time around - it's new... so there's a flag on new cell contents which prevents processing the current game frame.

 

So, I mentioned two things - the type, and the character.  Characters are what we see.  For example, the puff of dust we see when squares are vacated... this puff of dust is TYPE_DUST (that is, it's known as an object of type "dust").  But it consists of 4 characters of animation.  Another way to put this is that there are four uniquely defined characters (called CH_DUST_0, CH_DUST_1, CH_DUST_2, CH_DUST_3) in the 128 character charset.  ALL of these characters are of type "TYPE_DUST".  So when we're processing things on the board, there are two major independent processing sections. Some things are processed based on their TYPE, and some things are processed based on their character.  To facilitate quick speed, there's a lookup which converts character # to TYPE.  In other words "charToType[CH_DUST_0] == TYPE_DUST".  And based on the type, I can look up attributes for that object type.  For example, if something is HARD and we want to have a percussion/bang when something hits it... I don't do lots of conditionals based on what's been hit... I look up the attribute table.  So,  "if (Attribute[TYPE_BOULDER] == ATT_HARD)" will return true. All objects of type boulder are hard. So in general usage I have a lot of code like this... "if (Attribute[CharToType[GET(*this)]] & ATT_SOMETHINGOROTHER)".  This lets me control a lot of behaviour just with an attribute table for each object type. I have about 50+ types of objects, and a 32-bit attribute int for each type.  In reality I have maybe 20 attributes i actual use.

 

So, some things as noted are processed based on type.  I have an ATT_ACTIVE set for all objects that need to be processed. So, for example... blank spaces and dirt does NOT need to be processed and take up precious time.  So the first thing when we're scanning the cells is.  ... "if (Attribute[CharToType[GET(*this)]] & ATT_ACTIVE) // process it!".  So, that kinda covers types in terms of processing the grid of character cells (the "board").  But types are also used dynamically at draw time (that is, when the screen buffer is being filled with the graphics).

 

Even though the GAME is running at a (say) 10Hz frame rate, ANIMATIONS can run at the full 60Hz.  To achieve this, there's a dynamic replacement during draw time of the character in each cell with a different character, taken from the TYPE ANIMATION for that character.  During draw time, the code grabs a cell (which may contain CH_DOGE_00 -- a frame of the spinning doge coin).  I don't need to replace ALL the doge coins on the board with the next animation frame (and in any case that would only happen at 10Hz if I did).  No, the coins spin at 60Hz ... well, if I want them to.  It's done with each TYPE having a little animation program. That animation program is a little list of what character to actually display, and for how many TV frames.  And it has simple commands in the program such as play a sound, generate a spark, halt, loop, etc.  So at draw time, when we grab characters from the board to display... first thing is to see if the TYPE of that character has an animation program associated with it. If it does, then we lookup a replacement character to draw from the animation program.  Otherwise the character we got from the board is drawn.

The upshot of this is that ALL coins, for example, animate at the same time with zero cost in terms of speed. They all direct to the same animation program. The code basically goes "if (Aimation[CharToType[GET(*this)]] // then lookup animating char".  This is pretty cool because I can make lots of things happen on the screen just by having several of the types have their own animation programs running.  But the downside is that ALL of the characters visible on screen of that type can ONLY have the same character at any one frame. They all share the same animation program in other words.

 

Back to the board scanning code. We've covered TYPES.  Now we cover individual characters. If we don't handle the TYPE generically, then individual characters are handled in a case by case switch.  For example, the rocks continually do a few things;  they look below themselves to see if they should fall (ATT_BLANK is set on the TYPE of the object below them), or if they should roll (ATT_ROLL on the below object).  They see if they should kill the object below (ATT_SQUASHABLE).  And of course each rock decides based on the characters surrounding itself if it should change the shape it is displaying to that connected-embedded-dogecoin form.  Note that the TYPE of the character is still TYPE_BOULDER in all cases, but the character displayed in dogecoinrock form obviously has variations (16, actually) showing the UDLR connection to other dogecoin-embedded-rocks nearby.

Similarly, for all types of objects, we can process individual characters.  The crushers for example... are implemented in this system.  Really the crusher only has a "head" and a "body".  The body is ignored, and we only do "stuff" when there's a head.  Consider the "up" crusher. There are two identical-looking characters one called CH_PUSH_UP, and another called CH_PUSH_UP_REVERSE. They look the same but because they're different character numbers they are processed by different code.  The CH_PUSH_UP looks at the character above it, and if it allows a crusher to move there (ATT_BLANK | ATT_GRAB) then it puts the head in the square above and replaces the character in the current square with the vertical body of the crusher.  And likewise for crushers moving left/right/down - each with their own pair of characters - forward and reverse. In this way it seems that large crushers are being drawn, but it's only a single character moving back and forth.  Of course in reverse, the crushers replace the head with a space, and the head replaces the previous body part beside it.

 

I try to get functionality out of "creatures" like this, using the 60Hz animation systems (super cheap), or the character-by-character case-statements in processing the board (somewhat less cheap).

 

And finally, there's a system for the slergs - those green slug-things that move around.  These are a post-draw system which keeps a little list of all the squares each slerg occupies, with a head and tail pointer, so to speak.  It's reasoably quick to move the head and delete the tail, and then update the board with the appropriate changed character for each slerg.

 

Other systems running are the sparks -- this is a short structure of 12 "dots" which can be drawn anywhere on the screen. Basically just a single icc pixel (the colour can ONLY be white) represeting the x/y pixel coordinate of the dot.  I create new dots whenever there are various events - anything grabbing a dogecoi, the crushers hitting something AT_HARD, the supercritical entangled dogecoin giving off entangles, the player "bullets" (press fire), anything really which needs a bit of spark-type stuff.

 

Finally finally, for this description anyway, I can draw arbitrary bitmaps over the top of all this.  Such bitmaps include words (there's a full character set), and stuff like spaceships.  The draw is pretty expensive CPU-wise so I need to make sure not a lot of other stuff is happening at the same time.

 

That'll do for now. Feel free to ask for clarification.

 

 

 

 

 

WenHop_20230317@23_22_35.bin

  • Like 3
Link to comment
Share on other sites

I love reading about this stuff, even though 90% goes over my head (reminds me of the ZZAP64 diaries of a game).

.

Animation is looking better now, still animating very fast though, I think you can dial it down more !

The "face forward" frame looks great when standing ! and the digging look more dynamic.

I hope you can include all 4 directions eventually.

I still get random glimpses of the "impatient" frame mixed in the action..

.

I like the idea of color on the character, maybe I'll give it a shot later on..

Another idea is to allow the astronaut guy to dig down too and not only left and right !?

.

The gameplay is hectic, many things to keep track of, great fun !

 

Edited by TIX
Link to comment
Share on other sites

8 hours ago, TIX said:

I love reading about this stuff, even though 90% goes over my head (reminds me of the ZZAP64 diaries of a game).

.

Animation is looking better now, still animating very fast though, I think you can dial it down more !

The "face forward" frame looks great when standing ! and the digging look more dynamic.

I hope you can include all 4 directions eventually.

I still get random glimpses of the "impatient" frame mixed in the action..

.

I like the idea of color on the character, maybe I'll give it a shot later on..

Another idea is to allow the astronaut guy to dig down too and not only left and right !?

.

The gameplay is hectic, many things to keep track of, great fun !

 

 

 

In this version I've added the up and down walking animations.

I've also added graduated colour/shading to the helmet and although there's the occasional glitch at the bottom, it looks pretty good to my eye.

The colour of the helmet will randomise at reset so we can have a look at different options. Just debugging but who knows maybe different helmet colour during games.

Overall, looking much better.

 

As to digging down - well technically it's already there for dirt -- hold button and press down.  Uses the original animation of course. If you're talking about mining boulders below you - well an animation to do that would be difficult and in any case I don't think it's really necessary -- actually having to go down and to the side of rocks you want to mine ads to gameplay, I think.  

I'm also thinking of introducing just plain rocks - and rocks with doge - and so you have bot on screen. To build the entangled dogeblocks you'd need to destroy the plain rocks, and combine the doge rocks.

 

 

 

 

WenHop_20230318@16_04_34.bin

  • Like 3
Link to comment
Share on other sites

More work on colouring the player sprite. There's a helmet/lower-body colour, and an independent mid-suit colour.  At the moment these two are chosen randomly every time you reset. Within the colours there are 4 intensities for the helmet/lower-body, and 3 intensities for the mid-suit.

 

cols.jpeg.f41d4a142ed3cc29508387a8dac72c2f.jpeg

 

WenHop_20230318@17_55_59.bin

  • Like 2
Link to comment
Share on other sites

4 direction animation is looking great,

stripe coloring is challenging but you have made some great choices (a grey gradient is missing) !

I see you are using one of the idle frames for the "crashed by boulder" sequence, I may have to tweak this a bit..

 

I still get random glimpses of the "impatient" frame mixed in the action, I think you are using it for something that is not suitable,

let me know if you need some additional frames !

 

 

Edited by TIX
Link to comment
Share on other sites

On 3/15/2023 at 7:46 AM, Andrew Davie said:

Just a what-if/idea exploration. Crusher factories....

 

 

Don't know how my post got duplicated so I'm editing.

 

I've been playing more and really enjoy the axe sound/animation, really feels good. Also the Slergs fighting you for the coins really adds to the game play and certainly makes it more challenging. I'm loving the way this is shaping up. Feels almost like a rick dangerous type of gameplay. Traps, outrunning things, split second timing etc

Edited by Prizrak
Link to comment
Share on other sites

it just occurred to me that in the real universe, a rock with a gem/agate inside is called a GEODE. This word just happens to a mixed up DOGE (plus an E).  So we'll call the doge-embedded-in-rock GEODE, and know we're really talking about a mangled "e-DOGE". How good is that.
 

  • Like 2
  • Haha 1
Link to comment
Share on other sites

This latest change significantly changes the whole feeling/concept of gameplay. I've introduced a new type of rock - or more to the point I now distinguish between GEODES and ROCKS.  GEODES have a dogecoin embedded inside them, and behave as before -- that is, when GEODES are alongside other geodes, the dogecoins become engangled and the geode merges with all neighbour geodes.  And if you mine any part of that merged geode, all the entangled doge are mined at the same time.  However, a ROCK does not have an embedded dogecoin, and rocks do not merge/entangle.  I can vary the relative proportions of geodes and rocks when you visit a planet, so this is a significant differentiator with gameplay. As your goal is to entangle the geodes to get more multipliers when collecting dogecoin (the larger the geode entanglement you collect, the bigger the multiplier)... having lots of rocks in the way is a major pain.  And slow, too, as you need to remove/mine each rock individually so they're a pain in the bum.  I quite like the changes here. It seems to open a LOT in gameplay/strategy/mechanics.  Building blocks with fully-entangled dogecoin is really quite tricky -- depending on the blend of rocks and geodes.  One other change - crushers now crush geodes, as well as dogecoin... so there's that, too!

 

I'll be keen for any feedback on the feelings about the change in gameplay mechanics this introduces.

Also of note, the player colours/shading.  Some original frames are still in there (e.g., joystick button + down) so that may be the cause of some of the "glitches" being reported. If not, I'll need more detail!

 

 

 

This time, two extra binaries - one with more ROCKS, and the other with more GEODES... just to show the huge difference it makes.

 

Regular:

WenHop_20230318@23_32_22.bin

 

more geodes...

WenHop_20230319@00_02_14_GEODE.bin

 

more rocks...

WenHop_20230319@00_01_32_ROCK.bin

  • Like 2
Link to comment
Share on other sites

13 hours ago, TIX said:

stripe coloring is challenging but you have made some great choices (a grey gradient is missing) !

 

 

All colours are available. As noted, they are selected randomly. I simply showed a subset in the earlier image, running the game a dozen times or so and grabbing a screenshot.  Grey gradient is there - all of the 16 variants of palette hue are available. Random.

Link to comment
Share on other sites

A bit of a focus for animations this update. I've worked on the player animation transitions - most noticeable when you walk up (facing away) and when you let go there's a pause and then a rotation back to the default facing-forward frame. All directions end up on that frame, transitioning in different ways. It's made a bit of a difference I think - things feel less "clunky". I've also put just a little vertical motion on the walk. The puff of dust now also appears when you walk into a square that has dirt. Previously it appeared in the square you left (still does), but adding to the new square too is subtle, but works.

 

As an aside, the slergs don't actually chase dogecoin - even though it seems they're pretty good at it.  They are just predominantly trying to move in the same direction with occasional random turns.  And rarely they will push through dirt if they can't move ahead. And failing everything they just head/tail switch and reverse. But these together make them a real pain and they are quite effective at grabbing dogecoin that you're mining.

 

 

 

WenHop_20230319@13_25_11.bin

  • Like 3
Link to comment
Share on other sites

A short preview of "decorators" - in this case showing a drill, and a numeric overlay.  The numeric I might use, for example, when you mine a dogeblock and you have the entangled doge (do-geodes fully surrounded by other do-geodes) -- remember the entangled doge are hard to get and multiply your doge value/count when you mine a block.  Not including a binary this time, but jotting down so I don't forget;  the doge conversion is now symmetric... when you mine a do-geode and it turns all surrounding (entangled) do-geodes into dogecoins, there's now an automatic/equivalent back-conversion. Any dogecoin which is next to a do-geode will change into a do-geode (this is also a chain-reaction).  So, depending on gameplay... you might have a large "block" of dogecoin you're harvesting, but if a do-geode somehow gets next to one of those dogecoin, then a chain reaction starts and you see them all change to do-geodes.  This isn't a huge disaster; you can always mine them again... just at the cost of a bit of time. Visually it looks good.

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...