Challenges: Game Design
I was uncertain whether I should continue writing Pen dev diaries while in development, even though I still have nothing interesting to show. Or wait until I finish the main parts of the game and write a diary full of accomplishments. Looking at the awesome dev diaries online with the professional art and gameplay, I don't stand a chance. I mean all I'm facing now is a huge set of challenges, most of which I still struggle to overcome. I wasn't sure if any Alnin would be interested to read my complaints and the boring challenges I face.
However, after a long discussion with my professional assistant (myself), I realized that writing a diary full of accomplishments is not, in my opinion, the exciting part of game development. The process of developing a game is what really matters. That moment when you want to pull your hair out because of a stupid bug or when you can't sleep because you received a river of ideas from your sleepy brain. And that moment when you dream about your game winning an award but wake up to face the ugly truth (I guess that's just me!). Whatever the feelings and obstacles you are going through, they are what make game development unique and inspiring. To keep my point short, my dev diaries will be filled with challenges and a little bit of whining here and there (Maybe not so little). If that's too boring for you, then I guess we should break up here :(
New Addition To My diaries :o
Since I'm mostly facing challenges while development, I added a new part to my diaries! It's called Developer's Rescue. In this section, an experienced game developer will rescue me by answering few questions about the challenges I'm facing. Hopefully, you'll benefit from their answers as much as I do. You'll always find this section at the end of each diary from now on. Now, let's talk about my Pen!
Game Design Challenges
I started struggling with Pen's game design from the very start as I already mentioned on the first diary. Here are the main challenges I faced on this stage of development:
Challenge 1: Designing a Complete Experience
I want to design Pen in a way where the gameplay, art and story are combined as one entity. Meaning, if one part was removed it will affect the rest and you won't enjoy the game or even understand the story. Hence, they become one entity. I've always wanted a game that enables me to play a complete experience without filling the gaps between its parts. For example, in many games, I often feel the separation between story and gameplay. Of course they are connected somehow, however, they are not one.
Designing Pen as a complete experience is essential because there are no dialogs, hints nor text. The only way to understand the story and message is through gameplay. Hence, designing the puzzles and art to be the story is what challenging for me.
How I Almost Solved The Design Issue
Designing a game as a complete entity is a tough concept. Maybe just for me, though. When I first started, I tried different approaches until I found the right one, for now at least. At the beginning, I used to look at each part of the game separately. For example, I used to design the puzzles on their own, then check if these puzzles are aligned with the story. Lastly, I used to try to come up with an art style that will support the parts I created previously. This way, I ended up with separated parts. Again, they were connected somehow but if I tried to remove the art part for instance, the story, the message I'm trying to convey and the gameplay won't be affected.
Obviously, I needed a stronger connection between all of these parts. As a result, I changed how I think completely. Now, I focus on the message I'm trying to convey in Pen. Then, I use every part (art, story, puzzles) as a tool to help me carry my message through out the game. I give a role to every game part. The art in Pen will tell a huge and important section of the story and message. The puzzles in Pen will enable the player to translate the story and message by what they feel and experience while solving the puzzles. Now, if I try to remove one of these parts, the player will experience a different game. This way of thinking helped me tremendously while designing. By having a major role for each part I don't have to use a language to communicate with the player. They will understand the message by experiencing the game from its different parts.
Challenge 2: Enabling The Player To Make Decisions
Enabling the player to make decisions in the game is another game design challenge. I love the idea of giving the player a choice and consequences that follow their choice; nevertheless I don't like nor enjoy how the decision-making part is done in most games. First of all, Choosing from a list of choices feels like the game switched to a quiz or something! Second of all, it breaks the illusion of being part of the game when you have to choose what do next from a list. For me at least, these ways of making decisions in a game never made sense. Another thing about making decisions is what kind of consequences should follow the decision? Should the decision alter the story or the ending? Must all consequences be explicit?
How I Almost Solved The Design Issue
As I stated above I don't like the process of making decisions in most games. To be honest, I never liked that they are very explicit. Not all decisions in real life are that obvious. Sometimes we make stupid decisions without even realizing and only at some point later we understand what we did. Other times, we won't even realize the outcome of that stupid decision we made. Also, what about how we choose to think? Isn't that a decision as well?
Pen is a game that tells a personal story but in a metaphorical way. Since it's personal and it represents real life in many ways, I want it to be relatable and open for interpretations. It's not just my story it might be anyone's story but in their own way. Thus, I don't want the decision-making process in Pen to be rigid or black and white. It has to be implicit and unforced. It might not alter the story entirely nor the ending (mostly because I can't code a game with multi-endings at the moment). Yet, it will affect the player's feelings, how they relate to the game and experience it.
Considering the fact that I'm an inexperienced game designer, perhaps whatever I want to accomplish here is wrong or can't be done. Regardless, I will test all my game design theories on this game, because why not?
Knowing how the game will end and knowing the purpose of the game are what help me overcome most of the game design challenges in Pen.
Challenge 3: Writing The Game Design Document (GDD)
From the deep bottom of my heart, I hate GDDs. I hate writing them, reading them and even looking at them. They’re inefficient, long and unuseful. Despite the hate, though, I do believe documenting your game is critical, especially at the beginning when everything is changing and new ideas pop up all the time. Moreover, as a developer, I need some type of document which I can follow while development. As you can see, I have a complicated relationship with GDD. I need it but I don’t like it. My professional assistant (myself) had to interfere again to help me come up with an efficient and easy way to write GDD.
How I Almost Stopped Hating GDD
I asked myself the following questions.
- What do I hate about GDDs?
- Why do I need to write a GDD?
- To have a document to follow while programming.
- To record my ideas.
- What are the important parts that I want to document?
- Concept art.
- User Interface.
- Levels including their characters, environment and story.
- How often do I need to update these parts?
- I will need to update my GDD with every development cycle to help me code faster.
Answering these questions helped me realize how I should write my GDD. Here's how I write my GDD now:
- The tool I use for writing my GDD is Keynote . I stopped using Google Docs or Pages because they tend to make me write more and add unnecessary details. Writing a GDD in Keynote helps me focus on adding pictures, sketches and keeping it short.
- I divide my GDD to separate Keynote files based on my development cycle. This way, I only focus on the part I'm working on at the moment rather than going through a huge file.
1. Thinking Out loud (Keynote File)
This file is for brainstorming. I don't update it. I don't even write it in a proper English or Arabic. I just use it to save ideas and go back to them whenever I need them. The picture you see above is how I write my ideas. I use the different shapes in Keynote and write whatever comes to my weird brain, Literally! I usually hide all tool bars in Keynote and only focus on the slide in front of me. To be honest, I used to use paper and pen for brainstorming. But because I'm traveling the world, I can't carry or keep these papers with me all the time.
2. Gameplay Timeline - Chapter 1 (Keynote File)
This is a group of Keynote files that represent each chapter in Pen. Each chapter has concept art, music, levels, environment and characters. The template you see above is for the first chapter in Pen. I call it a timeline because I write it in the same order of how the game is played. In these files I use sketches to draw the levels and the characters and I try to be visual as much as possible. Being visual in my GDD, helps while coding because I already see the connections and how the game look like.
2. UI (Keynote File)
The UI file contains sketches which shows the navigation of the UI. I don't write much in this file. I use the shapes in Keynote to draw simple UI along with some concept art for how I want it to look like. I separate the UI in a different file because it doesn't affect the gameplay nor story.
My rescuer for this diary is Tariq Mukhttar. He is an independent game developer from Saudi Arabia. He’s the founder of the Happiest Dark Corner game studio. Artist, animator, programmer, designer and musician. He also founded and manages the game development community “Gamedev Corners” that’s active in three cities and offers regular meet-ups, talks, and workshops. An IMGA international juror, and the Arabian Zanga game jam organizer and judge. He is currently developing “A Cat’s Manor”, that has been getting a lot of attention, recognition, and has been showcased in various venues and shows including PAX East.
Game Design Questions:
Sara: The usual game design process requires a lot of brainstorming and writing. Many game designers recommend using a Game Design Document (GDD) to document all the details of your game for a better game design process. I disagree with that to some extent. I don’t mind documenting but the way of writing a GDD is not helpful nor efficient in my opinion.
What do you think about that?
And what is your process when designing your game?
Putting your ideas to paper is a must. It really helps. But I struggle to find a unified format for a GDD that I find personally useful. Perhaps because I don’t need to communicate my ideas to a team or pitch my game to an investor. However, when it comes to the actual design of the game, I mean the real details, especially if your game is complex, then you really must put it to paper. A scientist would call it a form of cognitive distribution and I agree. It aids in maintaining the bigger picture while examining the total sum of its parts. Things that are problematic might only reveal themselves in writing. Likewise, solutions that elude a brainstorming session might suddenly appear when the game designs are committed to paper. It’s not a rigid, strict, one-time thing though. Like any written project plan, it constantly evolves and changes as the project moves forward.
As such, my process of designing my game is very iterative. It’s like adding multiple layers of polish. For instances, a narrative segment of the game consists of four elements: map area, characters involved, story, and gameplay in that order. I have a setting for my game world (map area) that my (characters) are inhabiting at that (story) moment in the narrative and you must do certain (gameplay) here. Let’s think about it for a moment:
Are the puzzle elements (gamaplay) suitable and acceptable for this part of the (map area)?
Are the puzzle elements (gameplay) consistent with where the (Story) has reached?
Are the (Characters) acting naturally around the puzzle elements (gameplay)?
Are the (Characters) in this (map area) logically here and consistent with the (Story) flow?
Did we arrive here (map area) in reasonable (story) flow and logic (gameplay)?
In order to create a believable setting, you need to address all of the above and more. So you refine the answers or solution to questions 1 through 5, and then take another look at them. Then answer them again, and again until you reach a satisfactory level. Iterative process. Obviously this causes changes in your story, the design, the map, and the characters.
Sara: I’m still in the early stages of development but I’m struggling with art because I’m not an artist. The art in my game supports the story & gameplay heavily. Therefore, even in the prototype, I need to have expressive art. Not necessarily the best but at least good enough.
- Tell us what are the best practices you follow when creating art for your game as well as when using your art in Unity?
- What tools do you use for creating art?
I prefer to start with “Concept Art” that mirrors your vision of the game. How it looks, how it feels, the characters, the world they inhabit. This helps develop your mental image of the game, helps crystalize your vision, and helps communicating it to any collaborators. It also helps formulate an art style for your game. Always look at other games for inspiration and try to learn from what they did and did not. Once you have a clear idea what your game should look like, it’s time to move on to producing a “Target Render”. What you try to achieve with that is creating a “screenshot” of your final game. This helps estimate art assets requirements, camera placement, effects needed, etc. Obviously this comes in handy when it is time to construct things in your game engine of choice. Knowledge beforehand of the capabilities of your choice of game engine helps set realistic boundaries for your Target Render. How flexible is the lighting system? Are you employing post processing? How much depth and scope should the game world require relative to your chosen camera view? What physics system tools are required? Target Renders help to answer these questions.
My tools primarily are Gimp, Inkscape, 3D Studio MAX, pen, paper, standard laptop touchpad, smartphone camera as an alternative scanner, and smartphone pen as a makeshift drawing pad. Usually things start out as a simple sketch, then gets refined outlines in InkScape, and finally a nice color and finish in Gimp.
- What are the best practices you follow when animating your characters?
- Do you use bone based or sprite animation?
- And what tools do you use for animation? Unity or a separate tool?
I guess it all depends on the art style you’ve chosen for your game, but if I had to define how I approach my animation it would be to adhere to a certain level of realism by mixing in some of the 12 principles of animation such as anticipation, easing, and mass. I try to make objects move as smoothly as possible with an air of finesse and refinement.
To create my animation I mainly I use Unity’s basic MECANIM system, and since my character are composed of multi-segmented sprites, it works hand in hand. There instances where that isn’t enough. Either the movement is too complex (number of joints involved), or the object is very small and moves in a bone-defying way. In such cases I would fall back on 3D Studio MAX to create complex smooth animations, or InkScape to create animation frames the hard way… by hand.
Sara: General advice and recommendations for indie game developers who just started developing their game?
Indie game is all about community. Connect as quickly as possible with other indie devs around you. Just being around others like you offers plenty of reasons to drive and encourage you forward towards finishing your game. Participate and engage in local events, take part in game jams. Don’t be afraid to ask for help, and always keep learning.
Ship your first game as soon possible. There are things you can’t possibly learn unless you take that essential step of releasing a game. Chances are, your first game isn’t “The One”, maybe even your second game isn’t. It’s a journey of self discovery after all. You have to find your purpose in the general scheme of things.
Never bank on your game. Unless you have a game out there that is making you enough money to provide you a comfortable living, never quit your day job! Game development is a highly dedicated passion that requires big sacrifices if you decide to do it yourself, but it’s also greatly risky with a guaranteed level of failure. So always maintain a source of steady income that will carry through your passion.
Let me know what you think about my challenges and how I "almost" solved them. Also, I hope you liked the new addition, Developer's Rescue. Tariq was amazing as always :)