Indie Game Pre-Production Help
Hello Polycount, i'm going to start my first indie game (to be sold) soon and I'm looking for a bit of insight. I've been dawdling with 3d art and game development for about 2 years with only one menial game under my belt. However, I think it's time for me to start a fun game that I can actually finish, polish, and sell by next year when I go to college. So here's what I'm confused about... If you have any other advice, please share, because I can't ask all my questions here, just a few big ones that I've had for years.
Question 1 - Game Proposal
What are the steps one would take to plan and design a game... How do you put a game proposal on paper and how can that proposal be organized into simple tasks for production? I'm wondering this because, while I may lack creativity in this type of planning, I have a friend who i feel would do a wonderful job at a proposal but I don't think he would know the most efficient way to write one.
Question 2 - Creating a team
How does one create an Indie team online? I'm not the best developer, but if i want to create a game, who should i recruit and how many people? I would feel bad if I got some pro developers and the game turned out to be a bust because of me. On the other hand, I do have some experience and wouldn't want the rest of the team to suck.
Question 3 - Tools and Collaboration
I currently have the most experience in Unity and If I make a game it would be with this engine. How is work assigned and how is the game assembled from the assets created. Do coders write scripts on their own or do they need the unity engine with the game on it? Or do they need the art assets involved with the script, so they can create a unity package and send it to me for assembly? Any general help with this topic would be nice.
Those are my three main questions but I will use any advice at all. As you can see I desperately need some help if I want to make this real. Thanks for reading.
Other topics?:
-copyright and legal
-publishing with apple ios and xbox marketplace
-creating a fan base before first release
-general marketing techniques
-Funding (when and why it takes place)
-Marketing Research when proposing a game (target specific audience early on?)
tldr: I want to make an indie game, I need some insight and direction
Question 1 - Game Proposal
What are the steps one would take to plan and design a game... How do you put a game proposal on paper and how can that proposal be organized into simple tasks for production? I'm wondering this because, while I may lack creativity in this type of planning, I have a friend who i feel would do a wonderful job at a proposal but I don't think he would know the most efficient way to write one.
Question 2 - Creating a team
How does one create an Indie team online? I'm not the best developer, but if i want to create a game, who should i recruit and how many people? I would feel bad if I got some pro developers and the game turned out to be a bust because of me. On the other hand, I do have some experience and wouldn't want the rest of the team to suck.
Question 3 - Tools and Collaboration
I currently have the most experience in Unity and If I make a game it would be with this engine. How is work assigned and how is the game assembled from the assets created. Do coders write scripts on their own or do they need the unity engine with the game on it? Or do they need the art assets involved with the script, so they can create a unity package and send it to me for assembly? Any general help with this topic would be nice.
Those are my three main questions but I will use any advice at all. As you can see I desperately need some help if I want to make this real. Thanks for reading.
Other topics?:
-copyright and legal
-publishing with apple ios and xbox marketplace
-creating a fan base before first release
-general marketing techniques
-Funding (when and why it takes place)
-Marketing Research when proposing a game (target specific audience early on?)
tldr: I want to make an indie game, I need some insight and direction
Replies
Make a basic working demo for your game that shows promise and ask help to polish & finish it after you have something to show, only this way you can interest some quality people and hope for their help, be it art or programming.
http://distractionware.com/blog/
http://cactusquid.blogspot.com/2010/08/cactus-arcade-20.html
http://www.increpare.com/
What? That is all important stuff. You don't just jump in and start modelling stuff, planning is essential, even if it's just to get your own head straight.
The best advice I think would be to either scale back your plans such that you can finish this game solo or come up with money to pay people from the start.
If you're set on a team then you should get a solid prototype together.
What I've never seen happen is a person gather a team on nothing more than a concept.
You can't plan something you don't know. You can plan to learn that thing and maybe gather tutorials, but learning itself happens only when you actually jump in and get your hands dirty.
If I knew nothing about modeling would you advice me to write a lengthy plan about how I'll make complete enviro or just sit down and make a simple table or whatever I manage so that I can wrap my head around software and modeling process?
You plan to find out.
Game docs always get done at the beginning, then change as prototyping dictates what work and doesn't work. But a lot of word processing comes first. Game design 101.
I've heard pretty successful indie developers stressing importance of experimentation and prototyping from early on as well as fluid/iterative design process, not to say anything about various short indie game jams.
I've yet to see one advocating 'lots of word processing' that isn't a code though.
An architect/engineer draws up blueprints before they build a house/boat/plane/whatever.
A chef makes a menu and a list of ingredients before cooking a meal.
If you're making a film, you don't grab a camera and start filming, the preceeding writing process can be quite long (frequently longer than production).
If you're writing a book it is generally advised to plan it first.
etc. etc.
If you're a one man indie, grand (though I still recommend writing docs; it sure helped me when I made a prototype) but if you have a team, as the OP is aiming for, it's critical to get your ideas down in a doc so everyone is...excuse the pun, on the same page.
http://www.gamasutra.com/view/news/172326/Video_Create_new_genres_and_stop_wasting_your_life_in_the_clone_factories.php Skip to chapter 8 if you want the design doc advice, watch the whole thing for some epic advice.
http://www.lostgarden.com/2010/08/visualizing-creative-process.html
http://mainroach.blogspot.com/2012/11/feeding-iteration-engine.html
http://makegames.tumblr.com/post/1136623767/finishing-a-game
http://makegames.tumblr.com/post/4061040007/the-full-spelunky-on-spelunky
http://sethgodin.typepad.com/seths_blog/2012/11/four-questions-worth-answering.html
A Designer; you'll need one. I don't mean to offend, but generally artists are good at making something pretty stuff, but not good for 10 minutes of good play time. I've seen this many times, a 'vision of gameplay' that is divided into seconds-long segments, and they try to make the gameplay fit around a couple of 5-second 'set pieces'. This doesn't work, if you can't imagine yourself having fun in one continuous 5 minute straight play session - without skipping ahead to different bits - you're doing everything wrong.
A Programmer, you'll also need one of those, or at the very very least some readily available help for scripting and so on. Unity has a good community, and Unity Answers WILL save your life 100 times all day, every day, but you'll still need a fair bit of help.
Sandro, the phrase you're looking for is 'test early, test often', with 'test' being interchangeable with 'build', 'prototype', etc.
Scope it out, then make sure it's good enough that if you were forced to cut two thirds out of it, it'd still be functional and fun. Scope now too small? Then you've got a boring mechanic.
For getting freelancers and outside help, it can usually be as simple as providing some concept or idea (like a certain asset), and they'll send you a unitypackage. If that works, then give them a copy of the project folder if they need it (which they might, they may need to know scale, camera positions, image effects, etc etc etc). Generally if the first asset 'test' goes well, and they seem nice, then it's smooth sailing. Paypal will work for payment 90% of the time for small indie Unity projects like this.
Well, that's one way of making stuff, it's well proven and pretty orthodox
I definitely agree that when it comes to teamwork communication is a must and you do need some docs to accomplish that, but I'd still abstain from rigid 'design doc' as such. More like something describing overall vision and direction.
Especially nowadays with tools such as unity, construct, various flash libraries and readily available game engines you can come up with rough prototype in a week. I'm sure it will be nice foundation and communicate essence of gameplay lot faster and better than 120 page document.
Anyways, that's just my opinion and way I'd approach pre-production of indie game.
as far as teams - big teams are a mess, I'm speaking from experience. If you need a team I'd suggest finding 1 person who can fill your knowledge gaps.
There's more to games than 3D Art, Coding, UDK lol.
Just because you have those 3 doesn't mean you'l know how to manage people or how to plan assets/tasks for a production pipeline, there's all this other junk you're going to need to know before hand. And then there's the Finance, PR, legal junk, QA.
But tbh if you have a second job funding you through it, then you've all the time in the world to play with things.
Good luck with it dude
http://www.gamasutra.com/view/news/26577/Opinion_Indie_Game_Design_Dos_and_Donts_A_Manifesto.php#.UOSioW_CZ8F
Personally a game design doc feels pretty useless for an indie project imo. Most indie games are more or less simple ideas taken to extremes. At their core they're pretty basic.
I have a development blog on the process I used to make my game, you can check it out here, it might help a bit. Though I am just one person making my game, I'm not using a team: http://macattackk.weebly.com/fractal-reality-dev-blog.html
It's probably worth it just to have it out of your head, you'll realise that at least one of your totally awesome and sweet as fuck ideas is actually kind of stupid
As for the game document, I feel it's important because it probably won't be me who will come up with the great ideas. I think i need to play more games before I can design something that I would spend hours playing. One of my more innovative and intelligent friends is interested in planning out a game and I'd like to give him the chance to come up with a good idea based on a simple concept of mine. And the best way for him to present the game to me would be through writing. He can write really well so i'm not worried about vague descriptions or confusing ideas. However, I don't mean for the initial design to be so important, only enough to start me off in the right direction.
Yes, I will create a prototype before I recruit. Now that I've got some good experience with Unity scripting, I could probably make a quick prototype after I get some design plans.
If I make this, I will be contributing to the art and coding but I feel like I'm missing some important roles in the development process. I can code but it seems amateur and sloppy. I don't know how important that is for game development, but I feel I would need a more experienced coder to do this. But I do have enough coding knowledge for a prototype.
Thanks so much for all the help and links. I will spend tonight going through all the links and get some good tutorials before I actually start to create a game.
Absolutely.
I usually prototype (even if it's in paper with cut out bits and bobs) everything before thinking about people and tools.
Making games is not a straight path. It's cyclical. You get an idea, write it down in like 10 sentences to communicate your idea to others, make a quick prototype, then write on how to improve shit, and make another prototype.
"I can code but it seems amateur and sloppy."
This is good. Well not that it's sloppy, but that you can visualize your idea, and that you have a rough understanding what may or may not be possible.
You haven't answered my question, but from what I read you want to be a designer and managerial. In which case it's important to know a bit about every skillset in the industry, as you will largely function as a communication hub and a translator for the different development areas. Artists rarely talk code, and viceversa, so you need to interpret what artists need coders to do and then effectively communicate that.
I'm glad you liked them
@ambershee:
Yeah paper is where it's at! Anything to iterate faster is a good thing. Make use of paper prototypes before coding something whenever possible. If it's not fun in paper form, it's not going to be any more fun in digital.
2. Begin to get all your development pipeline in order, what engine? what source control? build process?
3. Now start to prototype your high level concept and explore the possibilities, lots of whitebox, hacking and messing around. Find the core gameplay of your game as early as possible!
4. Once your gameplay is very loosely defined begin to shape your art, design, code and animation direction around it. Design breaks of to explore mechanics and push core gameplay further. Art formulates an art direction that works with the core values of the project and the already defined core gameplay, level ideas are pitched and explored and very early whiteboxing is explored. Animation lays the principles for the projects demands while story and cinematic direction are explored.
5. You begin to come to the end of your pre production and you have.
- Defined high level concept (pitch)
- Art direction
- Story and level direction to help define roughly your experience from start to finish.
- Playable and enjoyable early core gameplay
- Early building blocks of mechsnics
- Demo level containing core gameplay
- Early whitebox levels
Well that was a quick ramble in the hope it might help, I think I probably missed a lot of stuff. But hopefully the thread and other feedback will help fill in the blanks.
EDIT: Also just to add, I think its very important to not define the inner workings of your game without actually producing it and testing it. I personally feel that the high level pitch helps jell everyone together towards the same goals. But ultimately leaves a large amount of creativity for the team to define the game. You get a lot of indy/mod teams that make these massive documents that define everything and then without even doing pre production they jump straight into production. Its like completely the opposite to a creative process and I feel its why so many mods/indy games fail.