Introduction:
During one of my team's earlier meetings, we decided to either create or iterate on a number of documents that would help us make Snowball Showdown more efficiently. These included the basic, normal documents that one expects from such a project - a systems document, a design document, and several lists of assets we would like to see in the game. While these were assigned to the other members of the team, I was given a far different assignment than I was used to.
This was the data document, a large spreadsheet full of variables relating to Snowball Showdown's technical design. This includes transform values for each object or prefab (position [if relevant], rotation, and scale), collider information (box, sphere, or both), rigidbody data, and any other relevant data. Such a document, we agreed, would be incredibly useful, since it allows designers an easy way to examine in-game values, such as those pertaining to the items players can put in snowballs. It also lets both them and programmers change values - especially weirder ones like colliders - without having to worry about losing the original numbers. Being a technical designer, I was very excited to dive into the game and document everything I could, so I opened Google Sheets and approached this task with gusto.
Documentation:
The data document is split into three main pages of spreadsheets. The first page contains values for the player, the second contains values for the snowball prefabs, and the third contains values for the scene in which gameplay takes place.
The "Player Data" page contains information for four objects. First, there is a row simply labelled "Data," which pertains to all aspects of the player character. It lists their starting position (relative to the fort), their starting rotation, their scale, and whether or not they contain any colliders. The other three rows are based on the player's head camera (and especially its position relative to the player) and each of their hands. This information should prove valuable if the designers or programmers ever need to examine the player in depth, such as if they want to fiddle with the player's colliders or mess with the player's camera.
The "Snowball Object Data" page is somewhat more in-depth, mostly because it also contains columns for the object's effect type, damage or damage modifier, description, and many pieces of data surrounding its rigidbody and the Newton VR plugin. Other pieces of information, including the transform and colliders, are also present.
The "Effect" column contains dropdowns that allow users to determine whether or not an object has no effect, a damage-boosting effect, a disruption effect, or a base-damaging effect. The "Damage / Damage Modifier" and "Description" columns are mainly for designers, allowing them to easily and efficiently define an object's power, which they can then pass on to the programmers for easier implementation. The other new columns are mainly for the programmers to keep track of any physics changes they make to the objects, especially in terms of mass or Newton VR data.
Lastly, the "Level Data" page is also in-depth, as it contains the same basic columns found on the "Snowball Objects Data" page. The two main differences lie in its "Type" and "Health" columns, which replace the snowballs' "Effect" and "Damage / Damage Modifier" columns. "Type" contains four options arranged in a dropdown menu: "environment" (the world in which the game takes place), "geometry" (a value or object that is directly related to the environment, but that does not qualify as the environment itself), "interactive" (an object the player can see and touch), and "player."
"Health" contains the amount of hits each object can take before they are either temporarily or permanently destroyed. If a row's "Health" value is blacked out, that means that players cannot destroy or interact with it under any circumstances.
After adding the last bits of information to the data document and ensuring that it was properly formatted, I informed the other members of my team of this and stepped away, preparing to make further edits in the future when we created new objects or decided upon more concrete data for values such as damage and health.