Archived

This topic is now archived and is closed to further replies.

shakazed

Way of programming

Recommended Posts

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]

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
If you see something you have done that could lead to trouble ahead, fix it! Don''t just let it sit there like I do and then have to start over a little while later .

Share this post


Link to post
Share on other sites
Hi,

About a week ago I was a hardcore OOP programmer who designed everything. But I always ended up getting spaghetti code. Anyways I went to muckfoot for my work expirence and the programmer told me don''t plans things. Get stuff working first. B/c for games you can''t see the forseeable problems that may occur so how can you try solve them on paper. If you do it on paper you''ll end up solving problems which don''t need solving.
When you run into bad design implementations just write a FIXEME comment, then when the basics are up you can go back and solve the problems. Structure the code better, get rid rewritten code etc

hope this helped
Iain Fraser

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Thanks for your tips! I´ve decided to try not using classes for everything I do. Although if there´s something that I really feel need some enclosure I will use them. Graphics initialization and rendering wont be in a class for the moment, because this is what I´ve been having the most trouble with. For some reason after a while my IDirect3DDevice object won´t accept any more calls. :/

Share this post


Link to post
Share on other sites
I find it''s easier to put most of my stuff in classes, albeit big ones. If you store all your code in a million little classes that doesn''t help much does it?

I stick all my setup/shitdown/maintainence stuff (windows/d3d/dinput) in a core class. I also happen to have a seperate class for actual drawing, but it''s core that handles the lost devices and such. It''s just eaisier that way because you don''t have to code up as many methods for special class interactions.

Share this post


Link to post
Share on other sites
Classes are good for sure, although I can´t get them to work thanks to that IDirect3DDevice thingy. Wanted to avoid classes since I couldn´t pass interface objects to them without crashing my app. Pilot error for sure and I guess I´ll have to step back a couple of paces and look for the source of the problem.

Share this post


Link to post
Share on other sites
quote:
Original post by RapidStunna
IMHO: In my humble opinion...
AFAIK: As far as I know...
RTFFAQ: Read the f''ing faq...
RTFD: Read the f''ing docs...


You forgot:
STFW: Search the f''ing web...
STFG: Search the f''ing google...

[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]

Share this post


Link to post
Share on other sites
quote:
Original post by dalleboy
quote:
Original post by RapidStunna
IMHO: In my humble opinion...
AFAIK: As far as I know...
RTFFAQ: Read the f''ing faq...
RTFD: Read the f''ing docs...


You forgot:
STFW: Search the f''ing web...
STFG: Search the f''ing google...

[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]


How could I ever forget those .



---
Brent Gunning | My Site

Share this post


Link to post
Share on other sites