unit reimagined

Development directions, tasks, and features being actively implemented or pursued by the development team.
Post Reply
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

unit reimagined

Post by safemode »

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.
pheonixstorm
Elite
Elite
Posts: 1567
Joined: Tue Jan 26, 2010 2:03 am

Re: unit reimagined

Post by pheonixstorm »

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
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: unit reimagined

Post by klauss »

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
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: unit reimagined

Post by safemode »

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.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: unit reimagined

Post by klauss »

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
log0

Re: unit reimagined

Post by log0 »

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 ;)
TBeholder
Elite Venturer
Elite Venturer
Posts: 753
Joined: Sat Apr 15, 2006 2:40 am
Location: chthonic safety

Re: unit reimagined

Post by TBeholder »

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
mohsin123
Insys Pilot
Insys Pilot
Posts: 2
Joined: Mon Oct 28, 2013 10:36 am

Re: unit reimagined

Post by mohsin123 »

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,
Post Reply