Samurai Lantern/Night Ninja WIP

[ChrisB]

Been working in a conversion for the BBC B of a game called Samurai Lantern (https://adventurebit.itch.io/samurailantern) as an attempt at a fast paced platformer with large sprites.

I have the basic game mechanics working. There are several other bits to implement and it needs tuning and levels designing. Currently running at 25 fps - although I have an idea to improve this - but we'll see what happens.

I've tried to contact the author but no luck as yet so a video will have to suffice.

[lurkio]

Absolutely nuts! Amazingly great-looking game demo!

[leenew]

That looks absolutely great!
Well done so far!

Lee

[tricky]

Looks great.

[RobC]

That looks superb - what a good looking game

[oss003]

This is looking great ... nice graphics and very smooth ....

Greetings
Kees

[lovebug]

great looking game, amazing animation and smooth movement

its truely a work of art, well done

[fwibbler]

How on earth did you get so many colours on screen at once in that Mode?

[fuzzel]

Wow! Bring it on! And soon!

[ChrisB]

Thanks for all the kind words. The graphics are largely borrowed from the Itch game - hence me trying to contact the author.

How on earth did you get so many colours on screen at once in that Mode?

... by using a slightly squashed mode 2??? The graphics are all doubled vertically (originally for space reasons - although I'm not sure how necessary that is for now) so the pixels look square.

[RobC]

How on earth did you get so many colours on screen at once in that Mode?

... by using a slightly squashed mode 2??? The graphics are all doubled vertically (originally for space reasons - although I'm not sure how necessary that is for now) so the pixels look square.

They look really good. Could you use Tom's 160x128 mode to save on memory and CPU time?

[ChrisB]

I did look at that a but it seemed to be on the edge of what many monitors/screens would accept and I was concerned about compatibility.

[Dave_E]

That really looks great for a BBC game! The animation especially.

[ChrisB]

Long time with no update. One of the reasons for attempting this was to produce something using large sprites at a good frame rate. I have been trying to run the game at 50 fps and to do that I am looking at the sprite plotting routine. This is new territory for me and an experiment to see if I could do it.

I'm using exclusive or for the sprites to allow a "background" colour so the above demo uses read, eor, write. The main body of the samurai is 16x12 pixels (so 16x6 bytes - no compression). The routine in the demo above is basic in that it simply unplots then replots. Simplistically this would mean performing two reads, two eors and two writes per byte. So every update takes 16x6 pixels x 3 operations x 2 times or 576 operations.

I figured that I could update the overlapping part of the sprite with read, eor, eor, write (eg read screen, eor old sprite, eor new sprite, write screen). Taking the best case where the sprite moves a single pixel within a byte this would mean the routine performs 16x6 pixels x 4 operations which is 384 operations (a 33% saving). Unfortunately every other case requires that up to 4 "edges" are also drawn and if you only had a very small part of the sprite overlapping this would almost certainly take longer than the simplistic routine. It also makes the routine considerably more complex - hence it's taken me a long time to get this far... However - for the type of movement in this game (and the fact that a higher frame rate and allow smaller movements) this case should not occur too often.

At the moment my edge routines need finalising and I need to look at optimising the code once it's feature complete but it does appear to be faster the the old routine. I also need to put the new routine in the game. Here's a quick demo with no beam chasing so there is a minor tear at the top of the screen.

[tricky]

Looking good.
If your sprites aren't going to overlap, or maybe even if they are, you could also try a variation of what Sarah did on White Light.
Lda screen, and #background bits eor sprite and sta screen. Should save a few cycles with # and probably require less index manipulation and probably due into registers better.

[ChrisB]

With much fiddling I've more or less ported the new sprite routine into the game. There are some artifacts to do with the removal of sprites from screen when they "die" at the moment and the "hit" animaions aren't present for the moment.

After getting the overlapping squares to work I realised that generally moving left and right is no more than 2 pixels at a time (at that speed it only takes 1.5 seconds to get from one side of the screen to the other). As such I've taken the approach of having sprites that are slightly wider than they need to be meaning we can ignore left and right and a less general plot routine. This has given me the samurai and seven monsters on the screen at the same time at 50fps. There is more game logic to go and things like sound which may take time so this might need to reduce slightly but I'll look at that as we come to it.

Lastly I've also kicked out the OS to use most of the Beeb's memory. Here's a video (no collision detection in this one )

[lurkio]

Here's a video (no collision detection in this one )

Fantastic progress!



Here's a direct link for people like me, whose browsers no longer render the BBCode [flash] tag:

https://www.youtube.com/v/5fsY35JOVHs

[tricky]

Looks great and apart from the palette, not that beeb like.

[ChrisB]

A small update. I've fixed the remaining issues with the sprite plot routine so the corruption is gone. Also added in the sword "strike" animation and corrected the player movement when hitting blocks. I was concerned that the strike would take a large chunk of time and that might lead to stuttering but that doesn't seem to be the case. I have also shifted the level down half a line so the top and bottom lines are off the screen. This means I can reduce the screen size by two lines and I regain 1280 bytes! It also makes the aspect ratio a little wider which I like the look of.

This build doesn't act on the collision detection (although the detection is being performed) and includes more monsters on screen at once than I think will be final. This pushes the frame update time past the vsync some of the time but doesn't seem to adversely affect the gameplay.


Watch on Youtube

Next up is the next monster type and the level change logic.

[oss003]

Looking great but I don't understand how you can use the Read, Eor, Write principle without changing the sprite colours when it overlaps a colour on the background????

Or are you using decicated colours for fore- and background, eg colour 0-3 foreground and 4-7 background?

Greetings
Kees

[ChrisB]

You need to set the palette up the "right" way. For example - in Mode 2 you have 16 colours. Let's assume that the background will be either Red or Cyan. Define these as colour 0 and 1.

So - if we want our sprite to be black, yellow and blue (say) then define colours as follows:
2,3 - Black
4,5 - Yellow
6,7 - Blue
So if your sprite is Yellow - Colour 4 - then 4 EOR 0 = 0 and 4 EOR 1 = 5 both giving yellow. Plotting the same colour 4 again reverts back to the background.

You can do the same kind of thing with 4 background colours (0-4) but you need 4 copies of each colour of sprite that you want to use so you only get 3 sprite colours.

Lastly as Tricky says above if you know that you won't overlap sprites you can clear the previous data with an AND.

[lurkio]

A small update.

Absolutely stunning!

[fizgog]

Its looking better and better with each build

[ChrisB]

Another small update. No video this week.

I've added more "tiles" to make up the levels and add a bit of scenery. I've also added the level logic so there are multiple levels available and it is possible to complete one and move to the next with different parameters/colours for each level. I also have the logic (but no content) for a title screen to start/finish the game. Lastly it is now possible to fall off the bottom of the screen (some levels will have holes in the floor). Looking into fonts and experimenting with the second monster type movement.

[ChrisB]

Another update. I've changed the game's name to Night Ninja to provide some separation from the original.

New this week:

• A Title screen with some partially completed text.
• A new monster type. Spawning and movement are not quite finalised.
• An attract mode.

This is very much a placeholder screen layout with more tiles on it that are necessary.

https://www.youtube.com/watch?v=2uhTKcvEm0M

Next is the title screen logic to complete and then sound and levels to do. There may also be a third enemy - still looking at options.

[ChrisB]

This week I've complete the title screen logic so best times are recorded. Will probably look to do some more with it (Centred text - possibly in another colour) I've also updated the second enemy movement and created a couple of levels. As such I think it's time for an alpha release.

Collect the lanterns and get to the exit. One life to beat all the screens in the best time. No sound as yet and in the spirit of the original it's supposed to be hard. Opinions welcome. Post your best time!

Keys are:

• Z - Left
• X - Right
• Return - Jump. Tap for small jump hold for larger jump
• Space - Sword.
• Escape - Skip level

Skipping a level is intended to allow practice and stops the score counting.

NightNinjaR1.ssd

Night Ninja Alpha release 1

(9.25 KiB) Downloaded 58 times

Edit - Here's my time:

[Cybershark]

Wow. It starts so innocently, with you being able to scoop the first few lanterns pretty swiftly, and then it turns brutal in no time!
Very smooth and playable though. Am surprised I am the first and only one to comment

I think that - if I had one criticism - it'd be the keys. I didn't like the choice of space for jump, and thought shift would perhaps be a better choice.
Fabulous work so far

[lurkio]

I concur with everything Cybershark said, but I was too chicken to be the first one to say it..!

Brutal but brilliant!

Could the keys be user-definable?

Could the difficulty-level be adjustable?!

[ChrisB]

Definable keys - yes absolutely. I have this mostly working already (only shift and ctrl not usable at the moment - which I though would be popular keys). I'm also not sure I like space and have changed the default to shift.

Difficulty is a tricky one. You need to control the number of enemies on the screen or you'll be overrun. As such enemy spawn rate makes a big difference to how easy a screen is.

Have you played the original at the top of the thread? It's also unforgiving (I don't think I've ever finished it). It is short (only 3 screens) and as I see it designed as a pick up and play for a bit until you get frustrated/win. There are no more mechanics that are introduced after the second screen so there's limited scope for progression to keep it interesting.

If it's too easy you'll just blast through levels and there's no challenge, too hard and you'll just give up. Personally I think the instant restart gives it that "one more go" feeling and I find myself able to beat the first screen 50% of the time and the second screen only occasionally. There's defiantly some tweaking that needs to go on and once I have designed the remaining screens (probably looking at 4 screens in total) I'll look at screen order.

[fizgog]

Managed to find some time and download this to give it a blast.

First up, this is a very polished game, great work.

I thought the difficulty was just right, as you say you have to manage the enemies to play it.

Not sure I like the spacebar, but thumbs up for definable keys.

Second level on 4th attempt

Shaun