Jump to content
IGNORED

Wen hop? The Search for Planet X


Andrew Davie

Recommended Posts

Part of the internals of Wen Hop is the 'scheduler' which essentially processes everything that does stuff. The old version was kind of limited to having everything process at the same rate - let's say 10fps. But the new one I'm showing here is a bit more sophisticated, and allows objects on the screen to schedule at different rates. The details are a bit limiting, but it does for example allow the crushers to be fast, and the player relatively slow. Work in progress, so this looks horrid at the moment (at least in terms of jerky player movement).... but it shows promise with the extra speed of everything.

 

 

So there's this process that "scans" the board -- all 40 x 22 objects.  This scanning simply sweeps through the 'squares' and looks at what object is in that square, and processes the appropriate code (e.g., falling rock).  That's how things have worked for yonks.  This video although rough, shows a slightly different method.  In the old version I processed everything on the board and then WAITED until a certain time had passed - in order to establish a constant frame rate.

 

This prelim new scheduler does things a bit differently. It constantly sweeps through the board and does NOT wait for constant rate when it's done. It instead immediately starts a new sweep.  So everything is running fast at the moment -- look for example at the crushers. They are demonstrating "top speed".  But I have now based all of this around a "6-cycle" idea -- where some objects process every cycle of the sweep (so they're fast), some every 2 cycles, so half as fast, some every 3 cycles (so um... slower still) and some every 6 cycles. I chose 6 because it can be divided into even segments of 1, 2, 3 and 6 - giving me effectively 4 different 'speeds' for objects to be processed on the board.  So the player - I can have him operating at "2" which means every two sweeps he does his stuff.  When I get this working properly you won't notice he's only processing every 2, because everything is running faster so he'll actually appear to be the same speed.  But but but.... he's no longer running the same speed as the other things around him.  The other things are proceesing speed "1" at the moment, so they are twice as quick.  Effectively, say, rocks fall a lot faster than you walk - and you may argue this is a bad thing. Could be. Maybe. maybe not.  But I can tailor this now. So objects that don't do much can run only every 6 sweeps - and thus they cost 1/6 of the processing time, overall -- so the system has more ability to run faster.  No need to process pebbles, for example, every single game loop.  1/6 is fine.  Likewise, things which are fairly static and only do minor checks/changes... probably don't need to move fast.  

I'm still testing this out - asynchronous movement of objects. Its slightly different (for example when you move out of a square, a rock can fall onto it 1/2 of your movement faster than it would).  But that actually looks pretty good to my eye.  

So, I might continue refining this and see where it leads.  It does have one possible disadvantage - it kind of does suffer from the possibility of the ACTUAL physical time required to sweep the board (in terms of TV frames) being inconsistent - maybe 2 frames one time, and then 1 the next. and 3 the next.  That's what the original "wait" was fixing and making it all constant-speed. Maybe I'll reintroduce a lower "wait" inside of the new 1-2-3-6 scheduler. All part of the fun in making systems work.

 

Have to say, though., in the middle part of that video things are awesomly complex/hectic.

 

 

  • Like 3
Link to comment
Share on other sites

OK, so straight up front - this binary will crash occasionally. The crash is in the draw loop when it's doing an illegal access -- so basically I have put an illegal character on the screen, and it accesses wrong memory trying to draw it. Not sure why yet, but I do often do several passes of optimisations and I've borked something in there. Not a big issue. So it will crash. Known problem.

 

The new scheduler is now working smoothly. It operates by running the board scan at a minimum of 4 frames/scan and the objects can choose to run every frame, every 2nd frame, or every 4th. This allows the player to be responsive by initating a move every frame, but moving over 2 frame timing. Complex to describe, but essentially variable speeds for the objects to help with responsiveness and relative timing. This video looks pretty "tight". Note the crushers have new graphics and are going super-quick.

 

It's actually pretty slick; I'm quite happy with how responsive things feel and how the whole thing feels busy but not clunky.

 

 

Note the new details in the crusher graphics;  pads on the end of the crushers and a neat center-part which works well.

 

 

 

WenHop_20230407@22_21_16.bin

  • Like 3
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

3 hours ago, Andrew Davie said:

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 32 kB · 3 downloads

I like this animation of water flow the most - it’s the most „natural“ IMO. 

Link to comment
Share on other sites

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.

 

 

  • Like 2
Link to comment
Share on other sites

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

  • Like 5
Link to comment
Share on other sites

Hey,

 

I love the progress,

as I see it, you have more than enough material to span several games 😀

 

The latest binary (22_52_52) crashes Stella for me..

 

Player movement seems smoother,

I really love the water effects,

the new faucets and running water work great (how about an object that floats ?)

I'm currently recovering from covid, but I'm thinking some swimming animation will compliment it further, if there is space !?

 

 

 

Link to comment
Share on other sites

3 hours ago, TIX said:

love the progress,

 

TY. I live for feedback. Good and bad.

 

3 hours ago, TIX said:

as I see it, you have more than enough material to span several games 😀

 

Yes, maybe. I want to have a vast pool of things to choose from when I have to whittle things down.

 

3 hours ago, TIX said:

The latest binary (22_52_52) crashes Stella for me..

 

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.

 

3 hours ago, TIX said:

I really love the water effects,

the new faucets and running water work great (how about an object that floats ?)

 

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.

 

3 hours ago, TIX said:

I'm currently recovering from covid, but I'm thinking some swimming animation will compliment it further, if there is space !?

 

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

Link to comment
Share on other sites

7 minutes ago, Andrew Davie said:

 

but as noted I think the attached will be OK.

 

this worked great !

 

7 minutes ago, Andrew Davie said:

 

 

.. not going to work for "floating" objects.

 

no problem

 

7 minutes ago, Andrew Davie said:

I hope you are feeling better soon. 

 

thanks man

 

7 minutes ago, Andrew Davie said:

 The only real limitation would be my ability to ever finish such a game. Finishing stuff isn't my strong suite

 

for me, this is a stress free hobby,

it not necessarily have to lead to a finished game, so I may do some more animations or not, it's all for fun 😄

 

Link to comment
Share on other sites

Just now, TIX said:

for me, this is a stress free hobby,

it not necessarily have to lead to a finished game, so I may do some more animations or not, it's all for fun 😄

 

 

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.

 

 

  • Like 1
Link to comment
Share on other sites

Is something like this to your liking ?

I kept it simple with 1 frame only, but I think it's working.

I reproduced the faucet by eye so it might be off.. I've also done an alternative faucet design to alleviate the top distance..

 

look to the right for another element you can add to your collection..

it's the crusher (ok the crusher is already taken), rotating cogs that smash to powder everything that falls through them, including our hero 😲

 

 

faucet.thumb.gif.78d5919dcf74e3826a3fe22ba19a1f8a.gif

Edited by TIX
  • Like 1
Link to comment
Share on other sites

11 hours ago, TIX said:

Is something like this to your liking ?

I kept it simple with 1 frame only, but I think it's working.

I reproduced the faucet by eye so it might be off.. I've also done an alternative faucet design to alleviate the top distance..

 

look to the right for another element you can add to your collection..

it's the crusher (ok the crusher is already taken), rotating cogs that smash to powder everything that falls through them, including our hero 😲

 

 

faucet.thumb.gif.78d5919dcf74e3826a3fe22ba19a1f8a.gif

 

Very nice; TY. I will put these in soon.

Let's call the one on the right "the grinder". Looks great.

 

  • Like 1
Link to comment
Share on other sites

5 hours ago, Andrew Davie said:

 

Very nice; TY. I will put these in soon.

Let's call the one on the right "the grinder". Looks great.

 

 

Great,

let me tweak them a bit, I'll send you the final sheet in a moment.

 

"the grinder" sounds fitting !

Link to comment
Share on other sites

Hey there!

 

Glad to see continued progress, and I'm glad to hear that you're feeling better.  Since a lot has transpired, I'll just break my comments up per functional area:

 

Gravity switches: These seem to be working well.  I was thinking about it and wondered if it would look good / bad if the arrow-switch icon flipped upside down when you did.  That way, the "switch" is switching directions.  I don't know if that would be confusing, but it seemed like it would be worth seeing.  If it's always pointing to "gravity would go this way if you flipped it", that may feel more logical if it kept changing states when toggled.

 

Water feature: I think this is a fantastic idea, and having the water "fill" due to a faucet is a really cool mechanic.  Of your water animations, #5 feels the least correct to me, but it does feel like it's more like some sort of auger-fed drill.  That had me wondering if such a drill could be a useful feature on its own.  It's a bit hard to say, since the Crushers already seem to cover a lot of this territory, but I thought I would flag it, just because the spiral action kind of looked neat.  At a minimum, it could be some sort of "impassible wall" that you would have to switch off in some place before moving to the left/right to get past it.  If you touch the drill-bit, it's instant death.

 

Bombs: I see this topic come up from time to time, and I think this is a neat thing to play around with.  The question on my mind is how would it be different from BD explosions (and cascading explosions).  There could be a few options that separate it out and make it more interesting.  For example, there could be a countdown timer when activated-- this could be a lot of fun especially when you have to set a bomb off and snake your way through a bunch of crushers / drills / enemies just to get far enough away safely, just to inevitably have to run the gauntlet again later.  Another possibility besides a countdown timer could be different radiuses of explosions:  As an example, green bombs could have small impacts, yellow could have medium, and red could have large.  That could have some fun elements in a minefield layout where one has to decide which bomb to trigger if they want to make a path, but not destroy all the coins they need to complete a level.  The only caveat to a color designation is that it loses accessibility to color-blind players, so marking bombs with a "1 / 2 / 3" or some sight of marking may also be needed.  One other thought-- BD has cascading explosions; in Wen Hop, would that be needed?  Combining thoughts-- it might be interesting if armed bombs can daisy-chain ONLY if they're armed.  That would mean that bombs would need some way to be armed/disarmed without setting them off to allow for daisy chains, but it could allow for fun where a giant Red Bomb has to be disarmed in the middle of the level to prevent it accidentally being triggered and pretty much ruining the level.  A disarmed bomb just disappears when triggered instead of exploding.  Maybe something to play with.

 

Controls: I'm all for a HUD where the button can select what its function is for.  Frankly, for a game like this, I would support a 2-button approach via either booster grip interface or some extra hardware if the game is getting to be this feature-packed.  It wouldn't have to be mandatory, but I think this would help a lot with playability for those who choose to do so.  That said, I'm not sure what sorts of modern options exist for giving extra buttons to the 2600.

 

Update frequency: I for one really like the constant updates-- it's like a game development blog that's happening live.  I also really appreciate your frankness and frequent interactions with those watching the thread; it feels like we're sort of helping a little bit.  When I read these updates, I'm never really near an emulator, so I don't get much chance to test binaries, but I do really enjoy watching the snippet videos to see what new functionality has been added and what little tweaks are being tested.  I really like the current format.  If you have a concern for viewership, though, it might be that the thread is so long that some folks are nervous that it's too much to read to get caught up.  If that was something you wanted to try to address, maybe I'd suggest a "Summary: Where we're at so far and what I'm looking for" kind of post in this thread, and then make a single post in the "2600 Programming" forum that references back to that specific post.  That might give people a new jumping-off point.  I'm also not sure if you have been updating your first post over time; if you haven't, you could edit your first post to say "Want the latest summary?  Go HERE" pointing to that same to-be-determined Summary post on this thread.  That might help get newcomers to a good starting point without them feeling like they have to read over a dozen pages of content.

 

Good job so far!  I always like seeing new progress; I think the end result will be very fun.

 

  • Like 1
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...