[DISC] Planning Games

Just curious to know, how do you guys go about planning your flash games.

Personally, I've found chucking down any ideas that might spring into my head on a peice of paper to be the most beneficial, but it's also inconsistent and a tad untidy at times.. So the idea of this thread is to share what you find do be the most efficient planning method(s), and hopefully others (such as myself) can hopefully pick up a few good habits.

Obviously, any tips, tricks, good habits and examples are welcome.

Viza

Well usually ill jot down the basic concept in notepad. Then ill roughly work out what needs doing as far as character needs to move, enemies need to fire etc...

Then ill open up another notepad doc and start planning properly. Basically ill work out what functions i will need to use and then break those functions down into what happens in them.

I also have a needed notepad doc which has the things im yet to do in it. Then i just add and delete lines as i do new things and complete parts.

Its not a great way of planning a game but it works for me.

Planning??!?

I've not tried it, perhaps this is where I'm going wrong.

I'll have to try this 'planning' and see if it yields results....

I just wing it from the moment I have an idea in my head. Nowadays when I get ideas along the way, I write them down somewhere (due to the sheer scale of Commando 3, I ended up making a to-do list on my phone, and I'd tick off tens and tens of items on that list as I added them to the game).

It's nothing short of a miracle that Commando 3 worked out, when it was such a big game and I didn't plan it out at all. I actually released it 10 minutes before the deadline, following an all-night, no-sleep, last-minute coding session. That's what I call well-timed.

I use paper and pencil. I just keep a stack of notebooks sitting on my desk. A lot of them are just filled with random drawings, but it can really help to get an idea through your head when you see a sketch of it written on paper from a different perspective. As far as gaming goes though, I like to make a skeletal hierarchy of functions, starting with the basic inititation function. It helps me to understand where the control is being passed and it helps a lot to debug.

It also helps (at least it helps me) to jam-pack your fla with comments until you're finished. I usually create a small comment area above each function to describe whats happening on each line in the function:

Code:

---

//***********************************************************
// The follow are the 9 firing functions held within the game
// and they are only used once boughten from the upgrades
// and cannot be used for the rest of the level once out of
// ammunition. There is also the function with preps all the
// weapon types for use
//
// The system works such that two weapons are selected if
// available and their functions are loaded into fire1 and
// fire2. fire1 = spacebar; fire2 = ctrl. If one gun is out
// of ammunition, the system swaps the remaining gun to fire1
// and if that runs out, is defaulted back to basic bullets,
// considering whether or not multifire is unlocked and/or
// enabled.
//***********************************************************
//
//****************************
// accessories/items function
//****************************
function accessories() {
        // assign weapon #'s for array reference
        babu = 0;
        gari = 1;
        beca = 2;
        mufi = 3;
        homi = 4;
...

---

I don't really plan, unless I'm pitching for something and then I do fairly comprehensive Game Design Docs ( Although those are more client targeted rather than being something you can really sit down and work from ).

I find when I know what game I'm writing I know which components make it up, and any which are tricky I just ignore. It usually works out by the time I start on them my brain has worked it out for me.

One thing I always do ( Which V reminded me of ), is a to do list. I only do this near the end ( When it's worth while ) and just put all the bugs and nice to haves in there. It normally ends up being about 2 sides of A4 ( You remove one bug, but find another 3 things wrong with it ), but I find it really helpful so nothing slips off the radar ( In theory ).

Oh, and smoking lots helps. Takes your mind off what you're doing and gives you a little break, and then things just kinda click into place.

Squize.

Quote:

---

Originally Posted by Squize

I don't really plan, unless I'm pitching for something and then I do fairly comprehensive Game Design Docs ( Although those are more client targeted rather than being something you can really sit down and work from ).

I find when I know what game I'm writing I know which components make it up, and any which are tricky I just ignore. It usually works out by the time I start on them my brain has worked it out for me.

One thing I always do ( Which V reminded me of ), is a to do list. I only do this near the end ( When it's worth while ) and just put all the bugs and nice to haves in there. It normally ends up being about 2 sides of A4 ( You remove one bug, but find another 3 things wrong with it ), but I find it really helpful so nothing slips off the radar ( In theory ).

Oh, and smoking lots helps. Takes your mind off what you're doing and gives you a little break, and then things just kinda click into place.

Squize.

---

WTF how did I forget to mention smoking as a part of planning? Seriously if you don't smoke at least a pack a day, you aren't going anywhere with Flash Dev.

I develop my games on paper quite a bit before I ever start programming. I keep notes of gameplay ideas, character sketches, etc in my notebook. When I feel like I have something that might work, I build a VERY simple mockup of the game mechanics in Flash. I just use circles and squares for the art. This allows me to see very quickly if the core mechanic is fun to play with. If it's not then I know not to bother making fancy graphics and programming the rest of the game. You can't polish a turd.

As others have noted, it's very helpful to keep a list of things that need to be fixed or added.

I don't smoke, but I do notice that I usually find the answer to my programming problems when I take time to step away from the computer.

Quote:

---

Originally Posted by squize

Oh, and smoking lots helps. Takes your mind off what you're doing and gives you a little break, and then things just kinda click into place.

---

And I thought you were quitting, blue...

Anyhow,

I have found more and more that I enjoy doing a simple write up and sketches for what I want to try and accomplish with the game I am making. If I don't figure out the basic rules for the game, I'm just wandering around aimlessly or trying to make it perfect until the cows come home. I also do a rough list/diagram of the classes/methods I would need.

Usually, once I get a basic game engine going (with winning and losing conditions programmed), I make a list of bug fixes, graphics needed, game 'need-to-haves', and game 'want-to-haves'.

Since I don't smoke, I find a large variety of music (ranging from cheesy Eurobeat to straight-up Death Metal and everything in between) and some insprational game-playing breaks always seem to help me.

-pXw

pencil & paper?

Mh I have two different ways of planning :


When I'm working alone on a project, I think of it for a few days (before I fall asleep, I always think about 30mins-2hours about gamee making ^^) and then it's all clear in my head : I know everything about what functions will be needed, how they interact and how I will code the trickiest parts.
Now that only works for small projects.


Now for bigger projects involving more than one person, I do think it is ESSENTIAL to plan things entirely before coding a line. If you start coding before the discussions are over, you might end up with more half your code in the recycle bin (trust me, this is not fun :D).
I don't think such detailed docs are required, just some notes here and there about what you might forget (detailed storyline, names, system...).

At least, this works for me.

Quote:

---

Originally Posted by ImprisonedPride

Seriously if you don't smoke at least a pack a day, you aren't going anywhere with Flash Dev.

---

Really? Thats a shame, I was just starting to like my lungs :(

Ali

i have this big calendar on my desktop, or rather on top of my desk. i write down the descriptions and transfer em over month by month... lol.....
im nervous i get to take a license test driving thing tomorrow...

A few sketches, then I move it to UML.

I draw pictures on blank stacks of paper... generally scrapping about 80% of them immediately. The pictures demonstrate the gameplay with little scribbles you could call notes, and with arrows showing movement of certain objects. I worry about the graphics afterward... at least, on most of my games. Sometimes my ideas shift to other ones as I find how unplayable my original idea was.

Other than that, I'd say original concept, gameplay with simple graphics, scoring (if you have any), instructions, graphics, menu, then hiscores (if you have any)... in that order. Then change anything you want to later, typically at the suggestion of a fellow developer or gamer.

If you are having trouble coming up with something good, you could try modifying (adding new gameplay... not just recreating) an already existing game... just make sure it doesn't look like the original; unless, of course, you want it to. Also just playing other games helps, because you no longer think about what you want to make (releases stress, kind of like studying for an exam :), punching walls, throwing yourself from high ledges, or whatever floats your boat... I personally like playing video games best; though work is good too... if you have a good job) and perhaps an idea will pop up subconsciously... then when you have the idea, write it all down, and run with it, changing anything as needed.

Then again, this is all my opinion of course.

Quote:

---

WTF how did I forget to mention smoking as a part of planning? Seriously if you don't smoke at least a pack a day, you aren't going anywhere with Flash Dev.

---

I think we talked about this once before........

As to planning, yea I dont do that. I'm lucky if what I spent 6 hours on today will not be in the recycle bin when I wake up tommorrow.

I think planning takes the frustration out of it.... and thats no fun, without the frustrations I might stop smoking and drinking, and we can't have that.

i never plan, i usually listen to some music or watch a movie to spring ideas up. However thats for my personal games, working with soap we have meetings and brainstorming sessions, those are usually good, allot of ideas being thrown around, good and bad ;)

I like to think about the visuals in a game, every night i'll think about some different scenario that may arise when playing and i'll try to keep it in mind, the initial stages of building the game engine are very boring and plain, once you see stuff moving then the interesting part happens and you can make up those scenarios you've been dreaming about.

Some ideas will get lost though, but i really couldn't be arsed writing down a brief for myself.

I also don't plan ahead. I usually have thought through most of the game before I begin, but I don't write any of it down. All of the games I have created so far have been on a smaller scale, so I'm sure that planning for larger games is critical. Like others have stated, I also find that solutions to problems occur while I am away from the computer, usually as I am going to bed.

It's great to see the amount of reply's and helpful feedback so far (I'm sure my parents will be stocked about me taking up smoking, IP and Squize ).

I'm really relieved and also a bit shocked to see that most of you guys (especially the 'pros') don’t normally plan your games. From the responses so far, it seems the general perception is that it's really a personal preference (which I kinda’ predicted).

It's also a bit uncanny reading some of the replies, because they're so similar to how I go about planning (eg. I come up with most of my ideas in bed or otherwise from movies/games/music, I practically always plan things in my head only (which has proved very difficult when receiving an absolute ****-load of homework))

Though I'm very inexperienced and still very much a beginner at AS, I think that I'll stick to my current method for planning my (yet to be finished) games:
1.Plan in my head (usually just game concepts, gameplay, various ideas, etc). This is by far the most time consuming step.
2. Document things that are important or will most likely be forgotten (pretty much a to-do-list)-this is usually a fairly small amount of documentation, but it has helped so far nonetheless.
If it's a particularly challenging project, 3. Brainstorm, Research and document game functions + mechanics
4. Get started- up to this point, no drawing has occurred (though occasionally, I'll draw a very simple level overview)-whatever illustrations you see from me, will have been inspired without previous planning.

..Personally, at this stage I see planning as more handy then necessary, and though at times I may dread doing it, those few minutes that I have spent on planning have helped quite a bit in the long term.

[OFFTOPIC]

Quote:

---

Originally Posted by VENGEANCEMX

I actually released it 10 minutes before the deadline

---

You had a deadline for that?

Viza

Quote:

---

Originally Posted by Viza

It's great to see the amount of reply's and helpful feedback so far (I'm sure my parents will be stocked about me taking up smoking, IP and Squize ).
...
Viza

---

Maybe, but you'll look so damn cool. *points to avatar* Just do it. </peer pressure>


Erm on topic edit...

I agree with your style Viza, but I should say that until I consider myself one who can honestly just wing code (gotta love that right click -> view help feature), I find over-documenting and over-commenting a fair trade for a well organized, efficient game.

I'm not in the same league as most of the guys on this thread, but I'll add my perspective anyway.

I prefer to work things out mathematically, so the first step for me is to build a flexible and thorough library of math functions that are distributed within a bundle of custom classes. Once these are established, I write additional classes that contain functions for rendering, input handling, etc.

I write copious comments in my code until a class is in its final state, often with "note to self" multiple times.

I think it's important to develop a personal library of classes that can be used in a wide variety of situations before moving into a full blown project. If you're going to be making games, alot of it is writing low-level code, so it's easiest to write it once, make it flexible, and only have to code the things that are specific to the project.

From there, it's alot of thinking on paper and reading stuff on FK, Kirupa, LiveDocs, etc. I think the slowest part of any planning I do has to be thinking on paper because I try to work out all the possible pros and cons in the design approach to each element before I script.

Also, I prefer to avoid author-time construction of anything I work on, unless it is necessary. In nearly all cases, if I do not script it, it isn't in my project (with the exception of graphics, of course).

"I think it's important to develop a personal library of classes that can be used in a wide variety of situations"

Couldn't agree more, although I wouldn't do that at the expense of actually writing the game. The end product is what's important, not how you got there.
Any classes you put together always get more refined on every project you do, so I find it's best not to get bogged trying to make them too perfect ( Something I think most of us have been guilty of ).

Squize.

I dont use classes. I just feel its overkill for most things. I have functions that are entirely independent of the script they are in so I just rip the usefull ones out of a script and slap them in a new one.

I just cant be bothered to spend the extra time create classes when I could be working on something that is needed for the current project.

I was totally the same til I crossed over to as2.

Squize.

Yeh ive been told it is a change and I dabble in as2 for some things. Ill probably end up using classes at some point and find they are extremely useful.

Kakihara
The first time yeah, what happens if you need to fix something with the functions or extend them? then say some old old project needs to be re-exported?

I can't believe i've only been using classes for 1 year, they have saved me a hell of allot of trouble and made coding so much faster.

these guys have some good base classes for everything - http://casaframework.org/ although I've never actually used any of them, for any hardcore serious game i think it'd be a good choice. Probably getting a bit off topic here.

MY planning only goes as far as making a list of features and then adding
NC
WIP
Done