RPG IN 1-2-3 WITH bB

[MausBoy]

So you all know by now that bB makes programming for the 2600 fun and easy. Reading through the homebrew forums, it seems like a solid Ultima style rpg is one of the holy grails of homebrewing. Is anyone attempting this with bB? If not, why? That's one area where I can say for sure that bB would beat the hell out of using ASM. That is, assuming you are willing to have at least an 8k rom, 4k just won't cut it for much because of the huge data tables required for an rpg.

 

 

I've started messing around with ideas while I polish up my first effort, and I think this might be what I do for my second.

 

I've started with the "battle engine" now, when I first upload the game here it will just be a guy in front of a building, and which door he enters determines the level of the monters he will fight. I have room for 35 monster types, four doors. 10 of each first 3 levels, 5 final level monsters. The battle system itself is the old Dragon Warrior/Phantasy Star type, with options for Fight Magic & Run. Beating a certain type of level 1 monster so many times gives you Magic ability, and finding and beating a certain level2 monster gives you the ability to learn new spells from defeated monsters. There are HP MP, and the regular attributes like Strength, Agility, Luck, etc.

 

The fighting screen itself uses the multisprite kernel for hi-res backgrounds. The player sprites are stuck together to make a 16 x 12 drawing of each monster type, they are slightly animated and they can flash / change color when damaged or using magic. The rest is drawn with the playfield, including the menus, and options are chosen by moving the Ball sprite up and down menus and firing to select. I know this sounds about as fun as, well nothing. But it's just one part of the whole and I have to learn to do each one before I can stick them all together. Any comments?

Edited April 15, 2006 by MausBoy

[djmips]

I think it sounds great. Go for it, once you get the basic engine working, then all you need is to create content and don't forget to support the memstick!

[SeaGtGruff]

So you all know by now that bB makes programming for the 2600 fun and easy. Reading through the homebrew forums, it seems like a solid Ultima style rpg is one of the holy grails of homebrewing. Is anyone attempting this with bB? If not, why? That's one area where I can say for sure that bB would beat the hell out of using ASM. That is, assuming you are willing to have at least an 8k rom, 4k just won't cut it for much because of the huge data tables required for an rpg.

 

I think an Ultima-style RPG would be difficult with bB, unless you could develop a custom kernel that could handle the graphics display. (See Supercat's blog for a demo he wrote-- but not in bB-- which ought to work well with an Ultima-style game.)

 

However, you could much more easily create an Adventure-style RPG, a Raiders-style RPG, or even a Dragonstomper-style RPG.

 

Michael Rideout

[jjsonique]

MausBoy, that sounds great. I'm going to be tackling an RPG/Adventure-style game using bB as well. I'm not going to take on Ultima-like tiles and scrolling (as much as I love Ultima and lusted after the Homestar RPG), however -- movement in the world will be pretty quick and abstracted. I do hope to have a menu for a limited inventory, and the ability to buy/sell things, and a very simple turn-based combat engine (somewhat like Dragon Warrior's, but even simpler -- no statistics besides HP and current armor, and no magic (just item use instead) ). It will have two members in the party, however, who can each use different weapons, items each round of combat for some tactical options. I've laid out on paper how the screens could work within the limits of the current multisprite kernel, and now that I got that kernel working for me, I'll be making some test screens.

 

In short, I'll try to make something that would be pretty complex for a 2600 game, but very simple in terms of RPGs. I agree that anything approaching RPG-ness would need bankswitching to work, so I hope Batari's planned merge of multisprite with bankswitching will not prove too difficult.

[s0c7]

jjsonique, I wish you luck! That screenshot you posted way back when looked promising.

 

I think a primitive RPG (super-primitive by 8-bit standards) is probably possible using the current build. Might require the extensive use of flicker (even in the new kernel).

 

I'm still experimenting with flicker. Here's a small no-frills demo I did. RPS Fighter. Fight a RPS battle with Chunky-Li in the Red Temple. First one to win 3 wins.

[MausBoy]

I thought I could pull off the overhead map part with pfpixels and scrolling, but I found out that the multisprite kernel dosn't support those things yet so I've put off everything but my battle system for now. IMO there is no good way to do something like dragon warrior with the multisprite kernel, without playfield commands. With the smallest pfheight argument it would be possile to use variables and data tables to create quite a few different tiles and sprites, it's a shame we can't use the good playfield commands with it yet. I was planning on using playfield pixels for the menus too so it's really hard to work out how to do that when the playfield is mirrored. I hope your project goes well and you post source, a different pov on how to do some of this stuff would help a lot.

 

MausBoy, that sounds great. I'm going to be tackling an RPG/Adventure-style game using bB as well. I'm not going to take on Ultima-like tiles and scrolling (as much as I love Ultima and lusted after the Homestar RPG), however -- movement in the world will be pretty quick and abstracted. I do hope to have a menu for a limited inventory, and the ability to buy/sell things, and a very simple turn-based combat engine (somewhat like Dragon Warrior's, but even simpler -- no statistics besides HP and current armor, and no magic (just item use instead) ). It will have two members in the party, however, who can each use different weapons, items each round of combat for some tactical options. I've laid out on paper how the screens could work within the limits of the current multisprite kernel, and now that I got that kernel working for me, I'll be making some test screens.

 

In short, I'll try to make something that would be pretty complex for a 2600 game, but very simple in terms of RPGs. I agree that anything approaching RPG-ness would need bankswitching to work, so I hope Batari's planned merge of multisprite with bankswitching will not prove too difficult.