From design to implementation.
Author
I posted here because this is a beginner problem, although this probably won't help beginners much. go figure. Couldn't think of a better place to post.
Well, it seems no matter what you do, nothing can prepare a game programmer for game programming than programming itself. How ever, it seems there is still too much emphasis placed on technical implementation. Hence we get programmers who know their language, IDE, and APIs like the back of their hand, yet can't write a complete game! Why? You ask.
Because they don't know how to break down a problem in order to program it. The main part of the design phase where this is painfully obvious is going from design doc to tech doc. They can describe the way their game should play, but they can't break it down into programmable pseudocode. Unfortunately, you can't just find tutorials on it. And everyone, I repeat everyone has suffered from it at one point. It's kind of hard to explain, So I hope this is somewhat clear.
Basically, what I'm trying to say is, How do you go from the design to the the implementation? given a design doc, how do you figyre out what code to write? I think that if a diligent noob learned this, his skill would shoot through the roof!
Anyway what's your take on this?
This is one reason why Math is so important in programming. Math teaches you more than "solve this problem", it teaches you "given information X, Y, Z, solve the problem."
There are multiple ways to implement things - some better than others. Look at the problem specified in the design doc.
Example:
"Unit Counter."
Ok, now how do you make this? Logicaly, you would need a variable to hold the number of units. However, you may want to know how many units you have out of a certain number of possible units. So, now you have two variables. Now you want to be able to display this information and alter it at the same time. So, you have to make functions to do this.
Overall, it simple requires you being able to think in a logical manner and solving the problem with the tools are your disposal: functions and variables.
There are multiple ways to implement things - some better than others. Look at the problem specified in the design doc.
Example:
"Unit Counter."
Ok, now how do you make this? Logicaly, you would need a variable to hold the number of units. However, you may want to know how many units you have out of a certain number of possible units. So, now you have two variables. Now you want to be able to display this information and alter it at the same time. So, you have to make functions to do this.
Overall, it simple requires you being able to think in a logical manner and solving the problem with the tools are your disposal: functions and variables.
I don't precisely know how people breaks down 'problems', but from my personal experiments trying to imitate their behavior I've assumed it complicated, error-prone and slow process which involves the possibility that my solution doesn't fit any other aspect.
Myself, instead of trying to break 'problem' solvable, I evolved to take the approach of people who were mistakenly called computer 'scientist', implicitly morph the language to be able solve the 'problem' naturally.
Of course, many languages fail in providing me full support to modify their core or add anything alien into that core. Thought, there are some languages capable of doing it, and some of them does it very well.
To find even better approaches to problems, one should learn bits of theory related to computer programming, understand the system what he/she uses and be open-minded for existing (or new) information and process it before doing opinions or assumptions. Usually it cannot be done clearly, but worth of trying.
Myself, instead of trying to break 'problem' solvable, I evolved to take the approach of people who were mistakenly called computer 'scientist', implicitly morph the language to be able solve the 'problem' naturally.
Of course, many languages fail in providing me full support to modify their core or add anything alien into that core. Thought, there are some languages capable of doing it, and some of them does it very well.
To find even better approaches to problems, one should learn bits of theory related to computer programming, understand the system what he/she uses and be open-minded for existing (or new) information and process it before doing opinions or assumptions. Usually it cannot be done clearly, but worth of trying.
Ignoring the fact that there's probably half a dozen other large, common reasons that programmers don't complete games...
There are two fairly different problems you're describing.
One, the inability of beginners to take gameplay (or a game design doc) and... interpret that into some codified construct.
(Asuming a sane game design doc, which can help a lot) this isn't too big of a problem as it first appears. Most gameplay has been done before, and you can find tutorials about how to create the individual pieces (how do I make an inventory system? how do I implement pathfinding?).
The second problem is perhaps what you're asking about (or running into) but perhaps don't realise it. Almost all beginner programmers are terrible at technical design. A subtle distinction, since the first problem is interpreting natural language into a more technical 'problem. This problem is actual technical design.
Even if you break down the game into smaller problems, the smaller problems still need to work together, and share pieces to some degree. And this technical design isn't something easily taught. It's relatively recently that design patterns have come mainstream so that there is at least some common ground for discussion. Even with those discussions though, learning technical design is a matter for experience. It's near impossible to learn how things work, how they don't, what the implications are of large scale design decisions without actually poking at something.
But yes, spending some time to learn even what certain patterns are common will help the diligent noob fantastically.
There are two fairly different problems you're describing.
One, the inability of beginners to take gameplay (or a game design doc) and... interpret that into some codified construct.
(Asuming a sane game design doc, which can help a lot) this isn't too big of a problem as it first appears. Most gameplay has been done before, and you can find tutorials about how to create the individual pieces (how do I make an inventory system? how do I implement pathfinding?).
The second problem is perhaps what you're asking about (or running into) but perhaps don't realise it. Almost all beginner programmers are terrible at technical design. A subtle distinction, since the first problem is interpreting natural language into a more technical 'problem. This problem is actual technical design.
Even if you break down the game into smaller problems, the smaller problems still need to work together, and share pieces to some degree. And this technical design isn't something easily taught. It's relatively recently that design patterns have come mainstream so that there is at least some common ground for discussion. Even with those discussions though, learning technical design is a matter for experience. It's near impossible to learn how things work, how they don't, what the implications are of large scale design decisions without actually poking at something.
But yes, spending some time to learn even what certain patterns are common will help the diligent noob fantastically.
To go from the design to the implementation you need to know about program design to make life easier. For one example of the basic knowledge required go here: http://users.evtek.fi/~jaanah/IntroC/DBeech/index.htm#rewards.
( parts 4 and 5 in this link are the most specific answers to the question but the whole page helps in giving the 'diligent noob' a context of the topic). Your question has more to do with software dev in general rather than anything to do with games. Unfortunately the examples and exercises in the link are in the same vein: Game app related examples would be better wouldn't they?
The link above and other searches on terms like program design, pseudocode ,top down design, bottom up design, stepwise refinement will give the noob a feel for the basics of things that they can start looking at to get from design to implementation.( or rather the basics of the way things once were if I were an OO zealot or Mr Booch). Object-Oriented (O-O) technology is touted as making these earlier methods obscelete, at least in larger, more trendy, commercial software development, So Object-Orientated Design is also worth a search: You may find lots of info, but it does seem that free exercises/tutorials in OOD are much more scarce than the others methods (again probably a reflection of the commercial significance of OO) , so you may have to part with some cash either for a course or a book containing OOD related tutorials/exercises.
Or... if you are more serious about engineering you are also bound to find some free/demo/trial OOD related software tools in your search (e.g.UML case tools).
Hope this is more concrete help for you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
