Home » Stars! Clones, Extensions, Modding » Stars! Nova - Development » FleetIntel question
FleetIntel question |
Tue, 05 July 2011 17:45 |
|
Musmuris | | | Messages: 96
Registered: June 2011 | |
|
I changed the FleetIntelList class to be based on a Dictionary<int,Fleet> as part of my fleet ID rename (rather than DictionaryBase) as this seemed more typesafe and given we weren't using strings anymore would be marginally more efficient.
Is the FleetIntelList on EmpireData just for player fleets? If so I assume the OtherEmpires will have all the enemy fleets?
Report message to a moderator
|
|
|
Re: FleetIntel question |
Tue, 05 July 2011 22:00 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
Short Answer: I was leaning towards no, but now I'm not sure.
When I implemented the StarIntel/FleetIntel classes, the OtherEmpires<EnemyData> collection did not exist yet, so I threw all of them (owned and neutral/enemy) inside EmpireData.StarReports and EmpireData.FleetReports.
On one hand it sounds reasonable to have each EnemyData object to hold a list of that empire's fleets and stars, but on the other hand I was considering EnemyData to be another "Report collection", and was actually thinking of renaming it to EmpireIntel. (so it would be EmpireReports<EmpireIntel> as a third report collection instead of OtherEmpires) and in that context reports holding reports seems silly.
I think it's also a bit easier to look for things inside just one collection, rather than looping through several just to get all the fleets, client side wise.
But again, I'm not really sure how to organize all this data right now. One thing is that I sucked at naming those classes, and it makes things confusing. The plan I had until now was this:
Rename EnemyData to EmpireIntel
Rename OtherEmpires to EmpireReports
Rename some other variables to avoid confusion (there is already an empireIntel variable somewhere)
Find another name for EmpireData.EmpireRace as it is redundant (Sadly "Race" is the type and seems smelly to have it as public Race Race).
Find another name for EmpireData (I would rather name it Empire, but again... having public Empire Empire in some places is smelly).
Keep all fleet reports, owned and neutral/enemy inside EmpireData.FleetReports.
Keep all star reports, owned and neutral/enemy inside EmpireDatal.StarReports.
While this is what sounds logical to me, it may surely not be so for you, so i'm very open to suggestions on this. One issue i'm not happy with is some caveats on how Intel classes work. While they are convenient for the client (It doesn't care if it has to draw a Fleet or a FleetIntel for example since Intel classes inherit Star/Fleet so refactoring was trivial) it poses some problems determining the strict information they should have in different cases, like fleet composition (The FleetShips<Ship> collection inside Fleet). It needs to be there for owned fleets... but if it is unset it causes null reference crashes. So how to handle a non-owned FleetIntel with this unset and no crash? It would need Fleet and Ship changes.
So I was strongly considering "reverting" some implementations on the Intel objects to no longer inherit Fleet/Star, to hold specific subset of data from them and to use them only for enemy/neutral things, while passing regular Star/Fleet objects in another collection to their owners. For example, StarIntel would not care about the Star's production queue as it is irrelevant unless you own the star, so don't even have it as a member. FleetIntel would have a specific member not found on Fleet to report composition without revealing designs, etc.
In this scenario, it makes more sense to hold Fleet and Star reports inside OtherEmpires<EnemyData> grouped by owner, and another EmpireStars<Star> and EmpireFleets<Fleet> collections inside EmpireData for that player's own things... but there would be a need to use IFleet and IStar interfaces for the client to use both star/fleet reports and star/fleets interchangeably for drawing and summaries, else we would need lots of if/else clauses, and we would need to loop through all of OtherEmpires' FleetReports and StarReports plus looping through the EmpireData's EmpireFleets and EmpireStars to actually get them all together.
Also implementing IFleet/IStar would mean adding lots of properties to Fleet/Star and making currently public variables private, which is in a way something desirable.
Ugh, so much text and so confusing. The thing is: i'm not really sure if the changes I implemented were the proper solution to the .intel information amount problem, so I'm quite open to ideas on how to improve it, even if it means undoing some changes or redoing some things.
BTW, as it is now, it should be Dictionary<int, FleetIntel> as FleetIntel has some things that Fleet doesn't.
[Updated on: Tue, 05 July 2011 22:01] Report message to a moderator
|
|
| | | |
Re: FleetIntel question |
Wed, 06 July 2011 18:52 |
|
Daniel | | | Messages: 179
Registered: April 2006 Location: Nowra, Australia | |
|
Aeglos wrote on Wed, 06 July 2011 12:00 |
So I was strongly considering "reverting" some implementations on the Intel objects to no longer inherit Fleet/Star, to hold specific subset of data from them and to use them only for enemy/neutral things, while passing regular Star/Fleet objects in another collection to their owners. For example, StarIntel would not care about the Star's production queue as it is irrelevant unless you own the star, so don't even have it as a member. FleetIntel would have a specific member not found on Fleet to report composition without revealing designs, etc.
In this scenario, it makes more sense to hold Fleet and Star reports inside OtherEmpires<EnemyData> grouped by owner, and another EmpireStars<Star> and EmpireFleets<Fleet> collections inside EmpireData for that player's own things... but there would be a need to use IFleet and IStar interfaces for the client to use both star/fleet reports and star/fleets interchangeably for drawing and summaries, else we would need lots of if/else clauses, and we would need to loop through all of OtherEmpires' FleetReports and StarReports plus looping through the EmpireData's EmpireFleets and EmpireStars to actually get them all together.
Also implementing IFleet/IStar would mean adding lots of properties to Fleet/Star and making currently public variables private, which is in a way something desirable.
|
I like this idea. It sounds cleaner to me to have a seperate report class for fleet and star reports and to use an interface for common members.
Have fun.Report message to a moderator
|
|
| | |
Re: FleetIntel question |
Thu, 07 July 2011 05:03 |
|
Daniel | | | Messages: 179
Registered: April 2006 Location: Nowra, Australia | |
|
Aeglos wrote on Thu, 07 July 2011 12:06 |
Having 5 collections in empire data (Fleets, Stars, FleetReports, StarReports and EmpireReports) rather than 3 in which each element from one those has another two sub collections feels a bit cleaner to me. There is also the issue of enemy designs; together with owned designs in one KnownDesigns collection?
|
Agree. I would suggest Fleets, Stars, Designs, FleetReports, StarReports, DesignReports and EmpireReports all as members of EmpireData.
Have fun.Report message to a moderator
|
|
| | |
Re: FleetIntel question |
Sat, 09 July 2011 20:22 |
|
Daniel | | | Messages: 179
Registered: April 2006 Location: Nowra, Australia | |
|
Having thought about this a bit more after delving into the guts of EmpireData I have the following additional suggestions:
Within EmpireData these collections should be called StarReports, FleetReports, OwnedStars (instead of just Stars), OwnedFleets (instead of just Fleets) and EmpireReports.
Star should inherit from StarReport. (instead of vice versa)
Fleet should inherit from FleetReport. (instead of vice versa)
The Reports should contain all known objects, whether owned or not, to simplify generation of things like the star map. Some of the report objects may be the full versions of the object. So StarReport for your homeworld is actually the same object as the Star for your homeworld, using polymorphism.
The Owned collections should contain only objects the empire controls and can issue orders to (change production, move fleets, etc). This effectively replaces the former ClientState.Data.OwnedStars and ClientState.Data.OwnedFleets.
Have fun.Report message to a moderator
|
|
| | | |
Re: FleetIntel question |
Mon, 11 July 2011 03:15 |
|
Daniel | | | Messages: 179
Registered: April 2006 Location: Nowra, Australia | |
|
Aeglos wrote on Mon, 11 July 2011 06:53 | I'm working on this, but I want to be clear on something.
Daniel wrote on Sat, 09 July 2011 20:22 | So StarReport for your homeworld is actually the same object as the Star for your homeworld, using polymorphism.
|
Does this mean that effectively OwnedStars<X> should be exactly the same as StarReports<X>? Or it was meant in a more liberal sense where OwnedStars<X> is the extended object of StarReports<X>?
Because in the first case I do not see much sense in having the OwnedStars collection if they are all duplicates of things already found in StarReports. (Same for with fleets).
|
No. OwnedStars is a subset of StarReports with a different type definition. ie
Dictionary<string,Star] OwnedStars;
Dictionary<string,StarReport] StarReports;
thus:
StarReports[x] as Star
would be equivellent to
OwnedStars[x]
There are no "duplicates" because they are all reference objects. If you change the fields of OwnedStars[x], you are also changing StarReports[x]. However you would generally be looking at different fields anyway so that is not the point.
The point is that you can itterate through EmpireData.StarReports when you only care about data you might get from stars you do not own (e.g. map drawing); and you would itterate through EmpireData.OwnedStars when you want to be garunteed that all the Stars considered are owned by the current empire, such as when selecting next/prev planet in the production view (not sure if you can even do this yet).
Have fun.Report message to a moderator
|
|
| | | | | |
Re: FleetIntel question |
Wed, 13 July 2011 21:35 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
Having done progress on this, I think it's a dead end to be honest. I also think we might be overcomplicating things due to our inclination to model this relationship in some oop way after my initial changes ( )
There is a problem with the 'has-a' approach: The Star Report fields need all to be set with the proper real data inside the Star's report property for it (Star) to work properly, so we would need a special method to select the right amount of data according to the knowledge level for each object anyway, as we simply can't retrieve the full report; we would still be passing extra data (like colonists or concentration on unexplored stars).
Now that we've agreed to have them in separate owned/report collections again, we don't really need them to conform to a common interface or be polymorphic; we clearly aren't going to mix them up in the client. We won't be looking at the OwnedStars to draw the StarMap for example, and we won't be trying to access production queues on neutral stars.
I strongly think that we should treat them as what they are; diferent things, and be done with it. Star and Fleet (right as they are now) should have a GenerateReport(IntelLevel) method that creates and returns a new, distinct and separate P.O.D. StarIntel/FleetIntel object with the amount of fields set according to IntelLevel, with some sensible defaults.
I realize that this is probably going full circle to something really close to Ken's (or was it someone else's?) original design... but it's what's making the most sense after trying the other approaches in-code. Mea Culpa for braking this in the first place instead of improving the design already in place.
[Updated on: Wed, 13 July 2011 21:36] Report message to a moderator
|
|
| | | |
Goto Forum:
Current Time: Thu Mar 28 04:28:18 EDT 2024
|