Dealing with zone boundary issues

[+Geofellas]

As I get a bit more experience with both designing and playing these cartridges I have noticed a number of problem situations that all seem to come back to having a player prematurely leaving a zone accidentally.

 

Some of these issues are:

• Items or characters disappearing
  
• Messages getting overwritten
  
• Cartridge crashes
  

I believe that many of these issues can be explained by the phenomenon of people prematurely leaving a zone. This is, of course exacerbated when the zone is small and there is flaky GPS reception - so you could "leave" the zone even without moving. You could continually leave and re-enter - and I believe that is what was happening to me today causing the cartridge I was playing to crash. (In this case, on entry I was presented with an input request that I could not cancel, and I wandered around over quite an area looking for the data to enter - I'm sure I left and re-entered a number of times). This kind of behaviour will cause OnExit and OnEntry events to fire and if they do so repeatedly all kinds of problems could arise including stack overflow, resulting in a crash (which is what I think happened to me today).

 

I had thought at first that having larger zones might fix this so in my first published cartridge I made all the zones pretty large. but I failed to account for the human nature that causes people to stop moving immediately they enter the zone, rather than moving to the middle of it (in retrospect this is obvious - they have no idea where the middle is or how big the zone is!!). I had a player lose some useful (but not vital fortunately) information because he stopped right on the boundary of a large zone. He then wondered why he couldn't see the characters that should have been (and were according to his log file) in the zone.

 

Having pondered all these situations I have come up with what I think might be a rather simple solution. It can't be completely done in the Builder, a very small amount of lua code editing is required.

 

I would appreciate people's input on its efficacy.

 

In the attached game which you can open in the builder and run in the emulator, I have created a target zone (active and visible) and, surounding it, a larger zone (inactive and invisible). On entering the target zone I simply change its boundaries to those of the larger zone, thereby giving the player much more freedom to move around and the GPS much more freedom to wander a bit without firing the OnExit event. When the player does eventually leave the (now expanded) zone, its OnExit event shrinks its boundaries back to the original size.

 

(For the programming purists, the larger zone is not actually needed, I could just have coded the coordinates by hand, but it was easier to use the builder to create it and it also makes for a better display when you run it in the emulator. I would probably refactor any code I ended up actually using in a published cartridge)

 

When you play this in the emulator you will see that the display of the zones does not change to reflect the changed boundaries but that seems to be a feature (bug?) of the emulator itself since the other behaviour (e.g. the "Item" being visible") does conform to what I would expect.

 

Try playing this moving the character in and out of the inner and the outer zones and see what you think.

 

This seems a very simple approach and I would be interested in comments.

 

I plan to test this out live with the Colorado tomorrow and if it is effective I will incorporate it into my published cache.

 

Zone_Expansion.zip

Edited September 7, 2008 by Geofellas

[+Audion64]

I haven't actually downloaded and tried the cart (I will be for sure though) but this sounds like a very workable 'work-around' to the zone boundary 'in-out' problem.

 

I would say that just programming the coordinates to change rather than creating extra larger pseudo zones would be better just in the sense that there is less burden put on the processor calculating zones which aren't actually being used.

 

Looking forward to testing out your idea!

[+Geofellas]

I would say that just programming the coordinates to change rather than creating extra larger pseudo zones would be better just in the sense that there is less burden put on the processor calculating zones which aren't actually being used.

Yes - it is certainly a more elegant programming approach although I am not certain there would be any significant overhead other than a tiny bit of memory consumption as long as the zone is never made active or visible.

 

Attached is an example of doing this. In order to get the emulator to display the effects of this approach I found it was necessary to make the zone invisible then immediately visible again as part of the OnEntry and OnExit events. This would not, of course, be necessary or desirable in a published cartridge but is a useful technique to demonstrate the behaviour.

 

Zone_Expansion___refactored.zip

[+Audion64]

Ah, silly me, I missed the part about leaving the larger zone inactive. Which makes perfect sense and doesn't add processor load, just a tiny amount of memory usage as you mentioned.

Edited September 7, 2008 by Audion