"Even if your game doesn't turn out the way you'd like, it can give you ideas for other games."
Christopher Chance (K-Power Magazine, April 1984)
Today I'm writing about the initial idea for a game, and how to go about it. I will be using 'project stained with magic' as an example throughout the short article.
Firstly, it is crucial to know that the purpose of design is too solve problems. Game design being no exception in this case. Having a clear idea and the ability to state the problem you are designing a solution to is key here. For example, do you want to tell a story with strong historic themes or do you want to create a new fun way to allow players to run their own restaurant? With this in mind, we can come up with a solution easily, with brainstorming.
Brainstorming ideas can be difficult. With that, here are a few tips to get you started. One, create a mood board. A collection of media related to the problem you are trying to solve. Example, Stained with Magic is set in a near future-magic world setting. I spent my time gathering dark themed images related to magic and technology. As well as playing games such as Steins;Gate and Fate/stay Night. Two, always write every idea that you make. Even if its rubbish. You never know when it can be useful. Three, do something that gets your creative juices flowing. Play some music, play a game, watch a movie or read a book. Ideas can come to you at unexpected times. You never know when you may be stuck with something great. I hope these tips help, but remember they may not work for everyone.
Next step, you have a few plans and ideas ready to go. But, you are not quite ready yet. You need to know, from my experiences, the first few raw ideas are often rubbish. Now, you must keep thinking up more ideas or refine the ones you have already. In my best opinion, refining one of your earlier ideas is the best move to make. Stained with Magic was one of my first ideas to pop into my head. Since then, the story has gone through three iterations (small fact: stained with magic was originally going to be set in a high school).
Another piece of advice I often hear from other developers, is that the first five ideas you come up with will always suck and make terrible games. I don't fully agree with this statement. I say it depends on how you refine and experiment with your ideas. Play around and see what you can come up with. But, don't be afraid to kill your babies (ideas) if they suck.
One final piece of thought, I would say is crucial when developing your ideas. Is to apply your idea with Schell's four elements of game design, Mechanics, Aesthetics, Story and Technology. Let's apply my project to each element for an example.
Mechanics: This refers to the rules that generate game play. In my case, this was the rules and formatting for visual novels. As well as the values for determining the progress of player interaction.
Aesthetics: The visual and emotional feel of the game. Here, I chose a dark setting with digital art that would highlight this mood.
Story: Narrative that is going to used in the game. I stated the game will have a branching story set across three volumes, allowing for the player to make choices to change the course of the story.
Technology: The resources needed to make the game. For my project, a computer with the game engine Ren'py was what I needed.
If you can check off the above four points with confidence. Meaning you have a strong refined idea to make a game.
Next week, I will talk about how Hikage Studios formed, and give you advice with forming your own team. Now, I will leave you with a quote by Jon Freeman relating to today's topic.
"We have a good idea where the game is going and what it will look like at the beginning, but there's a lot of fine-tuning that can only be done after the game has started to take concrete form. The design is not something cast in stone that has to be followed to the letter--it's more of a guideline."
Jon Freeman (Compute Magazine, February 1985)
“Alone we can do so little; together we can do so much”
― Helen Keller
I wanted to talk about forming game development teams for the first time today. As games are made by a team of people. Unless your insanely awesome person with insane skills in every area (These people are rare, and a treat to be with). The most rewarding experience about working on a game, is working with likeminded people.
You will become friends, argue about a variety of things, teach each other new skills, bounce new ideas off each other and learn about the different personalities in the world.
Once you have an idea and a set plan of the tools, and assets you need for the game. You can start forming a team. Firstly, know the talents you need. This can range from artists, programmers, audio engineers, PR workers to level designers. Once known, you can begin recruiting. There are numerous ways to find people.
Create recruitment threads on specialised forums (E.g. Lemma Soft Forums), email friends who may interested, search through sites such as deviant art for artists or even start chatting around on social networking sites such as Facebook. You never know who you may find.
When talking to a potential member for your team. Be clear and concise about what you want and what you are offering. People don't like to cheated or lied to. Clearly state the workload, if the job is paid or unpaid, and their expected turn-out for each week. This will help with preventing people from quitting part way through the project over such difficulties.
Using Hikage Studios as an example for the above discussed topics. We met when I was first recruiting for the game last year, via a post on Lemma Soft Forums. Where I clearly outlined my intent and what talent I wanted. Honestly, I was surprised with the talent that came to me. This gave me confidence the project will succeed. The idea of forming Hikage Studios came later down the track, when we were discussing plans to release the game. From there, things run their course.
Next week, I will go through the inner workings of a game studio, and what I learnt personally from working with a group. It isn't easy all the time.
Plus, a new character will be announced next week. All I can say is, I hope you're a Tsundere fan.
"We must all hang together or most assuredly we shall all hang separately."
- Benjamin Franklin
Games are usually made by a team of people of various sizes. So it's apparent that you must some social and team-working skills. Or you are doomed to fail as a team.
From my experiences so far in game development, a strong leader and constant communication are required. Firstly, a strong leader who can drive the project forward is a must. They must be willing to take on the burdens and stress of the team as well. They must become the solid pillar the other team members can lead on. Otherwise the team will fall apart. On that note, you must also show that you are capable on taking on the job to the rest of team. Otherwise, trust and faith can be broken easily.
Next, constant communication should be made between members. Even, if this means having a weekly chat as a bare minimal. If departments don't chat with each other, a funnel vision situation occurs. Team members only become concerned with only what is happening in their department. I do warn to avoid this situation. Sure, work does get done. But, project progression does slow to snail pace and work involving multiple departments will often have mistakes.
If these problems are present in your team. They can be corrected, but they are always not easy to fix. For example, I once worked on a Location-based game centred around using in-built phone cameras called ImaginAlien. We had a team of twenty people to make and run the game over a course of twelve weeks. As a quick run-over, the team started with a team leader/producer and a leader for each of the four departments (digital media, print media, community management, software development). I was the leader for print media. But part way through our development cycle. Our team leader had to step down due to stress and other commitments. The role was then shared by the leaders of each department. Despite weekly meetings, tunnel vision still occurred and development was a slow process.
We were only able to finally effectively work as a team when we had an audience playing the game. Likely due to us not wanting to disappoint our players. Anyhow, I'm trying to say. Never give up on the team. You will get there eventually.
I wanted to cover more on this topic, but I don't want to keep you here for too long. Part two will come this week.
"The clash of ideas is not weakness. Truth reaches its place when tussling with error."
- Richard Henry Pratt
As promised, I'm back to speak about team dynamics again. As well as passing on a few updates.
I will start with the updates (for those who don't want to read my team dynamics piece). Development for our playable demo is progressing smoothly, with only one minor delay to date. As proof of our labour, you can view a few screenshots attached to this post. (They will be added to our media page shortly.)
Now, I'm going to continue my rant about what I have learnt about team dynamics thus far from my experiences.
To begin with, team members will start fights and continue to fight until they have been satisfied until they achieve their goal. Do not try to avoid these situations, they are going to happen. No matter what you do! Arguments are a natural development for team dynamics.
For arguments or debates, one of the best skills you can have is to know when it is time to step down and accept defeat. It's a skill that can be only learnt from experience, but defiantly one of the better skills to have. Not all battles can be won. And trying to win them all, will only cause strife for other team members.
If debates continue, the team leader must find middle ground and make the final decision. A respected leader shouldn't have any trouble with this task. But remember this, bad blood between members may continue to build behind the shadows where the leader cannot see. Time can become a poison, and may be a fatal poison for your team. I'm just saying, be careful what you're saying and to whom your saying it too.
To summarise, debates are healthy for projects and you shouldn't be afraid of them. But, remember to keep your personal feelings about other team members away from project related debates.
Shorter than usual, but my blog post will end here today. Next week I will talk about those wonderful free demos we all play.