Brian's dev process and take-aways

Title: An Inconvenient Death

An Inconvenient Death is a game made in collaboration with Evan and Chris for the “Circuit Stream Game Jam - Fall 2023” which ran from November 20th 2023 to November 26th 2023 and followed the theme of “Inconvenient Superpowers”. We ended up winning first place in the judge vote that was held after a discord stream where they played all the games (LinkedIn post here). It is heavily inspired by the Hitman series in both level objectives and level design. Our goal was to create a few levels that would allow the player to explore an interesting area and use a variety of powers to witness fun/interesting game moments. This was the first Game Jam for all three of us and was a great learning experience in operating as a team and under extreme time constraints.

Brainstorming:

Before the theme of the Game Jam was revealed we met as a team in order to share our current experience in game development and our interests in gaming. I felt that it would help a lot to start the event with a strong understanding of our shared interests and the breadth of our abilities. It ended up helping to streamline the initial brainstorming process as we were able to focus our conversation towards ideas that we all have a stronger connection to.

After the theme was released we used Figma to organize our planning efforts. Each of us contributed an idea of what we thought a good game would be that could follow the theme. When deciding which game to pursue the main factors that we considered were:

1. How easy it would be to produce a vertical slice
2. How simple we could start and the room to make it more complex
3. How fun and interesting it would be to actually work on
   1. One of the main motivations for participating for each of us was to expand our development skills and learn about the design process; the competition was generally secondary. 

After we settled on the Hitman-like game idea, our next step was to create a list of the features that we considered mandatory for the game to work and discussed which we thought would need to be done in what order. At this point we started using Trello to create and organize the tasks into To-Do, Doing, and Done. Each of us picked a few tasks that we were interested in to begin working with the understanding that as issues or ideas came up we could add new tickets to the list.

The last step of our concentrated brainstorming was to plan out the first couple levels that we wanted to present. The main discussion here was what Superpowers we thought users would find interesting or fun, or how we could turn Superpowers into a spectacle.  We also wanted to lay some groundwork by giving a general direction for the setting of the level, though this was somewhat secondary and more dictated by the assets that we had available.

Responsibilities and Challenges:

I was responsible for programming and implementing the power system that the player would be using. This involved creating data structures to store and utilize the information required to access them in game as well as setting up the controls and UI for them.  I used raycasting and tags on game objects to determine if the player was looking at an appropriate target. If they were within range and the target could be acted on then I activated UI messaging to let the player know that they could interact. 

My initial implementation of the raycast resulted in a ray that jittered and would often change angle or look through the intended object, but this was fixed with a quick google search and a utilization of the FixedUpdate method. 

It was important to me that the player was always acutely aware that they were allowed to do something and also that they received immediate feedback after their action to let them know that it worked. I found that just having a message for the player was a little more subtle, so I experimented with highlighting the interactable object (in addition to the UI message). I found that this made it much easier to tell when the player was able to interact. I created specific animations and imported sounds that activate after a power interaction to let the player know that the action has completed successfully.

In a similar theme of ensuring that information is clearly communicated to the player, I created the super power toolbar to let the player choose which power they wanted to activate. I wanted to build our game tools to allow for more expansion beyond what we had planned, so there are more spaces available on the toolbar than what we actually make use of.

 I found that it was an unexpectedly complicated question to decide how to populate the player’s toolbar for each level. It felt that there should be a better way than just initializing a new array with the properties for each level, but I wasn’t really certain what that would be. Ultimately, if we restrict which powers can be used per level, then there does need to be some level configuration somewhere, so I suppose having a set of the powers available would work just fine.

In the second level I created the sequence of the clouds coalescing and darkening, the ambient light darkening, and the lightning strike which electrifies the pool and fries the NPC. This involved using the animator for the cloud position and color as well as the global lighting. I also found some electricity assets and lightning sounds to use for the lightning strike as well as to make it clear the pool was now electrified. I even ended up creating a smoke emission for the NPC to show their successful elimination.

This was a really interesting sequence to work on as the way each of the elements has to activate in sequence to get it feeling right almost seems like a cutscene even though the player still has control of their character and camera. After working on it I can understand why the player’s control is taken away in similar situations. One, perhaps the sequence isn’t actually rendered in the same engine or is pre-rendered. Or two, you just want the player to see the cool thing you made! After seeing how the sequence came together I really wanted people to appreciate all the little parts of it.

When I was working on the electricity code I made the decision to make it a little more general in the hope that we could use it in a possible level three at some point. I included this “isWet” check that was greatly inspired by Hitman and the ability to assassinate targets by electrocuting them as long as they are on a wet surface. Ultimately I think this just led to needless complexity as there is no way to move our NPCs out of their routes, and the NPCs that can be electrocuted are always in that state. However, I still think that my tendency to try to make the code more abstract so that it can be applied more broadly is a boon. I just need to know when it is realistic and when it is better to just write something that is just a one-off.

Takeaways:

Before An Inconvenient Death, I had only worked on gaming projects alone. Despite the fact that I have been working on software dev teams for 5 years, this was a supremely different experience. I found working in a game dev team to be so much easier than solo work in numerous ways. When communicating with the team I am forced to voice my ideas and perspective which forces me to organize and contextualize my thoughts. Actively voicing the ideas in my head can put the ideas into a new light (either making me more confident in them or showing me the problems). Even more importantly, I get to hear the thoughts and opinions of my teammates who have perspectives that I would otherwise never see.

I think my favorite part of the team work was just getting to listen to my teammates’ opinions and thoughts on games and game development. It was really fun to listen and learn about where other people derive value from games and what features they find important. Evan and Chris helped me so much in iterating on ideas that I thought were great, but ended up only being half-baked.

I also had some more design focused takeaways. I think all games should have a pause/menu that needs to include the ability to exit the game. Asking your player to alt-f4 or use task manager to quit the game feels really bad. It’s funny how much I took that for granted until I was testing our game and couldn’t pause it! In a similar vein, a settings page provides a surprising amount of agency for the player. Perhaps, this is more specific to me, but not having the ability to mess with volume levels or key bindings was surprisingly stifling. I can understand that not all games need this, but I really like being able to customize my experience to a degree.