An Edit Instance of an area is always the #0 instance. Any changes made to the Area are persisted to the database as they are made. This saved version becomes the template for any future Play Instances of the Area, because the edits will be saved to the Repository.
The Edit Instance's sole purpose is for world-building. It is not a good idea to do gameplay testing in an Edit Instance, is there is any change that the play might affect anything that would be improper to persist to the database. Gameplay testing can be done in an Edit Instance, but it is not recommended.
To tell if you are in an edit instance or not, look at the bottom right-hand corner of the HeroBlade screen. Next to the area name, it will either have a number in parentheses, or the word "(EDIT)".
To further distinguish, an Edit Instance will always be displayed in a blue box. Play instances will instead be beige.
A play instance will have the instance number in parentheses next to it.
An edit instance will say (EDIT) next to it.
In most cases, an area will not have both play and edit instances open at the same time. However, HeroEngine does allow for this type of development, but it may require some careful scripting to deal with potential conflicts. This is because any changes made to the edit instance will not be propagated to a play instance, until the next time that a player enters that instance, and then the new information will only be available to the newly-entered player, and not to any players that were in the instance prior to the change. This may cause some confusion if not properly handled.
- Say that players Peter, Paul, and Patricia are all in Play instance #72, of a desert.
- GameMaster George is working on the desert's edit instance at the same time, and adds a volcano in the middle of the area.
- Peter, Paul, and Patricia will not see the volcano, because they were in the area before George started working on it.
- If Peter logs off, and then back on, his system will receive the newest .dat files. Or in other words, he will now see the volcano, but Paul and Patricia, who never left the area, still will not see it.
If your team desires to do this kind of development routinely, one way to handle it is to "force" area updates via HSL. In the above example, a script could be triggered via RemoteCall in all appropriate play instances, to say, "Add a volcano." Then, all players in that area would see it at the same time.
Keep in mind that, in general, this affects only your development servers. Ultimately all editing will be done there, and published to your testing and live servers. The primary use for play instances on your development servers is for testing and sandbox experimentation.
The technical description of how the area server stores its representation of the area geometry is found on the Area Node Structure page.