class design and interaction

The ability to design, say, the Unreal Engine 3.0, comes with experience. The guys behind that engine have designed probably around a dozens other engines before it.

And the ability to "see" when a thing should be represented by a class, also comes from experience. As with math, once you begin to think in the right way, the solutions to these kinds of problems will come much more naturally.

Start out simple, probably not even with an engine, but just a game with simple classes for Player, etc etc. As time goes by, and you start to think object oriented, and as you study the source of other engines, you will begin to think "Hey wait, I can do it this way instead!".

Alot of people look at it as a waste of time, but learning UML is a valuable skill, regardless to the type of program you are creating. Visual marking all your classes up, defining relationships, then start asking "real world" questions, and see if your design holds up. If it doesnt, refactor the drawing, and start asking the questions again.

There are quite a few free UML packages out there, but I can attest to the quality of any of them. Also, Visual Studio 2005 has diagramming built in now, but again, I cant attest to it either, as I use Visio... mostly out of habit. Plus, it supports plotters really well, and I like printing a wallsized copy once the design is finalized.

As to learning how, there are a few books out there, but alot of it comes from experience. Visually modelling your stuff before you implement it, will teach you to do it better and over time parts of it will become second nature.

Another great exercise, once you have a design fleshed out... hand it to another dev and see if they can find scenarios that "break" it. I guess this is part of that whole eXtreme/Agile methodolgy I dont completely subscribe to.

Also, look at the design patterns major vendors publish. Microsoft publishes ALOT of these, and even if they arent directly relevant to say, game programming, they do illustrate good design techniques. Google site:msdn.microsoft.com "Best Practices" for a good selection.

Thanks for the sincere replies.

I like the ideas of sending questions through your design or trying to find break cases where the design fails. I would like to know more about this kind of mentality. I could ask questions, but I would certainly like to know the right ones, or ones that are more revealing as used more in industry.

Second, what is the view when two designs stand up equally in terms of supporting requirements and both being non-faulty? How can we evaluate which one really is better. Do we evaluate which one is easier to change? And if even on that mark, do we evaluate which one requires more or less object creation? .. uses more or less memory? .. more or less virtuals? .. all these small pieces having a factor on performance, or at least a factor on this possible performance/best-of model?

I don't mean to take this topic over the top for the sake of it. Generally I feel I have two equally good designs, where one works via one path of thinking, and the other a separate path. At this fork, which path do I take? (oh romeo, oh romeo, where out thy romeo..)

I would offer more ideas, but I don't want to bias the finality of your replies.

I greatly appreciate your feedback. Thanks.

You're looking for pretty definitive answers to a rather subjective subject. The 'best' design is the one that works, and that you can understand. Readable code/design is worth more than small amounts of performance. If it comes at the cost of large performance, then that may not be true.

I think the key comment in the replies is experience. You can't learn to analyze design until you've done plenty of it yourself.

I didn't find UML particularly usefull, probably because school enforced it. However, the idea behind it - sketching out your design, essentially forcing yourself to think about it more thorougly - is very usefull, and that's what counts. UML is usefull because it's so widely accepted (or seems to be so), that's it imho.

However, a visual design and lengthy thought process are useless when you're not familiar with the subject. It takes experience to get some feeling for what will probably work well, and even then, reality always has some surprizes hidden somewhere. Experience helps you build better designs because you've learned what didn't work well in a particular situation, and what did for those situations. However, you still sometimes need to refactor an implemented design because it wasn't as suitable as you expected.

As for having multiple possible solutions, pick the one that best fits the requirements (fast, flexible, maintainable, fast-to-implement, familiar, whatever else). Two paths usually each have their own strengths and weaknesses. And if they're so equal, just pick the one you like most. Don't make things more difficult than they are.

Whatever you do, don't stop because of a lack of confidence in your decisions. Build confidence instead by continueing and testing whether it really worked as expected. If it didn't: you've learned something and choose one of the other solutions, or enhance the current one. If it worked: you've learned something as well.
If you stop, you'll never know, and your confidence stays low... (hey, that rhymes... ^_^).

Quote:

Original post by skillfreak Thanks for the sincere replies. I like the ideas of sending questions through your design or trying to find break cases where the design fails. I would like to know more about this kind of mentality. I could ask questions, but I would certainly like to know the right ones, or ones that are more revealing as used more in industry.

There are a few "standard" question that can be thrown to any design (do I respect the basic OO principles (papers on these principles can be found on objectmentor.com) ? is my design easy to use? and so on). However, the list of question you can ask really depends on what you do, so I can't help more.

Quote:

Original post by skillfreak Second, what is the view when two designs stand up equally in terms of supporting requirements and both being non-faulty? How can we evaluate which one really is better. Do we evaluate which one is easier to change? And if even on that mark, do we evaluate which one requires more or less object creation? .. uses more or less memory? .. more or less virtuals? .. all these small pieces having a factor on performance, or at least a factor on this possible performance/best-of model?

It is always good to keep some basic metrics on your design, as it helps you to evaluate its simplicity. If two design are equally correct, it is the simplest one that will be the best, because it will be easier to update it later if this is needed (and it will be needed). However, simplicity is not easy to catch. This is not related to the number of classes or virtuals (even if such numbers can help you). This is more related to how objects fits in the design.

Quote:

Original post by skillfreak I don't mean to take this topic over the top for the sake of it. Generally I feel I have two equally good designs, where one works via one path of thinking, and the other a separate path. At this fork, which path do I take? (oh romeo, oh romeo, where out thy romeo..)

The real answer to this question is "chose the one you like the more". This is more or less equivalent to the "Amstramgram, pic et pic et colegram" way of programming, but such kind of choice is really difficult. If you happen to have chosen the wrong way, don't worry - just go back in time and chose the other path. This way, you'll learn what works and what doesn't work. Since the design sense comes from experience, even errors are useful (actually, they are more useful than doing everything right).

Quote:

Original post by skillfreak I would offer more ideas, but I don't want to bias the finality of your replies. I greatly appreciate your feedback. Thanks.

These are really interesting questions. I tried to answer to some of them in my gdnet journal some month ago (well, I haven't added anything to this journal for month). I believe it is in the early posts - something that deal with the design of a 2D graphic engine. I often dealt with the "choice" issue, and tried to give hints about what sould work and what wouldn't work.

HTH,

As an aside, OO courses in universities emphasize the wrong things as you said Captain. Students would benefit more by designing against professor given requirements, and comparing and dissecting results as a class. I did not have a course directed in this manner; frankly, it sucked.

Captain, I really took in your final piece of advise - that is right where I'm at and am elated by this different way to look at it (Ben Franklin - haven't failed... 1000 ways that haven't worked).

Thanks again for your replies. The general similarity among answers has also shown me a great deal. Keep hammering away.

*I'll be checking up on this post over the next few days for other developments* - Sept 28

^sf.

Quote:

Original post by Captain P I didn't find UML particularly usefull, probably because school enforced it. However, the idea behind it - sketching out your design, essentially forcing yourself to think about it more thorougly - is very usefull, and that's what counts. UML is usefull because it's so widely accepted (or seems to be so), that's it imho.

Outside of the world of paid hourly consultants, "proper" UML is very rarely used. It is a good starting point though towards learning how to do a visual representation of your design. In the end, you wont end up doing half the things your supposed to ( as eventually it can almost become easier to just start coding sometimes ), but learning the fundamentals of UML is worthwhile.

And visual designing your classes in advance is invaluable, but sadly many people dont realize that. Im lucky in this regard... I got into programming because I love puzzle solving. Coding itself is fairly boring to me ( as after a few years, it really starts to get repetative ). Its really the design process I find stimulating ( aka... thats where the big puzzles are ). Therefore, I find upfront design work as anything but boring. Then again, I code in a world of deadlines, deliverables and real money. Coding for fun might change my mindset, but at this point, I frankly doubt it.

I am in complete agreement with Seraph. Also, I think there are far too many "start churning out code" types who don't think of code maintenance and scope for expansion.

Once you start writing a complex you need to document it and UML is an excellent way of seeing the big picture. Even if you document stuff after you have written it, it should be done. Then look at the design and see where things can be made simpler or more efficient.

Okay, I've been programming for 3 years and I've only scratched the surface of engine design, but the basic idea is that you should have little or no circularity, say you have two classes a and b. if a depends on b and b depends on a then there might be a better way sometimes. Not always but I've rewritten my whole engine from scratch like 5 times in a row and I've gotten it to run without having to do:

class bar;

class foo
{}

class bar
{}

and in the end it makes the code much more readable, but yah it's all about experience. I will probably run into a bunch of new ways to things...