Joshua Coulter // NEX.exe Alpha Devlog

Preparing for Playtests

To summarize this development phase for our team, I would say we have succeeded in staying focused on our goals and dividing ourselves into our respective roles to prepare for our first official playtest session. We were able to accomplish our goal of creating a playtest build by breaking it down into the necessary tasks that make up our core game loop. This allowed us to limit our scope to the functionality needed and will allow us to specifically playtest its usability.

Jira Playtest Build Tasks (in-engine)

My personal role during this process was to program the rest of the core loop functionality to a usable state. This involved collaborating with another programmer to script the rest of the email system with its corresponding file system, populating the computer tabs that the player will interact with. Putting my focus solely on the technical side of the build, I communicated often with my team members to ensure they knew where the build was and what to expect when it came to implementing other aspects into the project.  The tasks in-engine were split up between me and another team member to 

How did we do it?

As a reminder, this core gameplay loop consists of the following to complete a 'quest':

• Opening/Reading an email
• Opening/Reading the corresponding file sent to you
• Finding the intended keyword(s)
• Reply to the email with the correct keyword(s)

I wanted the process of populating content for the game to be as intuitive as possible to make it easier to evolve the system as development continues and to help other team members work in engine. I started by attempting to visualize how this system would function and that made it much easier when it came to scripting. With my team, we landed on using these visualizations alongside scriptable objects to make a system that is easily customizable and flexible.

System Structure Visualization Diagram

I decided to go with version B for the game loop as it lets us instantiate both emails and files respectivly but then their content is pulled from a single scriptable object. This way, we ensure each email has its corresponding file (displays the necessary keyword) and that when members implement the final written content, each 'quest' has its information organized inside a scriptable object.

Scriptable objects: 

These are objects that let you save a lot of data in one place and personally, they have been very helpful when customizing specific data in the inspector. If you are working on a project that deals with many systems needing data from one another, I highly recommend scriptable objects to keep your project not only efficient at calling required data but also for setting up systems such as ours, that will have other teammates interacting with it.

 (Structure of scriptable object data)

Vertical Layout Groups :

As for how this content is being populated on screen, emails and files are listed neatly using a Unity feature called Vertical Layout Groups. This is another feature that proved to be very useful when it comes to displaying UI. It essentially uses children UI elements and organizes them in a neat list based on certain settings. For each email and file, they are instantiated to respective layouts, placing them in a list that will update based on certain interactions. For example, when an email is deleted, the list condenses accordingly and if an email is added, it will go to the bottom of the list. This is another feature that I would recommend using when dealing with UI elements, particularly when creating lists.

 (Our use of vertical layout groups to list emails)