Author Topic: Seperating Data, Logic, and Graphics.  (Read 4665 times)

Offline RogueDeus

  • Newbie Mark III
  • *
  • Posts: 47
Seperating Data, Logic, and Graphics.
« on: September 26, 2011, 04:11:25 pm »
(I seek wisdom, I hope this isn't too mundane a question.)

I can see how the separation of Graphics works rather well when using a tool like Unity, so I will skip that part and just straight to something that has me a bit heavy headed at the moment...

I am wondering whether or not I should go out of my way to create separate classes for data and logic parts of a program. (Having never coded for more then small 'fun' things its never been something to consider)

I can not seem to decide how much an object should do for itself, and how much should be done by a proxy class.

Example... A PC attack can be handled by the PC object, directly accessing its own methods stats the PC object has, or by a 'CombatResolution' object that gets an event that the PC is attacking an Enemy, and grabs each involved objects stats through get/set's.

Take a simple attack event. Should the event access an attacker class method, a weapon/ability class method, a combat resolver class method? etc... Each will accomplish the same result, but I am at a loss as to how to implement it with future (ease of) use/extensibility in mind.

Am I explaining this correctly?

What do you recommend?
"It is impossible for a man to learn what he thinks he already knows." - Epictetus

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Seperating Data, Logic, and Graphics.
« Reply #1 on: September 26, 2011, 04:47:57 pm »
There are many ways to do this.  I don't think Unity's way is very good.  We don't separate out the logic and data parts of objects into different files; but we do have rigid conventions for how we organize it.  What you need to do is find something that is easy for you to do consistently, and which you can quickly find your way around in, and then keep doing that.  That's really all there is to it.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline RogueDeus

  • Newbie Mark III
  • *
  • Posts: 47
Re: Seperating Data, Logic, and Graphics.
« Reply #2 on: September 26, 2011, 05:27:05 pm »
There are many ways to do this.  I don't think Unity's way is very good.  We don't separate out the logic and data parts of objects into different files; but we do have rigid conventions for how we organize it.  What you need to do is find something that is easy for you to do consistently, and which you can quickly find your way around in, and then keep doing that.  That's really all there is to it.

Thanks. I figured it was a lot of personal preference and adherence to in house convention. When I was learning Java I had MANY people complain that I should separate data and logic, to the point of creating every base object as something called a POJO (Plain Old Java Object) which did make simple serialization easier.

Can I ask you to give me a simple example?

Say you have a monster being attacked by the PC. How would you organize it methodically?
"It is impossible for a man to learn what he thinks he already knows." - Epictetus

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Seperating Data, Logic, and Graphics.
« Reply #3 on: September 26, 2011, 07:30:28 pm »
Well, "a monster attacking an NPC" isn't really a thing in the way I look at stuff.  We organize all of the game objects into actors and static objects, usually, and then each actor has various abilities that they might trigger.  But the fact is, in AVWW, Tidalis, and AI War the data structures are all wildly different.  You can see the common thread in them in terms of how Keith and I approach this sort of thing, and the utility classes are all shared, but each design is tailored to the specific game.

It's not really a simple thing to answer: when Keith first came on board, he and I spent 6 hours straight on Skype looking through all the code and discussing its structure and design.  And then for a few weeks (if not months) after that, there were still a lot of followup questions.  When you're talking a codebase with hundreds of thousands of lines of code, if not more, it really becomes a complex thing to explain to someone because no matter what your explanation is incomplete if you don't spend a ridiculous amount of time explaining the whole thing.  Something like "Drawing an enemy" might involve code from 30 different classes and files, thanks to general OOP encapsulation, etc.  And you have the loops that render each object, and the stuff that the object does itself, and the wrapper methods around the raw draw calls, and all sorts of things like that.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline RogueDeus

  • Newbie Mark III
  • *
  • Posts: 47
Re: Seperating Data, Logic, and Graphics.
« Reply #4 on: September 26, 2011, 08:05:05 pm »
Well, "a monster attacking an NPC" isn't really a thing in the way I look at stuff.  We organize all of the game objects into actors and static objects, usually, and then each actor has various abilities that they might trigger.  But the fact is, in AVWW, Tidalis, and AI War the data structures are all wildly different.  You can see the common thread in them in terms of how Keith and I approach this sort of thing, and the utility classes are all shared, but each design is tailored to the specific game.

It's not really a simple thing to answer: when Keith first came on board, he and I spent 6 hours straight on Skype looking through all the code and discussing its structure and design.  And then for a few weeks (if not months) after that, there were still a lot of followup questions.  When you're talking a codebase with hundreds of thousands of lines of code, if not more, it really becomes a complex thing to explain to someone because no matter what your explanation is incomplete if you don't spend a ridiculous amount of time explaining the whole thing.  Something like "Drawing an enemy" might involve code from 30 different classes and files, thanks to general OOP encapsulation, etc.  And you have the loops that render each object, and the stuff that the object does itself, and the wrapper methods around the raw draw calls, and all sorts of things like that.

When you say Actors and Static objects I think of instanced 'new' (different in all places) objects and static 'old' (same in all places) objects.

I have been thinking how I wish to handle my first big project and figured I would try limiting serializable objects to data only, with companion manipulator objects that move and change the data from outside. Then, calling that data, to any necessary renderer, every frame (as needed).

When an object like the PC spawns, they should consist of no less than three objects. The data ‘body’, the manipulator ‘monkey’ on its back, and the rendering ‘projector’ on its head sending it to the screen. But in more complex forms, the data body and monkey could consist of as many objects as are bolted together.

Of course, I am a newbie and this may be impossible. :p
"It is impossible for a man to learn what he thinks he already knows." - Epictetus

Offline x4000

  • Chris McElligott Park, Arcen Founder and Lead Dev
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 31,651
Re: Seperating Data, Logic, and Graphics.
« Reply #5 on: September 26, 2011, 09:40:40 pm »
Yep, you can do it that way.  Whatever way makes the most sense to you and is comfortable.
Have ideas or bug reports for one of our games?  Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline RogueDeus

  • Newbie Mark III
  • *
  • Posts: 47
Re: Seperating Data, Logic, and Graphics.
« Reply #6 on: September 26, 2011, 10:24:38 pm »
Yep, you can do it that way.  Whatever way makes the most sense to you and is comfortable.

I will try to show examples and ask for feedback sooner or later. :)
"It is impossible for a man to learn what he thinks he already knows." - Epictetus