That's actually a cooler idea than what I was talking about.
My code "shakes the cup" until you tap a key.
But "hold down the key, and when you release it, then take the random
number" is an even better idea. I need to try that out. Much more
interactive. You can even use the old trick where you print "\", "|", "/",
"-" in sequence (with back spaces before each print!) while looping waiting
for the key to be released. That makes a spinning "busy" indicator. Look up
the ASCII code for backspace. Try this test program to get the idea
5 BS$=CHR$(8):CLS:PRINT"Waiting....";
10 FOR I=1TO4:PRINT BS$;MID$("/รต\-",I,1);:X=RND(1):NEXT I
20 IF INKEY$="" THEN 10
40 REM Now your randomizer is in a more random state
Unexpectedly, if you use i% or say DEFINT I first, the animation runs more
slowly, which might be useful to you.
I actually ran this program in VirtualT, so it should work.
Of course hack this up to work however makes the most sense to you. You
could put the INKEY$ test inside the FOR/NEXT loop, for instance.
On Tue, Jan 7, 2020 at 9:49 AM James Zeun <james.z...@gmail.com> wrote:
> Ok holding down a key to 'roll dice' is a genius idea.
>
> I understood a bit of that line, but I've delved in to keypresses etc. So
> this will be all new territory for me. But sounds exciting :-)
>
> On Tue, 7 Jan 2020, 3:27 pm Dan Higdon, <therealh...@gmail.com> wrote:
>
>> In my own random number based programs (for Traveller, not D&D, lol -
>> Traveller subsector generation is fun) I usually have a "busy loop" that
>> does something like D=RND(1) over and over until the user presses a key,
>> and then takes the next RND(1) value as my roll. This is the computer
>> equivalent of "shaking the dice cup", and lets the human's own reaction
>> times help with randomization.
>> Sort of like this:
>> 100 d=rnd(1): c=inkey$: if c=="" then 100
>> If you only want to wait for a keypress, you can of course do:
>> 100 d=rnd(1): if inkey$=="" then 100
>> I did a D&D (1e/2e) treasure table generator that used this trick. You'd
>> type the treasure code letter, and it would update the on-screen horde.
>> Space cleared the horde, ESC quite the program, and it "rattled the dice"
>> in a busy loop waiting for input. maybe not the most power efficient
>> program (not sure if ModelT "throttles down" while waiting for keyboard
>> interrupts or not), but it's easy to use. Takes a bit to load though,
>> because of the treasure tables. I didn't get to the point where it
>> enumerated the gems and magic items, nor do I have "Print a horde report"
>> working, since I don't have a ModelT compatible printer.
>>
>> On Tue, Jan 7, 2020 at 6:44 AM James Zeun <james.z...@gmail.com> wrote:
>>
>>> I already have a reasonable idea how the program should work.
>>>
>>> When run, it will ask the user the number of dice required. (Value A)
>>>
>>> Having established that value, the next INPUT shall be to determine the
>>> type of dice in play. (Value B)
>>>
>>> With those two values, I will either use the randomiser to roll the dice
>>> or if I can be a little fancy (as someone mentioned the randomiser isn't
>>> very random). I might have the computer wait for the user to tap the
>>> SPACEBAR or RETURN key twice. And use the time gap between the two as a
>>> value to use in the equation. (Value C)
>>>
>>> I'm utter rubbish at math, so I might have to trouble someone for a
>>> little help.
>>>
>>> An additional option would be to roll multiple dice of different types.
>>> So after inputting the value for one dice. The program asks the user if
>>> they'd like to add another.
>>>
>>>
>>>
>>> On Tue, 7 Jan 2020, 12:20 pm Charles Hudson, <clh...@gmail.com> wrote:
>>>
>>>> On January 6th James Zeun wrote:
>>>> "It would be even cooler on a TRS80 M100." I apologize for my
>>>> ignorance in that I know nothing about the D&D game, never having played
>>>> it, but I applaud your willingness to undertake the task. Programming
>>>> breaks down into two (usually sequential, but don't ever let yourself get
>>>> dragged into the argument) tasks: strategy and implementation. The
>>>> strategy, known as the "algorithm", is just the logical path ("steps") to
>>>> accomplish the desired end. Implementation is using a language's syntax
>>>> ("commands") to describe each step in sufficient detail such that the
>>>> computer can carry them out. If you're going to do this on the Model 100
>>>> the you probably will want to use the built-in BASIC programming language.
>>>> Hopefully you have the Model 100 manual, which has all of the syntax
>>>> detailed, including the RND function, which will be essential to your
>>>> implementation. Your strategy will be to determine /declare the number of
>>>> dice in play and the number of sides (range of values, if D&D dice differ
>>>> from the familiar 6-sided, dotted cube) on any given die, and then to
>>>> create a random value for each die in play that is within the domain of
>>>> legal possibilities for the game. Later you can expand the program to
>>>> display these values, but generating them is the first task. I know
>>>> I've seen this algorithm in one of my books - I like books, too - but when
>>>> I find it I'll post it.
>>>>
>>>> -CH-
>>>>
>>>
