Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Completely agree with developing the prototype, hell I believe in most big budget AAA games they consist of prototyping and programmer art until the last few months of development. The utmost core importance is to get it working before you get it looking good. Obviously this doesn't apply to people in teams with set roles, but in that situation, planning is of key importance before any asset is created or feature implemented.

Writing it all down is important too because it gives a clear list of what needs doing and when, including a list of art assets you think you'll need. This can be expanded upon or reduced in development.

To give a tip that isn't just reiterating what coquigames said, is to pick a scale and stick to it. This applies to art, but if you develop art assets, they'll be for a specific size, so when you import them into the engine, you may need to scale them up, but be cautious of having scales vary too wildly. For instance, if you model your character to be a specific height, then you'd obviously want your wall with a door frame in it to be a specific height and width for your character to fit through. So when you import them into the engine, and scale the wall to be 2x larger and your character 3x larger, then the character may not fit through the door anymore, or the door will be inconceivably large when your character walks through it. Same can be said for tables that are too wide or chairs that are too high. It sounds like a simple thing but I see it all the time in indie games, especially the horror titles.

Another tip is to use pseudocode. What that is is breaking a function down into steps in plain English (or your native speaking language), outlining what exactly needs to be done. For example, if you had a gun that shoots and when a barrel gets shot it explodes, what you would do is write something like:

1) Figure out if the barrel has been shot (hit with projectile)

2) Play a particle animation of an explosion 

3) Play an explosion sound

4) Delete the barrel from the game (or swap it out for your exploded barrel model depending on how complex you want it to be).

Then you have a clear understanding of what needs to be done, and gives you focus points on what to search for in your programming documentation.

Absolutely agree on the pseudo code! I use it all the time to create complex code and also to debug. Cant recommend it enough!