Jump to content

Photo

Grail of the Gods - a Rogue-like game in compiled XB

rogue roguelike dungeon crawl

26 replies to this topic

#1 majestyx OFFLINE  

majestyx

    Chopper Commander

  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Thu Nov 2, 2017 9:07 PM

So after completing my XB version of Oregon Trail, I decided to go a different direction entirely and, since I saw a thread from about four-and-a-half years ago regarding a Rogue-like game for the TI:

 

http://atariage.com/...7876-roguelike/

 

but never seeing a resulting game, I thought it would be a cool idea to run with.

 

I also saw a similar game on Jim Gerrie's TRS-80 MC-10 website, specifically here: http://jimgerrie.blo...-gods-port.html which is itself a port of a DarkBasic 20-line challenge, so I thought this looked promising and doable. The only issue I could think of was how slow it would run on a stock TI. That concern proved well-founded. I programmed it in Extended BASIC as it's so much easier to use than standard TI BASIC. The game absolutely crawls in Normal speed in Tursi's Classic99 and is playable but still sluggish in CPU Overdrive. Thus I compiled it using Harry Wilhelm's XB compiler, which presented its own challenge in additional manipulating of the code to get it compliant with the compiler's known requirements, plus a couple of other things that don't seem to compile properly even though they are supposed to, or don't work the same as in interpreted XB. The common thread for the things that didn't work right involved strings. Regardless, I came up with workarounds and am pretty satisfied with the end result.

 

So what I ended up with is a simple 8-level dungeon crawler using ASCII characters. I gave up on generating random mazes pretty early when it was taking 10 minutes in CPU Overdrive to get one level to 10% completion. So I "borrowed" the dungeon layouts from the "Doom" dungeon in Ultima III with very minor adjustments. The levels are 17x17 (15x15 explorable due to the border), each with static locations for gold, traps, potions, starting location, and exit, plus random placement of monsters, weapons and armor.

 

For those playing it, I will note that there is really no difference in any of the weapons or armor that you find. A rusty dagger will increase your weapon meter exactly the same as a magic claymore, the same as cloth gloves will increase your armor score as much as plate armor. The original was like this, so I didn't deviate from that, at least for this initial version of the game. I just wanted to make certain I could get something like this to work and was happy to find that I was able to. Also, the only plot is to get to level 8 and claim the Grail of the Gods. Goals can be to see how much (or little) gold you can get, how high a rank you can achieve by wiping out all of the monsters, or how low a rank you can achieve yet still reach the Grail.

 

Hope you enjoy playing it as much as I did programming it.

 

The attached ZIP file contains the compiled version of the program (GRAIL-C), the XB source that the compiler used (GRAILEB), and a txt file of the program listing with some explanations at the beginning of it.

 

 

GrailL1Scr1.jpg

 

GrailL1Scr2.jpg

 

GrailL1Scr3.jpg

Attached Files


Edited by majestyx, Fri Nov 3, 2017 10:26 AM.


#2 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,189 posts

Posted Thu Nov 2, 2017 9:42 PM

Nicely done!



#3 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Fri Nov 3, 2017 5:24 AM

 Thus I compiled it using Harry Wilhelm's XB compiler, which presented its own challenge in additional manipulating of the code to get it compliant with the compiler's known requirements, plus a couple of other things that don't seem to compile properly even though they are supposed to, or don't work the same as in interpreted XB. The common thread for the things that didn't work right involved strings. Regardless, I came up with workarounds and am pretty satisfied with the end result.

 

Can you provide examples of what does not work as described?

Thanks/



#4 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Fri Nov 3, 2017 5:50 AM

Can you provide examples of what does not work as described?

Thanks/

 

Sure thing. One of them was this line:

410 GOSUB 2070::DISPLAY AT(19,1):"YOU KILLED THE ";M$(MT,1)::GOSUB 5000

I had to change it to this:

410 GOSUB 2070::DISPLAY AT(19,1):"YOU KILLED THE ";M$(MT,1);"!"::GOSUB 5000

...because it would only display the first letter of what was in that array. Adding the exclamation point after it forced the entire contents of it. So for example, if M$(1,1) was "RAT " it would only display R on the screen.

 

Another was using '&' when adding to a string variable. I had originally set the program up to construct a variable A$ for a later DISPLAY AT command. An example would be

A$="YOU FOUND "&W$(11+INT(RND*5))&W$(16+INT(RND*5))

This completely crashed the compiled program when it encountered a line such as this. I changed lines 520 & 530 to just display the strings one after the other.

 

One other issue I encountered was with ACCEPT AT incorporating a SIZE(-1). No matter what I entered, it wouldn't accept the input. I originally had the "play again?" routine like this:

6080 DISPLAY ERASE ALL AT(12,1):"WANT TO PLAY AGAIN? (Y/N) Y"
6090 ACCEPT AT(12,27)VALIDATE("YN")SIZE(-1):N$
6100 IF N$="N" THEN 7998
6110 RESTORE 8102::GOTO 160

If I tried to enter an N it would not allow it. I changed it to:

6080 DISPLAY ERASE ALL AT(12,1):"WANT TO PLAY AGAIN? (Y/N)"
6090 ACCEPT AT(12,27)SIZE(1):N$
6100 IF N$="N" THEN 7998
6105 IF N$<>"Y" THEN 6090
6110 RESTORE 8102::GOTO 160

I believe those were the 3 that caused me the most trouble. Your guide on how to work around the changes to XB were very helpful such as the IF-THEN limitation of only being able to use line numbers and floating point math when using RND. If it wasn't for your compiler, what I came up with would have been scrapped due to how slow it runs in interpreted XB.


Edited by majestyx, Fri Nov 3, 2017 9:23 AM.


#5 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 2,811 posts
  • Location:Eagan, MN, USA

Posted Fri Nov 3, 2017 7:54 AM

I totally like the way you implemented the gradual exposure of the dungeons. The game plays really well. Nicely done. There is a missing parentheses in line 5010 by the way.



#6 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Fri Nov 3, 2017 9:20 AM

Thanks for the feedback!  I will be looking at these issues and hopefully will be able to fix them.



#7 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Fri Nov 3, 2017 9:20 AM

I totally like the way you implemented the gradual exposure of the dungeons. The game plays really well. Nicely done. There is a missing parentheses in line 5010 by the way.

 

Thanks! Yes, the .txt file is what I use to program and then paste into Classic 99. I also noticed I didn't need line 480 since it's taken care of in the ON GOTO in 500. I obviously fixed it in the final program but forgot to update it in the txt file.

 

I'd have preferred a line-of-sight exposure, but with the way it's set now, I realized I could "tease" parts of the dungeon that aren't accessible but that you'd want to visit by finding the path to it. Level 6 in particular is like that.



#8 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 2,613 posts
  • Location:Portland, Oregon USA

Posted Fri Nov 3, 2017 12:49 PM

lots of fun,  though I got the grail on my first game.. the monsters are stationary etc? are there any other commands (I guess I could read the source tldr) other than arrows and any key? I find myself accidentally going down a level have to be more careful of what i run into icon_mrgreen.gif

 

Greg

 

PS: I can totally see putting this on a cartridge once you feel it's "complete" 


Edited by arcadeshopper, Fri Nov 3, 2017 12:58 PM.


#9 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Fri Nov 3, 2017 1:55 PM

lots of fun,  though I got the grail on my first game.. the monsters are stationary etc? are there any other commands (I guess I could read the source tldr) other than arrows and any key? I find myself accidentally going down a level have to be more careful of what i run into icon_mrgreen.gif

 

Greg

 

PS: I can totally see putting this on a cartridge once you feel it's "complete" 

 

Yeah, it's definitely a simple implementation and I realize that the difficulty isn't all that tough. I have lost, but more often than not, it was on the first level due to bad random numbers.

 

It was a real chore just to get the player to move and update the screen, so for now, and with my skills still being nowhere near pro level, moving monsters are not in the cards. I could probably make them invisible until you bump into them (or make that an option), but that seems even less realistic than them simply standing around. Right now the trade-off is that once you start a battle it's a battle to the death... usually the monsters' deaths but hey, I wanted to prove something like this could be done on the TI. I do envision making the monsters have differing levels of difficulty, as well as differences in power for the weapons and armor you find and if space permits, maybe even a paper thin story a-la Tunnels of Doom.

 

Ladders go down only and once you move over one, you are on the next level. I'd like to at least add an option to ask if you want to descend so you don't accidentally go to the next level if you didn't want or mean to.

 

Also, I didn't want to spend a lot of time on something if people didn't like it. From the few who have commented, it appears those who have tried it like it. So thanks for the feedback to those who have left some!



#10 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Fri Nov 3, 2017 2:32 PM

Thanks for the feedback!  I will be looking at these issues and hopefully will be able to fix them.

 

Not a problem! I just hope I've explained them clearly enough. If not, feel free to send me a PM.

 

Your CALL SOUND suggestion to force a delay was just what I needed in order to cause a delay to the CALL KEY "press any key" sub-routine when messages would be displayed on the screen. Without that, messages would more often than not disappear due to the next key press being read.



#11 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,489 posts
  • Location:Denmark

Posted Fri Nov 3, 2017 3:00 PM

Thanks, I enjoyed playing the game.  ;-)

 

I underestimated the complexity of rogue-like games when I started Dungeons of Asgard. I thought that the coding would be simple because the graphics were simple, but games like Angband have a very rich game engine that it takes lots of time to reproduce.



#12 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Fri Nov 3, 2017 8:39 PM

 

Sure thing. One of them was this line:

410 GOSUB 2070::DISPLAY AT(19,1):"YOU KILLED THE ";M$(MT,1)::GOSUB 5000

I had to change it to this:

410 GOSUB 2070::DISPLAY AT(19,1):"YOU KILLED THE ";M$(MT,1);"!"::GOSUB 5000

...because it would only display the first letter of what was in that array. Adding the exclamation point after it forced the entire contents of it. So for example, if M$(1,1) was "RAT " it would only display R on the screen.

 

Another was using '&' when adding to a string variable. I had originally set the program up to construct a variable A$ for a later DISPLAY AT command. An example would be

A$="YOU FOUND "&W$(11+INT(RND*5))&W$(16+INT(RND*5))

This completely crashed the compiled program when it encountered a line such as this. I changed lines 520 & 530 to just display the strings one after the other.

 

One other issue I encountered was with ACCEPT AT incorporating a SIZE(-1). No matter what I entered, it wouldn't accept the input. I originally had the "play again?" routine like this:

6080 DISPLAY ERASE ALL AT(12,1):"WANT TO PLAY AGAIN? (Y/N) Y"
6090 ACCEPT AT(12,27)VALIDATE("YN")SIZE(-1):N$
6100 IF N$="N" THEN 7998
6110 RESTORE 8102::GOTO 160

If I tried to enter an N it would not allow it. I changed it to:

6080 DISPLAY ERASE ALL AT(12,1):"WANT TO PLAY AGAIN? (Y/N)"
6090 ACCEPT AT(12,27)SIZE(1):N$
6100 IF N$="N" THEN 7998
6105 IF N$<>"Y" THEN 6090
6110 RESTORE 8102::GOTO 160

I believe those were the 3 that caused me the most trouble. Your guide on how to work around the changes to XB were very helpful such as the IF-THEN limitation of only being able to use line numbers and floating point math when using RND. If it wasn't for your compiler, what I came up with would have been scrapped due to how slow it runs in interpreted XB.

This is gonna be hard to pin down.  For your first example I took out the gosubs and made this line which works the same way compiled and in XB
400 CALL HCHAR(1,1,42,768)
410 M$(1,1)="MONSTER!" :: DISPLAY AT(19,1):"YOU KILLED THE ";M$(1,1)
 
Likewise for your second example, which I adapted below by making up simple strings for W$()  

4 RANDOMIZE
5 DIM W$(26)
6 FOR I=1 TO 26 :: W$(I)=RPT$(CHR$(I+64),8):: NEXT I
10 A$="YOU FOUND "&W$(11+INT(RND*5))&W$(16+INT(RND*5))
20 PRINT A$

This also works the same in XB and compiled.

 
There are definitely problems with ACCEPT, including one that you did not report.  Don't know how this slipped through my rigid quality assurance program, but somehow it did!  I will figure out what is going on and fix it.
 
Are you testing the program in XB before compiling?  The TRS80 and other versions of BASIC will let you have A as both a variable and as an array.  A and A(7) for example. (I found this out when working on a port of one of Jim Gerrie's programs.) TI XB does not allow this and issue an error message.  But if you are writing the program and going directly to the compiler the error will not be found and the compiled code will crash.  

Edited by senior_falcon, Fri Nov 3, 2017 9:47 PM.


#13 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Fri Nov 3, 2017 8:44 PM

 

Your CALL SOUND suggestion to force a delay was just what I needed in order to cause a delay to the CALL KEY "press any key" sub-routine when messages would be displayed on the screen. Without that, messages would more often than not disappear due to the next key press being read.

You shouldn't need a delay for "Press any Key"

5000 DISPLAY AT(24,2):"PRESS ANY KEY TO CONTINUE"
5020 CALL KEY(0,K,S):: IF S<1 THEN 5020
5030 DISPLAY SIZE(28)AT(19,1)::DISPLAY SIZE(28)AT(20,1)::DISPLAY SIZE(28)AT(24,1)
5040 RETURN 

S=1 only when a new key has been pressed.


Edited by senior_falcon, Fri Nov 3, 2017 9:50 PM.


#14 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Fri Nov 3, 2017 9:32 PM

You shouldn't need a delay for "Press any Key"

100 PRINT "Press any key..."  

110 CALL KEY(0,K,S)::IF S<1 THEN 110     s is only 1 when a new key is pressed.  If you hold a key down s will be -1

120 program goes on...

 

Wow! I guess when you're used to programming it a certain way, you overlook the simple stuff. Thanks for pointing this out!



#15 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Sun Nov 5, 2017 11:50 AM

There are definitely problems with ACCEPT, including one that you did not report.  Don't know how this slipped through my rigid quality assurance program, but somehow it did!  I will figure out what is going on and fix it.

 

 
 
I finally sorted out what happened with VALIDATE with ACCEPT.  It was all tested and working fine, but at some point I moved the workspaces into the scratchpad for more speed.  I also used a faster VMBW and VMBR that uses R5 and with the BLWPWS at >8320 this is >832A which the gpl line editor also uses.  VMBW and VMBR zero out R5 and that made it so ACCEPT fetched a null string.  Not fixed yet, but at least the problem is diagnosed.


#16 BassGuitari OFFLINE  

BassGuitari

    Launch Edition

  • 6,026 posts
  • Remember how bright the future used to look?
  • Location:Milwaukee, WI

Posted Sun Nov 5, 2017 12:02 PM

Sweet, I'll have to check this out. I enjoyed the MC-10 version, as well (one of Jim Gerrie's better games, IMO). :)



#17 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 2,613 posts
  • Location:Portland, Oregon USA

Posted Sun Nov 5, 2017 9:25 PM

Just for fun, I made it a cart/module for loading off flashrom/finalgrom/classic99 cart/burning to an eprom

 

icon_smile.gif

 

 

Attached Files


Edited by arcadeshopper, Sun Nov 5, 2017 9:25 PM.


#18 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Mon Nov 6, 2017 7:43 PM

Thanks to the feedback I received, I've gone back and tried to play-balance the game by increasing the difficulty and hopefully making it tougher to get to the final (8th) map. The biggest step in implementing this was to give the weapons and armor differing amounts of boosting power based on their qualities. So now a rusty dagger gives the least boost while a magic claymore provides the highest. Armor was done similarly. A few other tweaks were made to get it to what I feel may be just right.

 

I've also added a prompt to see if you truly want to go to the next map level when you get to that tile (the small H).

 

There are still issues with the ACCEPT AT command which sometimes results in it not accepting your input regardless of what you type. All I can say about that for now is to just keep typing either Y or N and it will eventually register, then press enter. It doesn't do it every time (seems to be about every 4th or 5th time), so it may be a tough bug for Harry to pin down. I can always change it to a call key in a future version, but I really like the ACCEPT AT command so I'm not giving up hope on getting it working properly.

 

I also fixed a few logical flaws that were in the first version of the game. I'm going to keep the first version available above, as it would be a fun version of the game for young kids of the early '80s :D or for someone just getting familiar with this style of game.

 

I have again included in the zip file below the compiled version (GRAIL-C), the Extended BASIC source (GRAILEB), and my "working" text file which I use to do the actual programming and then copy & paste into Classic 99.

 

Attached Files



#19 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Mon Nov 6, 2017 10:44 PM

 

There are still issues with the ACCEPT AT command which sometimes results in it not accepting your input regardless of what you type. All I can say about that for now is to just keep typing either Y or N and it will eventually register, then press enter. It doesn't do it every time (seems to be about every 4th or 5th time), so it may be a tough bug for Harry to pin down. I can always change it to a call key in a future version, but I really like the ACCEPT AT command so I'm not giving up hope on getting it working properly.

 

I think you would be fine if you eliminated the VALIDATE.  Thought I had it fixed but apparently not.  Back to square one.  There are several things that have to coexist.  Once I can get them to make peace with each other this will work.



#20 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Tue Nov 7, 2017 12:45 PM

I think you would be fine if you eliminated the VALIDATE.  Thought I had it fixed but apparently not.  Back to square one.  There are several things that have to coexist.  Once I can get them to make peace with each other this will work.

 

I'm not using VALIDATE but I am using SIZE(1). Here is what I am using for the newly added next level confirmation:

502 DISPLAY AT(19,1):"TAKE LADDER TO NEXT LEVEL?            (Y/N)"
504 ACCEPT AT(20,17)SIZE(1):N$
505 IF N$="Y" THEN 170
506 IF N$="N" THEN 509
508 GOTO 504
509 GOSUB 5030::GOTO 280

Is it possible there is a bug in the original TI programming of the ACCEPT command?



#21 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 2,613 posts
  • Location:Portland, Oregon USA

Posted Tue Nov 7, 2017 3:46 PM

Here's 1.1 as a module

 

Attached Files



#22 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Tue Nov 7, 2017 7:24 PM

Is it possible there is a bug in the original TI programming of the ACCEPT command?

Nope, I am the sole proprietor of this bug.  But it WILL be fixed soon.



#23 majestyx OFFLINE  

majestyx

    Chopper Commander

  • Topic Starter
  • 158 posts
  • Location:Port Carbon, Pennsylvania

Posted Thu Nov 16, 2017 8:02 AM

My job has been keeping me busy these past few weeks (I'm typing this at work... shhh! ). senior_falcon was kind enough to send me some replacement libraries for his compiler but I haven't yet had a chance to recompile and test the result. Once I do, I'll post an updated version which should eliminate that ACCEPT AT issue.



#24 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • 958 posts
  • Location:Lansing, NY, USA

Posted Thu Nov 16, 2017 8:53 AM

Well, as Oscar Wilde once said:  "Work is the curse of the drinking class."



#25 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 395 posts
  • Location:The Great White North

Posted Thu Nov 16, 2017 1:54 PM

Well, as Oscar Wilde once said:  "Work is the curse of the drinking class."

 

LOL!

 

And the proof of that is summed up in a statement made by my late uncle Dennis who once said:

 

      "You're never as think as some drunkle peep you are!"  







Also tagged with one or more of these keywords: rogue, roguelike, dungeon crawl

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users