Seams - Week 1

This is start of a (hopefully) weekly development blog on a new video game project that I'll currently refer to as 'Project PsychWard'. Our first day started with forming a team for the project. Our team ended comprising of 9 people: 5 designers (with some of them also being able to fill artist roles), two musicians, one dedicated artist and myself as the team's programmer. The rest of the day was spent deciding the general theme and gameplay.

Initial Team Meeting

To my understanding, the designers decided on a top-down puzzle/horror game that takes place in a psychiatric ward. There were brief mentions of a day/night system in which you would explore the area during the day and hide from unimaginable horrors during the night. Admittedly I wasn't paying too much attention to their discussion, my priorities were mostly with finding out what sort of systems I would need to program for the game.

By the end of the day, we set out the final roles on the team, as well as set each other an assignment for the week to present to the team on the following friday.

(The final makeup of the team)

(Our main objectives for this week)

Learning the Input System

I got started with my assignment in the following days after by creating the Unity project for the game. It is currently not on Github but in the coming weeks I will make sure to host it on there for the rest of the team to access. The first task I gave myself was to have 8 directional player movement. Now there are two ways that I can immediately think of to achieve that. The easiest way of implementing it would be to just copy the movement code of one of my older projects. Not only would this just be really lazy, it would mean using the older default input system in Unity. What I decided to do instead is utilise Unity's newer input system.

I did have to relearn how to make user inputs, but what this means in the long-term is that I will be able to cleanly create new user controls for both the game itself and hopefully the UI (though I have yet to look into that) but also it should mean that controller support will be significantly easier to implement.

(Input system UI, from here I can create new actions and from the User Input component on an object i can assign a function to the action)

Setting up Transitions

The second part of my assignment for this week was to try and get transitions working. The objective here was to make it so that an animation can play between loading/sending the player to different locations. This was achieved by making a script in which someone can select a destination object and an animation controller, the game will run the animation, then wait a specified amount of time until it teleports the player object to the previously mentioned destination and then plays an exit animation.

I think it works well for the most part but there are problems with it. As it stands the script is fairly hard-coded, and any new transitions would need to follow the same structure (pictured below) where the object has a "transition_enter" animation and a "transition_exit" animation, with them being controlled by a bool parameter called "active"

Additionally, with the way it is coded, the code will begin to wait the moment the enter animation starts, so anyone working with that would need to keep that in mind and make the "transitionTimer" float slightly longer than the animation itself.

(The code snippet I just talked about)

Despite all of that, I think that the end result works well for now and likely wont need any change once more of the game has been coded. Have a look at how it looks so far with the attached video:

That's about everything that's happened this week. Around the time this blog post will be uploaded we will be having our second team meeting to discuss everyone's progress and next objectives.