Just wondering how you choose to code when you begin a project. Do you plan out the different systems/classes with a rough design before going into the project, make a flow chart, or detail what each system is going to do or need to do. Or do you just dive into it and start slapping away at getting things going?
I first prepare the boiler plate stuff to get at least a window up and running, with a basic game loop and state system.
Then I attack my white board with organizational stuff like flow charts, pictures, etc… 
After I get a somewhat clear picture of what the game is supposed to look and work like, I can start working. If you can’t get a good image of what you need, you can start incrementally working on what you know, and the rest should fit in place!
+1: Planning is the way to go…
Sometimes planning is good, so you don’t sit there and say: "hmm… This design bugs me… " or “Hmm… what to do now? nothing fits together”.
But don’t waste your time with planning
Plan for 5 days per week. Code for 2 days per week. When you get to the point where the only part left is to type away, then code as often and as long as you want. If it’s a full time job, then you have to work on an hour-to-hour or day-to-day basis instead of week-to-week basis. It all depends on the project and whether your schedule allows/requires you stay at a desk most of the time.
Plan whatever you’re going to do the next day when you’re in bed and about to sleep. But before you start spend a couple of days getting a general idea.
Probably not good for my sleep quality… 
Dive in. Hardly and straight 8)
Planning is useful for ensuring systems are consistent but I highly recommend getting something playable as quickly as possible and ensure that as you add stuff, the game remains playable.
Having something you can play and showcase helps with the self-motivation to keep developing!
If “dive in” means something like “I want to make game, so lets start coding”, hell, no.
For example, trying to add multiplayer features without planning from the very beginning will greatfully fail.
I constantly do class and module sketches with paper and pencil, write down requirements and features. No uml tools and the like for that, they all suck.
The more experienced you are, the more will automatically happen on your mind by recalling proved patterns, techniques and methodologies.
Do not try to be a fortune teller by planning to the smallest detail. Finding a good balance is the true art.
Haha, yah. My previous projects have all been modifications and had required planning really (or I just didn’t choose to plan them on paper). More or less 1 system being worked on at a time, and a matter of just implementing and testing it, then rewriting it if it wasn’t that good. I’ve learned a lot from that, but started realizing I should probably plan things out as I move into writing a whole game from scratch.
So far, I only have a few things written down on how game Entities and Worlds are going to be handled and what is the absolute necessary information they need to hold. My biggest issue is learning the rendering, I understand the concepts but it can be a bit difficult translating the math knowledge back down into code when there are so many varied examples on the net (especially with the large differences between GL11 and GL30)
[off topic] I’m just waiting for Cas to come in and say; “Jump right in, finish it as quickly as you can, and apply what you learned on your next game.” or something along those lines. [/off topic]
When I am starting a new project I will get all the, as ra4king puts it, boiler plate stuff done first; like getting a window going with game loop, basic entity system, and game states. After that I dive right in, and plan as I go. Usually I can get all the puzzle together without a hitch.
I plan out my game, then start coding one feature at a time. That way I get an idea of where I’m going with the code, and I know when I got it working.
Plan and prototype game desing but don’t waste your time to plan code that well. It’s allways end up totally different than original plan anyway. When you see full picture you can redesign and refactor code lot faster. Most of the game code is throw away stuff anyway so why bother with it longer than needed.
Experience will make the code better not planning.
Can’t agree more !
Just dive in, planning has never worked for me personally. I can spend a week planning and a few hours into coding and the plan is already broken, huge waste of time.
As far as code re-usability goes, it only comes from experience. As you write more games, your ability to write neat and re-usable code increases, reuse a bit from first game, reuse a bit more from second game, and a bit more from third game and so on and by the time you know it, you’ve created a sort of “framework” or “engine” that has a ton of reusable code.
Once you get to that stage, you may even wish to spend some time optimizing your framework or engine, and make it more usable as a whole package for future projects.
just my two cents ;D
I’d say think about it, plan a little and then go iteratively from there. You need a guideline that you can follow or else you’ll “dive in” all over the place. But I wouldn’t even try to lay down a complete design plan right from the get go because that is no good for the creative process; you need the freedom and liberty to just change your mind overnight and not have to go back to the drawing board each and every time you do that.
As long as you start by thinking about it, then you’re on the path.
Does anyone else see the planning part and the typing part of programming as very different things? I tend to plan out even tiny details before starting to type, but that’s mostly because I plan while I find myself waiting for people or things. A couple minutes at a time add up and it seems like I don’t have to scrap and rewrite code as often. It’s the opposite of the advice programmers normally get, but it seems to save time in the long run. I sometimes even disregard the advice to ignore performance considerations until later for the same reason (though I never underestimate brute force algorithms or focus on non-critical performance issues), though that’s even more discouraged.
Though once I start coding (which includes typing, reading about APIs, and sometimes solving equations) I do use iterative testing/prototyping like most people.
I just got a whiteboard for my ‘office’ and I don’t know what I ever did without it! My next game is all drawn out in diagrams and trees… helps me stay focused and on task, scope creep has always been an issue with me!
Something like this: I carry around a notepad and draw lots and lots and lots of sketches/design/screens & gaming notes. Then when I get near my PC, I open up IntelliJ stare at whatever I was doing last time… immediately lose interest… and then look at pr0n. ;D