Topic name may be a bit weird but not sure what to put it.

Okay, I want to ask about,

Things to do before start programming, and what to write first when programming, and should I focus on one aspect or little for each.

1. Do I need to make things like flowchart? document on level, gameplay, level, etc? etc...
And sample of how to write them would be appreciate. (I read a lot from website but I still write gameplay quite aimlessly.)

2. Once start programming, what I should write first?
main menu interface? world? gameplay?

3. And should I write that stuff until it is complete?
Like, if I make main menu, should I finish all of them or just make Start Game and Exit Game?

Thank you in advance, will check tomorrow.

When I start a new project I will always have an overview doc that describes all the functional compoenents of my game. This would include all the actions that the player can do, all the actions that the NPC or opponents can do. A listing of the resources that I will need etc.

After putting this doc together it gives me a big picture of the project. I will then start coding by outlining classes that are going to be needed to fill in all the requirements. These classes initially just have interfaces defined to them, with no actual implementation.

Once I start programming the implementation I typically start with the UI and the graphics side of things, just so that I can see things working as quickly as possible. This keeps me motivated to keep going. Typically the resources at this point are just place holders for the real objects that will be used.... ie boxes, and spheres.

The last thing I typically do is polish things off by replacing the place holders with real animated images.... and this is also the stage when I add sound to the game.

1. Do I need to make things like flowchart? document on level, gameplay, level, etc? etc...
And sample of how to write them would be appreciate. (I read a lot from website but I still write gameplay quite aimlessly.)

Maybe. Depends on how you work, if you're working in a team, and the complexity of what you're working on. Some sort of design document is useful to make sure everyone is on the same page, and can be useful when trying to make sure that you've got a good idea of what you're going to do.

2. Once start programming, what I should write first?
main menu interface? world? gameplay?
[/quote]

Logging.

3. And should I write that stuff until it is complete?
Like, if I make main menu, should I finish all of them or just make Start Game and Exit Game?
[/quote]

Generally you're going to be limited in doing 'all' of any vertical feature like that. Doing stubs or 'just enough to work' is often useful.

I find that its good to do some minimal organization. But once I try to plan out too much I get nothing done. What I do is set small goals, such as "by the end of tonight I will have the main menu fully functional and looking nice". What happens when I try to organize too much is I stress over it and lose my mind. Sometimes chaos helps me to work better. So yea, simple, achievable goals and simple helpful organization. Dont write a huge design document... to me thats a waste of time. Just my opinion though, everyone works differently.

Thanks, I like the way of mmakrzem.

@Telastyn Hmm, sorry but what's logging?


I would like to see the others' opinion and advice in both small team and single development as well.

But once I try to plan out too much I get nothing done.

+10000

Unless you have years of experience (and if you are asking this, it means you haven't), planning and writing documents is just a huge waste of time. I have seen dozen of projects starting to document how cool and super cool things they will do.. of course, nothing came out of it.

If you don't know how to implement something you can't plan for it... so just jump into it and write code. Try to get to a level where you can "play" your game to prove it's actually worth playing and the idea is a good idea.

If you're in a small team.. work on small weekly steps.. try to get to your "playable prototype" as soon as possible, don't overengineer.. don't implement anything before you actually need it to get your prototype done.

You'll do a lot of mistakes.. but that's how you learn, so your next project will be better.

Topic name may be a bit weird but not sure what to put it.

Okay, I want to ask about,

Things to do before start programming, and what to write first when programming, and should I focus on one aspect or little for each.

1. Do I need to make things like flowchart? document on level, gameplay, level, etc? etc...
And sample of how to write them would be appreciate. (I read a lot from website but I still write gameplay quite aimlessly.)

2. Once start programming, what I should write first?
main menu interface? world? gameplay?

3. And should I write that stuff until it is complete?
Like, if I make main menu, should I finish all of them or just make Start Game and Exit Game?

Thank you in advance, will check tomorrow.

For 1, you will need a document of every single game concept there is. Eg Sound, Setting, Genre, Characters (NPC and Player), Premise, Synopsis, Player Motivation, Target Audience, Game Mechanics, Game Graphics and so on. This is in the GDD and the TDD.

2. You need to start to write the base of your game. This includes basic world, Player (If have One)(Controls), Background, GUI, Stuff like that.

3.That's your Choice. Have an Adventure of your life. You can build what ever you like in programming if you have the skills

@Telastyn Hmm, sorry but what's logging?

Eh? Logging. Outputting information to a file/debug-stream/server so you can see what the hell is going on when stuff doesn't work.

Super 3D Game Platform Architecture (Click for Full View)

HI SamNainocard, my advice to you is to put your engine design on the drawing board first. It really helps to get a Big Picture on how all systems, classes, etc, tie together. By taking some time to design your software on paper, you may discover many software development techniques strategies that already exist that can help speed your progress when you do start coding. I discovered component-based entity models, model-view-controller, singletons, observer pattern, memento patterns and other software engineering methods when designing the GUI for S3GP. Blog or wiki your design, google when you have questions, and read the articles here in GDNet and Gamasutra.com.