Project Insensive's Post Mortem

We are a group of five students that are currently studying Game development in Sweden, Karlshamn. Our group was formed since we all shared the same interest in making a game for our last course.

For our final production course, the objective or the requirement so to say were the collaboration between students and external partners.

We all felt a bit of nervousness since this would put us in a new sort of pressure. Though, we all agree that it was certainly much needed, and should be a more common practice for students.

For our project, we were all interested in working together with Gameport (it’s an incubator that focuses on giving consultancy to game developers), since we didn’t have any prior experience with this sort of collaboration, we wanted to work together with people that were also interested in games and so would understand what we wanted from this project, but also so we could understand what they would want to see from us.

We knew that we were interested in making a game, but we didn’t speculate much further on what sort, since we first wanted to know what Gameport expected from us.

Our meeting with Gameport were pretty straightforward. What they wanted to see from us were a Devblog that was going to be updated continuously during the production, a Post mortem to be written at the end of the production and also to have our game showcased at Creative Coast Festival (Gameport’s own game event, with all sorts of speakers and cool stuff!).

When it came to the game we were going to create, they gave us pretty much free rein over the concept and development. Which to a student, it feels like Christmas.

We all feel a bit differently on how well it went with our brainstorming sessions. Some of us felt like it might’ve taken a bit too long on deciding the theme and core-concept for our game, while others expected that it would take the time it took.

Overall, the brainstorming sessions was a bit difficult. While we had small pieces of ideas, it was difficult to further develop the ideas into a more complete concept. After discussing it, we agreed that we should’ve maybe tried other ways of finding inspiration for our game, especially if it felt like we were stuck.

What we did was analysing games, researching them and using the whiteboard to write all sorts of ideas that came into mind, but maybe we should’ve tried activating ourselves by going outside or try looking into any other source of inspiration (listening to music, watching videos, etc.).

Although the brainstorming felt a bit bumpy, we still came up with an idea that we wanted to further develop.
 

Our concept was about a witch who could control the wind and thus be able to interact with the environment. We had different ideas on how this interaction would work. One of the ideas would have music and sound as main focus, we wanted the player to be able to use wind to interact with different objects in the environment and create music (imagine a big cave with holes, when wind blows through it would resemble a sort of instrument, like a flute).

The reason we couldn’t execute this idea was because we didn’t have anyone who could make music/sounds. Which is something we definitely should’ve prioritized and valued more in our game, even if the game concept wouldn’t specifically revolve around music.

Our other ideas were more focused on puzzle solving, like using parts in the environment to unlock more places or secrets.

We wanted the game’s aesthetics to be about feeling a sense of freedom, which is why we decided to have the world built on huge platforms up in the sky with clouds beneath them, so the player could only guess what might be down below. Then by exploiting the wind, the player would be able to glide to the next platforms/areas.

The witch also has the power to repel and attract objects. With this, the player would use that mechanic to either solve puzzles or interact with the environment.

When the concept had been decided, we started establishing how we wanted this production to be like, what engine and other tools we wanted to use and what we were expecting from each other.

We all agreed to try using HacknPlan for planning and time management, and for the Devblog we used Wordpress. Using both of these platforms were a new experience for us, which is part of why we feel like we should’ve utilized these better.

HacknPlan would be our way of seeing how much everyone had put the production hours into actual production, and if anything has taken longer than it should’ve had. Of course, it was difficult for everyone to estimate how many hours some of the work would take, but we wanted to use HacknPlan partly for getting better at time management and having “visual” control over the production.

But since we weren’t familiar with using HacknPlan and writing a Devblog, a lot of the production hours weren’t recorded and we felt that there should’ve been more posts on the blog.

Being able to establish and approximate the time for a production is vital. This is a lesson we’ll take with us and improve on our next project.

Being able to easily communicate between members in the group were important, so we decided to meet up every day at our college and work together in a project room. Even so, it was discussed beforehand that if anyone needed or wanted to, they should be able to work at home too. To make this easier for us, we set up ways of communication (Facebook, Skype, Slack and cell phones) and used the software versioning program SVN. This way, it became easy for everyone to contact one another and when it came to putting together the project it went faster thanks to SVN.

Even though it went quicker, it still weren’t without problems. Since most of us worked in different “test-projects”, problems could suddenly occur when putting the pieces together in the final product, even though there weren’t any problems in the test scenes.

Due to poor planning from our side, a lot of these problems revealed themselves close to our deadline (due to the time management), which were a bit problematic since we couldn’t create a build of our project. To solve this, we had to play the game directly from Unreal Engine using full screen mode. It wasn’t optimal, but a solution so we could at least showcase the game during Create Coast Festival.
 

When the production had reached its deadline, our group reviewed the outcome and there seemed to be different opinions about the result.

The prototype of the game as it is now, was what some of the members imagined that the end result would look like, while others thought the game would be more or less complete in the small area that the character navigates in.

Why did it end up being such different visions for the end result?

Along with the start of the production, we all went through various pictures that would be used as our moodboard (a set of pictures that share the same aesthetic which would work as a guideline for our game), we were all very keen on being on the same page and so held regular meetings to prevent miscommunication.

The game’s aesthetics were close to what we imagined, but maybe because we were so eager to get the right feeling for the game, we missed fundamental parts for the design. One could argue that our game is only a prototype and maybe that’s why the gameplay is a bit lacking. Even so, we should’ve together discussed the gameplay more thoroughly and had it in higher priority than the game’s aesthetics.