For a long time now I''ve been wanting to make the infamous ''my game'', and I''ve started on it over a hundred times. However, so far I''ve been unable to get anywhere because of my poor design skills. I know UML and I can program all the parts I need, I just have a very hard time making everything work together and with itself in a clean and understandable way. I plan to make it in C++, so I''m focusing on object oriented design, and I''ve always thought I understood it but so far it seems that I''m missing a crucial part of the big picture. Any help will be greatly appreciated.

Large Scale C++ Software Design is okay, but nothing replaces experience. Just fart around and try stuff out, there''s no magic potion to getting better at it.

Ever tried Extreme Programming?

As antareus says, trying to write the code''s usually the best way to identify the road forward. If you can find Dave Sim''s articles on doing an indy comic he talks about doing something every day. That''s probably of value to you. And take the advice of Turd Ferguson, aka Dion Picco: write it two or three times, and try to do as much as possible with as little code as possible.

ld
who''s also pretty sad at getting work done on personal projects

While ''the hard way'' might be the best way to learn, it seems that I''m unable to learn design that way. I''ve been trying for a long time, and everything but my design skills have improved. I figure maybe getting a little boost from a book/site/tutorial etc might help me get started with improving my design skills.

Also, does anybody know of any well designed open source projects I could learn from?

How can you be ''unable'' to learn this way?

You can''t let yourself be afraid of getting it wrong. Like anything else in life you only get better at it if you try. Design a little, ask for opinions on it, and measure the coupling/relative simplicity of it. Generally the simpler the design the better it is. This board is for those type questions.

Don''t let lack of experience or age or amount of education preclude. Just get out there and try.

Perhaps it''d help if you would mention what you want to make. If you don''t have a project in mind then its pretty hard to learn design at all.

If I seem harsh, its because I was where you were about 1.5 years ago.

I''m not afraid, and I''m not unable to learn by experience, I''m just having a hard time picking up design by trying it out over and over. I think it would help to have other people''s opinions and ideas as a starting place to lay my own. Right now I don''t even know what to do when you say ''design a little''. When I''m working on a project I just do stuff as I need it and never really get anywhere.

I have several projects in mind, all of them games of varying types. I''ve finished 1 game already, but it was many years ago and it was simple enough that poor design didn''t interfere. Also, it wasn''t OO at all - C with no structs or even typedefs. My second game will be an RTS, of which I''ve thought a lot about and I have some of the rules thought out etc but haven''t gotten anywhere near coding it yet.

First, let me say that I understand what you''re going thru. I''ve been there, am still there partially. C is very implementation centric meaning you just write what comes to your mind and don''t worry about design at all. The result of this is bad code. You''re seeing only trees but not the forest using this approach. OO on the other hand is a very different way to code. In OO you must have a design doc before you start writing a single line of code. Basically, using the OO approach one should be able to use the design docs and just code the implementation without thinking much about what one writes. Just working from the docs. I think the guy who wrote C compiler for Linux if I''m not mistaken, had written his design on cards beforehand. He then sat down and just copied stuff off them into his code. He was done quickly and the system he coded worked right the first time.

This is taking it into an extreme but it illustrates the idea. Usually the process is iterated(not a waterfall). So how do you start writing a design doc? First start with the game and write use cases for it. Keep an eye on the technology during this phase because that''s a limiting factor. Once you know what the game will need, things such as user interface and content you need to design tools to help you make that game. You most likely will have an engine that runs the content files the tools output.

Let me talk about design a bit. Design is governed by rules or design principles. It is you who decides what rules you deem important over others. You can use design patterns as a standardized tools during you design phase. They usually solve a problem that conforms to your rules. Sit down and make a list of most important rules to least important ones. Rules have a tradeoffs. You can for example shoot for data encapsulation with the understanding that it will create monolithic objects with polluted interfaces. Single responsibilty design principle fixes this.

Go over that list and then look up design patterns that encourage the most important rules in your list. Write some test apps to get a feel for them. Nothing beats an experience. Test apps are a must. While ago I discovered that double clicking caused error in my finite state machine logic. I haven''t taken into account the os way it does things. That''s why you must make test and modify your design to work around os api weirdness.

Ok, after that you will have learned some design language with which you can begin to write your design. Since you also written down the most important design rules that matter to you, you also know what the design should look like from ten miles up. By now you should also have all the pieces, or most of them, that make up the implementation. You won''t know all the details yet because you might have not learned them all but you''ll have the major pieces. You know that you''ll need a map editor, user interface editor, scripting editor and various support libs like math, physics, sounds, music, ai, etc. Now is a good time to figure out how all these pieces will work together. You''ll need to think of versioning system and feature creep. You can solve this numerous ways like using plugins or dlls, implementation inheritance, frameworks, etc.

You now understand that you''ll have to keep your initial implementation very small because the design will be the largest problem for you. After you''ve done couple of designs you get a good feeling for them and can then write larger apps which will be more implementation centric. Basically, start small and work your way up. Actually, you can go back to your C programs and rewrite them in OO. The benefit is that you don''t have to spend time doing implementation as you got it and all the time will go into design work.

Also, something very critical here. Look at other people''s work!!! Look at their app and try to figure out why they did it that way. What problems did their way solved? You''ll find this very enlightening. I know I did.

Lastly, do as much upfront thinking as you can since this will lower the number of code rewrites you''ll have to do. It is also faster and less expensive to do it on paper. If you did it on computer and later discovered that a part doesn''t play nice with what you''ve already got you''ve got to go back and redo other parts. Doing it on paper will expose these design flaws ahead of time so by the time you get on the computer to write the code the design will be pretty solid by then and you''ll run into fewer surprises. Good luck!

quote:Original post by JD
Lastly, do as much upfront thinking as you can since this will lower the number of code rewrites you''ll have to do. It is also faster and less expensive to do it on paper.

This is a heavily structured approach, and if you''re already suffering paralysis on the design front I recommend against it.

The alternative is the modern lightweight process: write a story/small piece of design which describes something you want to happen, then write the tests that will ensure it''s happening as described, then write the code that passes the tests. If you''re just trying to see how something works, you can skip the tests, but if you do so don''t even think about putting the code into production.

ld

The so-called ''lightweight'' method is what I''ve been using, but I usually end up rewriting everything 50-100 times every time I have to add a little feature, so I usually get tired of it and move to something else.
Really what I''m looking for is a good primer on code design (and secondly project design in general).
antareus mentioned "Large Scale C++ Software Design" as ok, and everything I''ve read about it says the same - its not great but its not too bad. Does anybody have any book suggestions that they regarded as better than mediocre?