Play In Editor

Document Summary: This document covers the Play In Editor feature.

Document Changelog: Created by Josh Adams.

Overview

Play In Editor (PIE) is a useful tool to quickly preview gameplay in a level while editing, but there are some things programmers will need to know about how the game world interacts with the editor world.

Using PIE

Starting PIE

There are 2 ways to initiate PIE:

• Select Play Level from the Build menu/click on the Play Level tool bar button
• Right-click in a perspective view, and select Play From Here

There is only one difference between the two. The first way will start the level in the editor using a standard player start (or however your gametype places the player) as the location of the player. The second method will place a teleporter actor in the map and then pass the name of the teleporter to the PIE game. The default implementation of GameInfo will spawn the player at the location of the teleporter (again, your game type can override this behavior).

Either method can be modified by holding the Control key when selecting PIE. If CTRL is pressed, the game will have ?spectator attached to game's URL.

Further, the string specified by the editor .ini setting, InEditorGameURLOptions, will be appended to the PIE game's URL.

Dropping Notes

While in PIE you can drop Note Actors at your current location, to help you remember areas to work on back in the editor. You use the dn console command (for Drop Note), followed by the string you want to assign to the note.

For example:

dn fix lighting here

Will create a Note Actor with your player's current location and rotation, with the text fix lighting here.

Ending PIE

When the user hits Escape in the PIE window (or types quit in the PIE console), the PIE window will close.

PIE Vs. Standalone

Here are some of the main differences between a game running in PIE and a game running standalone on the PC.

Garbage collection

When GIsEditor is set, garbage collection uses the old Serialization based method, instead of the new realtime GC method. See the GarbageCollection document for more information on the differences.

Async loading, level streaming

PIE does not handle level streaming. It loads all of the sublevels into memory.

Texture streaming, however, is performed in PIE.

Load flags

The load flags and functions (RF_LoadForClient, NeedsLoadForClient()), that specify to only load components and other objects in the editor, will act differently. SInce GIsEditor is true, different components may be around in the PIE world than in a standalone world.

Kismet

Kismet has a setting to disable links for PIE only. This was used in Gears of War to restrict teleporting the player to the level start (due to streaming between P maps in Gears, the PlayerStart actor wasn't really used for anything, and a teleport action was used). The teleport action would conflict with the Play From Here functionality, so the teleport action is disabled in PIE (orangle link color).

Performance

Performance testing should probably not be done in PIE as the game will definitely run slower. Not only is the editor still running and ticking away, and processing messages, etc, but any code that is disabled with "if (GIsEditor)" to speedup gameplay (because of validation that isn't needed at runtime, or whatever) will now be enabled. Usually such code has no side effects, it's just going to be slower.

Packages

Modifications to content in the editor will be reflected in the PIE world, even if the package has not been saved before running PIE. Similarly, when making level changes, the PIE world will reflect them, so if you don't like the changes, you can lose them by not saving the map in the editor (PIE saves the map to a temporary level file in the Autosaves directory).