Advertisement

How do you guys like to do this...

Started by February 07, 2000 08:38 PM
3 comments, last by Ratman 25 years, 1 month ago
I no there is no correct way of doing this, but Im starting to write my own DirectDraw engine. Just a simple 2D system to make things easier, something I wont have to rewrite every game I make. I''ve read a lot of books, and Im not sure how I want to orginize it. Like, in Real Time strategy Game Programming, the guy puts everything into classes, lots of classes. Then in Lamothe''s books, the DD stuff is left out in the open, and then all put into the BOB structure. I just want some basic feedback on how you guys like to do things.
What should your engine be able to do?
(B.t.w: It would be cool if anyone could write an article ''bout this stuff )
Advertisement
It all depends upon your tastes. Some people may argue that you program for the situation (classes here but never there), while others (myself included) believe that everyone develops their own style over time. My advice: experiment and discover yours.

What I''ve done with my DDraw lib is a hybrid approach. Most of the common stuff is C syntax, or ''out in the open'' as you said. Other things that vary in different situations are encapsulated in classes. Take for example, graphics primitives. How you plot a pixel or draw a line depends on bit depth. I have a pure virtual class I call DDGFX that is the super of DDGFX_8, DDGFX_15, etc...

This is useful in cases when I''m in a window and the user''s desktop can be any color depth, or I''m writing for 16bpp but some cards are 565 while others are 555 format. One function reads the current pixel format and points a global DDGFX pointer to the appropriate object.

This is what I''m comfortable with. I follow this design paradigm for most of what I do. Some like pure OOP, others like pure procedural. Like I suggested, experiment and find your own style.
My personal approach is this,

First get the hardware functionality working make sure you can switch modes, check input devices etc... then go from there. hehehe j/k

There is a book called Game Design Secrets of the Sages that explains how to market a game and design it... You have to buy it in a package deal At electronics boutique or whatever local video game store you have. I think its called Game Programming v3.0, It comes w/DX6.1, VC++6.0 and the genesis3d engine.

Then decide what modes, colors,devices you will support.
next create a WELL THOUGHT OUT DESIGN... this is sooo important if you just go ahead and start programming you don''t have any direction and you''ll find your more experimenting than striveing(sp) for a goal. If your just doing this for phun and your not going to market it then start with the tile engine or at least that''s what I did. create a class that interfaces with the IDirectDraw object it''s whole job should be to put you in a mode make a few surfaces and then start flipping.

Then create a graphics sort of class that loads your images possibly converts bmp files to your format and stores them in large lists for your program to load. Then one or the other of these classes will have to talk to each other or maybe create and entire new class that talks to both, its up to you. the job of this class is to get the images that you want on the screen to the screen this is the actual tile engine class...


Thats all the advice I have I hope it helped, if not it''s some pretty good banter.
Since you are just starting with it, I''d suggest taking the advice given here and just experiment. If you''re like most people, you''ll probably end up writing more than one wrapper anyway to get it exactly the way you want it. I personally prefer classes now, but I used functions and a lot of globals previously.

- Dave

This topic is closed to new replies.

Advertisement