a simple game/dialog platform and a debug bug!
b.xavier at internet.lu
Sat Jan 15 00:17:04 CST 2005
I've finished my very first Game in my scripting history! I can't believe
it! 3 months to think how to do it, preparing the stack prototype, conjuring
mega options and variations in design, but only 15 minutes scripting time to
write it all down and have it work! ok, it still ugly but the proof of
concept works as expected in the final version!
I wont tell you the concept yet but it is extremely fun and definitely
educational for all ages and occasions too! Actually it might be a new
tetris like game and a great justification for computer games in education!
I've layed down a most basic game template for those who want to try to make
a simple game with RunRev. I think the approach is simple enough for any
occasion including creating custom dialog windows...
But while using the object way of sending messages to controls the debugger
Has anyone encountered the same situation where the debugger is no longuer
triggered on a breakpoint if the handler is called via "send handlername to
control x" command? The breakpoint is triggered via the left hand side
bullet breakpoint field.
Here's the basic game (or dialog) calling loop and the script structure with
the nonworking breakpoint
script of button 1
put 5 into fld "Lives"
<advance game level script>
(breakpoint) put thisvalue into thisotherone
-- works the first time only when called by mouseup
<draw game script>
select line 1 of fld 1
script of field 1
put empty into me
if it is goodanswer() then
put empty into me
send "creategame" to btn 1 << wont trigger the debugger
subtract 1 from fld "lives"
if fld "lives" > 0 then
send "creategame" to btn 1
answer "Game over"
For the game setup, it's a "new game" button and an answer field in a card.
You can add anything else al gusto to make the game's display you need...
Since the code from a level to another can be quite different I might clone
the cards to make new variations while keeping the same simple code. Some
code like score tracking and timers might be moved to the background script
or the stack script. When a game level is finished, you draw the curtains,
go next card, open curtains and voila!
To adapt this to a custom dialog, the button or calling script sends the
script to a substack which does the setup you want (a list or a table or
graphics to choose from for example) and the field script is a field or
button in the card of the dialog substack that traps the rest of the
messages to answer the button or come back to it (creategame or another
handler in the calling stack). A good example is interactive dialogs that
show progress (there is one in my free Script Editor X for MC2.5 at
monsieurx.com for example).
Danger: This method can make for messagini code (similar to spaghetti code
but using send instead of goto/gosub/function over calling.) So careful
planning and as simple as possible design are recommended. Avoid sending
messages from script that got a message sent to it or it might lock up or
get lost at some point... (But if we could create threads this way, it would
The script is greatly simplified for simplicity - high scores, timers,
levels, scores, bonuses, effects and audio etc can be added anywhere needed
Regarding the breakpoint bug, if anyone entered a similar bug into bugzilla,
I'll add comments and votes, either way it's one more trip to bugzilla for
Thanks, cheers and hava bugless weekend!
MonsieurX.com - Not just a load of stacks!
More information about the use-livecode