Jump to content

Andrew Davie

+AtariAge Subscriber
  • Posts

    5,982
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Andrew Davie

  1. 9 hours ago, Corby said:

    Man. If I ever learn to code (which is never) this would be the first game I'd try to make! 

    Y'know... it won't happen unless you make a start on something. Just have a go. Something small, not a game.... just do some experiments.  Anything you learn is a bonus.  Don't just daydream; make an effort and be positive.

    • Like 6
  2. This is better. I removed the pattern from the wyrm body, shortened them, and made everything faster. I kinda like the weird angular/slug-like shape of them now, and I've christented them "slergs"...  why not.  Couple of screens installed.... hit F1 (select) to cycle.  I turned iCC on/off a couple times in the vide.

     

     

    There are two variants; one the slergs can move through dyrt, and the more sedate version where slergs can only move through blank areas (binary ...22_37_34) I think I like the latter.

     

    WenHop_20230303@21_02_38.bin WenHop_20230303@22_37_34.bin

  3. 13 hours ago, bigmessowires said:

    This should probably go without saying, but just in case: Did you actually develop Atari games in the 1970s and 80s? Did you work on Kaboom, Basketbrawl, and Miner 2049er? How much of the text in your first post is correct and how much is fiction?

    I did not work on those games. I did not develop '2600 games in the 70s, although I did do some 8-bit stuff in the 80s. I have not released Apple II games, although I have developed software on that platform. The veracity of the remainder is open to interpretation.

  4. 1 hour ago, Gemintronic said:

    I've been hoping someone would crack the code for detecting TV type on bog standard hardware.  Most people are OK with PAL60 and I'm OK with storing tables with NTSC and PAL color values.

    "please choose the green square to start playing" would work. Relies on a bit of trust, and non-colourblindness.

    • Like 1
    • Thanks 1
  5. First appearance of the wyrm nymph.  Basically an underground super-worm which "eats" dogecoin.  The graphics are prototype/rudimentary at the moment - particularly the "head" (which can be either end, and really just indicates the front, whichever direction the wyrm is moving).  Anyway, it's pretty cool how it finds its way around even in the most cramped crusher screen.  Sometimes it gets totally stuck, and as far as I'm concerned, that's perfectly OK, too. The wyrm shown here is 10 long; it can be any length from 1 to 32, but the smaller wyrms appear to be more effective. I could have the wrym grow and shrink as various events happen.
     

     

    Binary will be pretty dodgy, but at least you can have a play with it. Might crash; please don't report, as it's very untested code.

     

     

    WenHop_20230301@23_22_21.bin

    • Like 6
  6. The crushers are interesting; they give quite a variety of gameplay options. I've tied their function to the switch -- initially they are active. but if you hit/grab the switch then they are disabled. Here are a few gameplay examples on the same world, with a brief discussion of crusher usage/effect...

     

    This one is the stock-standard gameplay, with no crushers. The goal is to mine the rocks and collect the dogecoin.

     

     

     

    The next one has crushers that are active, but which cannot move because of the dirt. There are a number of rocks around, and you need to mine these into dogecoin. But, in some cases as soon as you mine the coin, the crusher activates and destroys the coin. So you may need to first move the rock before mining it.  Also a feature of this screen is that as you move around, removing the dirt as you go, you activate the crushers in your vicinity - they now have room to move. So as the gameplay goes on, more and more crushers become active, making it more difficult for you to mine dogecoin without it being crushed.

     

     

    The following one is just using the crushers as a sort of obstacle course/maze.  You might, for example, have to find the exit in a short amount of time.

     

     

     

    This next one is complex. It starts with nearly all rock.  Your only "move" is to mine the rock to your left, which sets off a dogecoin chain reaction. This is good. Lots of coins. But as the reaction proceeds, the crushers start to crush the dogecoin, so the coin begins RAPIDLY disappearing. There's a switch bottom left of the world, so you need to make your way quickly down to that switch, without dogecoin falling on you and killing you. When you get the switch, this turns off the crushers, and stops them destroying the majority of the coin. Your job then is to collect as much coin as you can/want and then exit.
     

     

     

    Here's the binary to play with...  I am aware of a crash when you go through the exit door. So... don't do that!

    Instead, hit F1 (SELECT) to go to the next world.

     

    That's all for today, folks.

     

     

     

    WenHop_20230227@22_48_25.bin

    • Like 4
  7. A few new (experimental) elements.  Crushers, and a switch.

    The crushers simply move left/right into available space, and reverse direction when they hit an obstacle. They can either crush things, or just provide a challenge in getting through the gap(s).  In the video, a short while into gameplay where I go to the 2nd level, you see this obstacle action. Quite interesting, actually... I may use something like this.  The other element you can briefly see top leftish of screen - that's an on/off switch, which I may tie to other objects on the screen (e.g., the crushers!) to enable the player to switch things on/off.
     

     

  8. I've done a fair few variations on this.  For example Boudler Dash (original) uses the left difficulty switch to toggle between NTSC/PAL.  This consistently confuses people because they don't realise that the switch exists, so depending on the switch the game will boot in the wrong mode. In my view that's the wrong way to do things, although it's "cheap" to implement.  My current preference is to offer on-screen indications via a menu.
    The new version of Boulder Dash (experimental/not released) does console auto-detect, which I think all CDFJ/ARM games should try to achieve. The detection code is robust and freely available for use.  In this situation, game can boot to the best default for the detected console type (PAL/NTSC/SECAM).  I default PAL to 60Hz (I call this PAL60) mostly because it gives a better display.  I allow menu-choices to switch to other modes (SECAM/NTSC/PAL/PAL60) and include AUTO as the default mode which does the aforementioned auto-detect.
    So, TL;DR - at the very least provide onscreen indication of the mode and how to change it. Otherwise, people simply assume the shitty colours/display are normal and never realise you need to flick a switch to get to their native format.

    As to the issue with incorrect rolling/scanlines, always boot into a 60Hz mode - nearly all TVs will display a non-rolling picture.  One possible option would be to switch between PAL/NTSC/SECAM colours with "press button when display looks good" type of thing - and then use that mode for the rest of the game.

  9. Some refinements...

     

    1. button-press is (for now) a weapon that shoots bullets in all direction. The bullets will zap dirt and dogecoin
    2. when you use the pickaxe (hold direction left/right against rock), there's a pause after you do the conversion, so you don't accidentally go in and grab that first coin and thus disable the chain reaction. This is a different method to earlier version(s) which kind of made the whole control system sluggish.
    3. dogecoin behave differently; they used to convert all rocks to dogecoin, but now they only convert rocks which were adjacent when the dogecoin is first "minted".  So, dogecoin falling on rocks will not convert those rocks, nor will rocks falling on dogecoin be converted. This makes the dogecoin much scarcer and improves the look/feel/gameplay
    4. the "bullets" are used as decorators during the death sequence (star explosion)
    5. they are also used as shrapnel when rocks fall onto hard surfaces
    6. I've removed (for now) the mid and overview modes. 
    7. I've fixed the crash when rocks fell on the player, and have re-enabled this (and hence death)

     

     

    Coming soon, maybe... a sort of cannon that can shoot bullets left/right.  If i put these in strategic places on a level, and they shoot when the player is on the same level, then that might be neat.  Maybe in a few days to see how it goes.

     

     

    WenHop_20230225@22_07_29.bin

    • Like 3
  10. Just now, Gemintronic said:

    I've noticed the rate of gameplay experiments/changes has gone up.  Do you bother with a game design document?  At what point do you make one and/or update it?

    Haha... no, never.  I try ideas as they come to me. The gameplay/design is evolving. Call it agile.

    I'm just weaving through the universe of potential, trying to find things that look good, I enjoy programming, and which might be fun to play in a game.

     

    • Like 2
    • Thanks 1
  11. Here's a version to play with.  I have a bug when stuff falls on the player so I've disabled that for now -- the screen rolls wildly even so... so basically don't let things drop on you for now.  In this version the use of the pick is now fixed -- 4 hits and should turn to dogecoin, and there's a pause in there before you move so no accidental coin grabs.  I've also put the "bullets" on the fire button, so when you hold that there's a random mass of bullets emanate from your current position. I plan to put the bullets on fire held, first emanating straight ahead, but as you hold the button and sweep the joystick around, you can change the direction you're firing in - pretty freeform would look a little like a flamethrower, actually - if the bullets were bigger.
    There's quite a few bugs - the aforementioned falling on you issue, but also we get random lines across the lower part of the screen. Please ignore - I know this is buggy; I'm pushing to try lots of new/experimental stuff rather than making it bug-free/tight.

     

    WenHop_20230224@22_59_53.bin

  12. You're gonna have a gun. And you're gonna need to shoot. Lots.  Here I've started work on the shooting system. At the moment there are just a heap of random "bullets" emanating from the player position. You can see they destroy dirt when they hit. Lots of bugs, and not ready for prime-time-release yet. But the basic principle seems to work OK.
     

     

    • Like 2
  13. Some attention to sound effects.  Particularly when you trigger a dogecoin conversion.

    This version is back to being tricky to getting the timing right - no delay - because I want the conversion to trigger quickly. The solution will be to wait for joystick release before allowing player to grab generated dogecoin. In this version the "chain reaction" proceeds at uniform speed in all directions, whereas it used to be kinda instant down and to the right, and slow up and left. Video shows slightly older version that didn't do it that way. Binary shows the new way.

    That's all for today.

     

     

     

    WenHop_20230223@23_27_57.bin

    • Like 4
×
×
  • Create New...