Here's some tips I find helpful:

*Don't abstract TOO much.

*Use get/set methods with classes for type checking

*Use namespaces

*Define an EXACT method of commenting and writing code

*DESIGN DESIGN DESIGN. I can't express how much a simple five-minute technical design for class organization can help in the long run.

*REFACTURE REFACTURE REFACTURE. Don't let ugly sit there - fix it. As you get better, you'll find yourself refacturing less because you're code will look better from the start.

*Create modular code. Have classes represent exact objects. You shouldn't have classes that simply do random operations. Those should be functions IMHO.

Edit: fixes.

[edited by - RapidStunna on August 10, 2003 12:28:01 PM]

quote:Original post by shakazed
Yeah I could spend some more time on the design part. Do you split up the code in dinput, d3d, dsound or something like that?

Not really - I usually don''t find myself in situations where that''s necessary - or at least not to that extent. For me, I usually use some sort of Direct3D manager - that handles initialization, resource management (ie lost devices) and clean-up. I also have derived classes of any Direct3D objects, so resource management is automatic and structure is common.

As for input, I have an input manager that can add devices. The devices are abstract but there are some default ones for keyboard and mouse. I have to go now, but the same applies to the rest of the code.

---
Brent Gunning | My Site

Being a hardcore OOP programmer does not entail designing to your death. There''s a design methodology called Xtreme programming where it goes like the following:

1.) Code a bit
2.) Does it work? Good! No? refacture and redesign
3.) Go to step one again

I would never recommend designing out a whole class, from it''s method parameters to its constructor types. That''s just pointless because the same design could be impelemented in code. Also, like WizHarDx stated, you cannot foresee the problems which may occur. It is, however, useful to layout a plan of how your objects interact with each other. If you just have one big list of different objects that never interact, either you''re programming EXTREMELT and most likely TOO modular, or you should definitly consider redesigning.

OOP isn''t for everyone. It''s not just a different way to program, it''s a different mindset all-together. You can''t learn it from tutorials, you have to actually experience it. It''s thinking of code as actual representations of objects, not just operations to do stuff. If you can''t get into that mindset, but need to get something done, don''t use OOP. Standard C programming style will do fine.

A little bit of my life story: I never liked OOP programming until the beginning of this summer. There I got a job at a nearby software company. One of the members there is an extreme OOP programmer and it took a few talks with him and some borroed books before it all clicked in. Since then I can''t imagine it differently.

---
Brent Gunning | My Site

I''ve been using a model view controller (aka MVC) design pattern for my last few games, where:

Model = game engine, logic, not device specific
View = graphics engine, usually uses a device specific API
Controller = input engine, usually uses a device specific API

When I first started writing like this it has a feeling like your code is a bit redundant & bloated. But once you are at the end of the project, and you are asked to change this and or that you will probably appreciate the ease of maintenance benefit.

Also from a reusability point of view - it is logical to make system dependant and non-system dependant components seperate so that porting becomes easier.

One issue you''ll quickly run accross is communications between the components, for example the View needs information from the Model - how should this be done. Every method I''ve thought up is derived from one of the following two ways:

1) View gets entire state of the Model
In a simple game, such as pacman for example, the view will just ask the Model each frame "where is the pacman", "where is the ghost", etc.

2) View gets differential of Model state
For example in the pacman game, the view will receive information that the ghost has moved.

The second way is more complex but is more efficient performance-wise.

Its the same thing with regard to Controller and Model - just much simpler IME.

Heh heh forgive my long windedness hope this helps.