STOS Dungeon Crawling

STOS-related stuff in here please

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Encolpius
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

STOS Dungeon Crawling

Postby Encolpius » Mon Aug 27, 2018 1:28 pm

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.
You do not have the required permissions to view the files attached to this post.
Last edited by Encolpius on Mon Aug 27, 2018 2:47 pm, edited 1 time in total.

User avatar
Orion_
Captain Atari
Captain Atari
Posts: 395
Joined: Sat Jan 10, 2004 12:20 pm
Location: France
Contact:

Re: STOS Dungeon Crawling

Postby Orion_ » Mon Aug 27, 2018 2:21 pm

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
My retro games shop including Atari ST/Falcon/Firebee games ! -- Free Atari games/demos/tools -- Free Falcon demos/tools
Atari Mega STe 4MB + SD2SCSI 1GB + NOVA ET4000 + Pico PSU + Gotek HxC // Atari STe 2MB

Encolpius
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

Re: STOS Dungeon Crawling

Postby Encolpius » Mon Aug 27, 2018 2:36 pm

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

mlynn1974
Captain Atari
Captain Atari
Posts: 203
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: STOS Dungeon Crawling

Postby mlynn1974 » Mon Aug 27, 2018 9:44 pm

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.
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

Encolpius
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

Re: STOS Dungeon Crawling

Postby Encolpius » Tue Aug 28, 2018 5:33 pm

mlynn1974 wrote: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?

User avatar
Orion_
Captain Atari
Captain Atari
Posts: 395
Joined: Sat Jan 10, 2004 12:20 pm
Location: France
Contact:

Re: STOS Dungeon Crawling

Postby Orion_ » Tue Aug 28, 2018 7:42 pm

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
My retro games shop including Atari ST/Falcon/Firebee games ! -- Free Atari games/demos/tools -- Free Falcon demos/tools
Atari Mega STe 4MB + SD2SCSI 1GB + NOVA ET4000 + Pico PSU + Gotek HxC // Atari STe 2MB

Encolpius
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

Re: STOS Dungeon Crawling

Postby Encolpius » Tue Aug 28, 2018 7:57 pm

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
Captain Atari
Captain Atari
Posts: 203
Joined: Mon Mar 03, 2008 10:33 pm
Contact:

Re: STOS Dungeon Crawling

Postby mlynn1974 » Tue Aug 28, 2018 9:33 pm

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
Still got, still working: Atari 4Mb STe, 520STFM, 2.5Mb STF.
Hardware: Cumana CSA 354, Ultimate Ripper, Blitz Turbo, Synchro Express II (US and UK Versions).

OverlordMRK
Retro freak
Retro freak
Posts: 11
Joined: Thu Aug 31, 2017 10:25 pm

Re: STOS Dungeon Crawling

Postby OverlordMRK » Tue Aug 28, 2018 11:47 pm

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
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

Re: STOS Dungeon Crawling

Postby Encolpius » Sat Sep 01, 2018 3:38 pm

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.
You do not have the required permissions to view the files attached to this post.

MM41
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 102
Joined: Sun Jun 28, 2015 2:36 pm
Location: France

Re: STOS Dungeon Crawling

Postby MM41 » Sun Sep 30, 2018 3:33 pm

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

Encolpius
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

Re: STOS Dungeon Crawling

Postby Encolpius » Tue Oct 02, 2018 6:41 pm

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.
You do not have the required permissions to view the files attached to this post.

Encolpius
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

Re: STOS Dungeon Crawling

Postby Encolpius » Sun Oct 07, 2018 12:46 pm

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.
You do not have the required permissions to view the files attached to this post.

User avatar
dma
Atari Super Hero
Atari Super Hero
Posts: 849
Joined: Wed Nov 20, 2002 11:22 pm
Location: France
Contact:

Re: STOS Dungeon Crawling

Postby dma » Sun Oct 07, 2018 3:05 pm

Hey pretty cool project. :)
I didn't expected it to be 3D, cool D.M. viewpoint and exploration. :D
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). :wink:

MM41
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 102
Joined: Sun Jun 28, 2015 2:36 pm
Location: France

Re: STOS Dungeon Crawling

Postby MM41 » Mon Oct 08, 2018 8:26 pm

The new configurable keyboard is perfect :cheers:

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

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 :cheers:

Encolpius
Atarian
Atarian
Posts: 8
Joined: Mon Aug 27, 2018 12:46 pm

Re: STOS Dungeon Crawling

Postby Encolpius » Tue Oct 09, 2018 6:48 pm

MM41 wrote:The new configurable keyboard is perfect :cheers:

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

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 :cheers:


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?

User avatar
farvardin
Captain Atari
Captain Atari
Posts: 367
Joined: Fri Jan 01, 2010 5:50 pm
Location: France
Contact:

Re: STOS Dungeon Crawling

Postby farvardin » Wed Oct 10, 2018 7:05 pm

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

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2217
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: STOS Dungeon Crawling

Postby calimero » Wed Oct 10, 2018 11:23 pm

Can you post some screenshots for us on mobile phones? :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X


Social Media

     

Return to “STOS”

Who is online

Users browsing this forum: No registered users and 2 guests