Team TBD developers' log

This post is a continuation of a previous blog entry.  Our MVP featured clickable, animated switches, but they were not "wired together." This meant there was no way to create a win state or any meaningful interaction! Without interaction, there is no game. Cool XOR gate, but what now? I thought it might be overwhelming to have every single Switch object report its Ready status via an event to the GameManager. Even from the perspective of the cockpit theme, it makes more sense to compartmentalize vehicle functions into different control blocks. In our design document, we brainstormed some of these compartmental functions: Start the reactor (necessary) Concept: Getting powered up Execution: Result: It is necessary to start the reactor before the ship can do anything at all. This is likely the first step a player will always have to perform in order to proceed with the other challenges Defeat the warning alarm (optional) Concept: “car alarm” Execution: Result: By d...

When I first started thinking about translating a switch into code, I did not map out every method, inheritance, relationship, and try to think of every consideration. This was likely not Best Practice(tm), so why did I just do what every noob does and start writing code? Because I am a noob coder. There is an important interdisciplinary principle which is that you don't know what you don't know, and when you learn something that you didn't know, you learn many new somethings that you do not know. So, rather than me get on this blog and try to talk big about my planning, I want to be transparent and discuss my inefficient and laborious process to building a code base that so far is working. First, a little aside. I view coding as nothing different than learning a language that computers speak -- that is, listen to. Whereas German is a language that humans speak and listen to, C# is a language that processors register with the help of an interpreter. So yes, it...

The MVP should be a litmus test for scope and primary mechanic. If your game won't be fun until "all the features" are implemented, then we can likely assume your game won't be fun at all. If your primary mechanic is not compelling, then we can likewise assume that the fully featured game won't be compelling, or the primary mechanic may get sidelined for something more interesting to the player. We decided that our MVP should include a switch that can be operated, and a timer. At its core, the gameplay will be clicking switches in a race against time. This made conceptualizing our MVP fairly straightforward. When we play-tested our MVP, it was incomplete. The timer had not been incorporated into the shared scene, and while the switches could be interacted with, they did nothing. There was no win or lose condition. There was no tutorial, and no real direction as to what to do. It was minimum. Was it viable? Looking at the player feedback from play-tester...

You know how in some movies, the heroes are running away from the bad guys? Then they all jump into a parked space ship, run up to the cockpit, and start purposefully and rapidly flicking switches to get the thing to start up and blast off? Well, I want to make a game about that. This was my elevator pitch for this project. I always wondered what all those controls did . It's easy to assume that in fantasy sci-fi movies, they're just part of the set. Yet, even in modern commercial airplanes, the cockpit looks futuristic and overwhelming. Is it part of a pilot's training to know what every control does, and when to use them? Is this why you'd need a co-pilot, so in case you don't know or can't reach, maybe they would be able to help? For a game, it seemed like there might be interesting questions to explore. If the player is thrust into a foreign cockpit, can they figure out how to get the ship to fly? What about if they're under time pressure like ...