How do you prefer to start the development of a game?

Hey folks,

this is not supposed to be the 126th "How do I start to make the next Angry Birds / GTA / Skyrim" thread. Instead I'm just curious and like to know how you prefer to start the development of a game - or be it a prototype - once your basic design document is done (if at all - do you use them?). It will apply for one-man-armies and small teams mostly, since bigger teams will be able to spread the work that needs to be done more evenly.

This is why I started this poll, but please feel free to explain your vote or to add another answer if it's none of the above.

I for one feel better when I stick to my plan at least until I get feedback from other devs or players - on the other hand it seems like I am not able to stop thinking about every little feature I could add, modify or remove. Dangerous when it comes to overthinking and getting tangled up in details.

I'm looking forward to your answers and comments,

Painter

 

Hey! nice Question. really looking forward how other Devs responde

So from my side i can say there are two sides of the medal. Games that you doing on your own and Games that you doing in a Gaming Company/Professional. So lets start with the boring one... the Professional:

In our Company (dont want to tell the name, 300+ employees) we doing it the following:
Game Designers Come up with a rough concept , CCO aprooves it (or not) and then the Producer come in and doing a Business Plan and Set some Milestone goals. Then The Artist and Developers Doing their thing at the same time and in the End you have a final Game. Of course there are a lot of steps in between but i dont want to go into detail here

And when I do stuff on my own its pure Chaos I just do how i want to do it. Mostly i start with the Graphics and do some Mockups with Renderings and so on and put a little bit UI here and there in photoshop and dont really care about Polycount and stuff like that. I have a rough Idea about what you do in the game but overall the ideas just fly by and i grab one here and there and try to prototype it without giving a S*** about code quality

If I realize "ok, this could be fun" i do most of the stuff again, but clean. Cleaner Models with clean meshes and a reasonable polycount and the same with the code. Why am I doing this? Because I can not garantie if the idea that i have is good at all. So i make a pretty dirty version of the game first, test it, test it with other people and if I am happy with it i Continue. If not I will flush it down the toilet.

About Concepting and stuff like Game Design Documents i have a clear opinion: dont write down what you want to have, just do it. Concepting in a one man project is a waste of time.

 

I always begin by eating a gallon of potato salad, followed by doing 8 consecutive backflips with my fingers in my ears. It's the true key to making a great game.

Actually I tend to go back and forth between programming and art (one man team here.) That way if I get frustrated with something I can work on something different, and come back to it later. I might start with any aspect of the game, and I'm open to new ideas along the way.

 

None of the above.
I code, my graphics designer cares about the graphics.

 

Actually I tend to try to avoid using 2D graphics in my games even though it's inevitable. So yeah, I tend to jump back and forth between programming and 3D modelling.

But I get this guilty feeling when I'm making the 3D models that it's not "real work". I mean how is making a 3D giraffe a proper job??? Even though it's mostly graphics that sell a game! I wonder if anyone else gets this? Or maybe people with an artistic background feel like they're wasting time when they do the coding?

 

I don't feel like I'm wasting my time with either. 3d art is as much a job as any aspect of game design.

 

In my case, I usually start with some core feature or mechanics. In The Hero's Journey, I started by replicating the character controls in The Legend of Zelda 2: Link's Adventure, which is a mix of mechanics, art, and code simultaneously. Then I started building levels to test those capabilities and their more subtle implications, and the game's most advanced execution challenges. Then, I created my 'core' levels which contain the bulk of the content that I wanted to guide the player's experience.

'Simple.'

 

With great zest and enthusiasm...


Which dies off after a few hours/days depending on initial progress.

 

I know it's unconventional, but totally works 100% for me in completing games and feeling satisfied, and that it is polished.

I usually have an idea in my head, a vision and feel already going with what I want. I start by designing my main character(s). I prefer games with more an iconic style, like Nintendo games. This leads me to a better understanding of what the graphical nature of the game will be like, and inspires me with more ideas. The thing is, I design them to be complete how it should look end game. This gives me exactly what I need to do other elements to compliment this style. Then I model or draw him/her/it, and start rigging and animating the smaller things. From there I drop the character into unity and start working on the basic features first. Adding ideas as I go, until I feel it makes sense, plays right and is complete from section to section. Then I do environments, UI, and audio is last. Coding comes in at every phase after the initial main character(s) have been completed. I'll definitely jump back and forth.

I'm very open, and it seems there could possibly be no end to the game development, but since I already have a deep understanding of what I want to do, I usually (almost always) don't teeter too much from the initial vision or structure of the game unless it makes total sense and I feel it will work well. Plus I work for myself, so I have no one who needs to follow my ideas other than me, in a developmental sense.

 

STEP ONE:



There is no step two.

 

I start by getting some mechanics down. Get things to feel nice. Maybe play with some prototype tech if it's specific to the game.

If I'm happy with that, it's iterative graphical, code audio and (maybe) writing passes, because each should inform the other. None of the above should be designed isolation! While graphics come chronologically later, I wouldn't say that they come second to code, and those two things aren't the whole of the game.

New features are not welcome "24/7". I decide on a minimum* set of features that my game needs to work based on player feedback, and I make a polished game with just those. If the game gets popular or whatever, I have a glut of stuff to add to the next version. If it doesn't then I've finished a complete product life cycle in less time than if I kept adding new features, and can apply what I learned to the next one. I guess that's some input from the "fail fast" school of thought - the longer it takes you to get to the finish line the longer it is before you can start your next learning experience.

* Seriously, ask play testers how darn long it took to convince me to add the dash functionality to Master Thief. There were months between when the first person said "I want to be able to move faster sometimes" and I finally put it in there.

 

Pure Design.

Anything else will most likely result in a crappier game than you could have done if you designed it well before you created it.

You can go another route, but more than likely it will result in all the other crap out there. That doesn't mean you won't make money or be popular. It just means you could have done a lot better.

Everyone has their strengths and their weaknesses, but the design of the game and anything related to the game is the most important aspect by far. After that, it's irrelevant if you use code or graphics first. In the end, you'll need both... or at least Code anyway.

 

Sounds great, and very similar to how I do things.

It also sounds like a very successful method. So many developers (even after financially successful through alpha funding) suffer from feature creep. So it's great to hear you don't stray from the original vision all that much.

 

Depends for me, smaller projects we'll get the code done 100% then fill it in with graphics. My current project is all of it as it comes.

 

It really depends. If you have a good idea of what you want to do then designing a lot of it out early can help you find problem areas. If you only have a rough idea of what you want then I would start prototyping early on. If, in either of those cases you have any high risk (don't know how to do, think it might be too resource intensive, etc) pieces then I would knock those out first. Kind of the agile approach of it's better to see if those are showstoppers as early as possible.

I'm basically paraphrasing waterfall and agile software development methodologies. There's others that fall in-between the two and the two are rarely followed to letter, but it wouldn't hurt to read up a little on those if you are unfamiliar with them.

In the end though, you need to find the approach that keeps you motivated and moving forward.

 

I work on a pile of hobby/early commercial projects, and mostly I just wing it honestly. I hate to say it but I don't usually have a GDD unless its end stages, no specific art style early on, and no real final goal in mind of projects as I start up (by myself, mostly for learning and testing) and just go with the flow of things until I hit a wall or find something severely entertaining.

Problem with this is, most of my stuff never comes out, and gets tossed on the backburner until some motivation awakes in me to return to them. I have probably got 10+ projects, ranging from super basic prototype to halfway decent framework just gathering digital dust all because of lack of direction and purpose, which usually leads to a flawed overall product, or horrendous code mountains of if statements and vague variables.

However the benefit is that by consciously treating every project like a learning experience to find out what works for quick iteration and prototyping and what requires a whole lot of fine tuning to get right if it were to go commercial, and not to mention learning the syntax and proper approaches to many different game design aspects within unity specific areas, I get to try out things that maybe would seem like a great idea at first, and turns out it bogged down androids or has some major long workflow that is too rough for full scale games.

And ya know sometimes I stray from this "headless" approach and draw up some concepts on the ol' wacom bamboo, maybe even a few rough level ideas, character sketches (which i'm terrible at) and things of this nature to kind of get my idea on the screen so I can decide if it even works or not. I like to do semi-placeholder art sometimes where I do 2D pixel art (in the case of low tech style 2D games) in photoshop to a scale I like, and then eventually I later revisit it to polish things up to look nicer, while still keeping dimensions and colliders accurate that way, saving me time later on.

But it seems like the hardest part is just buckling down and finishing something, anything! No matter what approach I use - I end up trying to come up with a way to press on and make a functional end product out of it, and to keep motivation up. I could care less if I fail really (as in abandon a project halfway) and don't feel bummed moving on from something, because working solo on an indie budget you can't expect to accomplish everything alone, and really I think of most things as likely never hitting a market anyway, and rather as some way for me to become more familiar with techniques and difficulty involved. This enables me to forget about what the end user wants to have, and work on what I can actually make happen. Whether this is right or wrong I dunno, but it works for me to keep me focused and keep that editor window open!

 

I always start with an idea of a/some cool game mechanics, then i code it and test it with simple cubes or whatever.

If the mechanics are fun then i go on from there.

 

I'm still working on my Master's thesis, so that's my immediate priority. However, I usually start a project by having my head detach itself from the rest of my body and head back to it's native universe so I can get ideas. Once I get an idea, I then start thinking about the mechanics, which I then start prototyping with either basic models or cubes. Graphics tend to come later, once I've got the basic idea laid out.

Admittedly, I have about five planned projects which exist only as random scribbles in a notebook, so I should probably shut up now

 

I want to finish projects! So, I prototype each idea for 1-2 days until I settle on the one I love. That's when I start a timeline like 4 weeks of basic gameplay and 8 weeks of polish. Then, I create lists of features in tiny print, on blank, white printer paper. I mark 'LOW' next to ideas that don't make the Minimally Viable Product (MVP) cut, "X" the ones I later cancel, and "Check" the ones I complete, whether it's from the official 'task' sheet or my various sheets of ideas. For these 12 weeks, there is no such thing as spare time - 2-3 hours on weekdays, 4-10 hours on sat/sun! Major systems are slashed and burned, never taking more than a day, as the focus is ALWAYS on functioning software.

Code, test, and deploy. Iterate. Fix bugs. Check, check, check goes the features, and "Add that one too", and slowly, my product evolves. Where once there was a blank screen, soon, there are buttons, and interactions, and game play, and UI until 4 weeks in, I've created a functional prototype with most major features. It's fun, ugly, and going to be a lot cooler in 8 weeks. Progress, progress, progress, always keeping the end date in mind.

"Finishing is a feature. A really important feature. Your product must have it" - Joel Spolsky.

That's how I start AND finish projects. Good luck.

Gigi

 

I start by staring at a blank page, then I check social media, forums... websites, YouTube. Then I play a couple new games. Listen to some music. Attend to some unrelated tertiary business. Read some stuff. See other people's games that I'm jealous of. Get inspired. Click over to whatever development software I'm using. Dick around a while. Get tired. Remember that I still have to do a couple chores before bed. Remember that there was that cool thing I wanted to look up that I heard on that one radio show that one time... Stumble off to bed in the dark after a late night snack which crushes my diet... I'll work on it tomorrow.

 

I can literally only create one way, and one way only.

Get extremely frustrated after procrastinating way too long, then go in with all the things I love and do an insane amount of work in a short, sleepless period of time.

Sort of like a procrastination slingshot. Hahahaha.

 

Do a market assessment, read around and try and dig out reliable stats. Do a basic design. Put together the art, allow the game to grow as I get additional ideas. Code the basic framework and start chopping and chopping to reduce the feature creep I allowed. Go and have a think for a few days. Come back, make sure the elements in the game are actually coherent and suit the game, if not more chopping. Rewrite and reduce the dialogue and narrative as much as possible, Ensure there is only one control mapping for every element. Lock down the design. Get it playtested to find glaring inconsistencies I may have missed. Optimise, add polish. Ship.

 

I usually think of an idea then I open up Visio and code out everything in diagram form. I try and think of every idea possible and don't worry about if it will work or not. Once I get to UI design, I normally open Unity and NGUI and setup a few basic pages with all the elements for each menu. Once I think I have designed everything out I start making the scripts. Once I create all the scripts I start piecing it all together to make it work. 99% of the ideas I come up with stay in Visio but they are all there so one day I can make 10000 games at once!

 

Not one of you perform the appropriate homage and rituals to the gaming gods?!?!?!

• I chant to the Great Old Ones Nintendo, Sega, Sony and the Outer God Atari, and finally I pay homage to the many arcade saints by offering a roll of quarters.

• Finally I initiate a cleansing of myself and the Unity Project by sacrificing a pig/chicken/cow/lamb/etc., what ever is in the evening dinner before I sit in front of my computer terminal and begin to write the "bible" for the game (read design document).

I try to cover only the basic goal of each system/sub-system and the overall game play, than I begin coding sections until it is working and is modular enough I can use it later when it is time. Once those steps are done I begin using primitives to emulate game play to test the code and make sure it works as expected.

Finally I move on the graphics and finally when they is done I begin to polish and check for optimizations within the code.

 

Your rites are not complete, Acolyte. You are missing some steps:

• You must also cleanse yourself with the Holy Water that comes from your local shower head, such that dark spirits like armpit smell do not infect your game with their vileness.

• In addition, you must go on a Holy Pilgrimage to a place where you can find the legendary Ambrosia of our kind. It is green, and comes in a bottle labeled, 'Mountain Dew'. Such Ambrosia was not meant for our kind, as too much of it causes uncontrollable heartrate and silliness, but a little is enough to sustain your strength for an entire night.

Blessings unto you, Acolyte.

 

Plain code (list of features, list ) with some concept arts only.

what about this:

 

I do not care for mountain dew. Give me coffee, coke, gatorade, powerade in that order.

 

Oh ok. The Dork Gods of Game Dev only demand ritual intake of caffeine so you're cool.

 

I prefer water or tea.

You know, because downing energy drinks and coffee every day of your career is very bad for your health.

I understand the Mt.Dew cans stacked. I was young once, I know what that is like. Although I know better now, I still understand.

However...energy drinks? People must be truly ignorant as to how horrible those are for you. I don't even understand how someone can use them "sometimes" let alone in stacks upon stacks. And how horrific it is when children talk about drinking several (large, tall) cans a day. It disgusts me when I see indie dev's desks stacked with energy drinks. I thought they were awesome when they first came out and I was a teenager, but I was also an idiot just like most of us when we were young. I didn't know what it meant, and the marketing was EXTREME!!!!!!111

Of course, I also don't understand the alcohol or whatever is in that tiny little packet of rodolfo's. The former makes me physically sick, and I find it perplexing why anyone would want to dumb down their brain or wits. I mean, at ANY moment the killer robot from the future could bust through your door as you're about to finish that video game which will revolutionize the world and prevent the robots from winning the future war.



Joking aside, the only thing that perplexes me are the energy drinks. It disgusts me that they aren't regulated until someone dies from them (in which point they disappear).

 

An article of interest on the subject of devs programming all day while downing unhealthy drinks.

http://www.telegraph.co.uk/technolo...ns-of-pilots-but-bodies-of-chain-smokers.html

It's about pro gamers, but the same will apply to most devs.

And then there's this one

http://www.cio.com/article/452400/Health_Hazards_for_IT_Workers_How_Your_Desk_Wears_You_Down

 

Mr process:
1. Make the player move
2. Give him some gameplay mechanics (jumping, shooting, sword fight, etc.)
3. Put lots of particles everywhere
4. Make ai
5. Download models from turbosquid (or the pirate bay if im desperate)
6. Put them in the game
7. Code any idea that pops into my head
8. Get mad when something doesnt work
9. Trash the project 50% of the way through because I thought of a better game idea

That's how it's been for 3 years now. Still yet to make a COMPLETE game.....

 

How I prefer to start? With the game already done, my name already in the credits, and my fees or profits already deposited in my account.

How I actually start? Lots of fidgeting and procrastination, eventually followed by a mad dash to get something resembling whatever it is the player is supposed to control on the screen in some playable state.

Then things kind of follow their own course from there.

 

I HAVE NOT YET FINISHED A GAME.

So my following words here are based off the experiences of failing and working on game projects.

I would typically start development by gauging and minimizing the game project work required to have a finished game. For 2D games, I've personally had the problem of not being able to finish all the artwork required and keep it polished looking. So be sure whatever game you envision, you are able to handle all the artwork required.

There will always be problems and more tasks to do when developing a game that you didn't foresee. So you gotta make sure you're passionate about the project, or else you may not be able to pull through.

 

I'm distraught! This morning, my daughter was prepping for an 8 day trip to Nashville to participate in a national championship she'd been working toward for 6 months. Everything was great, until she woke up this morning feeling really ill. So now instead of packing the car, we're waiting for the doctor to tell us if my sweet little Make-A-Wish child gets to spend a week in the Hospital, or in Oprey-land!

I'm in a bad mood, so I beg your forgiveness Kaji, for picking on you as an example of bad advice from people who never finish a product! You're sharing 'best-practices' to people who might follow your lead and end up where you are - with nothing to show. Although cliche's like the-blind-leading-the-blind, spring into my mind, I know that's not really fair. It's more like aspiring young artists, striving to be more than they are, sharing ideas they're only beginning to comprehend, and wanting more than anything to be a part of the conversation.

Though I don't have the perfect path, I'd like to share what I've learned while finishing six personal projects, getting publications in five books, and winning four national awards.

Whether my approach fits your reality or not, at least you'll know they are successful techniques learned from the school of hard knocks. You're mileage may vary.

Gigi

 

I have to agree with @Gigiwoo. You've clearly got passion. You want to be part of the 'best practices' conversation. Your courage in speaking up is admirable.

One small problem: you have nothing to show for it, which renders all the stuff you said useless.

You've not actually created anything, yet. A discerning reader, remembering Thomas Edison, would realize that much of what you've said is the recipe for "a way that does not work," which is valuable - parts of your path are ways not to go when writing a game. Some do work. The task of figuring out which steps belong in which category is up to you, ultimately.

In the interest of helping you improve, start by recognizing some things...

1. First, the process/rituals you're clinging to aren't working. At least one part of your development cycle is flawed. I think your next failed prototype, you should give yourself a post-mortem. The way you do this is you write a list into four columns: What Worked, What Didn't Work, Unaddressed Needs, and Discovered Best Practicies. You then list things; did you give up when writing code? Didn't work. It might also mean you need some form of help, either training, or a coder for that part of your games. Proceed to write a list, and if it's huge, don't worry - when you come back and see it after your first completed project, you'll realize how far you've truly come. Also, post it publicly, here on the General forum. You need people to give you feedback. Feedback is your friend. On most end-user sites (like Kongregate, Wooglie, or NewGrounds), the feedback isn't great, but here, on developer sites, this is where the feedback will be good, and where you will learn important things from others, by sharing your experience.
2. Second, I think your mindset going into your projects are bad, based on your post. Everything you wrote is, "When you do (thing A), then you ve got to do (something else, written to sound way more arduous than it really has to be.)" This is what's defeating you; you don't sound like you want to do the things you've convinced yourself you have to do. Passion aside, you don't sound like you have the substance to make it mean anything. The way that you correct this is to look at a task as exactly what it is: a task. You complete it, and you move on to the next one; each completed task brings you closer to your goal, which is finishing something. You do not gripe about completing a step that advances your plans, if you really want to achieve your plans; you accept that it's there, and that you're going to finish it.
3. Gigiwoo is always saying, 'scale things down; leave stuff on the cutting room floor; think of the Minimally Viable Product.' Someone else once told me, 'you can always patch your game later, if you don't ship you've wasted everything.' It sounds like your concepts are flawed by being overly complex, you're ignoring the beauty of simplicity! Look at the original Super Mario Brothers - it's running, and jumping! Everything in the game is built around all the possible things that can be accomplished while running, or jumping, or both!
4. Finally, realize that you're trying too hard to overrepresent yourself. You've written a lengthy forum post about nothing of value. You've got a signature half a foot long, with nothing really in it. Instead of merely shouting, present ideas of value. Seek out experience, and realize that success and failure are bedfellows; finding one inevitably means finding the other cuddled intimately beside it. That's the reason we write post-mortems of projects - not only to remind us of victories, but teach ourselves and others how to avoid failure, or invite criticism for all those same reasons.

What you posted is not helping you grow, it's stagnating you; you're reciting a mantra, hoping that it will shape reality to how you believe a game should be summoned, not to the way you're really going to finish something.

It sounds like you have some work to do. If that passion is real - and I believe it is - I think you'll be better for this critique, and I think you'll find a more constructive way of doing things than advising people to do things even you admit aren't working.

I wish you well, and if you want advice at some point, pass me a PM, I'll gladly give you any advice; similarly if I don't know, I'll tell you so.

 

@Asvarduil & @Gigiwoo
Thanks for the feedback and It's true I haven't finished anything, which is why I stated it to give warning to take my words lightly, but still 'hopefully' had something to offer. The project I have failed didn't follow the guidelines I spoke of, I also haven't seen success yet so, I suppose it is invalid advice.

I'll edit my post so that it I won't be giving bad advice.

 

Never give up, I have been working on my game for quite a while now and so far I haven't trashed it. It is looking good so far and maybe some of you will remember which game it is. Some might recall seeing it in the Work in Progress forum and they will see it soon.

What kept me going with this game was that I received very good feedback about my game (which was total crap at its current stage but it's awesome now). Hopefully I will make it and finish it!

 

My 5 easy steps:
1. Think of a fun simple idea
2. Make it more complicated
3. Make it more complicated
4. Make it MORE COMPLICATED
5. RAGE QUIT!

 

None of the above.

I play it in my head for a couple of years or so and return to whatever seems more suited to the game we need to make at a given time. At this point its prototype to see if it's fun. If it's really not much fun it's shot early on.

 

None of the above.

Start with lots of tea and days of writing in a notebook (probably over a month), laying down the basic mechanics, architecture, and how things should work for the best, before touching a computer. I then cover the wall in all the relevant pages and begin to write servers and client in parallel. Building zones only starts as and when I feel artistic (which isn't very often).

 

I just imagine it, I like to imagine how I will code the concepts and what could work and what won't work. Then I play the now complete virtual prototype in my head and make sure I have no issues, then I try and emulate other people and how they would play. Then I make a little prototype and see if it works as well in my head as in real life.

 

On paper or with a painting app, I draw how I want every interface to look. I use the page and location of each element on the page to get a relative size and position. If the health bar is the top of the screen and about 5% of the page...

Rect(0,0,Screen.width, Screen.height*0.05f)

I do that for every interface and menu that will be in the game, including the UI for being in the game. From there I build a menu system by writing a script full of scripts like void MainMenu and void InGameUI that call a bunch of GUI functions. I then make an instance of that non-monobehaviour menu script in my main script and use a switch structure on a menuState variable in the main script's OnGUI function to display the various menus in the game.

Next I fine tune my own fps controller (or other controller) to fit the project. It's really easy to do, even if you're making your own system entirely or using a few built in components.

Once I get the player walking around in game on a plane with a light and I've made sure the movement and controls are good on this controller, I go into blender to model the assets I need and give them a really crappy paint job and automatic weight armature.

I delete the light and camera (not sure if necessary?) and drop the blend into my Resources/Models/ folder of the project and get stuff on the screen. I don't use scenes except to reload the current scene for a convenient restart function. I have functions that delete or move stuff and instantiate new stuff to build the levels.

After that point I start making scripts for the things I've modeled.

Code (CSharp):

1. public GameObject body = Resources.Load("Models/whatever") as GameObject;

I make a list of player or other entity scripts in the main script and they have init functions to link models to a GameObject var (usually body) to their model. If I'm instantiating many instances of something, I may just pass the gameobject from the main script so I don't have 300 zombies all calling Resources.Load to find their bodies.

The update function in my main script iterates through all of my lists of non-monobehaviour scripts and calls their pretendUpdate function so you can write your scripts as if they were using an Update function but then rename it and call it from a main script to reduce the number of Update functions Unity has to run.

That about covers the first day. The second day involves fantasizing about starting the next project after the current one is finished.

 

No joke; you're the equivalent of EskimoJoe but instead of talking about scammers it's motivational speaking with a knack for English.

 

There are many reasons not to finish a game. Discounting what people have to say is a bad idea.

 

Every idea to me is probably the best idea in the world but when I share it with someone, they don't like it. At that point, it becomes my "little secret". I had an awesome RPG idea similar to No Man's Sky almost a year ago and everyone hated it. Like wtf u trying to make me not do that game so you could do it? Wtf bqq goml killem

 

Wow, we got some great replies here. I'm sure you guys / your workflow will be an inspiration to many others who - like me - wonder how to get going!

 

Just do it.

(Please don't sue me Nike)

 

I come up with a general design, create some basic art assets I'll need, and then start writing some code. As I need more assets or code, I make/write them. There's no point in getting fancy with either of them until I'm sure the game's going to be worth pursuing.

 

I roll the idea around in my head, imagining what it will look and feel like to play. If the idea sticks in my head for a while without writing it down, then I consider it a good idea and move onto a written / drawn planning phase.

 

Oh man, I would do terrible things to get some of those. Great movie.