Home World Forum
Stars! AutoHost web forums

Jump to Stars! AutoHost


 
 
Home » Stars! Clones, Extensions, Modding » Stars! Nova - Development » Item.Mass - should this be an abstract property?
Item.Mass - should this be an abstract property? Tue, 07 February 2012 14:51 Go to next message
ekolis is currently offline ekolis

 
Petty Officer 2nd Class
Stars! Nova developer
Stars! Nova developer

Messages: 51
Registered: May 2006
Location: Cincinnati, OH, USA

As I was looking through the code, I found that lots of things inherit from the Item class, which has a public Mass field. This includes fleets and fleet intel, which makes the field somewhat problematic. After all, the mass of a fleet is a computed value - the sum of the masses of all constituent ships. But this is never initialized, so fleets and fleet intel have zero mass! This is even handled inconsistently in the GUI: a fleet report shows its mass as zero, but the "my fleets" list shows the appropriate mass, so the calculation is being done - it's just being done inconsistently.

I think this could be solved by making Item's Mass field an abstract property instead. Then ships could implement it by checking their design, and designs could implement it by summing the masses of their components, and fleets could implement it by summing the masses of their ships.

If this causes performance issues, the values could always be lazy-loaded and cached, but I doubt this will be a problem to begin with.

Also, Item has a number of other public fields which I haven't looked into, but I suspect some of them might warrant similar refactoring.

Thoughts? Concerns?



Mr. Flibble says...
Game over, boys!

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Wed, 08 February 2012 10:00 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
The mass field is overridden by a property in Fleet and the same could be done for other objects which calculate mass from their parts. An abstract property is another way of achieving this. Up to you how you want to do it.


Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Fri, 10 February 2012 15:05 Go to previous messageGo to next message
ekolis is currently offline ekolis

 
Petty Officer 2nd Class
Stars! Nova developer
Stars! Nova developer

Messages: 51
Registered: May 2006
Location: Cincinnati, OH, USA

Hmm, this doesn't look like it's going to work... Some Item subclasses should have writable mass, cost, etc. but others should not. Thus I'm faced with a dilemma: If I declare the properties read/write, then I'd have to throw exceptions in some of the setters, but if I declare them read-only, it would be impossible to set them when necessary (e.g. for components and hulls)! I can't even declare the property {get; protected set;} and then make the setter public on the appropriate subclasses! This could be worked around using interfaces somehow, but I'm not sure it's worth the trouble...

edit: Actually, I've got another idea... Why are all these things in Item anyway, if they don't apply equally to all items?! Maybe they should be pushed down to the appropriate subclasses... not sure exactly how that would work at the moment though!


[Updated on: Fri, 10 February 2012 15:08]




Mr. Flibble says...
Game over, boys!

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Fri, 10 February 2012 18:37 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
Wait, do we have a new dev on board? Welcome! (Or you might be someone who I just don't recognize from this forum's name Razz)

I noticed you submited a lot of bug reports, most of those are because i'm re-writing the order system and it's taking longer than expected, so the server doesn't really process much besides research for now. I'll try to speed up the process~

As for the Item, there is a comment in the code somwhere that states that item should inherit from design and not the other way around, which I agree since a design becomes an item, and not the other way around.


[Updated on: Fri, 10 February 2012 18:42]

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Fri, 10 February 2012 22:58 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
Most game objects currently inherit from item. Item has settable mass and position. However it makes no sense to set the mass of fleet, star and minefield and only fleet, star and minefield have a position.

Perhaps the root of the object tree should be a 'gameObject' which has a name, key and type? It could have a 'mappableObject' descendent which adds the position property (which descends to fleet, star and minefield). And a design descendent which adds the cost property (which descends to component and Hull)?

This needs a good bit more thought about what properties are added at each point in the object hierarchy. It would be better to sort this out properly, rather than throw exceptions when setting inappropriate properties, so any issues can be found by static type checking.

Not sure if doing this now would confuse Aeglos' effort to re-write the order system?



Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Sat, 11 February 2012 00:16 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
I don't think It would confuse me much.

In fact, I might be opening a can of worms here, but I'm not too fond of inheritance in general. IMHO the current scheme is kinda overkill.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Sat, 11 February 2012 16:47 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
Without inheritance the code to generate keys would be repeated in every game object. Inheritance saves repetition and improves maintainability.

It does make it important though to have an object hierarchy diagram so you can make sense of it. Fortunately VS has good tools for generating that.



Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Sun, 12 February 2012 02:28 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
I agree, but for example; Ship inherits Item, and contains a Design which ALSO inherits from Item. That's pretty redundant.

I'd rather have Ship inherit a Design directly so there's a clear line of inheritance.

And as stated somewhere in the code in an old comment, Item should inherit from design, and not the other way around. It makes no sense for a design to have mass and position; an Item is a much more "concrete" thing anyway, so it should logicaly be lower down in the implementation chain than a design.

Although I also concede that this kind of logic not always makes sense in software, and I don't know what implications reversing the inheritance might have on the codebase other than the Key properties we worked so hard to implement would need to be realocated to track designs by Id.

Design -> ShipDesign -> Item -> Ship

Would be an ideal arrangement, instead of the current:
Item -> Ship
         |->Item -> Design -> Shipdesign


Even
Item -> Design -> Shipdesign -> Ship

Would be cleaner, and it could be a simpler change to implement.


[Updated on: Sun, 12 February 2012 02:30]

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Sun, 12 February 2012 15:50 Go to previous messageGo to next message
ekolis is currently offline ekolis

 
Petty Officer 2nd Class
Stars! Nova developer
Stars! Nova developer

Messages: 51
Registered: May 2006
Location: Cincinnati, OH, USA

Aeglos, I think you're confusing inheritance and composition. Ship should not inherit from design, as it makes no sense to say "a ship is a design". Rather, it is correct to say "a ship has a design". Thus the current system of ship object having a reference to a design object.

I think the main problem is that the inheritance hierarchy is too top-heavy: Item has way too much information that is irrelevant for certain subclasses.

I agree with Daniel that we should think this out, though.

Oh, and by the way, I'm not exactly a "new" developer on the project, but neither am I all that experienced with it - I was involved with Nova a bit several years ago, but then I got involved with another project, called Star Legacy, so I left the Nova project. Unfortunately Star Legacy has kind of fizzled out, but on the bright side, I can get involved with Nova again!



Mr. Flibble says...
Game over, boys!

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Sun, 12 February 2012 23:28 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
I understand inheritance vs composition, in fact I heavily prefer composition over inheritance, specially when inheritance gets to 3 or 4 levels. I was trying to convey that Item is kind of redundant in the current scheme.

From the current Item properties/Data I can think of these:

Mass/Cost/Design is irrelevant for Stars, so we could move them a level up to Designs, and it kinda makes sense.
Position is irrelevant for Designs/ShipDesigns/Ships but relevant for Fleets and Stars. We can't move it without duplicating it in both Stars and Fleets, which might not be that terrible.
Mass & Cost could move up to the Design, and Fleets get them from their Ship collections.

Perhaps having Ship not inherit Item since that data would be in it's design would be a step in the right direction. Still leaves designs with irrelevant positions which only become relevant at the Fleet level.

And welcome back btw!







[Updated on: Sun, 12 February 2012 23:45]

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Mon, 13 February 2012 02:31 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
I agree that we can probably do away with Item. There is no generic Item and it adds no useful properties.

An idea I would like to throw out there: can we do away with Ship? A ship never exists outside a fleet. All you need to know about a ship is contained in the ShipDesign.



Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Tue, 14 February 2012 10:41 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
Doing away with item means redoing the Key/Owner properties in all relevant cases, unless you mean doing away with it for the ship only.

We can do away with Ship entirely, but we would need to add methods of tracking individual ship's armor and shields to the Fleet, as those are kept on the Ship objects now, but that should be trivial and the battle engine is due to an update... eventually.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Tue, 14 February 2012 12:02 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
Not quite what I meant. We still need a base class which provides the key/owner properties (as well as Name and Type). However I do not think that We need a base class + Item + design. Also the word Item is confusing as it implies it represents something physical in the game. Let me draw a picture...


Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Tue, 14 February 2012 13:32 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
I am thinking of something like this: https://sourceforge.net/apps/mediawiki/stars-nova/index.php? title=File:Nova_game_object_proposal.png

I have left out all the component/component properties as that seems fine to me (but then, I built that.)

I am also not concerned with Hull, HullModule or StarList.

That leaves the current objects: Item, Design, ShipDesign, Ship, Fleet, Star, MineField.

I think we need to keep Star, ShipDesign, and Minefield in much the same form they are currently.

I think that Fleet could take on a couple of extra properties to track shield and armour damage in order to get rid of Ship. Damage is not managed per ship in Stars! However an argument could be made for keeping Ship in order to allow for future expansion. In that case it would descend from GameObject.

I have retained Design, however I put a question mark over it because the only things that use design appart from ShipDesign are planetary installations. Mass and key are not really relevant to these and the planetary installations could be refactored as properties of Star.

I have split Item into GameObject and MappableObject. This removes the Mass property from Star, Fleet and MineField. Whilst all these things could have a mass, it is irrelevant for Star and MineField and is calculated for Fleet (can not be set). This scheme also removes position from those objects which are not tracked on the map.

Ideas/recommendations?




Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Tue, 14 February 2012 15:28 Go to previous messageGo to next message
ekolis is currently offline ekolis

 
Petty Officer 2nd Class
Stars! Nova developer
Stars! Nova developer

Messages: 51
Registered: May 2006
Location: Cincinnati, OH, USA

Funny you came up with GameObject; that's what we called our base class in Star Legacy as well! Razz

At first I was a bit confused by the idea of getting rid of Ship - how would you ever have ships in the game without a Ship class?! But I quickly realized that since Stars! doesn't track damage to individual ships, but instead tracks damage to "ship stacks" similarly to the original Master of Orion, there's no need to instantiate an object for every single ship; all you need to do is keep something like a Dictionary<Design, Tuple<int, int>> to tell you how many ships you have in each stack and how much damage each stack has taken! Smile

One question, though - why does GameObject need a Type property? Can't you tell what an object is by using the built-in GetType method of System.Object, or the "is" operator? Or is this something more detailed than just the CLR-type of the object?



Mr. Flibble says...
Game over, boys!

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Wed, 15 February 2012 01:24 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
Item.Type holds a lot more concrete things that don't have a particular class. For example, there are Factory and Mine types which are both Design objects.

Or the general ship slot categories; A MassDriver class has Orbital as it's type.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Tue, 28 February 2012 03:27 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
I was sorting Designs for the Design commands and was thinking if maybe we oculd do away with Design entierely and leave just ShipDesign (renamed as Design?) instead.

I know Design is used for Factories, Mines, Defenses and planetary Scanners, but is it really useful to do so? Mines and Factories are just integers on Stars with costs handled in RaceData, and their ProductionUnit classes (the ones Pavel made) void the need for designs for them. I assume Defenses and Scanners can also be handled by ProductionUnits, and it would simplify the class structure a little more.


[Updated on: Tue, 28 February 2012 03:28]

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Wed, 29 February 2012 02:17 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
Daniel wrote on Wed, 15 February 2012 05:32

I am thinking of something like this: https://sourceforge.net/apps/mediawiki/stars-nova/index.php? title=File:Nova_game_object_proposal.png

I have retained Design, however I put a question mark over it because the only things that use design appart from ShipDesign are planetary installations. Mass and key are not really relevant to these and the planetary installations could be refactored as properties of Star.






Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Sat, 10 March 2012 23:20 Go to previous messageGo to next message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
I removed Design and left ShipDesign only as everything that is not a ship will be handled by Star properties.

I was looking to implement the structure in your image as it's much cleaner, but there's something not accounted for: Components. They also have mass/cost.

How about renaming GameObject to something like "KeyableObject", and where Design sits in the picture we intrododuce a "BuildableObject" which contains Mass/Cost and from which designs and components can inherit. The left hand branch should be left like it is in the pic.

Ideas?

EDIT -

I removed "Ship" in favour of a new "ShipToken" class which tracks a design, it's quantity, and the armor damage it has sustained. It does not inherit from anything, and made ship handling easier. It also led to the simplification of some things on the battle engine, and it's now closer to Stars! as it targets tokens instead of individual ships.

The battle engine still needs some work though, as I suspect it's not accurate yet.


[Updated on: Sun, 11 March 2012 23:54]

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Tue, 13 March 2012 15:19 Go to previous messageGo to next message
Daniel is currently offline Daniel

 
Chief Warrant Officer 3
Stars! Nova developer
Stars! Nova developer

Messages: 179
Registered: April 2006
Location: Nowra, Australia
I do not think components need a key. It may be possible to add mass and cost to the component object directly and remove them from the inheritance chain. On the other hand it would not hurt to do it like you say and would make it possible to add a future feature for building raw components (which you would ship some place for final assembly) (Something for version 2.0).


Have fun.

Report message to a moderator

Re: Item.Mass - should this be an abstract property? Tue, 13 March 2012 18:39 Go to previous message
Aeglos is currently offline Aeglos

 
Chief Warrant Officer 1
Stars! Nova developer
Stars! Nova developer

Messages: 142
Registered: May 2011
Location: Chile
Indeed, on better examination it looks like not even ShipDesign might need mass/cost, as it can derive them from the sum of it's hull/components.

I'll implement a "buildableobject" (name pending, I suck at naming classes) and remove component from the current inheritance altogether.


EDIT-

Ok. I moved Mass and Cost to Component instead of introducing a middle object. They are now responsible for keeping that data. Other classes like Fleet or ShipDesign still have properties to access Mass and Cost information, but they are just calculated properties;

i.e. ShipDesign.Cost just returns the sum of it's component's costs, Fleet.Mass returns the sum of it's token's masses, etc.

Since Fleet/ShipDesign/Whatever don't need to share an interface or be polymorphic with Components, I think this is the cleanest way to improve the design.

Component doesn't need a Key, but it needs the Name that Item provides. I'd leave it as it is, as I think it would be nice to change the components to actually USE the Key field in the future (not critical though)... not really a fan of indexing by string name.


[Updated on: Wed, 14 March 2012 01:04]

Report message to a moderator

Previous Topic: Production classes - IProductionUnit and derivates
Next Topic: Spam posts
Goto Forum:
  


Current Time: Wed Jul 28 07:45:44 EDT 2021