Atari Roguelikes

[jrok]

 

It would probably be more proper to call it the "display kernel" rather than just the "kernel," because the "kernel" would really include the code you write, too, and not just the code that gets performed when you use the "drawscreen" command.

 

Yes, great point. It's easier in some ways to think of the display kernel as something that is accessed and modified by the Basic script, but it's all "the kernel."

 

And above, I meant to say "I think that a lot of folks understate what can be done with the language." I mean, I think that if you approach it as you would any other Basic-type language, it can offer lots of opportunities to make some really neat stuff. But I guess as with any other dev environment, having some prior programming experience (professional or otherwise) probably helps.

[SeaGtGruff]

And above, I meant to say "I think that a lot of folks understate what can be done with the language." I mean, I think that if you approach it as you would any other Basic-type language, it can offer lots of opportunities to make some really neat stuff. But I guess as with any other dev environment, having some prior programming experience (professional or otherwise) probably helps.

I think most people think of the "canned kernels" as being an integral part of batari Basic, such that they define (i.e., determine, and thus limit) what batari Basic is capable of. But the language itself doesn't require the use of the "canned kernels"-- one can write a custom kernel using inline assembly or custom include files. The language itself is simply the set of all the batari Basic keywords which are used to construct batari Basic statements, which the compiler converts into assembly code so it can be assembled with DASM. It's even possible to write a display kernel using batari Basic statements rather than assembly instructions (as I've shown in one or two examples, although they were just simple "color palette" displays rather than game kernels per se), but the drawback to using batari Basic statements to create a custom display kernel is that you can't always get the precise timing and tight coding-- or, for that matter, all of the address modes-- that are possible when using pure assembly code.

 

You don't even need to use the default RAM locations that are defined in batari Basic's header files-- you can create a custom includes file that tells the compiler to use your own set of custom include files (headers, display kernel, etc.), without using any of the "canned" include files provided with batari Basic. You can totally customize the RAM usage, playfield display code, sprite display code, etc. As long as you use batari Basic statements and compile your code with the batari Basic compiler, it's still a batari Basic program, even if all of the header and include files are custom-written, and even if large sections of the "main program file" are in inline assembly code.

 

Michael

[SeaGtGruff]

at this point, i just don't see a way within bB to be able to generate an inventory. it's like everything is going to have to be activated the instant you pick it up.

Using just one of the "canned kernels," you could program the inventory display as a separate screen from the map display, using the players to draw the inventory items. The simplest way to do it would be to position player0 and player1 side-by-side in the center of the screen (but not necessarily right next to each other-- they would look better separated), such that each player is a column running up and down the screen. Then you can define each player as a "stack" or column of items. In other words, you might have 16 objects on the screen at once, arranged in 2 columns, 8 items per column. You might even have several screens for the inventory-- one screen for the weapons, one screen for the armor, one screen for magic potions or wands, etc. I've never played "Rogue," but I've played "ADOM," and that's how the inventory is listed-- items are grouped together according to type-- so you could draw the inventory as a series of screens in the same manner. You could use the GAME SELECT console switch to call up the inventory and paginate through the different inventory screens, and use the joystick to select the items you want to use, with either the missiles, ball, or playfield pixels being used as cursors to highlight the items which are equipped.

 

As for the map screen, you could use the score (with custom score graphics) to show stats, or maybe to show the equipped items.

 

Michael

[jrok]

at this point, i just don't see a way within bB to be able to generate an inventory. it's like everything is going to have to be activated the instant you pick it up.

Using just one of the "canned kernels," you could program the inventory display as a separate screen from the map display, using the players to draw the inventory items. The simplest way to do it would be to position player0 and player1 side-by-side in the center of the screen (but not necessarily right next to each other-- they would look better separated), such that each player is a column running up and down the screen. Then you can define each player as a "stack" or column of items. In other words, you might have 16 objects on the screen at once, arranged in 2 columns, 8 items per column. You might even have several screens for the inventory-- one screen for the weapons, one screen for the armor, one screen for magic potions or wands, etc. I've never played "Rogue," but I've played "ADOM," and that's how the inventory is listed-- items are grouped together according to type-- so you could draw the inventory as a series of screens in the same manner. You could use the GAME SELECT console switch to call up the inventory and paginate through the different inventory screens, and use the joystick to select the items you want to use, with either the missiles, ball, or playfield pixels being used as cursors to highlight the items which are equipped.

 

As for the map screen, you could use the score (with custom score graphics) to show stats, or maybe to show the equipped items.

 

Michael

 

 

That's sort of what I was thinking, too. No need to include the inventory on the same screen in a turn-based game.

 

Also, probably no need to waste color clocks on "walls." You can use negative space to define rooms and hallways (rooms/hallways are black, everything outside is color) and thereby save eight px on each room both vertically and horizontally (at least, in the example PACMAN RED provided; depending on the screen res, it could be even more than that). It may not sound like much, but when you are fighting for every pixel, it adds up! It might make more visual sense, anyway, to have the movable areas all the same color. Also, I think 4px players would be fine, in order to maximize the movement grid. You can make a lot of letters/symbols in 4px, which is all a roguelike seems to require.

 

I think the project is very doable, and that a keyboard probably isn't necessary to get the flavor of play.

Edited August 18, 2011 by jrok

[DemonoidTentacle]

I've recently started with visual bB, and I'm reading ALOT of tutorials. Seems to be a good place to start.

 

Any good tutorials you've found?

 

I've been checking out a few tutorials at www.bataribasic.com , and the Sessions by Andrew Davie have been a great insight into programming in general.

[jrok]

Another way to approach the game as a single screen might be to go with 2-6px tiles, and use two-wide game objects instead of four. From the looks of it, the Rogue display is 64 characters wide, so each of bB's 32 4-wide pixels would represent two horizontal positions. With that setup, we could get the full map on screen, and have plenty of vertical space left at the bottom for stats, reporting and inventory:

 

 

Here's a ROM with basic 2x6 grid movement.

 

Rogue_sample.bas.bin

[+SpiceWare]

within bB i don't see where you can code key pad controllers.

Check out keypads and batari basic for routines to read them.

 

Has anyone seen a completed project in bB that wasn't just a simple shooter?

Gingerbread Man

 

4 of the 5 games Stella's Stocking.

 

Cave-In

[RevEng]

Has anyone seen a completed project in bB that wasn't just a simple shooter?

21 Blue!

 

As long as you use batari Basic statements and compile your code with the batari Basic compiler, it's still a batari Basic program, even if all of the header and include files are custom-written, and even if large sections of the "main program file" are in inline assembly code.

Well said. I totally agree.

[DJT]

Another way to approach the game as a single screen might be to go with 2-6px tiles, and use two-wide game objects instead of four. From the looks of it, the Rogue display is 64 characters wide, so each of bB's 32 4-wide pixels would represent two horizontal positions. With that setup, we could get the full map on screen, and have plenty of vertical space left at the bottom for stats, reporting and inventory:

 

 

Here's a ROM with basic 2x6 grid movement.

 

Rogue_sample.bas.bin

 

OMG that looks awesome!!!

[PAC-MAN-RED]

Also, I think 4px players would be fine, in order to maximize the movement grid. You can make a lot of letters/symbols in 4px, which is all a roguelike seems to require.

 

Agreed, and I believe they would look something like this:

 

 

I used the Rogue Manual to help put these together.

 

Illya

[+Gemintronic]

I like jroks roguelike test binary - but as a map view. Personally, I think an adventure style room layout would do. Maybe less box-ish by making tunnels and more cave-like areas.

 

Also, you might be able to use the multi-sprite kernel and tell the monster AI to move to separate rows whenever possible (without ruining pathfinding).

 

You can do alot even without multi-sprite. Use the ball as the player so two objects (sprites) can be in one screen. If an item is supposed to be in that screen then simply make it a drop when the monster dies.

 

Heck, you could go crazy and represent monsters as missiles. When you enter combat mode you can waste a sprite on the active monster.

Edited August 19, 2011 by theloon

[Asaki]

I second the idea of having a map screen, I don't find it necessary to be able to see the entire map at once.

 

With Pac-Man-Red's assistance, we might even consider giving it a proper console look; a close-up view with graphical sprites instead of font characters.

 

Usually I feel like doing the whole "keyboard emulation" thing instead of menus makes for a "faithfulness over practicality" situation when it comes to Rogue ports, but for the limits of the 2600, this might be necessary (to an extent).

[+grafixbmp]

Another way to approach the game as a single screen might be to go with 2-6px tiles, and use two-wide game objects instead of four. From the looks of it, the Rogue display is 64 characters wide, so each of bB's 32 4-wide pixels would represent two horizontal positions. With that setup, we could get the full map on screen, and have plenty of vertical space left at the bottom for stats, reporting and inventory:

 

 

Here's a ROM with basic 2x6 grid movement.

 

Rogue_sample.bas.bin

 

This demo reminds me more of gateway to apshai... Which I would love to see on the 2600!

[yllawwally]

The screen was 72 squares wide, leaving originally a 4 character margin on each side. The only thing about not changing the color for walls, was the doorway was inside the wall. If the door was closed a plus was there. I would say the genesis controller would work great for this game. One button for shooting arrow/zap. And the other for bringing up the menu, or the game select button on the console. If none of the rooms are lit, the most there would be is 9 creatures on the screen at once. 3 on each line, for 3 lines in a row. If scrolling is used, and the sprites left at 8x8 the graphics don't have to stay characters. We could draw up lots of nice looking monsters.

[jrok]

I second the idea of having a map screen, I don't find it necessary to be able to see the entire map at once.

 

Well, the topic was "roguelikes" so I figured we were going for a "Rogue" feel. Hence, trying to get all the play data on one screen.

 

we might even consider giving it a proper console look; a close-up view with graphical sprites instead of font characters.

 

If the object is to go full-on dungeon crawler with multi-party characters and such, yeah I agree. A fullscreen tactical view of each room (perhaps with an automap on a secondary screen) would be the way to go.

 

If I were apporaching the project, I think one of my big goals would be to get as much unrestricted loot and enemies in each room using minimal flicker.

 

I've thought about this a bit and mocked up a ROM with sample movement. In the attached binary, you alternately control a Warrior and a Wizard. When one is active, you will see a "Move Meter" at the bottom of the screen that gradually fills up as you make moves.

 

 

Once the Warrior's meter is filled, it's location is marked by a playfield brick, and it becomes the Wizard's turn (and vice-versa).

 

 

For expanding it to a game, I'm thinking that the GRP0 would always display the active player character (or active enemy character, during their own turns), with everything else represented by GRP1 or a pf brick. The flickering square in the top left corner could function as a cursor for spells, ranged attacks and other target-area actions. The bottom areas where the movement meter and the score are positioned could variably show different kinds of relevant game information (for instance, the score could probably function as an inventory that changes to show what the active character is carrying.)

 

DungeonRaiders.bas.bin

Edited August 19, 2011 by jrok

[jrok]

Actually, this version is a little better example of what I was trying to show. Basically, the top 80% of the screen would be reserved for the tactical room display, with the bottom twenty showing things like inventory, current weapon, armor, hit points, etc. In this version, I swapped the movement counter from M1 to the bottom rung playfield row (the bar shortens by one pixel with each move).

 

 

 

 

I guess this stuff isn't very roguelike, though. More like an old RPG-style game.

Edited August 20, 2011 by jrok

[jrok]

*Double-post, sorry*

Edited August 20, 2011 by jrok

[jrok]

Actually, this version is a little better example of what I was trying to show. Basically, the top 80% of the screen would be reserved for the tactical room display, with the bottom twenty showing things like inventory, current weapon, armor, hit points, etc. In this version, I swapped the movement counter from M1 to the bottom rung playfield row (the bar shortens by one pixel with each move).

 

 

 

DungeonRaiders_rev.bas.bin

 

I guess this stuff isn't very roguelike, though. This would play more like an old RPG game.

Edited August 20, 2011 by jrok

[DemonoidTentacle]

Another way to approach the game as a single screen might be to go with 2-6px tiles, and use two-wide game objects instead of four. From the looks of it, the Rogue display is 64 characters wide, so each of bB's 32 4-wide pixels would represent two horizontal positions. With that setup, we could get the full map on screen, and have plenty of vertical space left at the bottom for stats, reporting and inventory:

 

 

Here's a ROM with basic 2x6 grid movement.

 

Rogue_sample.bas.bin

 

OMG that looks awesome!!!

 

Agreed!

[PAC-MAN-RED]

 

I guess this stuff isn't very roguelike, though. This would play more like an old RPG game.

 

 

No wait, it's perfect! Everyone likes Rogue, so we'll release this new graphic intense version of it and call it New Rogue. And after awhile when people start seeing that's not the same, we will re-release the original Rogue and call it Rogue Classic. :D

 

Illya

[DJT]

Call it whatever! To see a dungeon crawling game with randomized game mechanics to make an almost endless replay, THAT would be fun!

[DemonoidTentacle]

If the game were to play with infinite random dungeons, I'd need a score count to keep me happy.

[Asaki]

Well, the topic was "roguelikes" so I figured we were going for a "Rogue" feel. Hence, trying to get all the play data on one screen.

 

Both the official ports for the Macintosh (B&W) and the Atari ST show only a portion of the map at once:

 

 

I forgot to mention before, regarding the menu/keys/controls, I've always thought that Sega handled it very well with these two games:

 

http://en.wikipedia.org/wiki/Fatal_Labyrinth

http://en.wikipedia.org/wiki/Dragon_Crystal

 

 

I don't know how feasible it would be on the 2600, though.

[Robot2600]

I came into this topic thinking a Roguelike would be impossible. You guys have obviously proved that theory wrong.

 

Anyway, one of the most annoying things about Roguelikes is the amount of button pushes most of them take (although my favorite, DC:SS fixes this with auto explore) to traverse the screen. 80 keystrokes to move across the screen? Tedious and painful even.

 

My suggestion is that the little dude moves around more like the SQUARE from Adventure, or if he's still moving on a grid that you can simply hold the direction you want to move in, like 8-Bit Dragon Quest or Final Fantasy.

 

And as cool as the other prototype looks I think something like this is more of a roguelike:

 

The idea being that the lack of graphics is actually a benefit because it allows for a bigger space to move around in and it allows one's imagination complete control over how everything looks.

 

 

I've actually got a pretty balanced, bare-bones roguelike combat system (feel free to use, anyone):

 

Here's how I envision it:

 

--You have 2 forms of attack, Melee and Item. With melee you run into a mob to fight. With items, you push the button then a direction.

--Equipment: Melee Weapon, Wand (for boosting the magic spell, the ranged attack), Armor. No bows and arrows or any missile weapons except the wands.

--Other items: Potions, Food, Gold. Scrolls are redundant and everything would be a potion.

 

Weapons, the number is also, conveniently, how many points of damage a weapon does:

 

1. Bokken (Wooden Sword)

2. Dagger

3. Mace

4. Longsword

5. Bastard sword

6. Claymore

 

 

Armor (the number is how many points of damage it subtracts from incoming damage)

 

1. Cloth

2. Leather

3. Chain

4. Splint

5. Plate

6. Crystal Plate

 

Wands (basic missile weapons. The number signifies both the damage it would do and the MP cost. There is a certain elegance to that, I think)

 

1. Fire

2. Lightning

3. Pain

4. Laser

5. Destruction

6. Death

 

Wands (utility, each costs 5 mp)

-Polymorph

-Teleport

-Sleep

 

Potions

-Acid (actually acts like a wand of digging, creates a hole down to the next level)

-healing

-Stat healing (IE ants attack your STR stat and this potion fixes that)

 

Monsters:

26 or so Monsters. A monster can be stored as a single number, and that stat would be used for damage done, it's hitpoints, and when divided by 5, it's defense.

 

 

examples:

 

A - Angel (26), 26 HP, 26 DMG, 5 def

B - bear (2), 2hp, 2dmg, 0 def

Z - zombie (1) 1 hp 1 dmg 0 def

G- Giant (15) 15 hp, 15 dmg, 3 defense

 

the numbers can be arbitrary so that maybe (A)ngel is the most powerful, (D)ragon is the second, and so on however the designer sees fit. I could work out a list of cool monsters at a later time, but the series should be a complete 1-26 set. Some mobs should have special powers.

 

Thoughts?

Edited January 26, 2013 by Robot2600

[yllawwally]

In the original game these are the special attacks

 

Aquators rust your armor (decrease by one per hit)

Ice monsters can freeze you (for several moves, giving other monsters a go at you!)

Leprechauns steal gold if given the chance to hit you.

Medusas confuse you with their gaze, making it difficult to accomplish anything.

Nymphs steal magic items if given a chance to hit you.

Vampires steal maximum hit points

Wraiths drain experience points

Xeroc's mimic (photocopy?) other items, giving you a nasty surprise when you try to pick them up!. Zapping a hiding Xeroc with a wand of cancellation will reveal it.

If monster is held or sleeping, you get a +4 to hit

 

Monster Stats

 

Name: aquator Abil: M Lvl: 5 Arm: 2 Att: 0d0/0d0Exp: 20 Gold: 0

Name: bat Abil: F Lvl: 1 Arm: 3 Att: 1d2Exp: 1 Gold: 0

Name: centaur Abil: Lvl: 4 Arm: 4 Att: 1d6/1d6Exp: 25 Gold: 15

Name: dragon Abil: M Lvl: 10 Arm: -1 Att: 1d8/1d8/3d10Exp: 6800 Gold: 100

Name: emu Abil: M Lvl: 1 Arm: 7 Att: 1d2Exp: 2 Gold: 0

Name: flytrap Abil: M Lvl: 8 Arm: 3 Att: %%%d0Exp: 80 Gold: 0

Name: griffin Abil: MFR Lvl: 13 Arm: 2 Att: 4d3/3d5/4d3Exp: 2000 Gold: 20

Name: hobgoblin Abil: M Lvl: 1 Arm: 5 Att: 1d8Exp: 3 Gold: 0

Name: ice monster Abil: M Lvl: 1 Arm: 9 Att: 1d2Exp: 15 Gold: 0

Name: jabberwock Abil: Lvl: 15 Arm: 6 Att: 2d12/2d4Exp: 4000 Gold: 70

Name: kestral Abil: MF Lvl: 1 Arm: 7 Att: 1d4Exp: 1 Gold: 0

Name: leprechaun Abil: G Lvl: 3 Arm: 8 Att: 1d2Exp: 10 Gold: (100?)

Name: medusa Abil: M Lvl: 8 Arm: 2 Att: 3d4/3d4/2d5Exp: 200 Gold: 40

Name: nymph Abil: Lvl: 3 Arm: 9 Att: 0d0Exp: 37 Gold: 100

Name: orc Abil: G Lvl: 1 Arm: 6 Att: 1d8Exp: 5 Gold: 15

Name: phantom Abil: I Lvl: 8 Arm: 3 Att: 4d4Exp: 120 Gold: 0

Name: quagga Abil: M Lvl: 3 Arm: 2 Att: 1d2/1d2/1d4Exp: 32 Gold: 30

Name: rattlesnake Abil: M Lvl: 2 Arm: 3 Att: 1d6Exp: 9 Gold: 0

Name: snake Abil: M Lvl: 2 Arm: 8 Att: 1d3Exp: 1 Gold: 0

Name: troll Abil: RM Lvl: 6 Arm: 4 Att: 1d8/1d8/2d6Exp: 120 Gold: 50

Name: ur-vile Abil: M Lvl: 7 Arm: -2 Att: 1d3/1d3/1d3/4d6Exp: 190 Gold: 0

Name: vampire Abil: RM Lvl: 8 Arm: 1 Att: 1d10Exp: 350 Gold: 20

Name: wraith Abil: Lvl: 5 Arm: 4 Att: 1d6Exp: 55 Gold: 0

Name: xeroc Abil: Lvl: 7 Arm: 7 Att: 3d4Exp: 100 Gold: 30

Name: yeti Abil: Lvl: 4 Arm: 6 Att: 1d6/1d6Exp: 50 Gold: 30

Name: zombie Abil: M Lvl: 2 Arm: 8 Att: 1dExp: 6 Gold: 0

Edited January 30, 2013 by yllawwally