question about code structure/style

Member
Posts: 749
Joined: 2003.01
Post: #1
I'm going to describe how I structured up my code, can some of you enlightend guys give me an opinion? So here goes.

Basically I have a "Game" object with about 50 fields (all the "global" stuff you want to keep available in most methods) and 40 "methods" that constitutes the"bulk" of my code. The methods include everything ranging from the "play game" routine (the very broad preocedure that calls the whole thing), to the "game loop" itself and most routines- functions in the game loop. Most (about 2/3) of the methods call no argument. For stuff that is obviously useful to generalise as a function with arguments (such as say, collision routines between two objects), I do it that way.

Then I have maybe 10 other kind of objects (like "ball", "link", "angle tension", "button"...) with on average about 4 methods each.


Would it be better to have a more "functional" approach (I mean, for every method of the "game" object, call all the stuff you want to change-use in it, so basically keeping everything as a "function", not a "method")?

From what I understand this would force me to think better the "area of interest" of each function, so to avoid for instance changing the score in the middle of the collision routine (I try to avoid that anyway, it's just to give you an idea).

Yet it would be also make it somewhat longer-harder to code (you would have to pass a lot of stuff through functions).

Is my interpretation correct?

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Member
Posts: 131
Joined: 2004.10
Post: #2
I don't think I entirely understand your structure but my thoughts from my interpretation of what you wrote.

Sounds like there is logic found in places were it should not be. This will give you grief if that logic changes, you may have to potentially change more than one place or inspect more than one place for ramifications.

Game object seems fairly large. Also since there only is one game object, does it need to be an object? Sometimes to code a la C with C++ goodies is better. But this is religious territory so go with your personal religion.

Can you break the game object down any further into smaller components and isolate those components from the rest? Probably an overly trivial example, score keeping. Should that be it's own object/module of routines that everyone talks with. Have a simple object/API to update the score and such instead sprinkling all that data around.

Often in application code there is a model (the data) and view (the renderer) separation. May be overkill but if they are tightly coupled, when you change the model, you will probably have to change the view.

Should the game object just hold data. Should you have a game renderer object that uses a game object to display the game state. Should you have a game input object that works with the game object. Should you have a game loop object (if that is really necessary) that works with the game object.

The more you can isolate the tasks that need to be done the easier it is to work on those individual tasks (for creating new code, for maintenance, for finding bugs...)
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #3
Hmmm... thanks. So I should better split the "game" object into different things...

So when I do a function, I can pass in only the "relevant" thing (instead of passing every single variable, group them into objects with similar "scope" and pass the object).

Anyone can post the list of his objects-methods-functions and their interface (what they call)?

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Member
Posts: 131
Joined: 2004.10
Post: #4
That would be up to you, you're the one designing the game. Breaking a problem down to the smallest chunks possible will simplify solving the whole problem easier. Plus, in the beginning, you sometimes don't know all the nuances of the problem at hand and will only stumble over them when they show themselves. Having the problem in smaller manageable pieces will probably make those down the road issues easier to tackle instead of one monolithic chunk of code that does the same thing.

Ultimitely it's your call. Sometimes learning is doing it both ways and seeing for yourself which is better. In other words, reinventing the wheel isn't always that bad.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Return style Coin 13 4,600 Apr 22, 2006 12:11 AM
Last Post: OneSadCookie
  Game Module Structure Question Lunatic 7 3,599 Sep 6, 2005 04:27 AM
Last Post: TomorrowPlusX
  Triangular Data Structure Sta7ic 4 4,328 Jan 22, 2003 02:45 PM
Last Post: OneSadCookie