The problem is:
#1: How do you properly code a commercial game architecture?
#2: How do you organize it?
#3: How do you make it not become unmaintainable spaghetti code?
#4: What specific things to keep in mind when building this, codewise?
#1: #2: #3: You basically just asked the same question 3 different ways.
The answer to all 3 is, “By leaning on the experience we have gained from past successes, failures, and experiments.”
It is not as if you are going to get an answer here that will just suddenly enlighten you and change your world forever. If such an answer existed, it would be on Google and we would have all done it.
Proper code and organization come from experience. Avoiding spaghetti comes from…experience.
I do however have some general tips to pass on, but I blogged them so that I would not have to retype them every time the issue arose.
Here are some tips for general coding safety
. This helps your stability and memory-leak issues.This post
is more helpful for avoiding spaghetti (feel free to ignore the section on naming conventions). Following a strict set of guidelines means consistency. If your code is consistent then it is easier to work with it. A lot of the suggestions there have sound reasons behind them, and I tried to explain the reasons instead of just listing the points.
One of the things that causes spaghetti at the office is that classes frequently go from public to protected to public to protected to private to whatever.
People just randomly change exposure as they went along. This makes it very hard for me to find functions, members, etc. Just because I left one public section does not mean there are no more.
However, if you follow the rules, leaving a public section does
mean there are no more, and if you missed something you now know you need to scroll back up instead of searching the entire rest of the file.
#4: I keep in mind past successes, failures, and experiments I have had. Seriously, there is nothing that can replace experience. Nothing we can say will suddenly just change the way you think about the code you are writing.
How you can help me:
a) Please tell how do you code your own game projects. What is your thought-process when designing the architecture?
b) Recommend books, blogs, tutorials, videos or anything else on how to organize a commercial video game.
c) Give hints and tips on do's/don'ts when building a game, codewise.
A: Think it all out ahead of time.
People have mentioned UML diagrams and in other posts have mentioned drawing things out. Even my coworker today showed me something he had drawn out about his plans for a new feature. Made no sense to me, but then again I can’t really read hand-written Kanji. So different from typed Kanji…
It may just be me, but this just does not work. UML diagrams just result in me not wanting to make improvements to the code because it would mean extra work updating the UML.
Drawing things out doesn’t help me personally either, even if it is in English. It is just more natural and easier to keep these things in my head until the whole plan is fleshed out. You may not be able to do this until you have more experience, but I can’t say that I recommend UML and friends either. I would recommend just gaining the experience necessary to think in code.
B: The goal of my site
is to provide this kind of insight, even if I don’t have as much time as I would prefer to blog about all the things I want to mention. You may still find something useful there.
C: See my answer to #1, #2, and #3 above.