majestyx Posted November 3, 2017 Share Posted November 3, 2017 (edited) 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/forums/topic/157876-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.blogspot.ca/2013/01/grail-of-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. Latest version available in this post: http://atariage.com/forums/topic/271679-grail-of-the-gods-a-rogue-like-game-in-compiled-xb/?p=3922022 GrailOfTheGods-TI-XB.zip Edited January 5, 2018 by majestyx 8 Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted November 3, 2017 Share Posted November 3, 2017 Nicely done! 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 3, 2017 Share Posted November 3, 2017 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/ Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 3, 2017 Author Share Posted November 3, 2017 (edited) 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 November 3, 2017 by majestyx 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted November 3, 2017 Share Posted November 3, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 3, 2017 Share Posted November 3, 2017 Thanks for the feedback! I will be looking at these issues and hopefully will be able to fix them. 1 Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 3, 2017 Author Share Posted November 3, 2017 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. Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 3, 2017 Share Posted November 3, 2017 (edited) 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 Greg PS: I can totally see putting this on a cartridge once you feel it's "complete" Edited November 3, 2017 by arcadeshopper 1 Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 3, 2017 Author Share Posted November 3, 2017 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 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! 2 Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 3, 2017 Author Share Posted November 3, 2017 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. Quote Link to comment Share on other sites More sharing options...
Asmusr Posted November 3, 2017 Share Posted November 3, 2017 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. 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 4, 2017 Share Posted November 4, 2017 (edited) 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),:: 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 November 4, 2017 by senior_falcon Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 4, 2017 Share Posted November 4, 2017 (edited) 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 November 4, 2017 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 4, 2017 Author Share Posted November 4, 2017 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! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 5, 2017 Share Posted November 5, 2017 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. 5 1 Quote Link to comment Share on other sites More sharing options...
BassGuitari Posted November 5, 2017 Share Posted November 5, 2017 Sweet, I'll have to check this out. I enjoyed the MC-10 version, as well (one of Jim Gerrie's better games, IMO). Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 6, 2017 Share Posted November 6, 2017 (edited) Just for fun, I made it a cart/module for loading off flashrom/finalgrom/classic99 cart/burning to an eprom GRAIL8.bin Edited November 6, 2017 by arcadeshopper 3 Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 7, 2017 Author Share Posted November 7, 2017 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 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. GrailOfTheGods-TI-XB-v1.1.zip 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 7, 2017 Share Posted November 7, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 7, 2017 Author Share Posted November 7, 2017 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? 1 Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted November 7, 2017 Share Posted November 7, 2017 Here's 1.1 as a module Grail_1.132K8.bin 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 8, 2017 Share Posted November 8, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
majestyx Posted November 16, 2017 Author Share Posted November 16, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted November 16, 2017 Share Posted November 16, 2017 Well, as Oscar Wilde once said: "Work is the curse of the drinking class." Quote Link to comment Share on other sites More sharing options...
+TheBF Posted November 16, 2017 Share Posted November 16, 2017 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!" Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.