STOS Dungeon Crawling

[Encolpius]

Hello people!

I found this place via the STOS Coders facebook group where I glory in the name of Jon S. Stock and have been attempting to bolt together a dungeon crawler. Since retrieving my two STs from storage I've been trying to think of something to produce for them, and this seems as good an idea as any.

Basically, I used to STOS when I was smaller as we had the Discovery Pack but since I didn't know anyone else in my childhood who also had an ST it felt a bit lonely and pointless doing it. Of course, now I've found that STOS is still a thing amongst retro enthusiasts, I'm getting into it somewhat.

I'll be posting updates to the crawler, named WARRIORS OF LIGHT after a Freedom Call song that came on Youtube (I like my heavy metal \m/) while I was merrily typing away, on the Facebook group and also cross-posting them here. Anyone wanting to inspect, critique, or (more likely) point and laugh at my code is more than welcome to.

Currently WOL includes:

- A complete wall engine but with ugly walls because I can't draw,
- Doors that open and close,
- A main menu that is subject to change,
- A character generation screen,
- The ability to load in a map from a .CSV file and work with it, and
- An interface that I am inordinately proud of.

When I get my hands on a screen for my STs that work (I bought an NEC 1770VX off Ebay because I was told these can work with it, but I was caught and bowled with one that doesn't) I may see if it will actually work on a real life ST. It should as this is vanilla STOS.

Controls are WASD with Q and E to turn, and the mouse to click things.

Anyone who is good at drawing walls and floors is encouraged to get into contact.

- Encolpius.

EDIT: I have inserted a "mode 0" statement near the beginning. Good spot; I missed this because I was coding mostly in low res in any event. I've also made sure to include a slightly extended map and the corrected door graphics.

[Orion_]

could you make an executable to load it ?
I tried to load it in STOS, but it starts in medium resolution mode (as the stos editor is in med res) and the graphics are not correct since it require low res

[Encolpius]

Agh, I must have forgotten a "mode 0" near the start. I'll rectify and repost.

[mlynn1974]

Very nice! Definitely looks good.

Points to note:
1. The STOS compiler has a problem at line 820 with undeclared variables:
dim curloc$(4),xt(4),yt(4)
dim wall$(8)
The code works in the interpreter because they are initialised by goto\gosub the compiler doesn't detect that.
Question for anyone (Charles?): Does the STOS Compiler support forward declaration in other circumstances?
I initialised them by declaring them at line 105\106 and commenting out the declarations at 2040.
2. There is a comment in the code that says don't dim here or something. Why is that?
3. The compiled version loads faster but the mouse pointer is hidden due to repeated switching on and off of the mouse.
I can't remember how to get round that. Possibly carefully use mouseon\mouseoff instead.
4. When starting a game there is debug mouse position info. I thought the code was loading data or something the first time I saw it!
You could switch that off or only show it in debug mode or something.

I look forward to seeing more of this game.

[Encolpius]

Very nice! Definitely looks good.

Points to note:
1. The STOS compiler has a problem at line 820 with undeclared variables:
dim curloc$(4),xt(4),yt(4)
dim wall$(8)
The code works in the interpreter because they are initialised by goto\gosub the compiler doesn't detect that.
Question for anyone (Charles?): Does the STOS Compiler support forward declaration in other circumstances?
I initialised them by declaring them at line 105\106 and commenting out the declarations at 2040.
2. There is a comment in the code that says don't dim here or something. Why is that?
3. The compiled version loads faster but the mouse pointer is hidden due to repeated switching on and off of the mouse.
I can't remember how to get round that. Possibly carefully use mouseon\mouseoff instead.
4. When starting a game there is debug mouse position info. I thought the code was loading data or something the first time I saw it!
You could switch that off or only show it in debug mode or something.

I look forward to seeing more of this game.

Glad you liked it. I'm not a professional programmer or anything involving computers at all in my real life.

To answer your questions:

1. Yeah, this is fixable.

2. Oh, that. Don't dim here was a reminder to myself to wait until I'd got the level dimensions from the map file before declaring the array for the map grid - DPOS(x,y). I was thinking that I could have levels of varying size from the small to the arbitrarily large. Unfortunately I've since discovered that there's no easy way to adjust the size of an array once it's declared in STOS (no REDIM statement). I may have to stick to 35 x 35 now and just wall off empty space for the levels that don't need to be that big.

3. It's been ages since I last compiled anything so I'll have to look into that.

4. Yes, this needs removed. I'll also rework that box to use SET ZONE rather than a multi-dimensional IF to determine whether the mouse is where it needs to be.

The next step for me is to implement an inventory and then objects. I can't recall if you can SCREEN COPY into a window because I was aiming at a "paper doll" type affair. I've put together a small 12-item "test" object directory CSV and where objects are in the level is determined by a secondary array in the form n=OBJGRID(x,y,p). Basically, when drawing the view what I have in mind is a check to see if the object array for each visible square contains a number above zero. If it does, it consults the object directory to see what object n is, and then draws the appropriate sprite for that object on the square with an offset of p*16. This is so I can have up to six sub-cells in each map square for objects. Sorry, no infinite stacking. Besides, I don't expect to have every last corner of the dungeon contain treasure or something useful. This is for a number of reasons:

1. I don't like the "hyperspace arsenal" in a crawler. Basically, I want players to think, am I likely to need this in the future, and then make their decision.

2. Inventory management is tedious for the player and I want to discourage it.

3. Sometimes a room with a large monster in it also serves to notify the player that resources are limited and they have to gamble whether the risk is worth it.

A question that does arise, though, is this - how can I shrink a sprite for when it's drawn in the distance? Or am I reduced to having a "normal" object sprite entry and a "small" sprite entry for when it's in the distance, using up more memory space in so doing?

[Orion_]

nice, but please don't use ASDW because this is only valid for QWERTY keyboard, on AZERTY keyboard it's not fun to play
please use the standard arrow keys

[Encolpius]

A fair point.

On a French AZERTY keyboard, are the scancodes different? That way what would be WASD for QWERTY or QWERTZ users would be ZQSD.

I might even just insert a keyboard reassignment routine in the main menu actually. That's better for everyone possibly.

[mlynn1974]

A question that does arise, though, is this - how can I shrink a sprite for when it's drawn in the distance? Or am I reduced to having a "normal" object sprite entry and a "small" sprite entry for when it's in the distance, using up more memory space in so doing?

You could use the zoom command to enlarge the sprite. It's slow but probably OK for up-to 64x64 sprites.
Example: zoom logic,0,0,32,32 to logic,100,100,164,164
The SKOPY command with the Misty Extension is much faster. Instead of using STOS sprites you put the graphics on a back buffer or memory bank and copy them. It's much faster to use pre-shifted and pre-scaled sprites.

There is a handy guide here:
https://temlib.org/AtariForumWiki/index ... STRUCTIONS

[OverlordMRK]

I agree Jon, give people the option to reassign keys if possible. I personally prefer WASD Q&E for most keyboard controls as I find it much more comfortable than having to place my hand further over to the arrow keys, while still using the mouse also. So a reassign key option (or different keyboard/language modes) would keep everyone happy.

[Encolpius]

Update time!

Object handling is 70% there. I still need to work out why their won't show up in the inventory slots even though you can put them and take them from there no problem, insert a routine to draw them in squares other than right in front of you (which means redrawing them in small and inserting a "distant sprite" entry in OBJDIR.CSV first), and then switch on the equipment slots.

I've also added a credits fading routine to the splash screen and made it a little less static.

Anyone wants to have a go, inspect or, more likely, point and laugh at, my code is welcome to download the disk image and run WOL0_40.BAS.

Not been able to incorporate a settings page yet though I'm afraid.

[MM41]

Encolpius it's a nice dungeon crawler ,but same remark not adapted to a french keyboard

[Encolpius]

Hello there. Sorry to delay in responding.

Yes indeed. I've actually implemented level transitions and an extra square's view distance (I'm posting updates more frequently on the Facebook group). However next update will include an options screen in which you can re-assign the keys. I'll rejig the main loop to work on scancodes as well for input so you can have arrow keys if you prefer. This might also be preferable anyhow so I can implement keyboard shortcuts for inventory and pause menu (space).

I was hoping to be able to make level transitions persistent next actually but it makes more sense to implement that when everything that might actually be on a level that is mutable (i.e. monsters, switch and door states, pits and traps) is in place so I don't have to go and keep rewriting it.

EDIT: This disk image has a compiled .prg file as well and works on a real life ST.

[Encolpius]

Version 0.52 is here. The big addition here is reconfigurable controls. I've also got rid of the ABOUT screen because it was just taking up space and time. Also there's a keyboard shortcut for opening the inventory which is [return] but you can set it to whatever you fancy.

[dma]

Hey pretty cool project.
I didn't expected it to be 3D, cool D.M. viewpoint and exploration.
Keyboard remapping works fine.
Wait screens during game and setup inits would be nice (even just with basic text in for now in your w.i.p. version).

[MM41]

The new configurable keyboard is perfect

I have played all the first floor and i have refinded my 15 years old when i drawing the card

I seen some little bugs: wall not closed according to the angle of view (room of the scroll), sword in the wall,
item changing when approaching (falchion or sword ?).
Some items are difficult to pick up (flickering) and changed when placed on the inventory but normal then cased.
Those bugs must be confirmed by another person (may be SD card fault or hard drive)

It is possible to draw the rail of the grid (when we are on the square grid, we see a normal wall when doing a 360°)

Encolpius i can't wait to see the next evolution of Warriors of light

[Encolpius]

The new configurable keyboard is perfect

I have played all the first floor and i have refinded my 15 years old when i drawing the card

I seen some little bugs: wall not closed according to the angle of view (room of the scroll), sword in the wall,
item changing when approaching (falchion or sword ?).
Some items are difficult to pick up (flickering) and changed when placed on the inventory but normal then cased.
Those bugs must be confirmed by another person (may be SD card fault or hard drive)

It is possible to draw the rail of the grid (when we are on the square grid, we see a normal wall when doing a 360°)

Encolpius i can't wait to see the next evolution of Warriors of light

Why thanks.

Okay, the flickering objects are possibly because I'm using sprite routines to draw them. The original problem I had was that PUT SPRITE didn't work properly in the inventory screen. Thankfully, I found that by using TRAP 5 in a FOR/NEXT loop I was able to make the inventory objects appear no problem. I need to adapt that to the objects on floor routine, possibly by invoking a run of TRAP 5s when you pick up or drop and sticking a SCREEN$ of the viewport into place beforehand.

The potion that turns into a falchion, or is it the other way around? Yeah, that's probably me making a typo in the object directory.

Sword in the wall - that could probably be fixed by moving the hotspot on "large" items to the centre rather than the top left.

Next on the agenda is a routine to apply decor (signs, shelves, etc.) what I call "spackle" to the levels. I was going to procedurally generate it in-game but it would have added to loading times a bit too much. So I made a separate program to rejig random walls and floors to be marked as having cracks, chips, etc. on them. I am also thinking about incorporating locks and keys, which I could possibly implement in the sprite bank so I can invoke TRAP 5 to draw them and a few lines in one of the map files to determine which doors are locked and the keys required for them. I was also thinking it might be easiest to put the locks actually on the door frames myself.

(The advantage of TRAP 5 for smaller items is that you aren't limited to 16 pixel steps.)

Then after that, monsters! You will be pleased to note that I'm trying to make said monsters as unusual as possible - no orcs, no goblins, no undead. I don't suppose, though, you've ever fought a Giant Millipede, a Yale, a Baelon, or a Keraunosaur before?

[farvardin]

i've tested it and it looks promising! Well done.

[calimero]

Can you post some screenshots for us on mobile phones?

[NGF]

Very interesting project! Especially since I have been thinking of starting a similar project with a dungeon crawler! STOS seems to have no limits.

Are you planning to have realtime events/game ticks, for example monsters moves on their own, doors closes on enemies when not visible on screen, player stats changes even when standing stil etc.
I noticed that you freeze now when open doors.

How do you calculate what view should be displayed/drawn on screen for each move?

Good luck with your project, looking forward to the complete game!

[Encolpius]

Thanks. I'm glad you like it.

The doors open like they do because I was aiming at the sort of "clonking open" that Eye of the Beholder had where they go up a bit at a time, however, I don't want to spend more memory storing part-open frames so it composites them on the fly with a WAIT command between each one. However I'm wondering if it might be possible, and probably quicker, to have them whoosh open a la Grimrock. Possibly by chopping the ceiling part of the frame into a SCREEN$ then compositing the scene with the open door, the door itself semi-open in a FOR/NEXT loop, etc. If I make it open like ten pixels a frame (with a nice sampled sound maybe in the final game?), I can sort of ersatz it at a distance by having them just appear with the same sound effect if a door opens at a distance or out of view.

It will be intended to be in real time. The plan I have is that 50 vbls (i.e. 1 second) equals one "tick" and on every tick the game runs routines to decide the movement of each monster, any temporary effects or status effects, etc. It also will check the monster grid to see if a creature has hoved into view and if it has, draws it accordingly. I'm probably going to have to create a routine to do a "limited redraw" if there's monsters round a corner or similar. Otherwise I'm just redrawing everything to no effect. Ten ticks makes a "tock." This would enable me to make attack patterns for monsters or timing-based puzzles - i.e. something like "ON TICK GOSUB Attack(), Spell(), Attack(), Attack(), TryToFlank()," etc.

How I calculate the view? With lots of IF statements. It's not exactly elegant. I have a routine that checks what direction the player is facing and then decides which dungeon squares to interrogate for what should be drawn, then uses a whole load of SCREEN$ calls to composite them on screen 8, then blits the whole of SCREEN 8 to back and physic.

I'm actually currently working on a program that isn't necessarily going to form part of the final game but will be used to create monster files. I originally thought I'd have a .CSV as a "monster directory" and then have the game look up which monsters are present accordingly but it seems very cumbersome, esp. considering the viewport size which would require the larger monsters to have their graphics bridged across two screens. I'm thinking instead, have a program that compresses one or two screens into a single file together with that monster's stats and indications whereabouts in the file each frame of animation can be found. The game itself can then, upon loading each level, load from the location master file details of what monster types are about, then load the requisite monster files, decompress them, load each frame into a SCREEN$ (yes, I know BLIT / M BLIT is faster but it also wastes memory on empty pixels unless each graphic set fits exactly in a single screen, and I'm already in 1 meg only territory, and you have to remember exactly where in memory each frame is stored), grab the stats, then purge the memory, then do the same with the next monster type, and so on.

I'm really hoping, in terms of graphical assets, to get nice versions of the walls soon enough. Once that's done I plan to do the same with wall sets, compress them into a single file. While on that subject, I'm all open for volunteers to draw nice walls because I suck calamitously at all things art...

[swapd0]

I can't make it work, also the last two disk images (I haven't tried others) seems corrupted because it has 13.872.738 bytes used, who needs a hard disk? XD

[Encolpius]

Hrm. The disk images aren't corrupted; I've checked them myself. How I did it was I formatted a real disk on my ST with Diamond Format in Diamond Super Fast mode (which is demonstrably quicker at reading data), wrote an MS-DOS boot sector, and copied everything to that. I then imaged it from that. I think the large amount of bytes used is something to do with the way Diamond Format does it.

What exactly is the error or suchlike it is throwing? And are you running the .prg or the .bas from within STOS?

[swapd0]

Ok, the prg version works (I didn't know that it existed. XD) but the bas version doesn't, it gets hung before the intro screen, I'm using TOS 1.02 into Hatari 1.8, Mac OSX.

[spiny]

I can't make it work, also the last two disk images (I haven't tried others) seems corrupted because it has 13.872.738 bytes used, who needs a hard disk? XD

the disk image isn't corrupted, the weird file size is because of a Windows/Mac system folder thats also on the disk.

If you just copy all the files, and not the folder, to a new disk/folder it's about 650k

[NGF]

Thanks. I'm glad you like it.

It will be intended to be in real time. The plan I have is that 50 vbls (i.e. 1 second) equals one "tick" and on every tick the game runs routines to decide the movement of each monster, any temporary effects or status effects, etc. It also will check the monster grid to see if a creature has hoved into view and if it has, draws it accordingly. I'm probably going to have to create a routine to do a "limited redraw" if there's monsters round a corner or similar. Otherwise I'm just redrawing everything to no effect. Ten ticks makes a "tock." This would enable me to make attack patterns for monsters or timing-based puzzles - i.e. something like "ON TICK GOSUB Attack(), Spell(), Attack(), Attack(), TryToFlank()," etc.

How I calculate the view? With lots of IF statements. It's not exactly elegant. I have a routine that checks what direction the player is facing and then decides which dungeon squares to interrogate for what should be drawn, then uses a whole load of SCREEN$ calls to composite them on screen 8, then blits the whole of SCREEN 8 to back and physic.

I'm really hoping, in terms of graphical assets, to get nice versions of the walls soon enough. Once that's done I plan to do the same with wall sets, compress them into a single file. While on that subject, I'm all open for volunteers to draw nice walls because I suck calamitously at all things art...

I have also considered real time but it feels like it's one upper level of difficulty to code/complexity to the game so I might skip it and make it more like the Elvira games.

Ok, you have the exact solution to the viewpoint as I have with alot of IF's. As long as it works I guess.. But I can't escape the feeling that it should be a easier/shorter way to calculate view

About the graphical assets, why not "borrow" some graphics from Eye of the beholder / DM as a start and then edit them beyond recognition for your own needs?

I wish you good luck with the game!