Staying Focused

Hi everyone,

I have had 3DGS for awhile now but have never had the time to devote to a project until recently.

Before I get started on any development I wanted to know if there's any tips anyone can give me to help me not lose my way and get distracted by little details.

Should I be setting my self goals or making some kind of development plan or something? Really anything that you find helpful when you want to stay focused.

Thanks

Tom

I don't know whether you aware of the extremly helpful articles in the AUM Magazines. Look at the small game samples to get an idea of the effort that you will have to make. Try to make a concept of your game idea that is as small as such games. Write your game concept in few sentences. Then write a sentence for each function, that you need to write to achieve the minimized version of the gameplay that you imagined. Then code and test the functions step by step until you've got the gameplay.
You might want to let others test the game - listen to their feedback: what did they understand, what did they misunderstand, what did they like etc.
Then start again with widening the concept to several levels or settings or whatever your 'bigger' plans are.
Don't forget to write down that 'extended' version of the concept before you go on with coding, modelling etc., as well.
You can call this repeating and extending prototyping.
...

A development plan is very important.
Start with the stuff you only need for the very basic working version. Then add the other stuff in steps. Like:
Step 1: Load Level, Movement, Save
Step 2: Enemies, Fight
Step 3: Make Levels, Replace guard.mdl with something fitting.
Just as example. Whenever great things come to you in mind, write them down and look in what future steps they can be included. Be sure you can handle the active step in time.

I do it that way and it works very well for me.

Oh, and you probably have to rewrite your code once or twice while you learn. ^^

edit:// Was maybe not clear in my text, but like Pappenheimer said write everything down and stick to it. And the AUMs are really helpful. In the intervies especially the last point which is often "What do you want to say to beginners" or something.

a few tips that helped me:
- plan your game. write down what you want. write sentences, draw sketchs or something else (i prefer mindmaps and textual descriptions).
- list the required features, the optional features and the nice-to-haves (-> set priorities).
- Use the spiral model for your projects. It minimizes the chance of a complete fail. built the main game mechanics and improve it continously.
- view code smaples, tutorials, ask users to find a good technique to realize the needs (for example: how to realize laser-rays? particles? models? sprites? )
- use a version control system (like subversion or git) to track the development and get the possibility to test major changes in your project without destroying your previous work

It's realizing that it's all baby steps and starting with the most simple parts. No sense making hugly complicated and beautiful levels if you have not made a player movement code so you can see it, or even worse you can't make a good code that works with the level size, either your character seems way to tall or way to short and then the level needs to be replaced.

Thanks for the quick and helpful responses everyone.

@Pappenheimer - I never thought to look in the AUM Magazines for some reason I have never read them, don't know why.

@lemming - I like the method you have for breaking down the parts of the development and being able to easily slot new ideas into. I think this will be extremely helpful when I think of something that I want to add.

@Tempelbauer - I think the Spiral Model is going to be quite helpful having a visual aid is a great idea. I didn't think about breaking features down by required features, the optional features and the nice-to-haves I would have just had a massive list. I always find Subversion useful when I'm coding.

@FoxHound - When making levels/models is there an typical quant - cm ratio or is it just what I think is best?

Tom

Not that I am aware of. How big a quant should be is very debated here on the fourm. Generally the smaller your level the better, but if it's to small things won't look right. So go for best look.

Thanks for the helpful pointers everyone.

If anyone is interested I have started collating all my ideas together and set-up an development environment using; Skydrive, Subversion and trac by edgewall.

I'm hoping trac will help me better manage my changes in subversion by making it a little easier to read/search through the changes. The ability to create milestones and tickets for each feature will help to break it down into individual code changes and make it easier to record my progress. Also putting it on my Skydrive means I can make changes at work through lunch .

Hopefully I can come back here in 4-6 months with an video of the basic parts of a demo level with some place holders.

Tom