Initially, I was just fooling around, creating code snippets to see how it all may fit together. Quick, dirty hacks you know.
But somehow things got more and more refined and today I was able to test my little two-word #textadventure #game #parser by walking between two rooms.
Written using #gforth but also works with #dxforth on #cpm80
Back to some code exercises. Technically, you could write a #textadventure game in #Forth using the dictionary and the command prompt. I've seen at least one code snippet following such an approach.
However, I want a "classic" #parser (e.g. TAKE SWORD) and make sure it keeps the user "fenced" inside the game engine.
This means I need arrays of strings to provide lists of words the parser can check the user input against.
So here is some basic research on how to accomplish this in #gforth (also works with #dxforth)
It sounds simple but I had to tackle a very annoying and naughty bug. But hey:
A)bort L)ist S)ave now works after entering the message
Here are the latest news regading my #TMSnake #game for #rc2014 and #TMS9918a #graphics.
The video below shows the current state of affairs, and I've just added some limited #sfx to the game - however the recording below did not capture the beepy beeps for some reason.
There is one last tweak I need to add in terms of gameplay but the final release is "coming soon" β’οΈ π
+++ Important information for all DX Forth users +++
There is a #new #release v4.60 available for CP/M and DOS since january 7th, 2025 !!
Get it here:
https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw
Update on #dxbbs which now allows the user to enter multiple lines of text until enter is pressed on an empty line.
The text is stored in a temporary ASCII file, line by line. This will later allow for additional line editing before saving - at least that is what I plan to do.
The final message is appened to the message base file and a new index record is written as can be seen in the screenshots.
For those of you who are interested in my latest project, #dxbbs you may like to know that I've done some code cleanup, renamed existing variables and introduced new ones, especially for the message base files. this is in preparation of handling multiple message bases.
I've also implemented "message flagging/unflagging" in combination with the msg_purge routine. The latter takes some time to process all messages since it actually creates a re-indexd copy of all files for the selected message base.
So I thought it would make sense to "flag" messages for deletion, effectively excluding these from being listed or read and then have the option to physically delete them and re-arrange the message file during a maintenance window, where there is enough planned downtime for such an action.
Let me note that the code is by no means an example for proper #forth programming. I'm not there yet, but in case you are interested, here's the link:
https://gitlab.com/ufud-org/rc2014-dxforth/-/tree/main/bbs?ref_type=heads
if you are interested in the various drivers and programs I've so far written in #DXForth for the #rc2014 computer running the CP/M #cpm operating system, I'd like to remind you of the code repo I've put up recently. Documentation is rare, to say the least. But all the code is there:
... another update on the progress with DX BBS. Today, I've updated the input routine so that it is now capable of:
1.) input length limitation ( it is not possible to enter more than 'n' characters, halting cursor movement at 'n')
and
2.) a basic mechanism of "hiding" the input instead of echoing it
these two features are implemented in one #Forth word which ( in the example screenshot ) is being called like this:
#16 #1 bbs_input | Stack: ( ulen uhide -- )
so you can enter a max of 16 chars and these will be "hidden". It's a more basic routine similar to "instr()" in #RBBS4. I use the return stack to store the length and hide-flag which works since the loops in the word definition are *not* counted (do..loop). Boy do I feel clever ... heh ... π
Wintermute_BBS