Why

The final course on the bachelor program at DSV we had 10 weeks divided over 20 weeks to create a game demo.

What did we want to achieve

We wanted to create a humorous point and click with a lot of inspiration from the classic adventure gamesreleased by Sierra.

Game description

Motts Adventures is a humorous point and click adventure game in a full 3D world. The protagonist of the game is a henchman who is striving to find his master by using potions to transform himself to exotic forms.

My role

The team started with nine students, eight from DSV that were divided equally with four graphical designers and four programmers, the last member was a student from the royal musical academy. At the end of the project one programmer left the group for personal reasons. The story group consisted of four persons and after the dropout only three. I had the role of story lead and programmer. It is hard to say exactly what code I have done since we used SCRUM and almost everyone of the programmers have been changing all code, but the dialogue tool that is created as a external program used for writing dialogue that later is imported into the game was made by me and Karl, this was my personal goal for the course. Same is for the story the concept was my idea but almost everything that you can see in the game has been brainstormed by the story group. I have been involved with all dialogues and most of the things Mott says when he is examining objects.

Choice of game engine

The three suggestions that we decided amongst was XNA, UDK and Unity. All of the team had tried out UDK more or less before the course, two persons(me included) had experience with C# that can be used both in XNA and Unity. We finally decided that we did not want to use UDK since we believed that it is not as good for a fixed camera third person view that we wanted. We also did not want to use XNA since the scope would be to big and we thought that Unity would be a good experience if we want to work in the indie market after our education. Since two of us were experienced in C# and really likes it we decided to make all Scripts using C#.

Description of work process

We started to have meetings almost six months before the project started and made detailed instruction on how we would work and the way we will implement the project. When the project started up we started using scrum with two weeks sprints(halftime).

What problems did we encounter and what did we do to solve them

During the ten weeks we encountered a lot of problems, the biggest one to the project in my opinion is the problems we had the first weeks when we tried to merge the code and the graphics after each sprint. This made all the small problems to emerge at the same time, making it a hard and time consuming chore. We then decided to export the whole project each time a team member had updated it and then the next one who needed the “live project” he or she could import it, the new problem was that the export took almost 10 minutes and the import almost 20 minutes when this adds up it is much time that goes to waste so we started to have the live project up and running on one computer letting the one who needs to implement new assets use it. This is not perfect but the best solution we could figure out. A big problem when we developed our dialogue tool was to make it compatible with the game, we started out by exporting the data in XML but got trouble, because we had a data structure where a “Speech”class could have another “Speech” as a class member and that could go on in circles so some dialogue could lead back to the main hub as we called it. This made a recursive loop making it impossible. Our quick fix was to change all the references to strings that were the same as a unique identifier at the “Speech” instance. But after we implemented this we felt that there become to much unnecessary searching and decided on another approach, we saved it as a binary file and loaded that into the game solving our problems.

What went bad

This was the first time I’ve been in a group as big as this and worked on a project and this made it hard to predict how much we could produce and the quality of it. Making the game end up a lot smaller then I hoped it would be.

What went good

A great process and good cooperation from all members made it a fun project to work on. Trying out SCRUM was a great experience and I learned much from the extreme programming we had. Overall it feels like a fine crafted game but within a very small scope.

Credits:
Mikael Lyck - Story lead / Programming
Karl Dahlgren - Project lead / Sound lead / Programming
Sofia Häggvik - Design / Story
Aleksandar Jankovic - Programming
Tomas Jonsson - Music
Erika Skoglund Kling - Design
Zebastian Lilja - Design lead
Camilla Nyberg - Design / Story
Frank Wennerdahl - Programming lead