Hell's Halls - TI BASIC Cassette Game Dungeon Crawl Project

[+pixelpedant]

Here's a preview of something I've been working on recently.  It's a dungeon adventure developed with the following parameters: 

 

Language: TI BASIC (no machine code jailbreak)

Requirements: Unexpanded TI-99.  Currently also loadable via disk, but this is not a requirement, and offers no advantage.

Medium: TI BASIC via Cassette or Type-In.  Currently also compatible with XB, but this is not a requirement, and is not well tested.

 

 

 

Very unfinished.  Still needs content development.  But the engine's pretty much figured out.  How dungeon level generation works, and all that.  The intro, which is really an elaborate ruse to distract the player with shiny objects while it loads a huge pile of character patterns and colorsets and all that.  But as I say, far from finished.  I'll distribute code once I've cleaned it up, finished all the core content and made the comments coherent and what have you.

 

Edit: Uploaded an updated gameplay video, due to a bugfix

 

[+arcadeshopper]

https://c.tenor.com/lIRFDhFPvzEAAAAM/damn-good-job-matt-berry.gif

Sent from my Pixel 6 Pro using Tapatalk

[GDMike]

It's nice throw it through the xb compiler to make it faster.

[+arcadeshopper]

It's nice throw it through the xb compiler to make it faster.

The design is to run it in TI Basic. That's the experiment to see how much he could get out of it in that low memory low speed model. It's very impressive gameplay considering..

Sent from my Pixel 6 Pro using Tapatalk

[+pixelpedant]

Indeed, that's it alright.

 

For my part, this project is all about squeezing everything possible out of TI BASIC. 

 

So when I do finish it and distribute code, I'm fine with folks compiling it, or running it in XB, or what have you. 

 

But for my own purposes, this is 100% about what I can cram into a 16K TI BASIC cassette game, while still managing to get playable performance.

 

How (and whether) it can run by other means is not an immediate concern.

[jrhodes]

Looks very promising ?

[eebuckeye]

This looks terrific!! Very nice!

[GDMike]

Very nice BASICly.really cool

[+Vorticon]

Very nice indeed. Love the creaking door sound effect. This is the kind of detail that elevates a game beyond the obvious limitations of the platform.

[senior_falcon]

It seems as if the sounds have some decay-i.e. they progressively get softer. Am I imagining this?

[+RXB]

18 hours ago, pixelpedant said:

Indeed, that's it alright.

 

For my part, this project is all about squeezing everything possible out of TI BASIC. 

 

So when I do finish it and distribute code, I'm fine with folks compiling it, or running it in XB, or what have you. 

 

But for my own purposes, this is 100% about what I can cram into a 16K TI BASIC cassette game, while still managing to get playable performance.

 

How (and whether) it can run by other means is not an immediate concern.

Impressive and runs from Cassette and that is backwards compatible along with minimalistic.

[+pixelpedant]

2 hours ago, senior_falcon said:

It seems as if the sounds have some decay-i.e. they progressively get softer. Am I imagining this?

This is true, yes.  My approach to music is as follows:

 

All musical elements are stored as strings like this one for the title music:

 

9150 DATA "]WN]WNIWN>:IN"

 

These are played by the following subroutine with a GOSUB to 7400 or 7410 depending on whether I use DATA or just set N$ to a desired value.

 

7400 READ N$
7410 FOR X=1 TO LEN(N$)
7420 TN=ASC(SEG$(N$,X,1))*2
7430 FOR V=1 TO 13 STEP 6
7440 CALL SOUND(-450,TN,V,TN+1,V,TN*2,V)
7450 NEXT V
7460 NEXT X
7470 RETURN

 

This routine multiplies the ASCII value of each character by two to derive a frequency between 110Hz and 254Hz. 

 

The routine then plays on the three tone generators, respectively,

 

1) The given frequency

2) A frequency detuned by 1Hz (upwards) 

3) A frequency twice the given one (one octave above)

 

Which I find to have a desirable effect.

 

Meanwhile, it loops through attenuation values of 1, 7 and 13 (duration negative, so as quick as it can manage) and sustains a short while longer on the last loop (as nothing interrupts that one).

 

In the end, it's called CALL SOUND 39 times, with 273 input values, all based on a 13 byte string, in the case of the title music.

 

In all, it is meant to achieve a harpsichord-like effect.  Which I think it does, to the extent that such a thing is possible in TI BASIC via CALL SOUND on a TMS9919.

 

 

[senior_falcon]

Very nice effect on the sound. That is way better than the usual beeps and honks.

 

 

[broettger]

I like it!   An impressive start for a “simple” TI BASIC game that can run on the base system!  Way better than the run of the mill type in games back in the day.

[+dhe]

A 9 pin dot matrix printer and some sandwich bags and your in business!

 

Very Impressive PixelPedant.

[Willsy]

This is great! I watched the whole video and was disappointed when it ended! I like the sense of humour too... There's a somewhat British feel to it 

[Tursi]

On 6/1/2022 at 2:44 PM, pixelpedant said:

Here's a preview of something I've been working on recently.  It's a dungeon adventure developed with the following parameters: 

 

Language: TI BASIC (no machine code jailbreak)

Requirements: Unexpanded TI-99.  Currently also loadable via disk, but this is not a requirement, and offers no advantage.

Medium: TI BASIC via Cassette or Type-In.  Currently also compatible with XB, but this is not a requirement, and is not well tested.

 

Very unfinished.  Still needs content development.  But the engine's pretty much figured out.  How dungeon level generation works, and all that.  The intro, which is really an elaborate ruse to distract the player with shiny objects while it loads a huge pile of character patterns and colorsets and all that.  But as I say, far from finished.  I'll distribute code once I've cleaned it up, finished all the core content and made the comments coherent and what have you.

 

Edit: Uploaded an updated gameplay video, due to a bugfix

 

Just got a look at this - that's insanely impressive.

 

[+pixelpedant]

Thanks! 

 

I need to stop obsessing over the music subroutine.  I've been messing around seeing what other instrumental effects I can provide for (within the constraints of TI BASIC's performance limitations, obviously). 

 

And it seems to me that in a perfect world, I would just treat the ASCII values in which my music is recorded as representing successive notes on the chromatic scale, and calculate their frequency based on distance (in semitones) from the lowest supported note.  Which in this case would be G1, 49Hz, as this is roughly the lowest frequency which I feel I can acceptably reproduce with a mix of periodic noise and overtones from the tone generators. 

 

However, that extra work just slows things down too much. 

 

The alternative, in which the ASCII value is just multiplied by 2 to derive a frequency is a tad imprecise.  But it's fast enough to work in TI BASIC.  So I shall satisfy myself with it.  Because making things work in BASIC is the point here, after all.

 

[tmop69]

@pixelpedant are you using floating point math in the game? Just to see if could be compiled once finished. ? 

[Tursi]

3 hours ago, pixelpedant said:

I need to stop obsessing over the music subroutine.  I've been messing around seeing what other instrumental effects I can provide for (within the constraints of TI BASIC's performance limitations, obviously). 

It sounds great, I don't think I'd worry about it. And the presentation is fantastic, it does not even need a "for TI BASIC" disclaimer. Had I actually typed this in back in the day, my jaw would have been on the floor.

 

Definitely picked up a couple of techniques watching it run

 

[+pixelpedant]

9 hours ago, tmop69 said:

@pixelpedant are you using floating point math in the game? Just to see if could be compiled once finished. ? 

It does to a certain extent, yes, since it does a lot of random number generation (one thing TI BASIC is pretty fast at).  And almost never uses INT() in the process, since it would just slow things down a bit unnecessarily. 

 

Even when feeding randomised values to commands accepting what are inherently integer values (like a pattern number or colour), they're sometimes calculated with floating point math.  As commands tend to happily accept floats, as everything is one regardless. 

 

So, say, CALL HCHAR will happily execute the following absurdity:

 

CALL HCHAR(4.81432, 4.8492, 33.3333+7/3, 40.7)

 

And this leads to insanity like wanting a screen location to have a 1/3 chance of being one tile, and a 2/3 chance of being another, such that this is achieved as follows:

 

CALL HCHAR(Y,X,32+RND*1.5)

 

[+pixelpedant]

If you'd like to hear more about this project (but more generally, my thoughts on TI BASIC cassette game development strategy arising from it), I've got a video up on it which goes into a lot more detail:

 

 

[WhataKowinkydink]

I'll check that out next vid or two :)

[senior_falcon]

Very nice video! (As usual)

I liked the way you combined the ASCII with the pattern data. That is a really clever trick. It looks like the quotes are not necessary.

For what it is worth, it is possible to make one string define 4 or even 6 characters. To redefine ABCD you could have DATA A16bytesforA16bytesforB16bytesforC16bytesforD   

Without the quotes,you can fit enough data for 6 character definitions into 1 line using the BASIC editor

You could have 4 characters per data statement your way x 3 lines or 6 characters per line this new way x 2 lines

Both could define 12 characters but with my way you save 46 bytes. (Actually it would be a little less because you can fit enough for 5 characters per line your way.)

I haven't worked out how much extra code would be needed to extract a DATA statement like this, so whether it is useful will depend on how many characters you are defining.

Food for thought-you have probably thought of this already.

Unless you are a purist about this, you can use XB to enter additional characters into a DATA statement, save it in XB, and Basic will read it fine. Or better yet, you can use a text editor and use "Paste XB" in classic99. Seems to work fine in Basic.

[+pixelpedant]

Indeed, I'm just doing what is possible directly using the TI BASIC editor, since a lot of this is motivated by the fact that there was a time when that was all I had, and so I'm motivated to explore the limits of what was possible in principle with TI BASIC and cassette.  Dubiously possible in practice though, since so much of this is based on knowledge which was not available to me (or to most people), at the time. 

 

As far as concatenating DATA statements, your point about omitting quotes is well taken.

 

As far as concatenating patterns, though, it would be a revision on two fronts.  Firstly, in that I omit trailing zeroes in the majority of them at present, and secondly, in that I load them in groups of varying size (dictated by length of intended/acceptable pause), interleaved with other data, so they are

 

1) Of variable individual length

and

2) Of varying "group" size 

 

There is, however, surely an argument for loading pattern strings as concatenated 16 character (untruncated) strings, still in groups of whatever desired length, and simply inferring the length of the group (i.e., how many patterns it contains) based on the length of the concatenated string.  That option might be worth exploring when next I run out of memory.