Important advice for beginners
For this thread, if your a game developer please share what you would consider your singlemost important piece of advice. To keep it readable comment your advice like you would your code! Please keep this tidy and avoid asking questions.
Here's my important piece of advice:
/*
Programming is a skill and the only way to get good at it is by practising.
Sometimes re-inventing the wheel is a good thing, dont use other people's libraries if you dont understand what it's doing - a lot of learning happens when you solve the exercise yourself. If you copy and paste someone else's code and get it to work this does not make you a good programmer!!
*/
Learn to think in an object oriented way so as to simplify code development and increase code reuse. Avoid using global variables as much as possible so that all properties/variables belong to a class.
Quote:Original post by LionMX
Sometimes re-inventing the wheel is a good thing, dont use other people's libraries if you dont understand what it's doing - a lot of learning happens when you solve the exercise yourself. If you copy and paste someone else's code and get it to work this does not make you a good programmer!!
Poppycock. Developing the skill of learning and adapting a 3rd party library to your own needs is vital to every programmer.
Quote:Original post by LionMX
please share what you would consider your singlemost important piece of advice.
I don't know what that would be, but here are some pearls of wisdom I like:
1) Take time to become reasonably proficient in whatever language/library you're working with.
2) When writing code - first make it work, then make it fast.
3) Most programs spend 80% of the time in 20% of the code. Most programmers try to guess what that 20% is and get it wrong. Don't optimize prematurely or based on guesswork; use a profiler.
4) There is no excuse for a program not to use some kind of error checking, even if only in a debug build.
5) And my personal favorite:
"There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - Sir Antony Hoare.
I might add a few more later.
Quote:Original post by TelastynQuote:Original post by LionMX
Sometimes re-inventing the wheel is a good thing, dont use other people's libraries if you dont understand what it's doing - a lot of learning happens when you solve the exercise yourself. If you copy and paste someone else's code and get it to work this does not make you a good programmer!!
Poppycock. Developing the skill of learning and adapting a 3rd party library to your own needs is vital to every programmer.
Everybody is right. [smile] Learn to use 3rd party libraries. Reading documentation, observing how they are architected, and solving problems relating to objects you don't have the source for are all very useful skills.
But when it comes to tutorials and finding code snippets, read what they are doing, understand them and recreate them yourself.
If I were to say anything it'd be to finish things. There is a world of difference between 90% done and 100% done. If the project is too large, cut it down in size - drastically if need be. But get it finished, working, and polished to whatever bar is set.
Quote:Original post by TelastynQuote:Original post by LionMX
Sometimes re-inventing the wheel is a good thing, dont use other people's libraries if you dont understand what it's doing - a lot of learning happens when you solve the exercise yourself. If you copy and paste someone else's code and get it to work this does not make you a good programmer!!
Poppycock. Developing the skill of learning and adapting a 3rd party library to your own needs is vital to every programmer.
Keyword: SOMETIMES
If you go into a job and they ask you to implement a line drawing algorithm and you say "can I have access to the internet to copy one" im pretty sure they would kick you out laughing!
When looking at code on the internet think critically. It is typically there to demonstrate something as such it is usually poor quality code outside of the one thing it is demonstrating.
When following advise such as "don't use globals" try to understand what is actually being said about software design. Too many times I see people trying to follow "the don't use globals" advise create a game or app class that makes all the mistakes of global variables in every thing but name.
Try to drive your app from data, the less you try to do through code the better(by better I mean more flexible and easier to reuse.)
When following advise such as "don't use globals" try to understand what is actually being said about software design. Too many times I see people trying to follow "the don't use globals" advise create a game or app class that makes all the mistakes of global variables in every thing but name.
Try to drive your app from data, the less you try to do through code the better(by better I mean more flexible and easier to reuse.)
Quote:Original post by LionMX
your singlemost important piece of advice.
Understand the difference between a number and the representation of a number.
Quote:Original post by LionMX
If you go into a job and they ask you to implement a line drawing algorithm and you say "can I have access to the internet to copy one" im pretty sure they would kick you out laughing!
I would reply: "Bresenham's or Wu's algorithm, reference implementations are available in various sources".
I've implemented them myself, long time ago, in assembly, dealing with 64k VESA buffers, and using vertical scanlines in ModeX, etc... but that is long behind me, and I simply do not remember or care about them.
And yes, most people would kick me out for such an answer.
I don't know what I would consider the single most important thing, but a few that leap to mind include:
1. Fail. Try things out, and when they don't work learn from the mistakes. Failure should be thought of as an excellent opportunity to learn rather than something to avoid at all costs or something to be ashamed of.
2. Practice, practice, practice. All the reading in the world won't make you good at either programming or design - you need to actually try things out for yourself, even if that means lots of stupid little programs to play with the things you're reading about, or perhaps finding ways of working new things into a larger project you're working on.
3. Choose appropriate tools, and don't just pick the ones professionals use; just because they use them doesn't mean they're right for you. Just like an IDE or art package, your programming language is also a tool.
4. Ask good questions and make sure you pay attention to the responses; don't just wait for someone to agree with what you originally thought, take all the answers into account and see if there's something you can learn from them even if you don't end up taking a particular piece of advice. Thank people for thier time.
5. A working game is better than a well-engineered one that is never finished. Try to follow good practices, but don't get caught up in them so much that you never get a game done; do you really need an object oriented state system that pushes and pops States from a stack, or will a simple switch statement do the trick?
6. Write Games, Not Engines. Actually read that article if the title just made you defensive; it doesn't actually say you shouldn't create your own engine, but rather argues that a better approach is to create some functioning games and abstract the reusable functionality from them rather than trying to write an engine up-front, and it's very good advice.
1. Fail. Try things out, and when they don't work learn from the mistakes. Failure should be thought of as an excellent opportunity to learn rather than something to avoid at all costs or something to be ashamed of.
2. Practice, practice, practice. All the reading in the world won't make you good at either programming or design - you need to actually try things out for yourself, even if that means lots of stupid little programs to play with the things you're reading about, or perhaps finding ways of working new things into a larger project you're working on.
3. Choose appropriate tools, and don't just pick the ones professionals use; just because they use them doesn't mean they're right for you. Just like an IDE or art package, your programming language is also a tool.
4. Ask good questions and make sure you pay attention to the responses; don't just wait for someone to agree with what you originally thought, take all the answers into account and see if there's something you can learn from them even if you don't end up taking a particular piece of advice. Thank people for thier time.
5. A working game is better than a well-engineered one that is never finished. Try to follow good practices, but don't get caught up in them so much that you never get a game done; do you really need an object oriented state system that pushes and pops States from a stack, or will a simple switch statement do the trick?
6. Write Games, Not Engines. Actually read that article if the title just made you defensive; it doesn't actually say you shouldn't create your own engine, but rather argues that a better approach is to create some functioning games and abstract the reusable functionality from them rather than trying to write an engine up-front, and it's very good advice.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement