Yikes! Please don’t take that as 100% true! If you design all your classes that way, you will find that some features become extremely difficult to implement in a game.

For example, if you have a Door and a Key object in your game, how do you use the key to unlock the door? Is it Key->unlockDoor( door ) or is it Door->unlock( Key ) ? What if this door is in a room in which all locks do not function? So, all unlock() functions must fail. How do you code that feature? Do you add another parameter to Door’s unlock() method? Do you keep adding parameters to all methods in all object classes whenever you want to add a new feature? Maintenance nightmare! Yes, it is good academic object-oriented design, but it can be bad game design.

I say keep some classes as data containers (nouns), and have other classes perform the actions (verbs). A game can be seen as a view of data. Merging the view of the data into the data itself is a bad idea, in my experience.

Good luck!
Neil

So, you want to try and increase the chances you have for such epiphanies. I find that reading *good* open source code and listening to others explain something, even if it’s something I supposedly already know, really helps. Also, explaining it to others. You have to really understand something to teach it, and trying to figure out how best to teach it can help you internalize it.

For instance, my native language, so to speak, is PHP. I had been working on finding good tips on how to write a good modular, plugin architecture and come up dry, and my multiple own attempts hadn’t gotten very far. Then I stumbled across Drupal. Suddenly, after a week or two of on-and-off studying, (fortunately it’s a very well documented project), I realized how to do function-level polymorphism in PHP and how to use objects and arrays “properly”. Even when I’m not working on Drupal now, my own code follows similar patterns and is almost gleefully elegant in places. (You know you’re doing something write when you can look at it and go “wow, that’s so elegant” rather than “wow, that’s so cool.)

Also helpful is to mimicry. Find an API that you like, or think is well implemented. Then try to reimplement it yourself. It doesn’t have to be an exact copy, and you can look at the actual code at times to figure out how they handled some particularly thorny issue, but try to make it your own. It gives you a good target to shoot for, but a challenge to figure out how to make it elegant. You’ll probably end up with something that’s similar to but not identical to (in API or internals) what you were copying. If you get a great idea in the process, go ahead and do it. Even if the code you end up writing you never use, it’s still a great learning experience. (In my case, I had to write a new CMS at work, fast. What I ended up with is not Drupal, but is very Drupal-esque, and in some places I find it even more elegant than Drupal’s code after I’ve gone back and looked at it.)

The Ruby folks are big on “beautiful code”. I find that a waste of time. “Elegant code”, however, is something to shoot for. I define elegant code as being code that logically makes sense to read, accounts for all possibilities without funky if-then or switch statements, and just “feels clean”. When you write a routine that seems to “just work” in your mind, and does so in code, you just know it in your gut. Let yourself take the time to write such code, and you’ll find your quality improving over time.

Much of that is language-specific, of course. What makes something elegant in PHP (arrays, implode, and explode are AWESOME) is not what makes it elegant in Perl (if it can’t be done in a regex it’s not worth doing) is not what makes it elegant in Java (switch should never be used, and else-if is the enemy) is not what makes it elegant in C++ (uh, not really sure )

Another refactoring guideline I use is what I call the Hawking Rule. Steven Hawking (at least I think it was him; it could have been Einstein ) once noted that the most unlikely number in the universe is 2. Something can be unique, and occur only once. Or it could occur lots and lots of times. But for something to occur twice and only twice? Extremely unlikely. (In context, it means that either we’re the only intelligent species in the universe or there’s a crapload of them out there, but there won’t be just one more.)

In code, that means the first time you write something, go ahead and write it inline if it makes sense to. Then if you find yourself writing it again elsewhere, or something very similar, 99% chance it means you’re going to write it a 3rd, 4th, and 497th time. STOP RIGHT THERE, and refactor it into a general routine (function, object, method, library, whatever your language does with such things). The extra 30 minutes you spend over copying and pasting it “just one time” will save you days of debugging next month.

You know, I really should just put these long entries in my own blog and trackback to you.

As for my C++ code, I suppose my fears aren’t very specific. Sometimes it is easy to look at my code and say, “Oh, no! What if I am doing it wrong?!?”

And such questions aren’t very helpful at all. I should make an effort to ask “Is there a way I can improve this code?” I think there will be less freaking out and more productivity as a result. B-)

My advice to you would be: find the coding style that works best for you. The benefit you have as a lone wolf is that you don’t have to design your code for others to work with. If you like to structure your code in a certain way – even if others may frown on it – then go for it; you don’t need to defend your coding style to others. Think only of what you want from you code. When you’re alone, it pays to be egocentric.

This all becomes incredibly obvious as you grow and you come across less and less code that is up to your own personal standards, let alone code that you can learn from.

So.. Don’t worry so much about working on your own.

btw. If you want to look at some very nice high-quality code (IMO) in an open project, take a look at antigrain.

While I can expect documentation in code to be sparse, it can be like reading an old work of Shakespeare without notes on the left page to help you along. If you get it already, there is no problem, but if you are exposed to it for the first time, it can be a real chore to get through.

I suppose it is just a matter of experience. I’ll learn what works and what doesn’t. Five years from now, I’ll probably look back at my concerns today and laugh.

I would recommend not to focus to much on “perfect” code. The search for this holy grail prevents one to learn from experience. During development, you will find parts that are not as flexible as you would want, or cause more bugs than you can tolerate. Then you can find a solution, using development forums etc.

And working with other developers does work. I think reading others code will help if working with others is not an option.

Ziggy