I have a good idea for a game, but where is the best place to start?

Should I build the world first or script first?


Also, I'm having difficulty creating a terrain with a texture that changes from the level of the terrain & paths. I've tried all kinds of terrain creators, but I don't understand them.

Can someone show me a tutorial on how to do this.

In my humble opinion there are different approaches to a game.
However the first thing should be to write down your idea and think the game through.
- Who is the player?
- What's the main objective?
- What can the player do?
- etc.
This can be useful to have a list of features that are essential for your gameplay to work and to know what requirements your game has.
However you should think about each feature twice "is it really needed?", "how hard is it to make it work? (animations, scripting etc.)"

When all the writing is done and you have a feature list and maybe a design document for your game together you should stick to it.
Adding features during the development process might kill the project in the end, because there is too much.
For a first game: Keep it simple!

Now its time to do something. However what you do with all the written documents depends on what you can do and what you cannot do.
If you're an artist, it might be a good idea to draw some concept art, build a few first models and sceneries which express how the game should look like etc.
Then you could try to get a scripter/programmer as a team mate.

If you're a programmer/scripter, you probably should start with a scripting
Which means: Either look for some free models which fit to your game, or build quick prototype models (a simple box is sufficient for a lot of things) and script the key gameplay features to see if they work together and to have something to show when you're looking for an artist.
If the game is already fun with your simple dummy models, you have a winner and it should be easy to find somebody doing the graphic part.

Thats my personal view on the subject.
However there are more experienced users around here, who are able to give a way better advice.

-have a rough idea in mind,
and quickly make a prototype of the game.
Dont care yet for the graphics or propper programming.

once you have a working prototype up and running,
sit back and see if you enjoy it.

You should stop putting too much work into the prototype,
if it runs and is basically fun.
(usually a single level, basic actions are enough to
see if it works)

---

Then stop here, and start with the propper development.

make a design-document
(from a simple bulletpoint collection,
to an advanced design-doc with several chapters,
depending on how serious the project is, and how big the
team is)

Make notes about how the program architecture must be,
sont forget that you need to implement much more content, art
and levels later.

Limit the amount of features, to the one that are really
contributing to the game.
Having too many features in mind, will actually hinder
you to get anything done.
Throwing out lower value-stuff and keeping high value stuff is the actual art in project management.


Programming: reprogram your game in a propper and clean approach.
Use only parts of the prototype that can be implemented
cleanly, reprogram the other parts.
The prototype should only be a visual / gameplay demo
of how the game should look and play.

Dont build up on dirty prototype code!

----

Have a short change / test cycle.
The time between changing a part and testing it should
be really small. Especially for codechanges.

---

Do a stress test for your game, by including
a big amount of dummy content (models, shaders, etc)
So you can determine what the limits for the leveldesing
should be, to keep a decent framerate.


---

Artwork: - Consistancy

much more important than high.quality artwork and models
is, to keep to a consistant style.

Even a game with ugly models looks better, if the complete game
is made in the excact same style.
opposed to a high-qualty model, in a world of
objects with totally different styles and quality.

(the same applies to leveldesign)

Look for a style that looks good, but
can be realized by you in a sufficient number of models / textures / level-designs.

I just want to add one thing to what has already been said.
In case you are a one-man-show. Once you have a working prototype start with the programming. I wouldn't care about the artistic part at all until you are done coding the game mechanics (movement, AI, combat, interaction, etc).
Not having graphics can be solved with money/free artwork/crappy graphics... while the game can still be fun.
Not beeing able to do the coding... most likely will break your game's back.
^^only applies to one-man-projects with shallow wallets though.

@SomebodyNew: Ok, right - coding goes first. Suits my plans very well. But problems start when it comes to a battle system. Let's say we have a medieval game with a simple "hit the left mouse button to attack with your sword"-mechanic. How could you *ever* get that done without a model that has a matching attack-animation? After all, you need vertice numbers in order to get the collission detection sword vs. enemy to work... (this is exactly where I'm stuck at the moment, you know... I'm not interested so much in making a whole game, the only thing I'm really interested in is coding)

Greets,

Alan

Wow. That's a lot of great information, haha, you guys rock. I'll start writing up a draft of my idea first so I can see how much work there is gonna be.

And yes, right now I am a one-man-show, I cannot afford to pay anyone for help so I'm going to have to learn to do it on my own. Would be nice to find people to work pro-boneo. But who wants to work for free? Little to no one. lol. Might take me a long time to get going, but it'll be worth it because I would like to take my finished game to an actual game publisher and see if they'll port it to console systems.

But that is just a dream of mine. But who doesn't have that dream here.