Recap Week 02

This is a post for my course at University. It's a long post analyzing a shorter game that the Eucroma group created last week, and why the game wasn't finished. Just so you know. :)

- We spent the last week working on a shorter project that would be finished on Thursday. The project was to create a smaller game that would be playable by the end of the week. The intention of doing a project over 4 days was to test the pipeline and the group. We would hopefully be able to see where problems would arise in a more controlled setting, and bring those lessons with us into the big project.

Everyone who wanted to was involved in the process of creating the idea. The goal was to at least create a simple game; if we had the time we would also create a trailer for the game. As I wanted to focus on a personal project and didn’t care too much about what type of game we would make, I chose to not involve myself too much in the beginning phase.

We chose to keep the concept phase short. Within the first day we had an idea for a game and designs for the two main characters. The rest of the time was spent on production of the assets needed for the game.

The tools I needed to start my work on the game (animation) involved two other people – the modeller and the rigger. The modeller created the character from the designs our Production Designer made. When that was done, the rigger received the character and created a so-called skeleton for it. The character that the modeller created will then act as a skin on the skeleton, as with a real human being.

This also involved a lot of communicating. Even though I couldn’t actually start animating until I had a character with a skeleton, I could give feedback on the process of the character creation. At this time I also communicated with the programmers. They knew what kind of animations they needed for the game to look believable. In our case the game involved throwing and getting hit by various instruments, and so we needed characters that looked like they are doing so.

In a perfect world, this would have been a fast and smooth process. But as we, after all, are a group of people from around Europe that has never worked together before, there were a lot of problems that arose once we were in production.

 - The most important problem was that there was no direction. As with any kind of bigger group that needs to produce something, whether it is a game, orchestra or basketball team, you need someone to organize the effort. It could be a coach, conductor, or in this case a Game Designer (from now known as GD). The GD has an overview of the progression of the game, and makes sure that the end product is something that’s enjoyable to play. (this is a very simplified version of the role)

In this short project we didn’t have a GD, or any other kind of leading role. This was due to the fact that the leading group (GD, Producers, Production Designer and Animation Director) spent almost all of their time in meetings concerning the main project. Specifically the universe that is to be created for it.

One of many consequences of this was that the programmers had to take focus away from their main task and take decisions that the GD should have been responsible for. Among many things they had to design how you actually play the game. This process was very rushed because the programmers still had to do the actual programming, so a lot of bad decisions were taken.

Simply put, since no one had taken direction of the general direction and experience of the game, it wasn't something that could engage the player. In the first play-through of the game we realised that it wasn't very fun to play at all. As a result the programmers had to throw away everything they had done so far and create a completely new game. Something that should have been avoided with a clear direction from the beginning.

- The creative team also experienced a lot of turbulence. Since we are very dependent on each other’s work, it’s important that we share the same vision about how the end product should look. If a few people think that we are making an apple, and some other people think that we are making a banana, then there’s going to be a lot of confusion in the communication within the team.

One way to avoid this would have been to have a central point of information about the concept. This source of information could for example be a Style Guide, Wiki-page, etc. It would be updated with info and clarifications for different aspects as problems and questions arise.

There was a lack of direction in the creative team as well. The Production Designer who designed the characters weren’t available enough to answer all of the questions, and no one had an oversight of the process. I had no way of knowing if the file I received was approved for the next step in the process, because there was no one there to approve it.

In the end the project never got finished. We had a lot of finished assets, but the game as a whole wasn’t playable. There were a lot of smaller issues as well, but I believe that the two issues I’ve described above are the causes of project being unfinished.

If you have read this far, I would really appreciate if you left a comment on how easy/hard it was to understand. I’m trying to keep my language open so that non-game production people can read it too, so please point out for me if there are any passages or words that are confusing. Thank you!

2 kommentarer:

  1. I think you have made a very good and clear analyse of the process. And that is the first step to not make the same mistake again.
    Personally I would want more details, but it's very nice that you have written it in a language that is understandable even if you are not in on the animation business.
    Very interesting read, keep posting like this!!
    /Maria Sandberg

  2. Jag fattade det mesta... ;)