a simple game/dialog platform and a debug bug!

[MisterX]

Hi everyone,

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!
(Fingers crossed!)

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
stopped working! 

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

on mouseup
  put 5 into fld "Lives"
  creategame
end mouseup

on creategame
  <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
end creategame

script of field 1

on returninfield
  enterinfield
end returninfield

on enterinfield
  get me
  put empty into me
  if it is goodanswer() then
    answer "Great!"
    put empty into me
    send "creategame" to btn 1  << wont trigger the debugger
  else
    subtract 1 from fld "lives"
    answer "Booh"
    if fld "lives" > 0 then 
      send "creategame" to btn 1
    else
      answer "Game over"
    end if
end enterfield

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
be cool!)

The script is greatly simplified for simplicity - high scores, timers,
levels, scores, bonuses, effects and audio etc can be added anywhere needed
for games)... 

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
me! 

Thanks, cheers and hava bugless weekend!
Xavier
--
MonsieurX.com - Not just a load of stacks!