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
unit reimagined
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
unit reimagined
Ed Sweetman endorses this message.
-
- Elite
- Posts: 1567
- Joined: Tue Jan 26, 2010 2:03 am
Re: unit reimagined
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
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: unit reimagined
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.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 .
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.
-
- Developer
- Posts: 2150
- Joined: Mon Apr 23, 2007 1:17 am
- Location: Pennsylvania
- Contact:
Re: unit reimagined
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.
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.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: unit reimagined
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.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.
So... why not get a prototype ready and we take a look? It might solve SUCSS problem too.
Just try to make it type-and-pointer-safesafemode 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.
The "pointer-to-function-taking-a-void-pointer-argument" is the complete opposite of safe.
Re: unit reimagined
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
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
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: unit reimagined
So, in other words, what we really need is to separate things of different nature: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.
- 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.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
-
- Insys Pilot
- Posts: 2
- Joined: Mon Oct 28, 2013 10:36 am
Re: unit reimagined
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.
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,