Pitching “Treasure Monkeys” #2: The horror of unpredictability!

I found an unpredicted problem!

I am still working on the pitch for “Treasure Monkeys”. After reworking my Game Overview Document, I reworked my feature breakdown, asset list and feature matrix. I also did some scribbles to visualize the dialog system. And while I did this, I realized that I had overseen something! As you know, I plan to implement a customizable character. I also plan to show the character in different situations (when finding a treasure / finding no treasure). And of course, animations would be nice. But until now, I did not think about how this would be implemented! In the prototype, I worked with static placeholder pictures. I always had the dialog system of “Professor Layton” in mind. (Characters have different poses and facial expressions, sometimes also animations.) And when I made the list of the art assets I plan for the characters, I realized that:

  1. either the artist had to draw all the customizable clothes and accessoires multiple times to fit all the poses (which is insane and would probably oversize the app), OR
  2. my customizable main character could only have one pose, but several facial expressions (like it is done in the Advance Wars game series), OR
  3. I would need an animation tool which animates the character and it’s attached accessoires, OR
  4. I would have to cut the personalizable main character.

What will I do? I have not decided yet. I am currently researching 2D animation tools for Unity.

layton_pandora_example

In the “Professor Layton” series, the characters have several poses, gestures and facial expressions. But they are not customizable.

Why are unpredicted problems horrifying?

Unpredicted problems are very common in game development. And if the problem is big or brings it’s friends, it can have desastrous effects. And with desastrous effects I mean: it will need more time, respective more money. The later a problem is identified, the more costly it is, because:

  1. If there is already an existing game, the solution for the problem has to be integrated, which means rework.
  2. During production, more people are working on the project. Delay means that all of them have to be paid longer than predicted. Perhaps more people have to be hired, because your current staff lacks knowledge or time to handle the problem.
  3. If the problem is found very late in the development process, it may delay the publishing date.

I am currently working on my own, so no one else’s time, money and nerves are wasted. It is only MY problem, and when I have resolved it, it is no problem anymore, but more knowledge about the game.

How to predict (and solve) problems early?

There are different strategies to predict problems early. Of course, you can never predict all, but the more you can get, the better it is for your project (and your nerves).

Mock Ups and/or Paper Prototyping

Mock Ups and/or Paper Prototypes are great for visualizing how you plan to implement a feature or feature complex. If you don’t have time, at least do some scribbles. Paper Prototyping does not work well for every game. You can also use toys to visualize the game scene.

20150529_115151

I did some research on dialog systems of “Advance Wars” and “Professor Layton” and made some scribbles about how the dialogs in “Treasure Monkey” could be presented. (Let’s Play Videos are extremely helpful when it comes to research!)

 Talk to Experts

Talk to the experts (= dudes and dudettes who have experience with working on games) you hired or plan to hire. Also talk to the experts you are friends with. And if you don’t know anyone, search for groups or forums (e.g. on LinkedIn or XING). Most developers I know are happy to share their knowledge. Because I live together with a great artist, I always have someone to talk about art related questions.

Feature Breakdown, Asset List and Feature Matrix

Break down your features and make estimates about the scope to create first rough asset lists. Don’t worry, they will never be perfect. But they will help you to talk to the experts and to estimate the costs.

feature_breakdown_example

An exemplary view into my feature break down. Because I am better and faster with my native language and I do not have to show it to someone else, it is written in german.

A great tool for estimating the complexity of features is the feature matrix. With the feature matrix, you can detect and examine dependencies of features.

feature_matrix_example

An exemplary view into my feature matrix. Here I check the influence of each feature on every other feature. I could have predicted the animation / pose problem here, but I did not, although I wrote it down. No tool is a guarantee for success, you still have to think yourself ;)

Gameplay Prototyping

The best solution is doing one or several gameplay prototypes. But also the gameplay prototype can not show you all problems. (Because I only used static pictures in my prototype, I did not think about animating the custimizable character.)

static_pic

I used only static pictures in the gameplay prototype, because the prototype was just about the core gameplay, not the dialog system.

Pay Attention to yoru thoughts

If you think about a feature and notice that you say to yourself:

  • “Ah, this will be easy!”
  • “There can nothing go wrong with this!”
  • “I’ll simply copy it from game xyz!”
  • “I’ll copy it from game xyz and make it BETTER!”

or similar, you probably don’t know enough about a topic and there will very probably be one or several problems that you have not detected yet. Because once a feature is in a game and works well, you do not see what effort it had cost. Actually, the easier a feature looks in a game, the more work was probably invested.

Some words of wisdom: Do not expect perfection

Even the best preparation can not detect all problems. Some things only occur during implementation. But as I said before, the more you think about your game before the production process from different views, the more likely you find the dangerous problems. Also, do not blame anyone. Problems happen. Everybody worked with their best knowledge. Work together to solve the problem and grow your knowledge.

 

***

This blog is about learning game design and game development. Please do not steal my pictures or other content. If you want to use something, ask me!

This entry was posted in Developer Diary and tagged , , , , , , , , , , , . Bookmark the permalink.