RONIN... A Samurai Homebrew Game (8/22 update and WIP bin)

[LatchKeyKid]

Well, it's final time to start on my New Year's Resolution for 2024 and program my first bB from scratch.   I joined the forum a little over two years ago and came out with my first (and only!) hack over the course of that first year thanks to the excellent line by line annotation in the Pitfall disassembly and the help of others here on the forum as I stumbled my way through it.   I've mainly been following the progress of others since then trying to pick up various bits of knowledge and doing the equivalent of preproduction (concept design, layout, sprites, etc) but without ever taking that next big step into actual programming until now. 

 

The first three video games I remember playing as a kid (outside of the arcade) are checkers, The Oregon Trail, and Kareteka on the Apple II for the one hour of computer class at school and another hour once a month on a Saturday on the local library's computer.  I was surprised to see that Karateka had never had a port to the system and decided that a game inspired equally by that game and old Samurai movies would be my goal in my first homebrew attempt using Batari Basic.  I wasn't sure if I was going to do a game like Double Dragon where you could go up and down on a limited set of Y coordinates or just have everything on a single line (excluding jumps) like with Kung Fu Master.   I couldn't really think of a controller scheme compatible with the single button cx40 where you could travel up and down the screeen on the Y axis without resorting to mutidirection/button combos to accomplish actions like jumping as I'm not generally a fan of those on the 2600.   As a bit of a compromise, I decided that the player would be limited generally to just a single plane (except for jumping) but that enemies could move and potentially attack from others.  

 

Next up, I created a simple pair of mockup sprites which I then cut and pasted them into a crude MSPaint image to just get a general working concept.   I then went to work on the rest of the multicolor sprites for various actions I thought I might need like low/high attack and block, jump, crouch, and a static "hero" pose expecting to use the ball as the sword.   Karateka has alot of empty space on the top of the screen so I decided to incorporate that asthetic as well both for a more letterbox asthetic style as as to shrink the size of the rows since I'd be using the blank lines option on the bB basic kernel as I need at least one missile.   I did a quick mockup of various aspect ratios to just visualize what they might look like; admittedly, this would never be entirely accurate given that I have no original hardware nor any way of currently playing ROMs on my old 4:3 CRTs either but it might give me a starting point.  I was drawn to the look of 2.35:1 the most and did some a further test with MSPaint to see how the potential chunky playfield blocks might work on that ratio.   While I like the look, it felt potentially too limiting as I'd have difficulty incorporating the enemy movement/attacks on different heights and also because I had no clue if it would look too narrow on actual 4:3 CRTs so I decided instead to shoot for a 16:9 look on a 4:3 screen similar to watching widescreen DVDs in the 90s on a CRT.

 

 

 

 

 

Edited August 23 by LatchKeyKid

[8bitPoet]

Great to see you're starting on your first bB game!

 

Karateka was one of my favorite games to play on the Apple II and later on my Commodore 64.

 

There are quite a few limitations to consider when using the standard kernel in bB. Essentially, you have 32 columns and 11 rows to work with.

You can use pfcolors as a kernel option to use different colors per row.

 

Here's a few screenshots from the actual game with some translated mockups that could be achievable with the standard kernel in bB:

( If you won't be using missile0, you could also include the no_blank_lines kernel to remove the horizontal gaps between rows)

 

Overcoming the limitations of the Atari 2600 and batari Basic to create an enjoyable game is what makes this a fun challenge.

[LatchKeyKid]

Thanks, and while this might sound silly, I got a big kick out of seeing that you ported over my test sprites over as well!   I haven't figured out a way to add the mountain or a setting sun in a way that I'd like since I'm using custom PF heights so I won't be able to use those unfortunately but I appreciate the ideas.  As for the doors/pillars, I'll probably have to use a quad or 8x width sprite for those since my custom color and height playfield pattern won't be an option.

 

In preparation for potentially making a game of some sort (though at the time I was still deciding which one of my game ideas I would attempt to tackle first), I started up a dedicated thread to asking questions about bB in the hopes of getting a more accurate understanding of the software limitations that I'd be working with using the basic kernel as compared with what others accomplish with ASM.   That's not a dig at bB in general or the kernel specifically as it's obviously an incredibly helpful set of tools that, in experienced hands, can make very impressive games as evidenced by the Princess Rescue and Knight Guy games.    Over the months I cleared up various misconceptions about the kernel and I adjusted my potential plans accordingly.  Most affected were my planned character sprites as, even in the earliest versions after my simple test sprite, I modified the ball line by line (and missile for enemies) for the weapons to both add a different color to the player character as well as go beyond the usual 8 sprite width bounds for both players and enemies without losing detail.  Unfortuantely, that isn't possible with the basic kernel so I had to redesign things to conform to this limitation that I wasn't aware of.    Additionally, I was hoping that I'd be able to use different sprite data on multiple lines (for example using player sprites also for the background terrain and sun) but multisprites are the strict domain of another kernel that I won't be able to combo with; initially I had hoped that you could complile some levels/banks with one kernel and others with another but that isn't possible.   I toyed with the idea of making a full screen mega sprite for the player character and just having him be on a static position on the x-axis (like the player in Kung Fu Master) but the inability to toggle player width in the kernel mid line made that unfeasible as well since the terrain would have required doubled/tripled or quad/octo-width sprites.

 

Regarding the UI, I decided to go with the PF score bar option to get two different life/damage counters without having to use a separate minikernel.   I'm not sure if this option adds any CPU cycles like the other score minikernels do but it was relatively simple for me to set up.   I wasn't planning on actually keeping track of a score but I'm not entirely sure I can turn it off.  I'll have to ask this week in my noob questions thread if I can redefine the score sprites to instead maybe indicate powerups/items instead of numbers using Visual Studio.  I assume they're stored as sprite data somewhere in a compiler file but that's just a guess on my part.  Finally, I'm leaning toward a different method of tracking health than on this game with possibly lives on one side and a health bar on the other as opposed to player health on the left/enemy health on the right but that's not set in stone yet at this early state.  I just don't expect to have each enemy be a full on mini-boss itself like in Karateka with it's own health bar though I'm not sure about what method, if any, I'd use to visually track that for the player on screen. 

 

So, earlier this week, I finally put pixels on the screen and came up with the first posted screen pic below!   At the time, the player sprite was basically just free-floating and the shapes/dimension/colors are obviously still in flux but I had something actually in game/engine as opposed to my crude MSpaint mashup.    Since then, I've added some simple bounding to the player character to see how it looks when he moves around the screen as well as added test code for an enemy sprite with its different limitations.   I've also tweaked the dimensions to better reach that widescreen look I was initially going for as well but I'm not sure if I'll keep it exactly as shown; technically the play area is centered on the emulator screen but the score bar below makes it look a bit lower so I may tweak that further.  The bars on the left are just there as visual cues to the size of those custom playfield row heights as well as to let me know the color I've assigned there temporarily since I'll be using them on some of the other levels/locales unlike with this first outdoor level.  None of this code is final as it's just the simplest way for me to get some control over the sprites for further testing/tweaking and I expect that I'll have subroutines for each major action like jumping, blocking, and attacking for the player as well as (?) separate subroutines for whichever enemy type is onscreen as I hope to have different actions for them individually.

 

 

Edited May 19 by LatchKeyKid

[+Karl G]

2 hours ago, LatchKeyKid said:

Regarding the UI, I decided to go with the PF score bar option to get two different life/damage counters without having to use a separate minikernel.   I'm not sure if this option adds any CPU cycles like the other score minikernels do but it was relatively simple for me to set up. 

Regarding CPU cycles used, it is a matter of how much vertical screen space you use below the main screen. The more you use, the less you have in overscan following the drawing of the screen/score/minikernel to run your own code before the next frame. In your case, using pfscore bars with the score would take up about the same number of extra CPU cycles as using the lives or lives/status minikernels with the score disabled. If you were to use *both* the score and the a minikernel, then that would more severly cut into your remaining cycles.

[LatchKeyKid]

58 minutes ago, Karl G said:

Regarding CPU cycles used, it is a matter of how much vertical screen space you use below the main screen. The more you use, the less you have in overscan following the drawing of the screen/score/minikernel to run your own code before the next frame. In your case, using pfscore bars with the score would take up about the same number of extra CPU cycles as using the lives or lives/status minikernels with the score disabled. If you were to use *both* the score and the a minikernel, then that would more severly cut into your remaining cycles.

 

Thanks and I'll try that tonight then.  I vainly hoped that it would use less with the standard pfscore bars but I'll take solace in that my shrinking of the playspace for asthetics has inadvertently freed up some CPU cycles to help make up for it potentially.

 

Do you know if there is a way to redefine the sprites used as numbers in the score with pfscore bars?   I'm using Visual Studio with the Atari plugin in case that matters.   I assume the sprites are stored somewhere and I'd prefer to either use the score as a progress bar for the level ala Moon Patrol instead of using the numerical high score and redefining the sprites seems like the easiest way to go about that.

Edited May 19 by LatchKeyKid

[+Karl G]

35 minutes ago, LatchKeyKid said:

Do you know if there is a way to redefine the sprites used as numbers in the score with pfscore bars?   I'm using Visual Studio with the Atari plugin in case that matters.   I assume the sprites are stored somewhere and I'd prefer to either use the score as a progress bar for the level ala Moon Patrol instead of using the numerical high score and redefining the sprites seems like the easiest way to go about that.

Fortunately, that part is pretty easy. Copy the file score_graphics.asm from your bB includes directory to your game directory. That way when you compile, bB will use your local copy instead of the system copy. Edit your copy of this file, and redefine the digits in the same way as you would define player sprites that are 8 lines tall (with the graphics being upside-down like bB player sprites).

[LatchKeyKid]

5 hours ago, Karl G said:

Fortunately, that part is pretty easy. Copy the file score_graphics.asm from your bB includes directory to your game directory. That way when you compile, bB will use your local copy instead of the system copy. Edit your copy of this file, and redefine the digits in the same way as you would define player sprites that are 8 lines tall (with the graphics being upside-down like bB player sprites).

 

Thaks again and I'll try that tonight.  Looking through Random Terrain's site and this page:

 

https://github.com/chunkypixel/atari-dev-studio/tree/master/out/bin/compilers/bB/includes

 

I might not even have to change the default numbers but rather just a font that I'll likely never use!

[LatchKeyKid]

Thanks to @Karl G's tips I was able to tweak the pfscore bar to my liking by changing the number sprites in one of the alternative language fonts that I don't expect to use (handwritten in my case!).   Basically, I turned the numbers 0-9 into the an Activision style display title for the game as well as an admittedly coarse five step level progress bar.   I wasn't really planning on using the high score function so being able to use that for two different things that I did want is a definite plus especially considering I didn't have to really increase the size of the game but rather repurpose what was already going to be in the ROM by default.    Alternatively, I did try the 6lives_statusbar minikernel option but it took up around 220 bytes more right off the top so I decided to go with the original pfscore bar instead given that I had already tweaked it to 90% of what I wanted.   I have no idea what the final size of the game will be (nor am I specifically shooting for fitting within 4k even since I have no clue what to expect honestly) but I didn't want to shave off 10% of my remaining free bytes from that first 4k when the existing option was working out better than expected.

 

The one thing I wasn't able to accomplish with pfscore bars was to do the two sided health bar colors like in Karateka (with one for the enemy and one for the player) by manually setting the colors after the main play area in the score section and turning the playfield to split player colors.  I'm guessing that code is buried in another of the asm files as I didn't find one named pfscore that I could play around with.  

 

So, here is the weekend's progress (admittedly mainly asthetic/visual) on the newly christened (but still not necessarily final) RONIN homebrew samurai game.      The area previously used by the score now alternately displays the name of the game and the progress through the level.   It's just a placeholder mockup now and not tied to any real gameplay but I'll be working on that next.

 

 

Edited May 20 by LatchKeyKid

[LatchKeyKid]

I realize I was rapid fire posting updates during that first week but I finally got down to the first steps in making an actual game as opposed to a proof of concept over the past week.   I started out by adding in various (mainly visual only so far) functions for the player character like animated movement, attacks, blocking, and jumping which I mostly expect to be it for active actions the player will be able to do given the one button joystick/CX-40 style limitation I've decided to stick with as I want the game to hopefully be playable on original hardware.  Since i was adding those in rather piecemeal, the system generally ended up working as a whole but the individual parts were quite messy once I was done adding them in.   Since it was an extended holiday weekend here in the US, I decided to try and reorganize the code into more of a system of subroutines and variables without breaking anything in the process and it looks like it worked.  

 

I hope this week to add in a falling mechanic next so I can have pit obstacles in the game to jump over in addition to enemies and their missiles but I'll have to research how to do that first as I'm not sure yet.   I'm guessing that I'll have to check to see if there is a pfpixel using the bB function underneath the player character but I don't know if there is a standard way of doing that in 8-bit games (do you only fall off if NONE of your character sprites are over the platform/playfield?  Or if you're balanced by one pixel do you tip over and fall?).    Additionally, I had to tone back the previous "letterbox" format of the play area as I was getting some instability/jittering that Karl G let me know was likely due to the decreased playfield size.  I may revisit that when everything is said and down and try to trim a little off the top and/or bottom but that bridge is very, very far away at the moment.

 

Regardless, here is just a working demo of the character animations that I've done so far including movment (left/right), blocking (down), jumping (up), and sword attack (fire button both on the ground and in the air).   I'd also appreciate if anyone who checks it out lets me know how the movement feels as I slowed it down a bit to not have the character skating across the whole screen in just under two seconds.   I tried to give some fluid animations to the sword attacks within the limitations of the standard kernel where you're not able to modify a ball or missile from line to line but rather only from frame to frame.   The score area is replaced with the games logo (which I expect will only be shown at the start of the game) which turns into a custom level progression indicator; right now the entire "level" is just the single screen to show the coarse steps I've managed to make work hacking the scoreboard font.  Thanks again for looking and let me know what you think!

 

 

RONIN v0.1.bin

[alfredtdk]

Great start. It gives the sensation of feeling gravity pulling the character down when they jump. You're doing great on your first homebrew. I look forward to the progress of this title. In fact, I'm a fan of games in this style, involving samurai and Japanese culture. In fact, my favorite title involving samurai and Kenseinden, from the Master System.

[+wongojack]

following

[+Living Room Arcade]

It's beautiful!  And this type of fighting game is so badly needed in our Atari 2600 game library. 

Thank you for doing this, @LatchKeyKid!  

Edited May 28 by Living Room Arcade

[LatchKeyKid]

10 hours ago, alfredtdk said:

Great start. It gives the sensation of feeling gravity pulling the character down when they jump. You're doing great on your first homebrew. I look forward to the progress of this title. In fact, I'm a fan of games in this style, involving samurai and Japanese culture. In fact, my favorite title involving samurai and Kenseinden, from the Master System.

 

Thanks!   I had initially hoped to use a data table for it but for now it's just a +1 up and down per frame with a pause at the top and bottom for simplicity as I was 80% happy with that and didn't want to break it by trying in the beginning for that final 20%.

 

5 hours ago, Living Room Arcade said:

It's beautiful!  And this type of fighting game is so badly needed in our Atari 2600 game library. 

 

Thank you for doing this, @LatchKeyKid!  

 

Thanks and I agree that the genre is a bit sparse.   The only homebrew that I can recall seeing in the space is the relatively recent Razor's Edge and Alfred's Double Dragon hacks.

[8bitPoet]

Lookin' good! The sprites are nicely detailed and I really like the clever repurposing of the score element.

[LatchKeyKid]

8 hours ago, 8bitPoet said:

Lookin' good! The sprites are nicely detailed and I really like the clever repurposing of the score element.

 

Thanks!  I was really happy that the score mod worked out as I didn't have any plan to incorporate a score but didn't want to waste the space (either on the screen or in the ROM) just by making it black to match the background.  The PF score bar is a great option and I expect to use it in the future as its very versatile and easy to use (no minikernel required).  I actually tried a minikernel but it took up 200 more bytes for only a little bit more utility.

[+ZeroPage Homebrew]

Looking forward to giving Ronin a quick look today during the news section on ZPH!

 

- James

[LatchKeyKid]

On 5/31/2024 at 2:07 PM, ZeroPage Homebrew said:

Looking forward to giving Ronin a quick look today during the news section on ZPH!

 

- James

 

Thanks for the spotlight and I appreciate the feedback from both you and the chat.  Leave it up to the Canadians to point out that my movement looks like ice skating! 

 

In all seriousness, it's a valid criticism and one that I agree with now that I watched it on a bigger screen than my potato laptop.  I'll have to incorporate video output via HDMI to my TV with each major build to double check how it looks on something bigger as I've discovered that you can obsess over minor things no one will notice yet miss something that others instantly will.   I tried a couple different methods of changing his walking style with some that had humorous and unintended consequences.   My first attempt had me try a +1 scanline bump on the alternate walking pose but I made a coding mistake and instead he floated up and away like Mary Poppins!   Another had me alternately raise a leg in each pose but that had the unintended consequence of making him look like he was riding a stick pony! 

 

 

 

Ultimately, I decided on a less drastic leg pose where he raises a foot a bit in the alternate pose, changed the frequency of the gait making the foot/leg movement look faster, and instituted a bit of a ratchet for added shifting in the walk so he doesn't look like he's smooth gliding.  I'm not entirely sure about that last part as it could be confused with a glitch so I'll include both versions here and would appreciate if folks test out the movement to see which one is better (with the slight "ratchet" or without).   Additionally, I added some test coding for falling (to your death!) so I can use chasms and secret pit traps as terrain obstacles in game. 

 

 

RONIN v0.11 walk test 1.bin RONIN v0.12 walk test 2.bin

Edited June 2 by LatchKeyKid

[7800Knight]

That does look pretty cool!  Though when you mentioned "Samurai", I thought of the arcade game Samurai Nihonichi.

 

 

 

Anyway, keep up the good work!

[LatchKeyKid]

On 6/2/2024 at 12:52 PM, 7800Knight said:

That does look pretty cool!  Though when you mentioned "Samurai", I thought of the arcade game Samurai Nihonichi.

 

Anyway, keep up the good work!

 

Thanks!  No relation to that game but I will not rule out the possibility of adding tigers now that I watched that video. 

[KainXavier]

I checked out both builds, and I definitely prefer the walk animation in the first one, RONIN v0.11 walk test 1.bin.  The way the samurai's hakama flares back and forth is perfect in my mind.  Also, I just wanted to drop in and say that I really like what you're doing with RONIN so far.  I meant to say that back when ZPH featured a preview of your game.  I hope you'll continue to work on it!

[LatchKeyKid]

10 hours ago, KainXavier said:

I checked out both builds, and I definitely prefer the walk animation in the first one, RONIN v0.11 walk test 1.bin.  The way the samurai's hakama flares back and forth is perfect in my mind.  Also, I just wanted to drop in and say that I really like what you're doing with RONIN so far.  I meant to say that back when ZPH featured a preview of your game.  I hope you'll continue to work on it!

 

Thanks for the feedback and encouragement!  I'm definitely still working on it but admittedly the pace has slowed a bit since the initial rush but it is still ongoing as I learn new aspects that I need in coding it.

[LatchKeyKid]

After a couple summer months off from the project, I decided to return back to work on it yesterday and did some minor tweaks to the animation and sprite work (very minor and definitely not worth a new .bin upload!).    After working on my Sky Centurion! game to try and figure out how to load screens/playfields, I'm wondering whether it'll be better to do single screen advancement ala Pitfall (where you just get to the right of the screen to go to the next one) or whether it'll be better to do continuous playfield side scrolling instead.   I'm not actually at all familiar with how to do that so would have to learn but I'm leaning toward it as I'm not sure the traditional screen has enough room on the X axis for what I'd like to do with PF0 missing by default with the basic bB kernel.   Ideas?

[+Living Room Arcade]

Glad to see you are back on this project again.  Looking forward to seeing your updates.  

[LatchKeyKid]

Thanks for the feedback and encouragement, LRA!    I was able to get the initial scrolling working with a single playfield for now.   I do plan on having multiple playfields once I figure out how to latch them together as currently I'm not sure how (hence why it's repeating one screen for now).   At a bare minimum if I don't figure that coding out then I'll at least have one easily noticeablely different playfield per level of the game.   I had to take out the pit trap opening when you approach for now as I wasn't sure how to recode it for scrolling versus just normally walking across the level.   For those interested in checking it out, let me know how fluid or not the movement feels now with scrolling.  The playfield scrolls every 4th frame since the playfield pixel is four times that of the player pixel size and I figured that was a good speed given that Princess Rescue does something similar and feels good.  If you're just flat out running through the level it feels too fast but obviously in game there would be enemies causing you to stop and attack/jump/block to break up that speed of movement.  

 

As always, feedback is appreciated.   Is the scrolling better more fluid than the single screen floaty/skating movement that was noted before?

 

RONIN 082224 scroll test.bas.bin

Edited August 23 by LatchKeyKid

[+Living Room Arcade]

My pleasure, LKK.  Oooo, this is VERY good.  Silky smooth.  I love it!!  👍