Gameplay Cycle

The main focus of this week’s BurntOut development was to create a functional, healthy, well-rounded gameplay experience that incorporated all the main elements proposed in the design document.

The cycle has various win/lose conditions that impact the end result. We have added some testing content to rooms C, D and E to further test the complete cycle using 5 scenarios. The structure is very flexible and can be expanded to incorporate any other additional content that we should add to the gameplay in the future.

With a door model available, “locked door mechanics” in the patient rooms were able to be put in. This forces players to complete the tasks inside each room before attempting to progress to the next scenario, which in return increases the chances of the player interacting with the Replenishment Room.

Increasing Player Engagement

The other focus of this week was to start incorporating features to the gameplay that would increase the player’s engagement. Adding rewarding visuals to completed tasks is a step in the right direction, so we added animated stars to reflect win/loss conditions.

We also added various UI elements that encourage the player to perform a particular task, such as replenishing their energy. Additionally, transitions between certain interactions have been added in the form of a screen fade.

Level Design Tweaks

The level design was also expanded, and the layout tweaked, so that the rooms are structured more logically.

  • Added the exit door at the end of the “Hall”
  • Updated textures of various models
  • Imported new models
  • Created “Ceiling Unit” with new lights and ceiling model
  • Played a lot with lighting baked/realtime/lightmaps

A Scalable Editor

Last blog, we briefly mentioned some issues with font sizes in custom Unity editors. Unity’s default font size in editors is “11”, which is actually akin to a font size of 9 in a typical word processor. (Unity includes the pixels at the bottom of letters like ‘p’ and ‘q’, while most programs omit these pixels from their font size calculations.) This is fine for basic editor data, but our project includes a lot of dialogue and text, which could span multiple sentences. The small font makes editing larger blocks of text much more inconvenient, so we had a need to allow the relevant editor window to be easily scaled up.

We ran into a lot of trouble along the way. Unfortunately, changing Unity’s font sizes in their editor styles wasn’t enough to fix the issue. We had been using the EditorGUILayout class for most of my controls, but its controls don’t properly scale with the font. This left a lot of text cut off in the middle. A fix seemed to be using EditorGUI and manually pass in rectangles with a greater height.

Getting that height was a bit tricky, particularly for TextAreas with word-wrap, as Unity would give incorrect values for widths every other call. To fix this, we managed to store the width between calls for TextAreas, to make sure it wasn’t stuck with a width of 1. It is a bit messy having to deal with another variable for each, but it works.

This issue seemed to stem from the weird way Unity handles the editor. Unlike an object-oriented UI, Unity opts to initialize controls on the same line you get their value from. This results in a strange mapping of a new control call to the respective control that’s already on the screen behind the scenes. It seems like OnGUI is executed differently every other call. I’d suspect one call is mapping controls, and the other is updating variables based on the new values.

Honestly, if the Unity editor UI was just object-oriented, this would be so much easier. It should potentially be possible to implement a UI system that is practically OO. Although a bit more work, with enough dependency on complex custom editors, it could be worth it.

You can read more about the BurntOut game at its website and follow along with our development on the blogs.