unit reimagined

Development directions, tasks, and features being actively implemented or pursued by the development team.

unit reimagined

Postby safemode » Thu Mar 14, 2013 11:18 am

nobody likes the unit class. it is huge, all encompassing and wasteful. it is hard to maintain and not intuitive

what I've always wanted to do was create a unit class that handled all physics interactions and draw functions. then real unit classes would have this unit class as a member. they would register callback functions with it for drawing and physics frame updates . then the engine has only a list of these unit members to iterate through. it wouldn't need any info about the class type of the unit. Python code wouldn't need to special case iterating the "unit" list. and best of all, it would be tiny and not need to include classes or headers from anyone. we would be free to design unit classes that only contain data and functions particular to that unit. I think callbacks could free us from the hell that is unit_generic
Ed Sweetman endorses this message.
safemode
Developer
Developer
 
Posts: 2150
Topics: 84
Joined: Sun Apr 22, 2007 6:17 pm
Location: Pennsylvania

Share On:

Share on Facebook Facebook Share on Twitter Twitter Share on Digg Digg

Re: unit reimagined

Postby pheonixstorm » Thu Mar 14, 2013 2:48 pm

Deleted the double post of this thread.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
User avatar
pheonixstorm
Elite
Elite
 
Posts: 1567
Topics: 113
Joined: Mon Jan 25, 2010 7:03 pm

Re: unit reimagined

Postby klauss » Thu Mar 14, 2013 7:28 pm

safemode wrote:nobody likes the unit class. it is huge, all encompassing and wasteful. it is hard to maintain and not intuitive

what I've always wanted to do was create a unit class that handled all physics interactions and draw functions. then real unit classes would have this unit class as a member. they would register callback functions with it for drawing and physics frame updates .


Ehm... probably not the best model. Check out SUCSS, specifically the Source class, which was inspired by Ogre. There's a pattern there that would be very useful for units, which splits the unit in aspects. Think strategy, but not quite.

You have an abstract Source, and then a RenderableSource which handles all things about rendering. Sources can have a RenderableSource, but only if they might be rendered.

For units, you'd have the abstract Unit, and Unit::getPhysicsUnit() which returns a PhysicsUnit. PhysicsUnit would also be abstract, since it would be the PhysicsUnit interface, and concrete instances of many kinds would be possible. NewtonianPhysicsUnit, KeplerPhysicsUnit for orbits, even RemotePhysicsUnit for network clients.

Then you have Unit::getRenderableUnit, and you catch the drift.

Then SUCSS has a SceneManager, that is a factory class, in fact, for all those things, and in fact keeps track of them to be able to update them all when necessary.

So, you'd have a PhysicsManager (abstract, many implementations), and when you instance a physics unit from the right factory, the factory tracks it. So when you have to render, you tell the RenderableUnitManager to do it. This is a departure from SUCSS, since SUCSS actually invokes the methods on the aspects, but for physics it would be best to reverse the pattern to be able to vectorize.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: unit reimagined

Postby safemode » Fri Mar 15, 2013 5:39 am

that doesn't actually help anything. it just makes the current system more complicated.

callback methods allow the unit pointer to be truly general without needing to link to or contain everything about a actual unit. callbacks could allow us to make independent objects that aren't units but still get a physics frame or graphics frame. it would allow us to divorce the scheduling and iteration of drawing and implementing physics from that which needs those things. right now we have to carry a massive unit object to do that. you would have us carry split versions of that object. possibly reducing size but not by much and not without totally rewriting the game to truly split drawing code from code that relates to physics. way more complicated than what I suggest.

all I'm suggesting is add this object to any class and point your dophysics and draw methods to it and that is all you have to do besides adapt to have the game work through a list of the new unit class. reorganization can then happen at our leisure. the rest of the game internals won't care.
Ed Sweetman endorses this message.
safemode
Developer
Developer
 
Posts: 2150
Topics: 84
Joined: Sun Apr 22, 2007 6:17 pm
Location: Pennsylvania

Re: unit reimagined

Postby klauss » Fri Mar 15, 2013 7:26 am

safemode wrote:that doesn't actually help anything. it just makes the current system more complicated.

callback methods allow the unit pointer to be truly general without needing to link to or contain everything about a actual unit. callbacks could allow us to make independent objects that aren't units but still get a physics frame or graphics frame. it would allow us to divorce the scheduling and iteration of drawing and implementing physics from that which needs those things. right now we have to carry a massive unit object to do that. you would have us carry split versions of that object. possibly reducing size but not by much and not without totally rewriting the game to truly split drawing code from code that relates to physics. way more complicated than what I suggest.


Well... I was going to try callbacks as an optimization for SUCSS, as in, having stuff that works implicitly through callbacks so you don't have to really have an instance of Source for each sound source, but rather a set of callbacks that create them on demand.

So... why not get a prototype ready and we take a look? It might solve SUCSS problem too.

safemode wrote:all I'm suggesting is add this object to any class and point your dophysics and draw methods to it and that is all you have to do besides adapt to have the game work through a list of the new unit class. reorganization can then happen at our leisure. the rest of the game internals won't care.


Just try to make it type-and-pointer-safe ;-)

The "pointer-to-function-taking-a-void-pointer-argument" is the complete opposite of safe.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: unit reimagined

Postby log0 » Mon Mar 18, 2013 1:14 pm

I've used a system in another project that sounds somewhat like the one described by @klauss.

It has been purely component based without inheritance. You identify a set of components. The components are managed by component systems(factories), one per component. I simply used vectors for storage.

Then there are complex objects assembled from multiple components(compile time). Their only function is to create/destroy and link components with each other. Component access happens per id(into the component vector) which simplifies memory managment. So the complex objects are simply lists of indices.

In the main update loop the component systems updates are called. Now the interesting part. The systems are double buffered. You read component state from previous frame when updating new frame. Which allows to multi-thread the updates.

The system I've used had just four components/systems. For VS I would expect a few more ;)
log0
 

Re: unit reimagined

Postby TBeholder » Wed Apr 03, 2013 9:17 am

safemode wrote: callbacks could allow us to make independent objects that aren't units but still get a physics frame or graphics frame. it would allow us to divorce the scheduling and iteration of drawing and implementing physics from that which needs those things. right now we have to carry a massive unit object to do that.
So, in other words, what we really need is to separate things of different nature:
  • Graphics.
    With understanding that we'll need at very least two sorts: mesh (ships) and procedural/shader (planets and suns). Some objects (waypoints) exist subjectively for the cockpit, without any physics or controls of their own - i.e. only as graphics, at best tied to devices' functionality of this and maybe another unit.
  • Physics.
    Collisions, emissions... Not necessarily accompanied by associated graphics (jumnp points - yes, warp suppression fields, solar wind - no), devices (solar wind?) or AI.
  • Device functionality
    Anything that juggles internal parameters (shields, "hit-it-and-it-does-this", etc.) - usually controlled by AI/player and sometimes associated with "physical" and graphical elements (shield flash, collision mesh), but not inherently so. For ships optionally represented in pictograms, controls (set priority of power consumptions for X), though not inherently either.
  • Controls: AI/player.
They are all linked, but still different things. Right?
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
User avatar
TBeholder
Elite Venturer
Elite Venturer
 
Posts: 732
Topics: 38
Joined: Fri Apr 14, 2006 7:40 pm
Location: chthonic safety

Re: unit reimagined

Postby mohsin123 » Mon Oct 28, 2013 3:38 am

With understanding that we'll need at very least two sorts: mesh (ships) and procedural/shader (planets and suns). Some objects (waypoints) exist subjectively for the cockpit, without any physics or controls of their own - i.e. only as graphics, at best tied to devices' functionality of this and maybe another unit.
Physics.
If want to learn web designing then join E10-001 dumps web design course and download free COMPTIA tutorials and University of California, Los Angeles demos to learn how to create amazing background patterns for your web project. Best of luck,
mohsin123
Insys Pilot
Insys Pilot
 
Posts: 2
Joined: Mon Oct 28, 2013 3:36 am



Return to Engine Development

Who is online

Users browsing this forum: No registered users and 4 guests

cron