There are certain limitations in the builder, the emulator, and in the GPSr's themselves. This page describes the limitations that have been discussed in the forums -- and which appear to be reasonably well-founded.
Zones, Items, Characters, etc. Limited by Memory
Lackeys who should know have commented on the relatively small amount of memory available, particularly on the Garmin Colorado. Complex objects such as zones, characters and items are of particular concern. But all objects consume memory. There are no hard and fast upper limits on any given object. However, there are tradeoffs. If you define only a few items and characters, you can have more zones. If you define many, many items, you will be limited to fewer zones. Zone complexity is also a factor. The more points in a given zone, the more memory it takes. Finally, remember that all text (for example, descriptions) is also held in memory.
On the bright side, media (pictures and sounds) are not stored in active memory. The definition of the media object itself uses some memory, but it does not include the actual picture or sound file.
As a rough rule of thumb, the lackeys recommend using no more than 10 zones in a single cartridge. If you need more than that, break the cartridge into multiple episodes. It is best to plan for this in advance since various authors have reported problems while attempting wholesale surgery on an oversized cartridge.
The lackeys also report an absolute upper limit of roughly 65,000 bytes (16-bit address space for you propeller-heads) for object storage. However, they claim you will hit the device limits well before you hit this one.
Active Zones Limited by CPU Horsepower
Your GPSr is not a desktop (or a laptop -- or even a pocket calculator). And it does have other things to do besides run your game. Each time the player's position is updated, the engine must evaluate the player's relationship to all the //active// zones. The more active zones you have, and the more complex they are, the less likely the GPSr is to get everything done in time.
Fortunately, it is relatively easy to design your game so as to avoid problems. Notice that we said //active// zones. The engine does not bother to evaluate the player's position relative to inactive zones. So, if you inactivate the zones you don't need at the moment, you can avoid running short of CPU cycles.
Note well: Events associated with inactive zones do not fire. This means that you cannot use the player's proximity to an inactive zone to activate it!
Minimum Zone Size Limited by GPSr Accuracy
The shortest side of a rectangular zone should be at least 60 to 70 feet. Avoid zone shapes with long, narrow protrusions. The issue here is a combination of GPSr accuracy and small jumps in reported location. If your zone is too small, the player will have difficulty entering the zone. You cannot count on accuracy much better than about 20 feet. In addition, position jumps of 20 to 25 feet are not uncommon. One Colorado user has reported the need to stand still for several seconds at the center of a small zone in order to actually enter the zone. Obviously, this makes your cartridge difficult or impossible to play.
Acceptance Limited by Cartridge Size
Media are not stored in active memory. This does not give you license to go crazy with pictures and sound. Your entire cartridge gets downloaded to the GPSr. The GPSr will only hold so much. The bigger your cartridge, the fewer cartridges the player can download at once. And larger cartridges take longer to download from the Internet to the PC, and then from the PC to GPSr. The moral of the story is to make it attractive but don't go overboard. In addition, the wherigo.com site will not take a cartridge greater than around 20MB.