Jump to content
Andrew Davie

Wen hop? The Search for Planet X

Recommended Posts

Posted (edited)

 

Wen Hop?

The Search for Planet X

 

You're the very, very famous and dashingly handsome spaceman/explorer/all-round-good-guy, Mellon Husk. To save humanity from the "Great Filter" that you fear is coming soon, you are on a mission to find "Planet X" so that you can establish a new human colony and safeguard the future of humankind.

 

 

Using your trusty rocket-ship, inspirationally named "ship", you are on a mission to visit the moons, planets, asteroids of the solar system to find that elusive new home. Your goal at each stop, to mine enough dogecoin (yes, in the form of actual physical coins) enable you to buy enough rocket fuel to continue your quest. Getting the dogecoins would be a matter of solving puzzles and avoiding aliens on the planet. It's going to be very much an action/puzzler.

 

Each planet/location has its own gravity. Terrain will have different characteristics - for example, friction on an ice planet.  Underwater swimming...  I hope to spend some considerable effort on variations in controls.  The terrain is fully navigable on a per-pixel basis rather than character graphics. That is, Husk's movement is freeform over the char background.  You cannot dig underground, but you can follow existing passages, and of course you can use tools. You will be able to pick up and drop some "objects" such as explosives, and rocks. Use rocks to allow you to reach stuff, or to drop on enemies, or block off exits. Use explosives to open up new passages. Underground you can crawl along diagonal passages. You cannot move "up" - you have to jump or climb. There may even be some alien superstructure/buildings - maybe you can even go inside for a sub-level on the planet. Whatever I can implement. Maybe a rocket pack....

 

At the moment the player sprite is just there to allow me to scroll around. It is not coupled to the background. That will come soon. At the start of each planet, I plan to have a big animating ship (character graphics) landing you on the playfield.  Out comes spaceman Husk and then you're in control. You try and collect the dogecoin by moving through the underground passages and using tools/explosives where necessary to get access. Once you get enough Dogecoin, you go back to the ship and it lifts off (huge animation) for the next adventure.
  
The video shows what I have so far. Essentially, it's a graphics engine that has the following capabilities...

 

* super-smooth playfield scrolling
* Animating background character graphics
* parallax scrolling.... pretty cool effect

* lava
* water
* earthquakes / screen shake

 

Objects/creatures/behaviour... this will be expanded...

 

* water drips
* alien eggs
* various foe - chasers, huggers, etc
* dogecoin

 

Tools

* rocks - can be lifted/carried
* explosives - place underground to blast away soil/rocks


So as a first pass I've worked on the dirt and made it so that it intelligently "rounds" the edges where appropriate. It gives the whole thing an organic (non-character-graphics) feel.  I feel that I work better when I get feedback, and I do like to share new developments ASAP.  So I hope/plan to occasionally update this thread with videos and very soon some playable binaries.

 

What you see in the video currently runs just fine on actual hardware.  I've tried to show a few of the features - lava (which destroys just about everything) and causes earthquakes. Rocks (eventually) explode when in lava.  Water, which dissolves soil/dirt, and will perhaps enable access to areas you might not otherwise reach. In other words, you float/swim until you're high enough. Both water/lava can slowly rise in level.   I'll be putting in what gameplay elements I can.

 

Well, if you want to contribute suggestions for gameplay, feel free to do so.  And if you "follow" this thread, that will let me gauge interest in the project.  It's a CDFJ (32K) project, written mostly in C.  I'm really pushing the hardware with this engine;  it's incredible what you can make it do if you design to the capability. I'm already very short of space, so it's going to be a matter of optimising from here on in.

 

Onward and upward!!

 

 

 

    
                               wow                          so various           
    
    
    
    
                               such example                            wow      
    
    
    
    
    
         so much blast       such first           so much objects                       
    
    
    
    such matter                   very necessary                    so physical      
    
    
                                              such spaceman                              
 

 

 

 

Edited by Andrew Davie
  • Like 26

Share this post


Link to post
Share on other sites

Neat!  Very Impressive! "Mellon Husk" is the perfect name for a protagonist. :lol:

 

Bed time for me now, but I will have another look tomorrow. 😎

  • Haha 1

Share this post


Link to post
Share on other sites

Here's a new element -- "scalators".  They're a kind of automated spiral elevator for moving up/down shafts.

There's a slow downscalator left, and a fast upscalator, right.

The idea is you can move into the shaft and the scalator carries you up/down, and exit when you want/can.

I'll probably add short demo videos of each element as it comes online...

 

 

  • Like 5

Share this post


Link to post
Share on other sites
3 minutes ago, Colonel Llama said:

Wow, this is looking great!

Did you use that same techniques as in the Boulder Dash port?

Well the triple-line "ChronoColour(TM)" system for multi-coloured graphics is the same.

But it's a complete code rewrite and shares zero bytes of code/data with BD.  BD was 6507 code, 3E bankswitching.

This is C-code and CDFJ bankswitching. Completely different technologies.

 

Share this post


Link to post
Share on other sites
1 minute ago, Colonel Llama said:

This explains why it looked a bit similar!

Can’t wait to try it!

 

Also, i love Husk’s animation XD

Also used the same ChronoColour(TM) concept in my Chess, Sokoboo, Life in Space and several demos.

Husk has many animations already done;  I have to "tie" him to the background and then he can start using them.

 

Share this post


Link to post
Share on other sites
Posted (edited)

 

I've merged the rocks into giant lumps - this has had the nice effect of emphasising navigable passages.  The rocks can/should still break-off the lumps and fall... so the same functionality. Here you may also see the ground slowly disappear as the earthquakes (from lava and exploding rocks) are happening. I haven't got all the rocks operational in this video, but the general idea seems sound.

 

EDIT/NOTE The video looks much nicer/brighter if you switch it to 720p/60!

 

 

 

Edited by Andrew Davie
  • Like 6

Share this post


Link to post
Share on other sites

Next up; a rock drill. My original intention was to have this as a tool that Commander Husk could use, but I think it might be better as an obstacle on screens. The drill causes rocks to split/explode into dogecoin, because how else are you going to mine doge underground?  In the video I do a number of resets to watch it in action.  Also note the refined "rock clumping", which is working very well now...

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Here's a bit of full-on action with lava, and earthquakes turned up to high. The earthquake shakes the screen, of course, but it also weakens the soil/dirt, so occasionally some will crumble away and rocks will fall/reconfigure. You can see the basic reconfiguration of the lumps of rock in real time. The rocks aren't exactly falling correctly yet, as I'm optimising to save space and changing the logic as a result. But it's good enough. This all has full-on sound... explosions, too. 

 

 

  • Like 3

Share this post


Link to post
Share on other sites

I barely understand my question here.  So, it'll be ill defined and badly worded :)

 

In Boulderdash my impression was you needed to figure out a system to manage events (like rocks falling) and do as much as you can until CPU time ran out then schedule them for the next frame.

 

Do you do something similar here and does your overall threading strategy/management change going from assembly to C?

Share this post


Link to post
Share on other sites
8 minutes ago, Gemintronic said:

In Boulderdash my impression was you needed to figure out a system to manage events (like rocks falling) and do as much as you can until CPU time ran out then schedule them for the next frame.

 

Do you do something similar here and does your overall threading strategy/management change going from assembly to C?

 

Yes, the original (3E) BD operated in that fashion - a timeslice system that prioritised certain events, and where necessary slowed down the game to get everything done (although that was barely noticeable and rarely happened). There's a reason it took most of a decade to develop... it was probably the most complex piece of coding I've worked on. This engine is totally different, as there is enough processor grunt to allow me to brute-force a lot of the processing and all of the draw.  And of course I can program it in C which is 1000x easier and less error prone. BD could draw a maximum of about 8 onscreen "characters" in any single frame.  It had extensive, and very complex code, to determine what changed on the screen and thus absolutely had to be drawn. It then did that and no more. And if you had an erase/draw "split" over two frames, you could get a momentary flicker - but almost never noticeable... I just know it's there.  This engine does away with all that complexity, and draws the entire screen (all 10x8 characters) every single frame.  I do have some time management code to ensure that things don't run overtime, but the screen is always drawn in full every frame. BD only updated the changed characters. With the new system I can animate everything onscreen at the same time, with no time penalty; it costs the same to have a static screen as it does to have everything going crazy as in the video. There is no priority/timeslice/scheduling system like in BD. The code is way, way, way more simple in this new engine. There's a reason that BD took many years to develop.

 

So saying, this is a different technology and a new challenge, and it has its own limitations and gotchas. I'm enjoying exploring this part of the envelope, so to speak. I've taken the opportunity to write totally new animation/draw/game systems to take advantage of the speed but also to make it much more versatile. There's zero reuse of code/techniques between the two. I'll be happy when we can move on from BD comparisons and appreciate this engine/game as a standalone new thing.

 

 

 

 

  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites
7 minutes ago, Andrew Davie said:

I'll be happy when we can move on from BD comparisons and appreciate this engine/game as a standalone new thing.

 

Only used BD as my first point of reference for your scheduling methods.   Thank you for the explanation!

Share this post


Link to post
Share on other sites

I'm thinking of attaching that drill rig thing to the side of the ship. So, you land in the ship and drill down to bedrock. The bedrock explodes to bitcoin, then you get out and climb your way down and fetch the coin. I just like the idea of this massive ship being used as a mining tool.  To move around, you'd get in the ship again, take off/fly to a different area, drill again...

  • Like 1

Share this post


Link to post
Share on other sites

That drill is awesome.  In fact, this whole project is pretty awesome.  Hopefully we get a "playable" demo in the near future!

  • Like 1

Share this post


Link to post
Share on other sites

One of those ideas on my bucket list for some time has been a "big sprite system" using PF graphics. With the spaceship, I've now managed to get this functioning. The ship-draw is actually a generic draw of any sized (up to 32 PF wide, unlimited depth) sprite, with masking.  In this demo - which is not truly practical due to timing - you see 5 ships moving around the same time and the background still doing all its stuff.  But the point of showing this is that I can imagine/see a 4-player fighting game with sprites this size.  Each PF sprite has a configurable centerpoint, so when you draw at a particular coordinate, the frame(s) shift around to keep the center point in the same spot on the screen.  This draw is happening at 60Hz. I may work on a stand-alone engine to allow this big sprite system to be used by others;  it's extremely simple to define shapes, and even easier to draw...

 

Here's the definition of the ship (and mask)... side by side for ease of editing...

const unsigned char rocketShip[] = {

    1,                  // width in BYTES (=8 pix/byte) (MAX =4)
    105,                 // height in SCANLINES (pref multiples of 3 -- TRIPIXs)
    3,105,               // center point (PIXELS) from 0,0 top left

    ________ ________    // colour 0
    ________ ________    // colour 1
    ________ ________    // colour 2 etc...
    ___X____ ___X____ 
    ________ ________ 
    ________ ________ 
    ________ ________ 
    ___X____ ___X____ 
    ________ ___X____ 
    ___X____ ___X____ 
    ___X____ ___X____ 
    ________ ___X____ 
    __XXX___ __XXX___ 
    __XXX___ __XXX___ 
    ___XX___ __XXX___ 
    __XXX___ __XXX___ 
    __XXX___ __XXX___ 
    ___XX___ __XXX___ 
    ___X____ __XXX___
    __X_X___ __XXX___ 
    ___XX___ __XXX___ 
    ___X____ __XXX___  // 00
    __XXX___ __XXX___  // 01
    ___X____ __XXX___  // 02
    __XXX___ __XXX___  // 03
    _XXXXX__ _XXXXX__  // 04
    __XXX___ __XXX___  // 05
    _XXXXX__ _XXXXX__  // 06
    _XXXXX__ _XXXXX__  // 07
    __XXXX__ _XXXXX__  // 08
    _XXXXX__ _XXXXX__  // 09
    _XXXXX__ _XXXXX__  // 10
    __XX_X__ _XXXXX__  // 11
    _XXX_X__ _XXXXX__  // 12
    _XX_____ _XXXXX__  // 13
    __X_____ _XXXXX__  // 14
    _XXX_X__ _XXXXX__  // 15
    _XXX_X__ _XXXXX__  // 16
    __XXXX__ _XXXXX__  // 17
    XXXX_XX_ XXXXXXX_  // 18
    XXXX_XX_ XXXXXXX_  // 19
    _XXXXXX_ XXXXXXX_  // 20
    XXX___X_ XXXXXXX_  // 00
    XXX___X_ XXXXXXX_  // 01
    _XXXXXX_ XXXXXXX_  // 02
    XXX___X_ XXXXXXX_  // 03
    XXX___X_ XXXXXXX_  // 04
    _XXXXXX_ XXXXXXX_  // 05
    XXXX_XX_ XXXXXXX_  // 06
    XXXX_XX_ XXXXXXX_  // 07
    _XXXXXX_ XXXXXXX_  // 08
    XXXXXXX_ XXXXXXX_  // 09
    XXXXXXX_ XXXXXXX_  // 10
    _XXXXXX_ XXXXXXX_  // 11
    XXXX__X_ XXXXXXX_  // 12
    XXXXXXX_ XXXXXXX_  // 13
    _XXXXXX_ XXXXXXX_  // 14
    XXXX__X_ XXXXXXX_  // 15
    XXXXXXX_ XXXXXXX_  // 16
    _XXXXXX_ XXXXXXX_  // 17
    XXXX__X_ XXXXXXX_  // 18
    XXXXXXX_ XXXXXXX_  // 19
    _XXXXXX_ XXXXXXX_  // 20
    XXXXXXX_ XXXXXXX_  // 00
    XXXXXXX_ XXXXXXX_  // 01
    _XXXXXX_ XXXXXXX_  // 02
    XXXXXXX_ XXXXXXX_  // 03
    XXXXXXX_ XXXXXXX_  // 04
    _XXXXXX_ XXXXXXX_  // 05
    XXXXXXX_ XXXXXXX_  // 06
    XXXXXXX_ XXXXXXX_  // 07
    _XXXXXX_ XXXXXXX_  // 08
    XXXXXXX_ XXXXXXX_  // 09
    XXXXXXX_ XXXXXXX_  // 10
    _XXXXXX_ XXXXXXX_  // 11
    XXXXXXX_ XXXXXXX_  // 12
    XXXXXXX_ XXXXXXX_  // 13
    ________ XXXXXXX_  // 14
    _XXXXX__ _XXXXX__  // 15
    __XXXX__ _XXXXX__  // 16
    __XXXX__ _XXXXX__  // 17
    __XXX___ __XXX___  // 18
    _____X__ _XXXXX__  // 19
    __XXXX__ _XXXXX__  // 20
    __XXX___ __XXX___ 
    __XXX___ __XXX___ 
    __XXX___ __XXX___ 
    __XXX___ __XXX___ 
    _XX_XX__ _XXXXX__ 
    _XXXXX__ _XXXXX__ 
    __XXX___ __XXX___ 
    XXXXXXX_ XXXXXXX_ 
    XXXXXXX_ XXXXXXX_ 
    __XXX___ __XXX___ 
    __XXX___ XXXXXXX_ 
    X_XXX_X_ XXXXXXX_ 
    __XXX___ _XXXX___ 
    ________ XXXXXXX_ 
    X_XXX_X_ X_XXX_X_ 
    ___X____ X_XXX_X_ 
    ________ X__X__X_ 
    X__X__X_ X_XXX_X_ 
    ________ X_XXX_X_ 
    ________ X_____X_ 
    X_____X_ X_____X_ 
};

Here's how to draw the ship... and flickery flame....  you don't need to erase... just draw things where you want...

 

drawBitmap(&rocketShip[0], x, y, false);
if (!(getRandom32() & 3))
	drawBitmap(&rocketShipFlame[0], x, y, false);

In the above example, a ship and the rocket flame share the same x,y coordinate (centerpoint). The flame will appear below the engine, because the center point of the ship is at bottom center of engine, and the centerpoint of the flame is top center. Anyway, I digress... it's a lovely thing.  Using the ChronoColour(TM) system, as this does, each sprite can have 9 ICC colours (that is, 8 colours of ICC AND a transparent "colour" due to the mask capability).

 

 

  • Like 8

Share this post


Link to post
Share on other sites

The spaceship is now "tied" to the background scroll, rather than being drawn on the front of the screen, so to speak.

the lock isn't perfect, but I'll get there. This is looking pretty busy...  now to make it a game...

See my other thread for a binary with Husk's antagonist's first appearance... the evil Space Pirate Billionaire Dozeoff.  Well, his ship, anyway....

 

 

 

 

 

 

  • Like 6

Share this post


Link to post
Share on other sites

I hope one or two notice/appreciate that circular wipe at about 16s!

 

  • Like 3

Share this post


Link to post
Share on other sites

You got my attention with "Wen hop?" in the title (SpaceX fans will appreciate that), but man, this looks super impressive so far!!  Look forward to watching how this evolves as you continue development.  :)

 

 ..Al

  • Like 2

Share this post


Link to post
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...