Let's Go! [First Major Release]

[Morri]

Hi,
I have been making a game over the past month using CPC BASIC 3. I must say that it is an amazing tool for all of those people who never got past learning BASIC (like myself  ).
Basically, you type your BASIC program into CPC BASIC 3, use the "RUN" command to compile it into machine code, use ManageDsk to add it to a .DSK file and create a simple BASIC loader to load it all up. As I make changes, it literally takes me 30 seconds to compile, add and test with WinAPE. SIMPLE!!!

After learning from @AMSDOS that it can be combined with other sprite drivers, I started experimenting with ESD2 from Sean McManus. While not the most powerful sprite routine ever written, it is short and easy to understand with only a few CALL commands to achieve what you need.

Anyway, I have began coding a game I have called "Let's Go!" which is a clone of the mobile game Relic Rush.
It features graphics in mode 0 (not my own but I can't remember where I got the tileset from) which are double pixelled vertically so that each pixel appears to be square. It gives the game a nice colourful, chunky retro feel. I actually like how they came out.
The gameplay is extremely simple being a one button game; press SPACEBAR (and eventually FIRE on a Joystick) to make your character stop (in order to avoid obstacles) and release to continue moving.
While not yet implemented I hope to make the following additions:
- Moving over an arrow will cause the player to jump, moving to a ladder will automatically climb etc until you reach a flag within the allowed time limit.
- Enemies will include falling and sliding blocks, enemies firing laser beams from their eyes and enemies hurling objects.

I have attached a .DSK file at the end of this post and will put any major updates here as I finish them. No doubt I will also run into heaps of problems and will probably have to ask for help from the experts  . Here's hoping I can get this finished  .

v1.0 - 12th July 2015 - Very early release. The player only moves left to right and has no reaction to any obstacles / ladders. Enemies do not move yet. SPACEBAR causes the player to stop. Working timer bar counts down and once reaches zero, the game is over and returns to the main menu.
v1.1 - 17th July 2015 - The player now jumps when passing over a "Jump arrow". Have attempted to add a sound effect but currently there is a delay.
v2.0 - 25th July 2015 - Player can now climb ladders. Block enemies now move. No player / enemy collision detection yet. Level completes when flag is reached and a tune is played. Removed jump sound effect.
v3.0 - 26th July 2015 - Collision detection added. Death sequence with sound effect added.
v4.0 - 26th September 2015 - First major release - All gameplay elements are present. 12 levels added. Ranking system added.
 

[AMSDOS]

That's looking great. I'm assuming you're using Double Buffering during the game? Don't know why I couldn't get that to work in CPC BASIC3 if that's the case.

[Morri]

That's looking great. I'm assuming you're using Double Buffering during the game? Don't know why I couldn't get that to work in CPC BASIC3 if that's the case.

No double buffering used, just a few well placed FRAME commands  . I thought I might have to ask about buffering when I first started because it was so flickery it was nearly unwatchable  . Can't talk too soon as it may get worse once more sprites are moving at the same time. If you ever manage to figure buffering out with CPC BASIC 3, be sure to let me know.

Just FYI, here is my order of commands to achieve this flicker free version so far.

• Take a snapshot of the background the sprite is about to be placed and save it to ram. (Using the ESD2 CALL 40164,ram,xpos,ypos,xsize,ysize)
• Place sprite over background (CALL 40053,sprite,xpos,ypos). Also use oldx=xpos and oldy=ypos (refer 7)
• FRAME
• Check for key press, reduce timer and check for obstacles (only the side walls done so far - If no obstacle then increase/decrease xpos or ypos)
• Change sprite animation (only have 2 per direction to keep it easy)
• FRAME
• Place background back over sprite using CALL 40000,ram,oldx,oldy
• Go back to 1.

[mr_lou]

This is great! 
Seems like everyone is doing games for the CPC these days. 
I like how it's possible to develop for the CPC in so many different ways.

@Morri, are you planning on submitting this to the CPCRetroDev2015 too? You should! 

Not entirely sure about the rules though. @ervin, do you think it's ok to post the games here on the forum, if they are to be accepted by the CPCRetroDev2015 crew?
I remember them writing something about that the games shouldn't previously have been released. Maybe it's considered a release when posting it on the forum?

[Trebmint]

This looks really nice... please finish it. A very Bubble Bobble look to it, though I dont know what the game play is going to be. Seems like a bit of a renaissance in the past few months with CPCbasic and CPCtelera going on. I must admit that looking at the source CPCBasic was producing was a real eye opener as it's near perfect, and as quick as can be. Obviously the negative number stuff is an issue, but for games thats not really a problem at all. Actually I think this will claim due to not coping with negative values to be the fastest compiler of any language on the CPC... Im doing Unify at the moment and was hoping to out speed everything, but in this case its actually impossible.


Very good stuff. Great looking start to a game too.

[Morri]

Thanks everyone for the feedback. I will do my best to keep working on it.
In saying that I do get easily distracted and I just spent the last hour watching Rick Dangerous longplays on Youtube  .

[mr_lou]

Thanks everyone for the feedback. I will do my best to keep working on it.
In saying that I do get easily distracted and I just spent the last hour watching Rick Dangerous longplays on Youtube  .

No worries. The deadline for CPCRetroDev2015 isn't till October 23rd, so there's plenty of time. 
And you can win 300 euro!!!
 

[Morri]

No worries. The deadline for CPCRetroDev2015 isn't till October 23rd, so there's plenty of time. 
And you can win 300 euro!!!

A great incentive for sure. I did see the post from @ronaldo and it's a wonderful idea to generate interest and support for games creation.
If my game meets the criteria I would happily summit it without really worrying about winning or losing. I just want to see more games for the CPC and that really seems to be happening atm. It's such a great thing to see.

I must admit that looking at the source CPCBasic was producing was a real eye opener as it's near perfect, and as quick as can be. Obviously the negative number stuff is an issue, but for games thats not really a problem at all. Actually I think this will claim due to not coping with negative values to be the fastest compiler of any language on the CPC... Im doing Unify at the moment and was hoping to out speed everything, but in this case its actually impossible.

Very interesting to hear your thoughts on CPCBasic knowing you are an excellent Z80 coder. I was unsure myself how efficient the code being produced actually was so it's great to hear that @Dinoneno did such a good job.

p.s. Thanks for all your efforts with Unify, it is sounding more and more exciting with every post re symbos. Can't wait.

[Trebmint]

Very interesting to hear your thoughts on CPCBasic knowing you are an excellent Z80 coder. I was unsure myself how efficient the code being produced actually was so it's great to hear that @Dinoneno did such a good job.

Yes I did look at the source for a while and it looks very nice indeed. I would deny however I'm a good Z80 coder, but you dont need to be to see its pretty tight with CPCBasic. So yes he did an excellent job, and the optimizations are well done too including INCs and DEC for +1 -1's etc. Most of its unrolled too so, which is a judgement call on the part of the compiler coder. When do you include unrolled code or a subroutine, as the speed increases but the size grows fast too.
Loops and expressions are the main area for speed, and TBH you on a z80 wont get results that hand coded will result in, as FOR's & WHILES just by the syntax tend to require saving and lookup of the loop value, when most coders cleverly save a register just for the purpose. However CPCBasic is an amazing bit of code though... I wont say as good as a compiler can get, but very very close. If you're game is too slow using this, you're either pushing too hard or your Basic code isnt good. I'd say that using CPCBasic and a Sprite package you should get speed results 95% as good as a pure z80 coded commercial game.
So yeah go for it... I'm loving the game devving thats going on I'd probably be involved if it wasnt for Unify, though saying that network Pong and Table Football is coming along

[ervin]

A great incentive for sure. I did see the post from @ronaldo and it's a wonderful idea to generate interest and support for games creation.
If my game meets the criteria I would happily summit it without really worrying about winning or losing. I just want to see more games for the CPC and that really seems to be happening atm. It's such a great thing to see.
Very interesting to hear your thoughts on CPCBasic knowing you are an excellent Z80 coder. I was unsure myself how efficient the code being produced actually was so it's great to hear that @Dinoneno did such a good job.

p.s. Thanks for all your efforts with Unify, it is sounding more and more exciting with every post re symbos. Can't wait.

Yes indeed, Dinoneno has some serious talent.
I used his ccz80 compiler for 6 years, and loved every minute of it.
Really great compiler, and very easy to use.

The only reasons I've moved on are because cpctelera offers a wonderful environment with lots of tools/functions integrated nicely, and also the fact that (because cpctelera uses SDCC) I no longer have to write workarounds for negative numbers!

[ervin]

This is great! 
Seems like everyone is doing games for the CPC these days. 
I like how it's possible to develop for the CPC in so many different ways.

@Morri, are you planning on submitting this to the CPCRetroDev2015 too? You should! 

Not entirely sure about the rules though. @ervin, do you think it's ok to post the games here on the forum, if they are to be accepted by the CPCRetroDev2015 crew?
I remember them writing something about that the games shouldn't previously have been released. Maybe it's considered a release when posting it on the forum?

My understanding is that it's ok to have a WIP thread for your game, but no final release prior to the competition deadline.
If you're not sure, @ronaldo may be able to provide clarification.

I've got a development thread for my game RUN"CPC", but I'll be holding things back as it gets closer to completion.
My CPCRetroDev2015 entry - RUN"CPC"
My CPCRetroDev2015 entry - RUN"CPC"

In any case, there will be surprises in there that I don't want anyone to see until the competition is over! 

[AMSDOS]

No double buffering used, just a few well placed FRAME commands  . I thought I might have to ask about buffering when I first started because it was so flickery it was nearly unwatchable  . Can't talk too soon as it may get worse once more sprites are moving at the same time. If you ever manage to figure buffering out with CPC BASIC 3, be sure to let me know.

Just FYI, here is my order of commands to achieve this flicker free version so far.

• Take a snapshot of the background the sprite is about to be placed and save it to ram. (Using the ESD2 CALL 40164,ram,xpos,ypos,xsize,ysize)
• Place sprite over background (CALL 40053,sprite,xpos,ypos). Also use oldx=xpos and oldy=ypos (refer 7)
• FRAME
• Check for key press, reduce timer and check for obstacles (only the side walls done so far - If no obstacle then increase/decrease xpos or ypos)
• Change sprite animation (only have 2 per direction to keep it easy)
• FRAME
• Place background back over sprite using CALL 40000,ram,oldx,oldy
• Go back to 1.

It's been suggested to place other things between drawing and redrawing I think. It's something I struggle with for code which doesn't do much.


I'm trying to implement Sean's Overlay Sprite Driver, over the top of my Background Restore Routine, but I'm having trouble coming to grips with how Sean's Overlay Sprite Driver writes to screen. I was assuming his Fine Overlay Routine ignores 0s if found. So I thought if I had set another colour it would delete the edge when moved, but seems to be having the opposite effect. I'm assuming that because MODE 0 holds 2 pixels per byte, I need double 0 around the sprite for it to delete itself?

[Morri]

I'm trying to implement Sean's Overlay Sprite Driver, over the top of my Background Restore Routine, but I'm having trouble coming to grips with how Sean's Overlay Sprite Driver writes to screen. I was assuming his Fine Overlay Routine ignores 0s if found. So I thought if I had set another colour it would delete the edge when moved, but seems to be having the opposite effect. I'm assuming that because MODE 0 holds 2 pixels per byte, I need double 0 around the sprite for it to delete itself?

I too am using the overlay feature and the only way I could figure out to use it effectively was with the snapshot feature as I detailed (This technique was how Sean did his frog graphics demo). I haven't tried a double 0 around the sprites but that might work, not sure.

The only thing about the overlay feature is not all 0's are acting transparent. You'll notice it in my first release. The character walks over the cliff sprite and there are blue pixels around him. These are ink 0 and are supposed to be transparent. Maybe half the 0's work as they should. It's very weird. Any ideas?

[Xifos]

I The character walks over the cliff sprite and there are blue pixels around him. These are ink 0 and are supposed to be transparent. Maybe half the 0's work as they should. It's very weird. Any ideas?

Masking done at byte level, not pixel ?

[AMSDOS]

Masking done at byte level, not pixel ?

Sean's Sprite Routines all use Encoded Ink, so is handled at Byte Level.


My Plot Image routines use Graphics Pen colours, so can draw at Pixel Level, but because it's using Firmware, it's slow.

[AMSDOS]

I too am using the overlay feature and the only way I could figure out to use it effectively was with the snapshot feature as I detailed (This technique was how Sean did his frog graphics demo). I haven't tried a double 0 around the sprites but that might work, not sure.

The only thing about the overlay feature is not all 0's are acting transparent. You'll notice it in my first release. The character walks over the cliff sprite and there are blue pixels around him. These are ink 0 and are supposed to be transparent. Maybe half the 0's work as they should. It's very weird. Any ideas?

From the experiment I did based on 0s around the image, the Overlay skips the 0s, so if an image is there, it remains there after the sprite is drawn. What I was looking to do was generate a blanking effect around the character, then use this other little routine I made for Filling in the Background, minimising it to a few pixels. I got excited when I only saw a couple of those blue pixels when the character walks over the cliff area.
 
I can only think what's happened in your case is the Left Most Pixel was another value, an invisible square around the character would do that and then you had a black character as the Right Most Pixel, I can confirm this when I put my invisible border along the outer edge of my sprite, for me it might mean part of the background is deleted from an 0 as well as the outer edge, which would be bad for my backdrop routine if that's the case.

[AMSDOS]

I cannot quite put my finger on what this overlay routine is doing, when I move by sprite down the edges which has a zero in it becomes the pixel from the next line down and I have this other line which when is first drawn is just a line of 0s, earlier I had my blanking value (ink 9), which almost worked until I moved across the screen, not deleting some pixels where the sprite is near the edge. I'd thought I tried it with as many of the blanking inks, but now I don't know.

[Morri]

New update v1.1! See OP for download. Main sprite can now jump when he passes over the arrow sprite.

I've also added a jump sound effect but there is a delay between the command and the execution. The SOUND command is given before the jump command but doesn't play until the sprite has landed. Can anyone help with why that is.

[ervin]

@Morri - looking good!

The jump sound effect seems to be timed correctly.
Maybe (just temporarily) change it to a shorter, sharper sound effect, rather than the one you've got now.

The sound effect you are using starts quiet and gets louder near the apex of the jump.
Could that be affecting your perception of when the sound effect starts?

If you find that a temporary short sound effect is timed correctly, you can then be confident that everything is ok, and then you can put your actual sound effect back in.

[AMSDOS]

I tested the updated version in Winape and noticed there was some Graphical glitches appearing:


[attachimg=1]


Initially I thought this might of been occurring while I was in 464 settings, but this little graphical sprinkles seems to be occurring when I've CATaloged the Disk Image. A Memory dump was showing the results from the CAT resided around the same area ESD2 & Halfsize Fonts, unfortunately I wasn't able to resolve the problem & thought it might have something to do using an area which is normally 0, but not defining it as 0, which is resulting in all this stuff coming up because it's not being blanked out. Probably the easiest way to resolve that is save that area when it's all 0, then loading that which just ensures that problem won't happen in case someone does a CAT?

[Morri]

I tested the updated version in Winape and noticed there was some Graphical glitches appearing...

Interesting bug  My latest build as of last night is now resetting after a CAT (no issues when no CAT is done) so the problem is becoming more serious. 
I'll just keep soldiering on with it and see how far it will let me go. Once I know the exact size of the main file (currently at 8kb and growing) then I can try and move things to avoid this bug but I'm running out of space quick if this is going to stay a 64kb game. 

[AMSDOS]

Interesting bug  My latest build as of last night is now resetting after a CAT (no issues when no CAT is done) so the problem is becoming more serious. 
I'll just keep soldiering on with it and see how far it will let me go. Once I know the exact size of the main file (currently at 8kb and growing) then I can try and move things to avoid this bug but I'm running out of space quick if this is going to stay a 64kb game. 

I noticed with your first prototype this wasn't occurring, though there weren't many files on the disk, so it seems it's getting worse the more files are being stored on disk, which would result in more memory being used.
Of course with ESD2 the first 2 bytes deal with the Width & Height of the Sprite, it doesn't like it when it doesn't find what it wants, but I don't see how a CATaloging the Disk to Memory would interfere with that since it's been loaded after all that.

[arnoldemu]

If the data/code goes past &a700 then a catalogue could destroy it because the catalogue is stored around here.
So it means you need to make your code smaller, or start it at a different location,  or load it lower and copy it up before running it.

[Morri]

New version update. See OP for download.

I have added a few things this time round. Climbing ladders, stage completion, enemy movement. See what you think. It's starting to resemble what I was going for so that's a bonus.

Last big gameplay addition may prove to be the trickiest and that is player / enemy collision detection. I'm not too sure how to go about this. Any suggestions would be appreciated. Once that's sorted, I would like to start adding different enemies.

I also created a .DSK file with all the redundant files removed. This seems to help with the CAT bug for now.

[Axelay]

Last big gameplay addition may prove to be the trickiest and that is player / enemy collision detection. I'm not too sure how to go about this. Any suggestions would be appreciated. Once that's sorted, I would like to start adding different enemies.

If you have used some sort of map or grid for detecting platforms and ladders, you could perhaps use the same grid for enemy collision detection, but it might be too coarse.  Another way would be to use bounding boxes.  Here's a crude example of the bounding box approach in BASIC, use the cursor keys to move the player about:

Code: [Select]

10 plyWid=2:plyHgt=2
20 eneWid=3:eneHgt=3
30 CLS
35 DIM enemy(3,2)
40 FOR x=1 TO 3
50 READ enemy(x,1): READ enemy(x,2)
60 NEXT x
70 plyX=1:plyY=1
90 REM main loop
100 GOSUB 210
110 GOSUB 410
120 GOSUB 610
130 GOTO 100
200 REM refresh enemy display
210 PEN 2
215 FOR x=1 TO 3
220 FOR y=1 TO eneHgt
230 LOCATE enemy(x,1),enemy(x,2)+y-1
240 PRINT "***"
250 NEXT y
260 NEXT x
320 RETURN
400 REM bounding box collision check
410 bordercol=1
420 FOR x=1 TO 3
430 IF plyX+plyWid-1<enemy(x,1) THEN GOTO 500
440 IF plyX>enemy(x,1)+eneWid-1 THEN GOTO 500
450 IF plyY+plyHgt-1<enemy(x,2) THEN GOTO 500
460 IF plyY>enemy(x,2)+eneHgt-1 THEN GOTO 500
470 REM bounding box collision detected
480 bordercol=6
500 NEXT x
510 BORDER bordercol
520 RETURN
600 REM clear player, get input and move player, update player position
610 LOCATE plyX,plyY
620 PRINT "  "
630 LOCATE plyX,plyY+1
640 PRINT "  "
700 IF INKEY(0)=0 AND plyY>1 THEN plyY=plyY-1
710 IF INKEY(2)=0 AND plyY<23 THEN plyY=plyY+1 
720 IF INKEY(8)=0 AND plyX>1 THEN plyX=plyX-1
730 IF INKEY(1)=0 AND plyX<38 THEN plyX=plyX+1
750 LOCATE plyX,plyY
760 PEN 1
770 PRINT "++"
780 LOCATE plyX,plyY+1
790 PRINT "++"
800 RETURN
1000 DATA 7,5,15,10,20,15
[size=78%] [/size]