72 replies to this topic

[jrok]

SeaGtGruff, on Wed Aug 17, 2011 9:25 PM, said:

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]

jrok, on Wed Aug 17, 2011 9:48 PM, said:

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]

DJT, on Wed Aug 17, 2011 6:35 PM, said:

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]

SeaGtGruff, on Wed Aug 17, 2011 10:40 PM, said:

DJT, on Wed Aug 17, 2011 6:35 PM, said:

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 by jrok, Wed Aug 17, 2011 11:14 PM.

[DemonoidTentacle]

DJT, on Tue Aug 16, 2011 8:00 PM, said:

DemonoidTentacle, on Tue Aug 16, 2011 6:11 AM, said:

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   32K   36 downloads

[SpiceWare]

DJT, on Wed Aug 17, 2011 5:47 PM, said:

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

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

DJT, on Wed Aug 17, 2011 6:35 PM, said:

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]

DJT, on Wed Aug 17, 2011 6:35 PM, said:

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

21 Blue!

SeaGtGruff, on Wed Aug 17, 2011 10:24 PM, said:

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]

jrok, on Thu Aug 18, 2011 2:49 PM, said:

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]

jrok, on Wed Aug 17, 2011 11:09 PM, said:

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

[theloon]

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 by theloon, Fri Aug 19, 2011 7:06 AM.

[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]

jrok, on Thu Aug 18, 2011 2:49 PM, said:

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]

Asaki, on Fri Aug 19, 2011 8:21 AM, said:

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.

Asaki, on Fri Aug 19, 2011 8:21 AM, said:

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   32K   27 downloads

Edited by jrok, Fri Aug 19, 2011 4:46 PM.

[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 by jrok, Sat Aug 20, 2011 12:02 AM.

[jrok]

*Double-post, sorry*

Edited by jrok, Fri Aug 19, 2011 11:32 PM.

[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   32K   28 downloads

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

Edited by jrok, Sat Aug 20, 2011 12:52 AM.

[DemonoidTentacle]

DJT, on Thu Aug 18, 2011 5:16 PM, said:

jrok, on Thu Aug 18, 2011 2:49 PM, said:

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]

jrok, on Sat Aug 20, 2011 12:51 AM, said:

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.

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]

jrok, on Fri Aug 19, 2011 4:19 PM, said:

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....Fatal_Labyrinth
http://en.wikipedia..../Dragon_Crystal



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