Jump to content

View more

Image of the Day

Working on an auto spawn system. #gamedev #indiedev #screenshotsaturday https://t.co/Mm2kfekz7b
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

goto considered harmful within global macros

4: Adsense
  • You cannot reply to this topic
21 replies to this topic

#21 wodinoneeye   Members   


Posted 31 October 2013 - 07:44 AM

It is simpler but also prone to errors that the do-while(false) method is isn't. The do-while(false) method requires a semicolon to work, while it is optional and can silently change the behavior of your code whether it is there or not with your variant.


I used to do it simpler...


#define CheckPrecondition(condition)  {  if ( ! condition) goto  ON_PRECONDITION_FAIL; }



Could have sworn I used to get that to work in a (native code) FSM macro simplified script language



But, I'd say that such hacks deserves some happy debugging times when they do change the behavior...


It was used within an all 'scripted' code block setting (FSMs for object behaviors)  where the rest of the mini-language macros were used of similar definitions (and were not interwoven with normal code).  That language statement  defines actually would look more like  :


#define PRECOND(CONDX)  {  if ( ! CONDX) goto  STATEX##PRECOND_FAIL; }


The more interesting  defines were for the FSM state wrappers to work within  a BIG SWITCH.   and the ones needed to break each behavior state into 3 seperately run  behavioral phases of the game loop.  There could be  competing tasks for each object state,  which required seperated out phase processing (by tasks and individual target factors)  : first - discovery via state-task specialized sensor searches and situation conditions, then second - a phase prioritizing the search results , picking a 'best' task and executing the corresponding actions for the task,   third  -  a  epilog phase which did evaluations and state transitions based on results.  


Much of the overall complexity came from having interacting objects be frozen for equal evaluation, and after priority selection  both objects being locked into an interaction mode (locking out other object's interactions and forcing wait time for the duration of the action (related to the animation time).


The whole thing was organized to be table form programming (but was compiled into native code).  It had shortcomings of only being able to handle rudimentary inter-object interactions and signalling before becoming cumbersome.  I had to shift more complex object AI  operations to a Planner type scheme (easier to handle interupted tasks when you just abandon and reevaluate everything and restart).  The original mechanism was retained for objects with  simple reactionary and single minded behaviors as it was more lightweight and was still used on a majority of objects in the simulation.



The script code using such macro statments were not nested (eliminated most of any problematic cases) and quite regular in the way they were used (and so easy to spot any syntax mistakes).    So there were few problems of that type.


The debugging fun was actually in the intricacies of the inter-object behavior interactions with follow-on sequential states for many tasks (I was considering building a wizard to help streamline the creation of the script 'code' data to handle alot of the table building 'bookkeeping'....)

Edited by wodinoneeye, 31 October 2013 - 08:32 AM.

--------------------------------------------Ratings are Opinion, not Fact

#22 Oberon_Command   Members   


Posted 04 November 2013 - 03:07 PM

The code in the original post smells to me like something written by someone used to "classic" Visual Basic.