From: Nick P. <np...@gm...> - 2004-11-10 02:37:44
|
After 20-some odd comments on the last thread, I think its time to step back and take another look at some assumptions. Specifically, the hierarchy of parts. Is this REALLY a good idea? Yes, its very general, and I like general as much as the rest of you. However, is it really too complicated for us? After all, most of the vehicle setup is fixed, and not mutable in any way. The only parts that are really extensible/variable to the same degree are: - Movement systems. I can see adding new ones of these. For example, CORE Command doesn't REALLY use Flight movement, it just pretends it does. - Vehicle Perks and Flaws. - Weapon Perks and Flaws. - Production Types (?) - Assorted user-specified fluff fields. - Weapons themselves. The rest of the vehicle (Size, Maneuver, Armor, Crew, Deployment Range, Reaction Mass) is very immutable. EVERY vehicle is going to have all of the above. On the other hand, we've got some perks that do weird things. The one-way/two-way transformation perks, for example. Or the costing of the FTL perks or crew levels. Or even just the way Arms are both Perks and Weapons. So... Is there a simpler model that reflects this observation and is easier to implement? -- -Nick Pilon |
From: Jake S. <Ja...@bi...> - 2004-11-10 02:55:19
|
On 10/11/2004, 02:37, Nick Pilon wrote: > After 20-some odd comments on the last thread, I think its time to > step back and take another look at some assumptions. > Specifically, the hierarchy of parts. Is this REALLY a good idea? Yes, > its very general, and I like general as much as the rest of you. > However, is it really too complicated for us? After all, most of the > vehicle setup is fixed, and not mutable in any way. > So... Is there a simpler model that reflects this observation and is > easier to implement? I should be asleep by now, but I'm not... gah... I saw this as there being a 'Part' abstract base class which implements the hierarchy and has abstract methods for things like "Calculate my TV", and then have specific classes for things like "My Weapons" or "My Statline" which have their own accessors to formalise the vehicle's structure whilst retaining the hierarchy to make it easier to perform a recursive "Find out my TV" operation. Or, y'know, any other vehicle-wide thing you wanted to do, like walk the structure and write it out to XML and vice-versa. But that was just off the top of my head. It'd probably be /easier/ to just hardcode the structure entirely, but then it would also make it a lot trickier to extend, expand and/or update to SilCore 4 when the time comes. -- Jake |
From: Adam T. <kr...@co...> - 2004-11-10 03:19:02
|
On Nov 9, 2004, at 6:54 PM, Jake Staines wrote: > On 10/11/2004, 02:37, Nick Pilon wrote: > >> After 20-some odd comments on the last thread, I think its time to >> step back and take another look at some assumptions. > > I saw this as there being a 'Part' abstract base class which > implements the hierarchy and has abstract methods for things like > "Calculate my TV", and then have specific classes for things like "My > Weapons" or "My Statline" which have their own accessors to formalise > the vehicle's structure whilst retaining the hierarchy to make it > easier to perform a recursive "Find out my TV" operation. Or, y'know, > any other vehicle-wide thing you wanted to do, like walk the structure > and write it out to XML and vice-versa. > > But that was just off the top of my head. It'd probably be /easier/ to > just hardcode the structure entirely, but then it would also make it a > lot trickier to extend, expand and/or update to SilCore 4 when the > time comes. This was my line of thought too. I just didn't like the idea of using an interface, well... because an interface doesn't let us reuse code on parts that use the same calculation for TV or what-have-you. There might be zero case for this, I know... but a Perk is extended into a RatedPerk, and a Perk is a part of a vehicle. To me, if something /is/ something more generic, then it symbolizes a parent/child class relationship. An interface is more along the lines of attempting to provide multiple inheritance without multiple inheritance. IMO, multiple inheritance and interfaces are pretty nasty things if done incorrectly, and are to be avoided when a clear class relationship between all the bits can be seen. For example, Apple uses interfaces in one of their API sets on the Mac, but they are limited to controller methods. These methods could be found ANYWHERE in an app depending on where it makes sense: attached to the view components, data components, or some mixture of the two. In this case it makes sense, because you don't have a clear relation between the methods that need to be callable and the classes that will implement them. In this case, I think we have a clear relation, and thus an abstract parent class is much more appropriate. Arms are an exception, but if components of a vehicle are treated like parts, arms and the like do become easier to implement within the component tree. I actually have a senior project at my college where I am implementing a pure OO 3D engine with serial I/O to communicate with a suit a couple other students are building, in Objective-C. Objective-C is similar to Java in many respects (no multiple inheritance, interfaces). I have spent almost enough time delving into the problem of how objects relate to each other in a 3D engine that it is starting to be driven more on intuition. If you like, I can provide a quick diagram showing how I believe things interact. It might help make what I am thinking in my head a little more clear than my words tend to do. - Adam |
From: Thorsten H. <gea...@th...> - 2004-11-12 19:04:08
|
Hi, * Adam Thayer wrote (2004-11-10 04:18): >If you like, I can provide a quick diagram showing how I believe >things interact. It might help make what I am thinking in my head a >little more clear than my words tend to do. That would be very useful! Go ahead! Thorsten --=20 He who passively accepts evil is as much involved in it as he who helps to perpetrate it. He who accepts evil without protesting against it is really cooperating with it. - Martin Luther King |
From: Brandon D. <br...@ho...> - 2004-11-10 03:03:08
|
Not being a programmer I can't really comment very well on this... but I'll do my best to share what I learned from Composer ----- Original Message ----- From: "Nick Pilon" <np...@gm...> To: <gea...@li...> Sent: Tuesday, November 09, 2004 6:37 PM Subject: Planning, Round #2 > After 20-some odd comments on the last thread, I think its time to > step back and take another look at some assumptions. > > Specifically, the hierarchy of parts. Is this REALLY a good idea? Yes, > its very general, and I like general as much as the rest of you. > However, is it really too complicated for us? After all, most of the > vehicle setup is fixed, and not mutable in any way. The only parts > that are really extensible/variable to the same degree are: > > - Movement systems. I can see adding new ones of these. For example, > CORE Command doesn't REALLY use Flight movement, it just pretends it > does. > - Vehicle Perks and Flaws. > - Weapon Perks and Flaws. > - Production Types (?) > - Assorted user-specified fluff fields. > - Weapons themselves. > > The rest of the vehicle (Size, Maneuver, Armor, Crew, Deployment > Range, Reaction Mass) is very immutable. EVERY vehicle is going to > have all of the above. > > On the other hand, we've got some perks that do weird things. The > one-way/two-way transformation perks, for example. Or the costing of > the FTL perks or crew levels. Or even just the way Arms are both Perks > and Weapons. The transformation perks aren't really perks at all, they're entirely new vehicle type. They're very similar structurally in terms of calculation to multi-section vehicles, but simply easier (one parent vehicle, a number of sub vehicles that generate a final stat value) FTL Is a pretty simple thing, but it's not really a perk in the same sense either. I included it in my calculations stage along with production type for my SilCORE composer. Arms I wasn't too sure about, so I had them as regular perks, and then made a separate value in the data structure of each vehicle which was the punch value. > > So... Is there a simpler model that reflects this observation and is > easier to implement? > > -- > -Nick Pilon > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > -- > gearwerk-worker mailing list > gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearwerk-worker > |
From: Adam T. <kr...@co...> - 2004-11-10 03:25:22
|
On Nov 9, 2004, at 6:37 PM, Nick Pilon wrote: > The only parts > that are really extensible/variable to the same degree are: > > - Movement systems. I can see adding new ones of these. For example, > CORE Command doesn't REALLY use Flight movement, it just pretends it > does. > - Vehicle Perks and Flaws. > - Weapon Perks and Flaws. > - Production Types (?) > - Assorted user-specified fluff fields. > - Weapons themselves. > > The rest of the vehicle (Size, Maneuver, Armor, Crew, Deployment > Range, Reaction Mass) is very immutable. EVERY vehicle is going to > have all of the above. > > On the other hand, we've got some perks that do weird things. The > one-way/two-way transformation perks, for example. Or the costing of > the FTL perks or crew levels. Or even just the way Arms are both Perks > and Weapons. > > So... Is there a simpler model that reflects this observation and is > easier to implement? Hmm, forgot to mention that I am not against combining stats into the vehicle class itself. Things like size, maneuver, armor, and other things you mentioned are attached to the vehicle... why make them a part? They are an aspect of a vehicle, and should be as such, and tracked by the vehicle class itself. I would even argue that fluff fields might even want to be part of the vehicle since we are unlikely to have fluff fields around perks. Weapons, Perks and Flaws are really the only parts that should be contained within an instance of a vehicle. - Adam |
From: Nick P. <np...@gm...> - 2004-11-12 00:23:11
|
On Tue, 9 Nov 2004 19:25:09 -0800, Adam Thayer <kr...@co...> wrote: > Hmm, forgot to mention that I am not against combining stats into the > vehicle class itself. Things like size, maneuver, armor, and other > things you mentioned are attached to the vehicle... why make them a > part? They are an aspect of a vehicle, and should be as such, and > tracked by the vehicle class itself. I would even argue that fluff > fields might even want to be part of the vehicle since we are unlikely > to have fluff fields around perks. Weapons, Perks and Flaws are really > the only parts that should be contained within an instance of a > vehicle. This is pretty much the decision I was hoping someone else would arrive at. I agree with Adam - I think that only Movement, Weapons, and Perks/Flaws really need to be "modular". Recursion's a fine thing, but too much of it can make your life very unpleasant, and I think that's what trying to break down the entire vehicle into a tree of classes would wind up being. This seems to be the simplest way to handle things. So this means that a vehicle is composed of: - A bunch of fields for things like Armor, Maneuver, etc. - A list of movement types, descended from some common base class or implementing some common interface. The list of available ones gets initialized from an XML file, so there needs to be a manager class for all available movement types too. - A list of perks and a list of flaws, descended from some common base class or implementing some common interface. Again, initialized from an XML file, so we're going to need a manager class. - A list of weapons, drawn from a weapons database, which can be part of the vehicle's save file or a separate file. Going to need another manager class. By manager class, I mean a class that: - Handles reading the perk/flaw/weapon/movement XML file and creating the necessary objects for each. - Stores these necessary objects in a list or other convenient data structure. - Can provide an iterator over the objects. - Can return a specific object based on some query string. (Internal name, say) Any objections or thoughts so far? -- -Nick Pilon |
From: Brandon D. <br...@ho...> - 2004-11-12 00:32:10
|
Once again I'll add in my completely unprofessional experience here. For Composer, I did up each vehicle as having a certain set of fixed statistics, maneuver, deployment, etc, and then separate DBs for the Perks and Weapons (I included Movement in the main vehicle stats, as I did the movement stats before I came up with that idea ^^;; Maybe in a later version I'll include it as modular also, but for now it works) Either way, there's no real need to make parts modular if every vehicle has them, such as maneuver, so your idea seems to make sense from my unprofessional opinion here... -Brandx0 P.S. is there any way I can switch e-mail addys? I'd prefer it to go to another address, this hotmail not handling Thorsten's messages is annoying me. ----- Original Message ----- From: "Nick Pilon" <np...@gm...> To: <gea...@li...> Sent: Thursday, November 11, 2004 4:23 PM Subject: Re: Planning, Round #2 > On Tue, 9 Nov 2004 19:25:09 -0800, Adam Thayer <kr...@co...> wrote: > > Hmm, forgot to mention that I am not against combining stats into the > > vehicle class itself. Things like size, maneuver, armor, and other > > things you mentioned are attached to the vehicle... why make them a > > part? They are an aspect of a vehicle, and should be as such, and > > tracked by the vehicle class itself. I would even argue that fluff > > fields might even want to be part of the vehicle since we are unlikely > > to have fluff fields around perks. Weapons, Perks and Flaws are really > > the only parts that should be contained within an instance of a > > vehicle. > > This is pretty much the decision I was hoping someone else would > arrive at. I agree with Adam - I think that only Movement, Weapons, > and Perks/Flaws really need to be "modular". Recursion's a fine thing, > but too much of it can make your life very unpleasant, and I think > that's what trying to break down the entire vehicle into a tree of > classes would wind up being. This seems to be the simplest way to > handle things. > > So this means that a vehicle is composed of: > - A bunch of fields for things like Armor, Maneuver, etc. > - A list of movement types, descended from some common base class or > implementing some common interface. The list of available ones gets > initialized from an XML file, so there needs to be a manager class for > all available movement types too. > - A list of perks and a list of flaws, descended from some common base > class or implementing some common interface. Again, initialized from > an XML file, so we're going to need a manager class. > - A list of weapons, drawn from a weapons database, which can be part > of the vehicle's save file or a separate file. Going to need another > manager class. > > By manager class, I mean a class that: > - Handles reading the perk/flaw/weapon/movement XML file and creating > the necessary objects for each. > - Stores these necessary objects in a list or other convenient data structure. > - Can provide an iterator over the objects. > - Can return a specific object based on some query string. (Internal name, say) > > Any objections or thoughts so far? > > -- > -Nick Pilon > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > -- > gearwerk-worker mailing list > gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearwerk-worker > |
From: Nick P. <np...@gm...> - 2004-11-12 00:42:58
|
On Thu, 11 Nov 2004 16:31:51 -0800, Brandon Drew <br...@ho...> wrote: > Either way, > there's no real need to make parts modular if every vehicle has them, such > as maneuver, so your idea seems to make sense from my unprofessional opinion > here... Doubly good. > P.S. is there any way I can switch e-mail addys? I'd prefer it to go to > another address, this hotmail not handling Thorsten's messages is annoying > me. You should be able to. I don't think the gearwerk-worker list is in any way tied to the address you used for your sourceforge account, so you should be able to switch them independently. Just go to the list page, unsubscribe one address and subscribe the other. -- -Nick Pilon |
From: Jake S. <Ja...@bi...> - 2004-11-12 01:25:07
|
On 12/11/2004, 00:42, Nick Pilon wrote: > On Thu, 11 Nov 2004 16:31:51 -0800, Brandon Drew <br...@ho...> wrote: >> Either way, >> there's no real need to make parts modular if every vehicle has them, such >> as maneuver, so your idea seems to make sense from my unprofessional opinion >> here... > Doubly good. Yeah - seems good to me. I was as much thinking about multi-sectioned vehicles where some sections don't necessarily have /all/ of the basic stats that a single standalone vehicle would have, so we'd have to be careful to only represent those stats that all sections have - size, armour, etc. - rather than things like, as you mentioned, movement systems. The other thing this brings to mind is that we also have to have the vehicle maintain an optional list of 'sections' for multi-sectioned vehicles, each of which is most of a vehicle in its own right... I got the idea that the sections themselves couldn't have additional sections, which would suggest to me that the base hull is in fact a specialized instance of a section which also contains a list of other sections... I disagree, though, "too much recursion" is semantically equal to "out of stack space"; anything else is nonsense. ;-) -- Jake |
From: George L <gli...@ro...> - 2004-11-12 01:58:34
|
I've jsut been sitting quietly reading to the various planning ... having little expereince myself, I don't have much to contribute in this way I guess, but I do have a suggestion: Currently there is a person trying to write a SilCORE board game sim, and it would be good if the VCS was done up as a library that could be used by another program - the goal of this is server-side checking of vehicle stats to avoid cheats for example, as well as possible on-the-fly TV evaluation for campaign tracking purposes (say you lose a gear or capture one, you might want to know what you're going to get out of salvaging it for example). |
From: Thorsten H. <gea...@th...> - 2004-11-12 19:20:57
|
Hi, * George L wrote (2004-11-12 02:58): >Currently there is a person trying to write a SilCORE board game sim,=20 >and it would be good if the VCS was done up as a library that could be=20 >used by another program - the goal of this is server-side checking of=20 >vehicle stats to avoid cheats for example, as well as possible=20 >on-the-fly TV evaluation for campaign tracking purposes Not too difficult if done right, just another view to the vehicle which acts as a network server and encapsulates the regular XML files. Thorsten --=20 Whenever there is a conflict between human rights and property rights, human rights must prevail. - Abraham Lincoln |
From: Nick P. <np...@gm...> - 2004-11-12 19:47:14
|
On Thu, 11 Nov 2004 20:58:26 -0500, George L <gli...@ro...> wrote: > Currently there is a person trying to write a SilCORE board game sim, > and it would be good if the VCS was done up as a library that could be > used by another program - the goal of this is server-side checking of > vehicle stats to avoid cheats for example, as well as possible > on-the-fly TV evaluation for campaign tracking purposes It'll definitely be possible, but I don't think we want to surrender control over our XML format or class structure for that end. We need stuff that works for us, and if he finds it useful, that's great. -- -Nick Pilon |
From: Jake S. <Ja...@bi...> - 2004-11-12 19:59:50
|
On 12/11/2004, 19:47, Nick Pilon wrote: > On Thu, 11 Nov 2004 20:58:26 -0500, George L <gli...@ro...> wrote: >> Currently there is a person trying to write a SilCORE board game sim, >> and it would be good if the VCS was done up as a library that could be >> used by another program > It'll definitely be possible, but I don't think we want to surrender > control over our XML format or class structure for that end. We need > stuff that works for us, and if he finds it useful, that's great. I read this and assumed he'd be instancing the 'vehicle' class (or whatever the UI ends up going to) directly, in which case I'd have thought that /whatever/ we end up doing interface-wise it's still going to be usable and queriable by a third-party app, and it's in the interests of the open-source ideal, good programming style and so on to make the class generic enough to be thus reusable... and shouldn't actually involve any extra effort. In theory, we shouldn't end up /relying/ on our particular UI being the one and only consumer of the class if we design it properly... -- Jake |
From: George L <gli...@ro...> - 2004-11-12 21:25:40
|
It wasn't my intention to suggest that development of the other program should guide this one's file structures (he -will- be using XML, so if worst comes to worst schemas can be translated between each other, or he might just use this program altogether for reading the sheets etc in the end - basically, plug it into his front-end as the vehicle interpreter). So I mentioned it because the only thing needed in that case would be a library-type implementation of this, or just what Thorsten suggested, which may well be a better idea. :) Nick Pilon wrote: > On Thu, 11 Nov 2004 20:58:26 -0500, George L <gli...@ro...> wrote: > >>Currently there is a person trying to write a SilCORE board game sim, >>and it would be good if the VCS was done up as a library that could be >>used by another program - the goal of this is server-side checking of >>vehicle stats to avoid cheats for example, as well as possible >>on-the-fly TV evaluation for campaign tracking purposes > > > It'll definitely be possible, but I don't think we want to surrender > control over our XML format or class structure for that end. We need > stuff that works for us, and if he finds it useful, that's great. > |
From: Adam T. <kr...@co...> - 2004-11-12 01:20:53
|
On Nov 11, 2004, at 4:23 PM, Nick Pilon wrote: > On Tue, 9 Nov 2004 19:25:09 -0800, Adam Thayer <kr...@co...> > wrote: > <snip> > > So this means that a vehicle is composed of: > <snip> I would agree, although I threw together a quick diagram of a possible class structure for how 'parts' work. (Mind you, it does ignore Manipulator Arms, but I personally think that it belongs as part of the Vehicle class) http://home.comcast.net/~krevnik/files/ProposedStructure.pdf (20KB) If we can somehow easily fuse Vehicles and Multi-Section Vehicles into a feasible single class, we have a class tree that is about 3 deep, with 2 abstract classes defining components in general, and components that contain components. The "Complex Perks/Flaws" describes all the custom classes that would be created to describe Sensors/Comms, cargo, and other perks/flaws that don't go by a rating, but some other measure. It can be tweaked as we get a little further in and should help the more visual among us. Also realize this diagram doesn't explain how an example vehicle would actually store parts within itself, I can add a second diagram showing that if people want it. > By manager class, I mean a class that: > - Handles reading the perk/flaw/weapon/movement XML file and creating > the necessary objects for each. > - Stores these necessary objects in a list or other convenient data > structure. > - Can provide an iterator over the objects. > - Can return a specific object based on some query string. (Internal > name, say) Yup, this sounds like what I am thinking on how it would behave as well. Although I think the data structure for storing the objects will wind up being a little more complex than a list. ;) - Adam |
From: Jake S. <Ja...@bi...> - 2004-11-12 01:28:21
|
On 12/11/2004, 01:20, Adam Thayer wrote: > I would agree, although I threw together a quick diagram of a possible > class structure for how 'parts' work. (Mind you, it does ignore > Manipulator Arms, but I personally think that it belongs as part of the > Vehicle class) As I suggested in the mail that I sent just as this one arrived, I reckon we'd be better off having the 'vehicle' class a more specialised descendent of the 'section' class, since all vehicles will follow the same rules that a section does but not all sections will follow the same rules as a vehicle... but aside from that, yeah, looks good to me. ;-) -- Jake |
From: Nick P. <np...@gm...> - 2004-11-12 02:42:48
|
On Thu, 11 Nov 2004 17:20:43 -0800, Adam Thayer <kr...@co...> wrote: > Yup, this sounds like what I am thinking on how it would behave as > well. Although I think the data structure for storing the objects will > wind up being a little more complex than a list. ;) Well, its more like a map/dictionary. But yes, that's basically it. While I'd like to say that a single-section vehicle is just a multi-section vehicle with one section, I think its worthwhile breaking that out. Both in the interface and in the underlying data structure. I think you're right that a single-section vehicle is a specialized version of a section that's also a complete vehicle, though. While a multi-section vehicle's just a vehicle that contains sections. -- -Nick Pilon |
From: Adam T. <kr...@co...> - 2004-11-12 02:50:58
|
On Nov 11, 2004, at 6:42 PM, Nick Pilon wrote: > On Thu, 11 Nov 2004 17:20:43 -0800, Adam Thayer <kr...@co...> > wrote: >> Yup, this sounds like what I am thinking on how it would behave as >> well. Although I think the data structure for storing the objects will >> wind up being a little more complex than a list. ;) > > Well, its more like a map/dictionary. But yes, that's basically it. > > While I'd like to say that a single-section vehicle is just a > multi-section vehicle with one section, I think its worthwhile > breaking that out. Both in the interface and in the underlying data > structure. I think you're right that a single-section vehicle is a > specialized version of a section that's also a complete vehicle, > though. While a multi-section vehicle's just a vehicle that contains > sections. So we would see something like this? Component Container -> Vehicle Section -> Vehicle -> Multi-Section Vehicle Or should Multi-Section Vehicles be based off the Vehicle Section? |
From: Brandon D. <br...@dc...> - 2004-11-12 04:53:35
|
If I may? A multi section vehicle functions very similarly to a transformable in terms of data structure, as far as I wrote it, in that both are a single vehicle with a combined TV and Cost, but with numerous sub-vehicles, so I don't see a lot of reason to treat them otherwise. In addition, one thing important for transformables at least is multi-level transformation, i.e. a transformable vehicle which has a one way transformation into another (i.e. Macross planes with FAST packs, for example.) I don't know about the feasability in Java, but I know in my access program we're looking at essentially unlimited layering, in that you could build a transformable that transforms into a transformable that... etc. While multi-section vehicles are a little different, in that they have separate masses, I see no reason for a strict one-level section design either, for example, perhaps a vehicle which has two main sections and numerous sub sections, like a ship docked with another or something. While it doesn't exist in any specific DP9 settings, I think its entirely possible, and has been done in other settings (though examples beyond Macross escape me for the moment) Just my 2 bits -Brandx0 ----- Original Message ----- From: "Adam Thayer" <kr...@co...> To: <gea...@li...> Sent: Thursday, November 11, 2004 6:50 PM Subject: Re: Planning, Round #2 > > On Nov 11, 2004, at 6:42 PM, Nick Pilon wrote: > > > On Thu, 11 Nov 2004 17:20:43 -0800, Adam Thayer <kr...@co...> > > wrote: > >> Yup, this sounds like what I am thinking on how it would behave as > >> well. Although I think the data structure for storing the objects will > >> wind up being a little more complex than a list. ;) > > > > Well, its more like a map/dictionary. But yes, that's basically it. > > > > While I'd like to say that a single-section vehicle is just a > > multi-section vehicle with one section, I think its worthwhile > > breaking that out. Both in the interface and in the underlying data > > structure. I think you're right that a single-section vehicle is a > > specialized version of a section that's also a complete vehicle, > > though. While a multi-section vehicle's just a vehicle that contains > > sections. > > So we would see something like this? > > Component Container -> Vehicle Section -> Vehicle -> Multi-Section > Vehicle > > Or should Multi-Section Vehicles be based off the Vehicle Section? > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > -- > gearwerk-worker mailing list > gea...@li... > https://lists.sourceforge.net/lists/listinfo/gearwerk-worker > |
From: Thorsten H. <gea...@th...> - 2004-11-12 19:32:05
Attachments:
VehicleandSection.gif
|
Hi, * Adam Thayer wrote (2004-11-12 03:50): >So we would see something like this? > >Component Container -> Vehicle Section -> Vehicle -> Multi-Section >Vehicle What would be the role of the Vehicle Section here? Please have a look at my take. The names are not nice yet though. Thorsten -- It is up to us. - Carl Sagan |
From: Nick P. <np...@gm...> - 2004-11-12 20:11:56
|
On Fri, 12 Nov 2004 20:24:39 +0100, Thorsten Haude <gea...@th...> wrote: > * Adam Thayer wrote (2004-11-12 03:50): > >So we would see something like this? > >Component Container -> Vehicle Section -> Vehicle -> Multi-Section > >Vehicle > What would be the role of the Vehicle Section here? > Please have a look at my take. The names are not nice yet though. Brand's right in that the nesting isn't simple. We've really got three kinds of vehicle nesting: 1) Section nesting. This is where we've got a vehicle that's composed of multiple sections. 2) Transformation nesting. This is where we've got a vehicle that can switch between forms. 3) Combination nesting. This is where we've got a bunch of autonomous vehicles that can combine into a larger form. This one's not really in the same category as the other two, but needs to be considered. Where things get strange is where you mix them. You can have a multi-section vehicle whose sections can transform, or you can have a multi-section vehicle that transforms into another multi-section vehicle. Or a transforming vehicle with subsections that transform. Then you throw combining vehicles into the mix, and combining transforming vehicles, and combining transforming multi-section vehicles... So, Thorsten's diagram's a good start, but here's a try at overgeneralizing it. ;) Vehicle - This is an abstract interface describing a complete vehicle. The only things it knows how to do are calculate its TVs and calculate its total movement. Section - This is what we were referring to as a vehicle. It is composed of armor, maneuver, deployment range, reaction mass, size, a list of perks, a list of flaws, a list of movement types, and a list of weapons. It is also a Vehicle. An autonomous vehicle is just a single Section. MultiSectionVehicle - This is a single vehicle that is composed of multiple Vehicles that have been glued together. TransformingVehicle - This is a single vehicle that can transform between multiple forms. It is composed of a list of Vehicles, each representing one of its forms. MultiSectionVehicles with TransformingVehicle engine sections get really odd. CombiningVehicle - This is a group of vehicles that combine to form DEVASTATOR. ;) It is composed of one vehicle that represents the group combined, and a list of vehicles that represent the parts of the group. Because a vehicle can be part of multiple combinations, and no perk is required to be part of a combination, this really just needs the list for calculating the total TV of the combined vehicle. -- -Nick Pilon |
From: Thorsten H. <gea...@th...> - 2004-11-12 20:28:17
|
Hi, * Nick Pilon wrote (2004-11-12 21:11): >Where things get strange is where you mix them. You can have a >multi-section vehicle whose sections can transform, or you can have a >multi-section vehicle that transforms into another multi-section >vehicle. Or a transforming vehicle with subsections that transform. >Then you throw combining vehicles into the mix, and combining >transforming vehicles, and combining transforming multi-section >vehicles... Parts come to mind. >Vehicle - This is an abstract interface describing a complete vehicle. >The only things it knows how to do are calculate its TVs and calculate >its total movement. > >Section - This is what we were referring to as a vehicle. We should name things right though. If we refer to it as a vehicle, it should be a Vehicle. This is trivial in the few names we've thrown aroung here; but once we are at the level where start thinking how a VehicleContainerController relates to a MovementSectionDisplayManager we are in trouble if the names don't tell us what's in it. (Rats, it is really difficult to get my hands on the rules over here.) Thorsten --=20 In dem Augenblick, wo wir anfangen unsere Freiheitsrechte einzuschr=E4nken, besorgen wir das Gesch=E4ft der Terroristen. - G=FCnter Grass |
From: Nick P. <np...@gm...> - 2004-11-12 20:35:20
|
On Fri, 12 Nov 2004 21:21:38 +0100, Thorsten Haude <gea...@th...> wrote: > Parts come to mind. Parts are too low-level. This strangeness gets introduced when you start dealing with designs that are composed of sub-designs. Individual designs (be they sections of a warship or modes of a transformer) really don't gain anything at all from being broken down even further. (Except for a few specific components) The list of things that they have is short and fixed, and all but a few of those things are simple numerical values. There's only four lists involved, and each list has /very/ distinct things in it. > >Vehicle - This is an abstract interface describing a complete vehicle. > >The only things it knows how to do are calculate its TVs and calculate > >its total movement. > > > >Section - This is what we were referring to as a vehicle. > > We should name things right though. If we refer to it as a vehicle, it > should be a Vehicle. This is trivial in the few names we've thrown > aroung here; but once we are at the level where start thinking how a > VehicleContainerController relates to a MovementSectionDisplayManager > we are in trouble if the names don't tell us what's in it. Right, that's why I wanted to change the terminology. We HAD been referring to it as a Vehicle, but it's better called a Section. A vehicle is composed of one or more sections, with their precise relationship defined by the kind of vehicle. > (Rats, it is really difficult to get my hands on the rules over here.) Can you order from the Pod's online store? If you can't, I can try to get permission to send you a PDF copy of the VCS. -- -Nick Pilon |
From: Thorsten H. <gea...@th...> - 2004-11-12 19:09:42
|
Hi, * Nick Pilon wrote (2004-11-12 01:23): >By manager class, I mean a class that: >- Handles reading the perk/flaw/weapon/movement XML file and creating >the necessary objects for each. A Factory. >- Stores these necessary objects in a list or other convenient data struct= ure. Convenient for whom? >- Can provide an iterator over the objects. Should be the container's job. >- Can return a specific object based on some query string. (Internal name,= say) Should be the container's job. Thorsten --=20 Everyone has the right to freedom of expression. This right shall include freedom to hold opinions and to receive and impart information and ideas without interference by public authority and regardless of frontiers. - Charter of Fundamental Rights of the European Union, Article 11 |