mlynn1974 wrote:Very nice! Definitely looks good.
Points to note:
1. The STOS compiler has a problem at line 820 with undeclared variables:
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?