Joshua Coulter // NEX.exe Beta Devlog

Hello! 

This is Joshua from Team Fusion and this is my devlog regarding the beta phase of our game NEX.exe. Since our alpha phase, we have made some major design decisions to hone our project into a focused and well-structured vertical slice. One change that I would like to focus on became apparent to us through our first playtest session and we are now preparing a new build for our (nex)t playtest session this week.

---------------------------------------------------------------------------------------------------

The Design Decision

The biggest change our team made to the structure of Nex.exe during this phase was to remove the previous mechanic of player movement and object interaction and instead convert it to a fixed view of the computer screen. This was a change we had debated from the beginning with the idea that scope creep was very possible if we were to allow the player to explore the game world. With the computer mechanics being the primary focus of the game, bringing exploration/interaction and matching its engagement to the computer would come with a much larger workload. With this concern already present, it was quickly confirmed to shift to a more static game view once playtesting commenced. It became very clear that players expected to interact with the game world outside of the computer with the ability to walk around the room and this left them with much confusion when we revealed that the computer was the only interactable object (other than the bed to transition nights). It was very apparent that we could only keep the player movement in the game if we had a reason for the player to move in the first place. Though that was something we hoped to achieve near the start of production, we decided that it would be wise to avoid this scope creep and put all of our focus on the computer system, aligning with our intended experience of physiological horror and overall message regarding AI issues.

(Fig 1 - Main Menu)

Though this decision was simply to remove a feature, with it came a menu change that re-utilizes our current content well and encompasses the game setting creatively. Rather than having the player physically move around the in-game bedroom, we now use the game world within the start menu that uses the environment to display UI. This includes:

Play Button: On opening the game, the camera is displayed within the middle of the bedroom, showing the computer setting with the residential suburb background. On clicking "start game", the camera zooms to focus on the computer for the rest of the game.

Settings: Clicking on the setting menu, the camera turns the TV within the bedroom and displays the various settings options we will add atop the tv screen.

Quit: Clicking to the quit menu, the camera turns to the creaked open door of the bedroom, displaying the option to 'quit' the game upon clicking on the door.

(Fig 2 - Game Screen)

(Fig 3 - Settings Menu)

(Fig 4 - Quit Menu)

Additionally, the way of transitioning nights has changed from the player going to the in-game bed to now a power button on the computer itself that the player shuts off. This again was a small change that came with the removal of player movement and we feel it supports the game's focus being on the computer system.

(Fig 5 - Computer Power Button // Transitions to next day when emails complete + pressed or certain time passed )

---------------------------------------------------------------------------------------------------

Take Aways

Here are some aspects of game design that we as a team have taken away from just this one change. I feel that these takeaways are relevant for any game project you may be working on and can be applied to every part of a project.

Keeping Scope - One of the most prominent difficulties of game development is keeping scope relative to your timeline. This change acted as a reminder to my team and myself that it's easy to ideate mechanics and want to add them, even if they don't fit within your schedule or aren't relevant to your intended game experience. This removal of player movement allowed us to both avoid the large workload of adding more mechanics and avoid unnecessary aspects of the game that don't support the game's message as strongly as the core mechanic (Computer system).

Getting the Most out of Content - Another aspect of this change that can be very helpful is the awareness that you can utilize your existing content in multiple/different ways to get the most out of the time it took to develop, especially when making cuts. For us, we spent time modeling, implementing, and designing the gamespace of the player and when the decision to cut player movement was made, we felt we had lost content that we spent precious time creating. Despite this, we found a new way to utilize this existing content and what came from it was a new and satisfying menu that still features our hard work in a new way.

Keeping Focus - As I mentioned in the keeping scope takeaway, it's easy to get excited about adding new mechanics/content to your game. This change not only mitigated scope creep, but also allowed us to keep the focus of our game on the computer as it's the main mechanic that gets across the consequences of AI. Though we could further our message through different mechanics, with our time frame and the complexity that would come with the player exploring a physical world, it would be difficult to keep a focused experience with the variety of options the player has. By limiting them to the computer, we can enclose the experience to play out through the computer system and tailor it more closely to our game's focus on AI.

---------------------------------------------------------------------------------------------------

Thank you for taking the time to read this devlog! We will continue to share our progress in the near future and I am excited to show what my team is working on. Hopefully, you enjoyed hearing about our progress and learned something along the way!

Joshua Coulter 

Team Fusion