Robot Santa

edited November 2014 in Brand new software
Alien Ferox has grown beyond what could be accomplished on a humble Speccy - i've run out of memory AND ideas so that's indefinitely halted.

BUT

In it's stead I decided to try my hand at a little Christmassy platformer, and it's well on the way to completion. Finally getting to grips with AGD, and with all the game mechanics in place all that's left is to add a front-end, completion screen, a few more sprites and more rooms.

So, here's a demo version of... Robot Santa (this title could change at any point :-P )

RobotSanta.png

It's simple enough to play... while on the fans, just press up to fly up the shaft... you can leave the shaft via any of the exits above (but obviously you can't go down!) You're character has a battery meter that depletes when you contact an enemy... this can be replenished at a recharge point, but if it reaches zero, a life is lost, and water kills immediately! Also, your battery automatically depletes slowly by itself..

Collecting a set number of pressies opens up the next set of screens (but i've locked this feature off for the demo!)

Oh, the keys are - O: Left, P: Right, Q: Jump/Float up shaft.

And i'd recommend playing in Spin... for some reason, sound in other emulators doesn't function as well (or at all!)

Anyway, hope you enjoy it - the full version should be out within the next couple of weeks :smile:

Download it here!!

Si
Post edited by SimonLCFC on
«1

Comments

  • edited October 2014
    nice atmosphere! really like the idea of using cubes for a pseudo 3D effect! only sonetimes having white sprites over a yellow or green or cyan background makes it hard to see them...maybe you could change colors ? or use some ink that is different from white?

    also it would be nice to have death animations (you know when the player looses a life)
    for that instead of using "kill" you can use
    "remove
    let b= 0
    spawn x y"

    where
    x= sprite type
    y= sprite number

    then in the x sprite event write something like
    "if image =y
    if a=0
    animate
    endif
    if b= 50
    kill
    endif
    endif"

    "a" is the usual counter for animation speed (you set that in the main loop event); b is another counter (also set in the main loop event:
    if b=50 let b=0 else add 1 to b endif) used so that the death animation lasts a while (from 0 to 50 in my example or to the number of your choice; it is important to set b=0 in the first part of the code otherwise death animation will last from wherever b is until it reaches 50; b cycles continuosly between 0 and the number you choose unless you restart from 0 when the collision with the enemy happens)
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • edited October 2014
    Man, this is very beautiful!

    I found some problems sometimes with the 'jump-boosting-devices' (haha) - it's hard to put the hero exactly in the place.

    Anyway - I wait for the final version.
    ZX81/ZX Spectrum/Amiga/Atari music: http://yerzmyey.i-demo.pl/
  • edited October 2014
    Very cute.
  • edited October 2014
    The best thing I can do with regards to making the character more visible would be to insert more of the darker blocks (and create darker dice blocks to add in - two character blocks each so should be easy enough.) I do agree though, sometimes it's a bit difficult to see the li'l fella.

    And i'd completely forgot about a death animation - tbh i'd not even thought about it after tinkering with the EXPLODE command and not getting it to work right lol, but i'll definitely be adding something in.

    And i'm glad nobody's spotted a parcel that gets nabbed by an enemy before you get a chance to pick it up :lol: a little glitch that's been fixed now!

    12k left, plenty of room to add more stuff :-)
  • edited October 2014
    Cool, this is very promising..!

    It's got a nice graphical style but I'd say from a gameplay perspective it feels really, really nice.. I sometimes feel like I struggle with jumping in some AGD games but this one feels natural, and I like the way you can control your jumps. I'm guessing you must have spent some time on the controls.

    At first I wasn't sure what was a solid platform and what wasn't, but I'd figured it out after traversing a couple of screens and it seemed very logical after that, so personally I wouldn't change much in that respect.

    I agree that a death animation or something would be cool, otherwise the game can start a bit quickly and it only takes a millisecond to lose your bearings.

    Look forward to playing the final version! :-)
  • edited October 2014
    I like the clockwork robot and the pseudo3d blocks, the hero could be more defined with a bulging eye like the pixar character. Instead of making all sprites in white, could be in a changing rainbow colour ? you know like the items in JSW, it could fit well with the toy theme and help them stand out from platforms.
  • edited October 2014
    A very attractive game. Love the use of single pixels throughput for snow and drafts etc.

    Thank you!
  • edited October 2014
    nice atmosphere! really like the idea of using cubes for a pseudo 3D effect! only sonetimes having white sprites over a yellow or green or cyan background makes it hard to see them...maybe you could change colors ? or use some ink that is different from white?

    also it would be nice to have death animations (you know when the player looses a life)
    for that instead of using "kill" you can use
    "remove
    let b= 0
    spawn x y"

    where
    x= sprite type
    y= sprite number

    then in the x sprite event write something like
    "if image =y
    if a=0
    animate
    endif
    if b= 50
    kill
    endif
    endif"

    "a" is the usual counter for animation speed (you set that in the main loop event); b is another counter (also set in the main loop event:
    if b=50 let b=0 else add 1 to b endif) used so that the death animation lasts a while (from 0 to 50 in my example or to the number of your choice; it is important to set b=0 in the first part of the code otherwise death animation will last from wherever b is until it reaches 50; b cycles continuosly between 0 and the number you choose unless you restart from 0 when the collision with the enemy happens)

    First chink in the armour...!

    Ok, so i've drawn a nice 8 frame death animation for the bot, and implemented the code you've provided, but I can't get it to work at all. It shows the animation, miles away from the original sprite (which doesn't lose a life, and can still move with the death animation on screen.) I've made a slight chance - the 'b' variable is used for battery power - substituting it for 'd' but no matter what I try (and i've been trying for a good while now) I can't get it to die nicely lol.

    Unless anybody has any suggestions (oh, and i'm using AGD 4.6 btw) i'm going to put this on the back-burner for now.

    And thanks for the comments chaps :-)
  • edited October 2014
    I like the aesthetics of the game, you have a lot of talent for graphics, thats clear. It plays smoothly and has some elements that make it fresh ;)
    Keep it up!
  • edited October 2014
    The colours look great, but in this style it would help if the sprites could be drawn 4 pixels higher, to stand in the centre of the platforms.
    Joefish
    - IONIAN-GAMES.com -
  • edited October 2014
    joefish wrote: »
    The colours look great, but in this style it would help if the sprites could be drawn 4 pixels higher, to stand in the centre of the platforms.

    Absolutely correct, and now fixed. The star sprite remains the same, but the main sprite has had his broken antenna fixed and his top position is at the top of the sprite, raising him 5 pixels and eliminating (imo) a lot of the colour/visibility issues too. Have done this with the other robot sprite too, have made the recharge pad a pixel smaller, but will get rid of that stupid chomping evil santa sprite, draw some other stuff tomorrow (or perhaps steal that little chomping bouncing ball sprite from Ferox!)

    Anyway, thanks for that joe
  • edited October 2014
    oh sorry i forgot: you probably have the enemy collision part of the code in the enemy code, right? so you need to use "OTHER" (otherwise what you wrote will aplly to the enemy itself not to the player character

    so, assuming this is in the enemy sprite code:

    "IF COLLISION 0
    let b=0*
    OTHER
    REMOVE

    SPAWN X Y
    ENDIF"

    In the main event
    "If a=1 (or 2 for a slower animation)
    let a= 0
    else add 1 to a
    endif
    if b (or whatever other variable)= 50
    let b=0
    else add 1 o b
    endif"

    In sprite code X:
    If image=y (defining what image allows me to have more than a death animation, always inside code x; this way i can have death animations also for the enemies)
    if b=50
    kill
    endif
    endif

    hope that works for you (as it does for me...)
    * you can set b=0 or to 20 or to whatever number so the time your sprite stays in death animation changes (for example depending on the enemy with which it collided, or depending on what sprite is in death animation, you or the enemy/ies)
    SimonLCFC wrote: »
    First chink in the armour...!

    Ok, so i've drawn a nice 8 frame death animation for the bot, and implemented the code you've provided, but I can't get it to work at all. It shows the animation, miles away from the original sprite (which doesn't lose a life, and can still move with the death animation on screen.) I've made a slight chance - the 'b' variable is used for battery power - substituting it for 'd' but no matter what I try (and i've been trying for a good while now) I can't get it to die nicely lol.

    Unless anybody has any suggestions (oh, and i'm using AGD 4.6 btw) i'm going to put this on the back-burner for now.

    And thanks for the comments chaps :-)
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • edited October 2014
    Great stuff. The 'boost up' columns work well for me.

    There are a few visibility issues with white ink on yellow paper but with graphics as sexy as this it's less of a problem. Did you try contrasting inks in the blocks? E.g. darker legs when walking through a light block? Just a thought, though it might look a bit wrong.
  • edited October 2014
    I'd like to insist on the rainbow cycling effect that I mentioned before so that you consider it for your sprites. See it in action on the AGD game TerraHawk whose source code was released here:
    http://www.worldofspectrum.org/forums/showpost.php?p=781861&postcount=24
  • edited October 2014
    I like the "particles" you use. True power of software rendering. C64 I guess would struggle to render that using limited HW sprites resources (and super slow CPU). Perhaps Mega Drive would manage that...
  • edited October 2014
    oh sorry i forgot: you probably have the enemy collision part of the code in the enemy code, right? so you need to use "OTHER" (otherwise what you wrote will aplly to the enemy itself not to the player character

    so, assuming this is in the enemy sprite code:

    "IF COLLISION 0
    let b=0*
    OTHER
    REMOVE

    SPAWN X Y
    ENDIF"

    In the main event
    "If a=1 (or 2 for a slower animation)
    let a= 0
    else add 1 to a
    endif
    if b (or whatever other variable)= 50
    let b=0
    else add 1 o b
    endif"

    In sprite code X:
    If image=y (defining what image allows me to have more than a death animation, always inside code x; this way i can have death animations also for the enemies)
    if b=50
    kill
    endif
    endif

    hope that works for you (as it does for me...)
    * you can set b=0 or to 20 or to whatever number so the time your sprite stays in death animation changes (for example depending on the enemy with which it collided, or depending on what sprite is in death animation, you or the enemy/ies)

    I think i've nailed what the issue is (the above code isn't working correctly either.)

    Each enemy sprite TYPE contains:

    IF COLLISION = 0
    BEEP 50
    SUBTRACT 1 FROM B
    SUBTRACT 8 FROM Y
    TRAIL
    ADD 8 TO Y
    ENDIF

    Contact with enemies drains 1 from the battery.

    And in Main Loop 1

    IF B = 0
    LET R = 50
    LET B = 100
    KILL
    ENDIF

    B is the battery variable (when this runs down to 0, kill the player)
    R is a countdown timer. 1 is subtracted from this constantly, and once this hits 0, 1 is removed from the battery. Once both variables hit 50, both are reset, and the player dies.

    Trouble is, doing it like this, there is no code in the sprite types dealing with any player deaths, just collisions that drain the battery. The death occurs in Main Loop 1.

    Hikoki: i'm gonna leave the colours the way they are (for the most part) but i've downloaded TerraHawk, and I may well look at using some stuff for my next title.... whatever that's gonna be lol...

    Maiki: Thanks :) the particle effects have been built into AGD, and are remarkably easy to implement, that's why there are particles everywhere :lol: (floating up, hitting an enemy, collecting a parcel, falling to far, and used as 'snow'!!) I kinda went overboard - I like the effect....
  • edited October 2014
    Fine, I wonder if this cycling-colour technique could help in general to fight against clash and self-censhorip when using colours, or rather, it'd be difficult to make it work in moving sprites
  • edited October 2014
    SimonLCFC wrote: »
    I think i've nailed what the issue is (the above code isn't working correctly either.)

    Each enemy sprite TYPE contains:

    IF COLLISION = 0
    BEEP 50
    SUBTRACT 1 FROM B
    SUBTRACT 8 FROM Y
    TRAIL
    ADD 8 TO Y
    ENDIF

    Contact with enemies drains 1 from the battery.

    And in Main Loop 1

    IF B = 0
    LET R = 50
    LET B = 100
    KILL
    ENDIF

    B is the battery variable (when this runs down to 0, kill the player)
    R is a countdown timer. 1 is subtracted from this constantly, and once this hits 0, 1 is removed from the battery. Once both variables hit 50, both are reset, and the player dies.

    Trouble is, doing it like this, there is no code in the sprite types dealing with any player deaths, just collisions that drain the battery. The death occurs in Main Loop 1.


    Ah! I see (btw nice way of draining energy: i wish i thought of that for "Leonardo last lost invention"

    my question is: what is the advantage of having this part
    "IF B = 0
    LET R = 50
    LET B = 100
    KILL
    ENDIF"
    within the main loop?
    what if you put it inside the sprite 0 (player) code?
    it should work as well... then instead of "kill" you could put

    "Remove
    spawn x y"

    and in the x sprite code (i usually have my death animations in code 8 )
    you could have your death animation (using the sprite image y)

    You need to have a counter for that (not B obviuosly, you should se another counter or maybe even use R, if you run out of variables*)
    so that when that counter goes to 0 (or to a certain value, depends if it is going up or down) then there is the kill. otherwise you woill not be able to se the death animation

    so in code 8 i write

    "if a=0
    animate
    endif
    if (counter) =0
    kill**
    endif"


    *The trouble of using R would be that it goes on even when the death anmation is played, so the player looses energy even when in death animation.
    It would be best to have a different counter for death animation and have a "let R= (any value you want)" inside the code 8. This way while death animaton is running, R stays at that value and the player does not loose energy

    ** sometimes instead of using "kill" i used
    "
    if (counter)=0
    if lives>1
    remove
    spawn 0 0
    subtract 1 from lives
    else
    kill
    endif
    endif"


    this way the player looses a life but the action continues from the place the player was killed (instead of having the player going back to the starting place
    unless lives are 0, in which case the player is killed and the game ends
    (cannot use "if lives>0" because then lives will restart from 255)
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • edited October 2014
    Ah! I see (btw nice way of draining energy: i wish i thought of that for "Leonardo last lost invention"

    my question is: what is the advantage of having this part
    "IF B = 0
    LET R = 50
    LET B = 100
    KILL
    ENDIF"
    within the main loop?
    what if you put it inside the sprite 0 (player) code?
    it should work as well... then instead of "kill" you could put

    "Remove
    spawn x y"

    and in the x sprite code (i usually have my death animations in code 8 )
    you could have your death animation (using the sprite image y)

    You need to have a counter for that (not B obviuosly, you should se another counter or maybe even use R, if you run out of variables*)
    so that when that counter goes to 0 (or to a certain value, depends if it is going up or down) then there is the kill. otherwise you woill not be able to se the death animation

    so in code 8 i write

    "if a=0
    animate
    endif
    if (counter) =0
    kill**
    endif"


    *The trouble of using R would be that it goes on even when the death anmation is played, so the player looses energy even when in death animation.
    It would be best to have a different counter for death animation and have a "let R= (any value you want)" inside the code 8. This way while death animaton is running, R stays at that value and the player does not loose energy

    ** sometimes instead of using "kill" i used
    "
    if (counter)=0
    if lives>1
    remove
    spawn 0 0
    subtract 1 from lives
    else
    kill
    endif
    endif"


    this way the player looses a life but the action continues from the place the player was killed (instead of having the player going back to the starting place
    unless lives are 0, in which case the player is killed and the game ends
    (cannot use "if lives>0" because then lives will restart from 255)

    Nailed it, thanks Gabriel :smile:

    Sprite Types 4-7 contain enemy code (8 contains code for all static sprites - the fan and recharge pads.)

    Removed the battery drain from Main Loop 2, and added into Types 3-7:

    IF B = 0
    LET B = 100
    OTHER
    REMOVE
    SPAWN 3 10
    ENDIF

    And in Type 3 the code is as follows:

    LET A = 1
    ANIMATE
    ADD 1 TO D
    IF D <= 7
    BEEP 75
    ENDIF
    IF D = 8
    SOUND 0
    ENDIF
    IF D = 15
    LET D = 0
    KILL
    ENDIF

    And it works perfectly! The extra bits of code are due to the death animation - the first few frames are the player being electrocuted (using BEEP 75 as an electrocution-type sound) and frames 8-13 are the player exploding (so SOUND 0 is called when frame 8 is reached.)

    So, Gabriel, thanks! Now we have death animation!

    Now.... how does this work with deadly blocks? :lol:
  • edited October 2014
    Newly shrunk-down sprites (I decided to alter the star, looked a bit oversized compared to the other sprites, as did that stupid swinging ball thing!)

    ROBOTSANTA-A.png

    Hopefully this eliminates a lot of visibility issues people were having.

    Si
  • edited October 2014
    SimonLCFC wrote: »
    ....

    Now.... how does this work with deadly blocks? :lol:

    Cool I am glad this works !
    as for deadly blocks (or custome blocks)
    the good news is that you can detect if your sprite (player or enemy) is over a deadly (or custom) block

    so just write this in the sprite 0 code
    "if deadly
    remove
    spawn 3 10
    endif"

    actually you can use deadly (or custom) blocks for whatever thing you fancy
    for example you could make the player to change its image (i am doing this with "Cattivik never dies")

    in "almost bosconian" i used custom and deadly blocks in the radar part of the game so when the little starship in the radar hits a deadly or custom block a purple or a green enemy starship is spawn in the center of he black screen (where the player starship is )
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • edited October 2014
    SimonLCFC wrote: »
    Newly shrunk-down sprites (I decided to alter the star, looked a bit oversized compared to the other sprites, as did that stupid swinging ball thing!)

    ROBOTSANTA-A.png

    Hopefully this eliminates a lot of visibility issues people were having.

    Si

    ...errr where is the new version?
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • edited October 2014
    The blocks are identical, all sprites have been changed and/or raised by 5 pixels, so in effect, the sprites are new ;)
  • edited October 2014
    I think he was asking, where is the download link for this new version?

    I still think that yellow paper is too much for white sprites though. Maybe swap those instances for something else.
    Joefish
    - IONIAN-GAMES.com -
  • edited October 2014
    I'll jiggle about with the colours once the game itself is complete (which isn't too far off now.) I can see your point though joe, visually i'm happy with the game but I think some of the colours could do with a tweak here or there.

    That code worked fine for the deadly objects btw Gabriel (can't remember how I did it, but when I tried it, there were issues) so again thanks!

    And there isn't a download link for the new version. As i've said, i'm close to completing it now, so the next download will be the full version :)
  • edited October 2014
    cool can't wait for the final release!



    SimonLCFC wrote: »
    I'll jiggle about with the colours once the game itself is complete (which isn't too far off now.) I can see your point though joe, visually i'm happy with the game but I think some of the colours could do with a tweak here or there.

    That code worked fine for the deadly objects btw Gabriel (can't remember how I did it, but when I tried it, there were issues) so again thanks!

    And there isn't a download link for the new version. As i've said, i'm close to completing it now, so the next download will be the full version :)
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • edited October 2014
    Almost done, and a couple more chinks in the armour found.....

    1: For the game complete event, i've called a screen number - this works absolutely fine, but I need to be able to completely remove the player sprite.
    Having the star effect on this screen would be nice, but again, something I can't get working.

    2: For the game menu, again i've called a screen number. For some reason, text messages bring up a "K: Invalid Colour, 10:5" error and returns AGD to BASIC. So, with memory left, i've added a character set to the blocks, created a menu screen, but for the life of me I can't work out how to call it - all thats required is calling the screen and a key press to start the game.

    *Ok, i've successfully called a screen for the title screen, but it freezes, and doesn't allow play to start...

    Once these issues are resolved, i've just a loading screen to create, bung them all together, and it's done!!

    Si :-)
  • edited November 2014
    you can call a screen (for example if your player sprite toches a certain object) where you simply place no player sprite
    just place a sprite (es code 3) using the a certain image (i like to have one that reproduces the player sprite)
    in that screen and
    in the code for that sprite write

    "if image= ...
    if screen=...
    if key 4 (if the player does nothing the game stays in that screen; if you have animated sprites they will play their animation routine; if the player hits key 4, the game ends)

    endgame
    endif
    endif"

    i did this in "donkey kong reloaded" and in "albert the wolf" and it works just fine


    for the menu you can use text messages to decorate it:
    in "donkey kong reloaded again" and "donkey kong jr II" I modified the characters (small case letters) and arranged them to compose the image of the kong. It takes some memory but everything is defined inside the menu screen (no need to call another screen).


    SimonLCFC wrote: »
    Almost done, and a couple more chinks in the armour found.....

    1: For the game complete event, i've called a screen number - this works absolutely fine, but I need to be able to completely remove the player sprite.
    Having the star effect on this screen would be nice, but again, something I can't get working.

    2: For the game menu, again i've called a screen number. For some reason, text messages bring up a "K: Invalid Colour, 10:5" error and returns AGD to BASIC. So, with memory left, i've added a character set to the blocks, created a menu screen, but for the life of me I can't work out how to call it - all thats required is calling the screen and a key press to start the game.

    *Ok, i've successfully called a screen for the title screen, but it freezes, and doesn't allow play to start...

    Once these issues are resolved, i've just a loading screen to create, bung them all together, and it's done!!

    Si :-)
    Find my (mostly unfinished) games here
    https://www.facebook.com/groups/1694367894143130/
  • edited November 2014
    Well, in a roundabout way, it's working :-)

    Impletementing the code that way still presented issues, so I added:

    Player Type 0 Controls:

    IF IMAGE <= 1
    IF SCREEN = 24
    IF P >= 12
    IF J >= 101
    KILL
    ENDIF
    ENDIF
    ENDIF
    ENDIF

    And at the beginning of Kill Player:

    IF SCREEN = 24
    IF P >= 12
    IF J >= 101
    LET SCREEN = 25
    REDRAW
    ENDGAME
    ENDIF
    ENDIF
    ENDIF

    Which effectively removes the player sprite (no explosion since REMOVE & SPAWN 3 10 wasn't used) draws the end-screen and places the new sprite at the start position of the end screen. And done :D

    I've drawn the title screen manually btw (and used blocks to create title logo, graphics and a character set.)

    Having issues with Text has caused serious issues (that thankfully have been worked around) so now I just need to insert a loading screen, double check a jumping issue and fix a silly problem involving decreasing numbers on the status:

    DISPLAY B
    PUTBLOCK 32

    Shows on the display: 100, then obviously 99, 98 etc. (instead of 990) but for some reason whatever block is placed after the number, is garbled. It DID work, but now it doesn't wanna know...

    And jumping has started to get erratic (some jumps are longer than others for no reason I can figure out) - to the point where i've had to redraw bits of screens to ensure players won't all their lives because one jump is longer then the next jump...

    :x
  • edited August 2018
    Hi :),
    is it still unfinished?
    Post edited by Supamax on
Sign In or Register to comment.