Team TBD developers' log

Posts

Designing the story narrative

This is not a story-driven game. Then again, neither was Bad Dudes for the original Nintendo. What's important is to provide some context for the player's actions. With some older games, many elements of the story had to be brought by the imagination of the players. Yes, obviously The "problem" with this type of arcade-level story is that it is inadequate for me on a personal level. I want compelling stories in games. I think the best games I've ever played have depth of lore and true value to exploration and discovery. So I wanted to at least include open-ended elements in this game's design where the player could imagine where the game would take them. So we typecast the player as a StarJacker -- the title of the game -- conjuring up 1980s retro-futurist glory (with main title art in the works). We put the player in the direct controller position, so he/she is not telling another character to move, but they themselves are operating the cockpi...

Designing and coding the in-level transitions

What do you think is happening at the end of the level? This is one of the questions we asked our players following the second in-class play-test event. For this version of the game, once the player successfully unlocked and pressed the launch button, they would see the following screen: Nearly every response included some variation of this sentiment: I have no idea. This was not exactly the sentiment I was going for in the level design. It's clear that something needed to be implemented to support the story, as thin as it is. The players did seem to remember the story pitch ("you are stealing a space ship") well enough to try to help answer this question with their own imagination. Yet, that wasn't going to cut it. After unlocking and pressing launch, we needed to communicate at least a few things: That the level was completed successfully That the player achieved his/her story goal of escaping with the ship That not all ships were the same every ...

Designing and coding the SwitchBlocks

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...

Designing and coding the switches

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...

Designing the MVP

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...

Initial commit

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 ...