Unity Gameplay Tooling Upgrades and Backend Database Standardization

Database Table Tags

Our tooling is just a bit smarter this week (but much more usable). Take a look–

Only database tables with “gameplay_physical” tag shows up in the spawn-here menus.

Beyond the ability to click-around and change our unit spawn position, the developer’s options for spawning entities into the physical game world are now much more constrained (and sensible). “Props”, “Items”, and “units”– the three database tables (spreadsheet sheets) that appear have been marked with the “gameplay_physical” tag–

A sheet itself can have metadata associated with it now via “tags”, which is a comma-separated list of strings in cell B2, near the table / sheet title.

These tags can be used to provide metadata for an entire table full of entities. The “gameplay_physical” tag is used to indicate a table of entities that could exist physically in the gameplay world. Tags like this could be used for other things too however.

The new API for grabbing these tags is ultra simple–

Simply specify what sheet you want, and you’ll get all of the unique tags for that sheet. The immediate use-case, as described above, is to eliminate certain classes entities (or rows of certain tables) from consideration in things like menus.

Database Standardization

Within different tables of our database (units table, items table, towers table, etc), there is often quite a bit of overlap and simularity between the entities in each table. For instance, the “units” table has a column / property for “display_name”, but so to does the “items” table–

This was not the case this time last week. Standardizing our table columns (every table should have an “id” column, “display_name” column, “description” column, etc) should allow us to write more general code, as currently each table is handled by a unique class in our codebase. If we can guarantee that each table has an “id” column, for instance, we can simplify our logic, thus reducing the possibility for bugs. In other words, in areas where our entities are similar, the same pieces of logic should process them.

A potential use case is in debug menus. If we can guarantee that every row across several tables will contain a “description” and “display_name” (and maybe even “icon”), we can create very generic and re-usable menus that display the icon and display name of each entity across theset tables (and put the description into a tooltip).

New Affordance : “AffAddComponent”

A powerful new affordance was created this week– the “AffAddComponent” affordance is a debug-only affordance that allows us to add any component in our codebase to any gameobject we click on. While not very user-friendly (yet) due to the long list of components we have, it has some powerful and far-ranging uses–

This random goose unit doesn’t care about the player, until we add the “ShouldFollowUserDirection” component.

Should we ever need a wall, we can add it by simply adding an “IsSolid” component.

Once we make this easier to use (likely by adding a search-bar to the top of the component menu), we will be able to quickly edit what components any unit, tower, or item has. This should allow us to iterate quickly, testing different combinations of components without reloading the stage or writing custom code.

Tooling Integration

Instead of using an external tool, or even launching a separate scene, the Gameplay Testbed and Editor mode is now integrated into the game from its mode select–

Our debug / content creation modes may now be accessed from the mode select

…But only in development builds. There is reason to be nervous about this “improvement”, as it isn’t very hard to imagine a member of the team accidently pushing a development build out to the world (at which point this special functionality would be freely accessible), but fortunately our automated build system does not allow dev builds to be uploaded. Automating the upload process takes human error out of it (well, to an extent. It increases the amount of effort and investment needed for a human to mess things up).

Subscribe to Future Devblogs!

Subscribe here to be notified when we publish future devblogs, tutorials, etc.