ATASCII-based ROGUE on A8?

[TheRaven81]

So, just for kicks, I wrote a kinda small BASIC program filled with print commands, and a few pokes and colors - to make this "mock screen". Why can't ROGUE on A8 look like this? I'd think it'd be much simpler to program probably? I've seen the ones by Epyx, and by Mastertronic(though I could not get the Mastertronic version working properly) - and they look nothing like what I remember Rogue to be.  I also took a look at A-ROGUE, which was listed in an issue of Antic(Vol. 6, Issue 1) - and it doesn't play very well. There doesn't seem to be any "room" structures, it's just a massive maze of hallways, and I don't get it. I couldn't even find the way to the next floor.

 

Making a version of ROGUE that's all ATASCII can't be that hard, can it? Feels like it would be easier than trying to draw all those fancy graphics sprites.

Edited April 21, 2020 by TheRaven81

[+slx]

It's probably more the size of the logic behind that makes it hard to port. AFAIK Rogue has a lot more going on behind the scenes than the Eryx dungeon crawlers. The C source is available on GitHub so you might have a look at what size it compiles to in CC65... 

 

You could do colored tiles in Antic mode 4 without much memory penalty but for meaningful graphics you would probably need 4 characters per object, losing a lot of overview, more like Apshai.

 

 

 

 

[Wrathchild]

Have a read of @Shawn Jefferson's blog:

 

[carlsson]

It seems that Whack by Aleksi Eeben was ported from VIC-20 to C64 by himself, and to the Plus/4 by Gaia. Kweepa also made an extended Whack-E on the VIC-20. While it is nowhere as advanced as Moria, Rogue, Hack, NetHack etc it might be another starting point for a simple text based roguelike.

 

There is also Grail of the Gods which started off as a PC game using Dark BASIC and then ported to by Tandy MC-10, Intellivision and I believe a version for Colecovision was under way too. Clearly also a more limited game but could be used as a basis for something simple.

 

Edit: It is true though that both these games work with continuous mazes, not room based like e.g. NetHack does on many of its levels.

Edited April 21, 2020 by carlsson

[TheRaven81]

1 hour ago, slx said:

The C source is available on GitHub so you might have a look at what size it compiles to in CC65... 

I don't know how to do that.

[carlsson]

As a hint, the installed size of Rogue 5.4.4 on Arch Linux is 190 kilobytes and that doesn't cover runtime memory use. There is a remastered, more graphical version for Windows and OSX which clocks in at 3 MB but that is irrelevant.

 

Beyond the games I mentioned, Brian Sawyer's DUNGEON (PET) and perhaps Jeff McCord's Gammaquest II (also PET, later improved as Sword of Fargoal) might also be of interest. In particular DUNGEON really seems to generate proper rooms with corridors.

 

Edit again: The online version of DUNGEON linked to above is not the original, but a recreated one with fixed dungeons... Here is a review of the original game, with the note that pre-Rogue games for home computers were rather simple compared to the larger mainframe games.

Edited April 21, 2020 by carlsson

[TheRaven81]

So, I am guessing that the verdict would be that unless you have a large amount of RAM(the U1MB seems like it might be enough for it) in your A8, then Rogue in its original state is probably not possible? Unless maybe it went on a cart that supplied its own RAM solely for the use of the program?  I don't know if cart games do that though. 

[evilmoo]

9 minutes ago, TheRaven81 said:

So, I am guessing that the verdict would be that unless you have a large amount of RAM(the U1MB seems like it might be enough for it) in your A8, then Rogue in its original state is probably not possible? Unless maybe it went on a cart that supplied its own RAM solely for the use of the program?  I don't know if cart games do that though. 

So you need RAM to store whatever is immediately needed and likely to change.  The code itself and any static data (monster names and statistics etc) could be either on disk or a cartridge.  In theory, each level not currently in use could also be swapped out to a disk.

[FifthPlayer]

59 minutes ago, evilmoo said:

In theory, each level not currently in use could also be swapped out to a disk.

 

Rogue doesn't really work like that; the levels aren't precompiled but instead are randomly generated.  But your general point remains; the game does have static data (monsters, items, etc) that could be stored on cartridge ROM and bank-switched in as needed.

[carlsson]

Yes and no. If you for example look at NetHack, for each level in the Dungeon of Doom and Gnomish Mines, it generates the map and saves it to disk so you can return to a previous level. A few levels have fixed layouts, like the one midway down the Gnomish Mines with all the shops and also later on in the quests I think. I don't know about the original Rogue if it works the same way, but yes a combination of primary storage (RAM) and secondary storage (disk and/or ROM for fixed layouts) would be preferred if you want your game to be complex.

[ilmenit]

dungeon-crawl-mini.xex

One of my never finished projects from about 2009. Looking at the sources it should compile also for C64, NES and even ZX Spectrum.

 

Controls:

WSAD - move
G - get
I - inventory

In inventory press a Key for context menu. Then D to drop and U to use.

 

 

 

 

[+cjherr]

That's cool! I'd love to see it expanded on.

[invisible kid]

Just random tidbits that are somewhat related. Found a version of Rogue in cassette form from somewhere. Has a nice looking title screen, but when I tried to start a new game it seemingly hung, maybe it was generating a map or something and I just wasn't patient enough. I also came across Talisman from somewhere which is quite playable. I think I cheated on that one my modifying the code via the monitor. GAMES315.ATR is where I originally found TALISMAN.COM, but don't remember where I got it from. H, J, K, L to move, and other commands similar to Nethack (or other rogue-likes, I only really played nethack).

 

This is one of those things that if you want to create a version, design conundrums arise, is it better to have smaller cells so more map can fit on a screen, which character mode is best for this, should I use color, or just use Graphics 0. One of the reasons character/text graphics were originally used is because either that's all there was or it was much more manageable resource-wise. Even in early (relative) versions of Nethack had graphical tile options. Not saying any approach is better than another, it's just one of those things where you just keep changing your mind trying to use best assets/traits of the Atari.

 

 

Rogue.cas GAMES315.ATR TALISMAN.COM

Edited April 22, 2020 by invisible kid

[carlsson]

The Rogue you found is the Mastertronic game. Nice find about Talisman too.

[Asaki]

On 4/21/2020 at 1:11 AM, TheRaven81 said:

Why can't ROGUE on A8 look like this?

The problem with Rogue is that, for some reason, Epyx decided that for a lot of their home computer ports, they wanted to copy the Atari ST version of the game, mouse controls and all.

 

Say what you will about the graphics, but you're trying to play this keyboard game, with a joystick that's pretending to be a mouse. Yuck.

 

I would be very surprised if a straight-up ASCII version were not possible.

[TheRaven81]

I actually finally got the Mastertronic version working in Altirra. It's an OK version, but it could do without the cursor movement though. I was still confused about gameplay - I could not figure out how to use any of the items I picked up, how to change equipment, or how to attack the monsters that I encountered. And none of this info was in the instruction sheet, so....I kinda just gave up on trying to play further.

[TheRaven81]

21 hours ago, ilmenit said:

dungeon-crawl-mini.xex 18.23 kB · 8 downloads

One of my never finished projects from about 2009. Looking at the sources it should compile also for C64, NES and even ZX Spectrum.

 

Controls:

WSAD - move
G - get
I - inventory

In inventory press a Key for context menu. Then D to drop and U to use.

 

 

 

 

 

21 hours ago, cjherr said:

That's cool! I'd love to see it expanded on.

Agreed! I think you definitely have something worth finishing there.

 

[carlsson]

Haha! I saw that Brian Sawyer's DUNGEON is present on Gamebase 64 as well, but whoever uploaded it as a T64 didn't bother changing a single POKE or PEEK statement so it does nothing but print out the status bar. That is not exactly what I call "porting" a game. About 4K of tokenized BASIC so perhaps I'll have a go at converting it later.

[FifthPlayer]

On 4/21/2020 at 11:54 PM, carlsson said:

Yes and no. If you for example look at NetHack, for each level in the Dungeon of Doom and Gnomish Mines, it generates the map and saves it to disk so you can return to a previous level. A few levels have fixed layouts, like the one midway down the Gnomish Mines with all the shops and also later on in the quests I think. I don't know about the original Rogue if it works the same way, but yes a combination of primary storage (RAM) and secondary storage (disk and/or ROM for fixed layouts) would be preferred if you want your game to be complex.

 

Excellent points.  I haven't looked at the Rogue source code to see if it works in the same way, but one idea would be to have the levels procedurally generated from a seed.  Some popular games like River Raid and Pitfall do this, I think.  With such a system, all you would have to do is save the seed for the level as well as the status of the objects (monsters can be repopulated) for when the player returns to the level. 

[carlsson]

Hm, storing a series of random seeds in RAM, and then generate the "dynamic" levels based on those. It still leaves the issue what if you stepped down one level without fully exploring the previous one, and then go back up, would the level reset? What about objects, randomly generated or not? I mean if there are 100 gold coins on one level, we don't want the player to milk it by picking up the gold, go down one level, back up and pick up the gold again etc. This is solved by storing generated levels on disk, which generally shouldn't be an issue on the A8 if the levels are somewhat well packed and you use a disk format that at least has some capacity.

[RevEng]

You can run a few different LFSRs to generate the various room characteristics and objects in a level. The input seeds for these LFSRs would be room#, level#, and any other characteristic you want to vary the LFSR with. This would mean the random objects don't need to be stored, but rather just recomputed when you enter a room.

 

Object+enemy persistence could then be tracked with simple byte or bit arrays, indexed by room#. To prevent griding by moving between levels, you track visited levels, and keep object+enemy persistence arrays for both the previous and current level. When going up or down stairs to a previously visited level, you swap previous and current arrays. When going up or down stairs to a new level, the current object+enemy arrays become the previous arrays and you clear the current object+enemy arrays.

 

This still opens the door to grinding by travelling through 3 levels. You can prevent that by removing goodies and respawning enemies when you travel 2 levels away from a previously visited level, or otherwise making backtracking that far illegal.

[carlsson]

Sometimes you might leave objects behind on purpose, for instance a heavy pick-axe which you figure out you'll need later but right now you have various weapons, armor, spellbooks and other items you need sooner. Sure, perhaps the maze will be littered with lightly used pick-axes later on but if you have cast a scroll of enhanced weapon (enchanted weapon? I never learn what is what) that made it +2 and rust proof, perhaps you drop it in a place where you hope no monster will pick it up. Sure if you have enough RAM you could maintain several of those byte arrays while having the actual level procedurally generated, but then again this is a pick-axe so perhaps I already digged a hole into the wall to get to a secret chamber full of gold and that also needs to be recorded unless the guards of the maze have closed up the hole in the wall when I get back to that level later on.

[RevEng]

So then you have one more layer of object spawning for rooms, similar to the object+enemy persistence array, but for the last 32 (or whatever power-of-two #) dropped objects. The objectdrop arrays keep the dropped object type, characteristics, and room. Same as the object+enemy persistence arrays, the objectdrop arrays have current-level and previous-level versions, that get swapped and/or cleared when you change levels.

 

I think memory of the 32 last-dropped objects should be enough for anybody™, and you're looking at an extra page or two of ram to implement it.

[Asaki]

10 hours ago, FifthPlayer said:

With such a system, all you would have to do is save the seed for the level as well as the status of the objects (monsters can be repopulated) for when the player returns to the level. 

I've never made it to the Amulet before, but I'm fairly certain that Rogue doesn't do this.

[Sugarland]

A great roguelike is TomeNET which is multiplayer and free and open source.  The Windows client is about 1MB but that can probably be lessened. Maybe it's easier to get TomeNET working since it's only a client..?