🔒 Locked

Structure for the coding... please help

Started by hammerstein_02 Jun 18, 2002 at 4:40 AM 5 replies 200+ views

Original Post

Jun 18, 2002 at 4:40 AM

Myself and a few others have just embarked on a project together. I believe we have the skills necessary to code the game, but I would like some advice on structuring the code. My initial design is the following: - Interface Class (Will create the window and contain the main program loop) - Graphics class (Will handle all the directx setups etc. and will also control drawing to the screen) - Game class (Will capture user input, compile a list of required images and pass to the graphics class) - Map Class - Sprite Manager ( Will control all non player objects on the screen. Will be responsible for checking collisions) This is a very rough outline of what I have so far. The other members of the team seem relatively happy with this initial design, but I would like some opinions on wether this is feasible and/or productive. The game class will create/maintain the map object, sprite manager object and will have a pointer to the graphics object. The Interface will create the graphics class and the game object passing it a pointer to the graphics class. This is the first time I have even put my head to a game design, so am quite happy for it to be completely wrong. We are using C++ with DirectX7 just incase that is relevant. Thank-you for your time. [edited by - hammerstein_02 on June 18, 2002 6:21:45 AM]

superpig

Jun 18, 2002 at 5:30 AM

Looks fine - for a 2D game.

It would help if you told us what the game was, so we can see if you''ve left anything out

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net

hammerstein_02

Jun 18, 2002 at 5:43 AM

The game is gonna be a shootem-up. There are gonna be three different types of enemy, ships, buildings, asteroids (Will be in space and on ground) The map is gonna be a tiled background and will loop around. We are in the early stages of design so far, but getting there. So does this system sound about right?

On another point, what would you say is the most efficient way of checking collisions between bullets/player/enemies etc? This section of the design is seemingly eluding me, I can''t figure it out.

Thanks for your time

Hammer

hammerstein_02

Jun 18, 2002 at 10:50 AM

Please.. I could do with some general advice and recommendations, would be greatly appreciated

Indeterminatus

Jun 18, 2002 at 1:41 PM

Hammerstein, I''m missing something very important in your list:
There are no logging / debugging functions.

The first thing you should do is to write a routine that can log down important messages or output an error message on the screen...
I also recommend you to implement a function pointer to a function that shuts down the whole system at once (for example if you face a serious error that wouldn''t allow you to continue playing...better don''t let your OS deallocate all the memory and stuff...got the idea? The occurence of the "blue-screen-of-death" should be reduced at least a little bit

)

Another very neat thing to do would be a console like Quake has. I''m using my own and I''m really glad about it. It is really great for debugging / balancing purposes.
Install a variable-system which lets you change a variables value while running the game...the pros are obvious, I think...

well, these were just recommendations, you don''t have to include them...hope i could help you at least a little bit

Yours,

Indeterminatus

--si tacuisses, philosophus mansisses--

IndirectX

Jun 18, 2002 at 1:57 PM

quote:
Original post by Indeterminatus
There are no logging / debugging functions.

A couple already exist to get you started.

quote:

The first thing you should do is to write a routine that can log down important messages or output an error message on the screen...

This one is called TRACE (or variants, such as ATLTRACE/_RPT/_RPTF).

quote:

I also recommend you to implement a function pointer to a function that shuts down the whole system at once

And this one is called ASSERT (or variants: ATLASSERT, _ASSERT, _ASSERTE).

Although I agree that you will need a way to report errors to the user at some point.

Arild Fines

Jun 19, 2002 at 1:53 PM

Looks more like a modular design to me - why not just dispense with the classes?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.