Uncategorized – Red Owl Games

Scouting Game Camp

Niels de Jong — Thu, 15 Aug 2019 19:14:28 +0000

The Scouting Game Camp application is a short interactive level select screen. It was part of a themed activity week for children.

Project

Approach

Use a MoSCoW-style planning to make sure the most important elements are present when the camp starts.

Decided on making it possible to manually fill in information before going to a public state that would be shown to the children. This way, it cost the camp organizers more time to set up the program, but it also gave them more flexibility in how to use it.

Result / Evaluation

Working application with the main elements functional: a character that walks towards a current level in a level-overview screen and certain skills that have an “increase” animation

Application became embedded in the camp’s culture. The children had built little rituals around the application, which was used to start and end their activities for the day

Description

Key design decision

Making the design choice to have users fill in all the required information before it the application could be shown to the children.

This saved development time, which was our scarcest resource. The flipside of this choice was that the camp organizers needed to do a bit more preparation work. However, this also gave them the flexibility to tweak scores when necessary.

Process

We started off by interviewing our contact person at the camp about what they wanted help with. Based on this, we formulated a Minimum Viable Product (MVP), as well as things that would be nice to have, but not absolutely essential.

This MVP proved to be instrumental, as we had very little time available to actually work on the project. (all three project members had other deadlines as well) Because we had prioritized different features upfront, we were able to finish something without having to update the design much.

We worked together with the camp organizers, one of whom voice-acted the transitions in the application.

We were invited to join the camp for half a day, so we could see the application while it was being used.

Project Role

Niels de Jong – design, programming

Melissa Tammens – 3d character modelling & animation

Esmeé van ‘t Hoff – 2d art, contact person

Project Duration

4 weeks (2 weeks actual project time)

26^th of June 2017 – 2^nd of July 2017

16^th of July 2017 – 21^st of July 2017

The camp took place from the 22^nd to the 29^th of July 2017

Play time

3~5 minutes

Haunted House

Niels de Jong — Fri, 06 Jan 2017 14:23:52 +0000

Haunted House is a bad 3D puzzle platformer. It has an interesting project and design process.

Project

Approach

Heavy focus on why the things that are designed are the way they are, looking for the arguments to support a design

Learn to work with and from another dedicated designer in the team

Try to establish what is wrong with the team, how I can function within the team and how we are going to get a sufficient end result with that team, and how to prevent these situations in the future

Result / Evaluation

extensive use of design models such as the Quality, Frequency, Clarity model for mechanics

major improvement in supporting designs with reasons why you would make a certain decision (or not)

fascinating to see how different people with a design background approach design when compared to people without this background

learned the importance of establishing everyone’s intentions early on

gained some experience working with audio

Description

This is definitely the most interesting process I’ve experienced so far. It hasn’t necessarily resulted in the most interesting product, however.

In this project we worked together with students from the Utrecht University. In an early phase of the project, we struggled to form our ideas into coherent concepts. Everyone seemingly wanted to do something else. When we did agree on something, we ran into the same problem as soon as we started specifying details. Looking backwards, I’d say the main problem here was a discrepancy in design knowledge. I was grounded in more than a year of design ‘thinking’, and did not realise others might not have that same knowledge and thus would look on design in a very, very different way.

Anyway. In the project it gradually became clear every decision could be reverted if it did not fit someone’s vision. This forced me to look for the reasons why a certain decision was important, so I could counter attempts coming from personal likings or dislikings of certain decisions. I started looking for arguments and relationships that would support a design choice. Additionally, I reconstructed our decisions made so far to be able to show and tell why exactly we did something, and why going in another direction now was a good or bad idea when taking the previous decisions into consideration.

So we worked on an elaborate design, looking for relationships, tuning our ideas to fit an experience. This was a great experience as a designer. Unfortunately, there was a) too little time to fully implement the design and b) we still had a dysfunctional team, with the one building our game unwilling to make changes, presumably afraid we would lose what we already had. Still, it was a great learning experience. Looking back I would have forced a conflict early in the project, to make clear what intentions everyone has and to look for opportunities to continue the project in a different way.

In the final two weeks I mainly focused on adding audio for the game, to create a richer experience.

This way of supporting your design for arguments and relationships is something I apply in other projects now as well. A possible negative side-effect of this approach is that it can seem like everything is set in stone to other team members, because you can answer almost every why-question related to design.