Home World Forum
Stars! AutoHost web forums

Jump to Stars! AutoHost


 
 
Home » Stars! Clones, Extensions, Modding » Stars! Nova - Development » FleetIntel question
FleetIntel question Tue, 05 July 2011 17:45 Go to next message
Musmuris

 
Master Chief Petty Officer
Stars! Nova developer
Stars! Nova developer

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 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
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 14:57 Go to previous messageGo to next message
Musmuris

 
Master Chief Petty Officer
Stars! Nova developer
Stars! Nova developer

Messages: 96
Registered: June 2011
I'm still getting to grips with all that stuff myself right now, and i've still to go through how intel and orders are created (I know the theory but I want to walk through the code). So I'm wary of suggesting too much till I know more.

A lot of the code I saw currently loops through all the fleet reports and don't check for ownership but if that's fixed up I think having one collection might be best. We can always change it later Smile



(And I did code it as Dictionary<int,FleetIntel> - just wrote it wrong above)


[Updated on: Wed, 06 July 2011 14:57]

Report message to a moderator

Re: FleetIntel question Wed, 06 July 2011 17:01 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
Let's leave it as it is for now and keep moving forward then. I'll rename some variables and types anyway for clarity.
And to clarify a little, I devised the current design like this: (speaking in real sci-fi terms)

An emperor recieves three binders each turn. One for all the fleet reports, one for all the star reports and one for all other empire reports.

The other option would be for him to recieve three binders; one for his own fleets, a second one for this own stars, and a third which has all other empire reports, and each one of those has two more binders will all their fleets and their stars.

That's why I went with the first approach, feels more logical. Again, this might not be the case code-wise so please point out any flaws or improvements.

Report message to a moderator

Re: FleetIntel question Wed, 06 July 2011 17:25 Go to previous messageGo to next message
Musmuris

 
Master Chief Petty Officer
Stars! Nova developer
Stars! Nova developer

Messages: 96
Registered: June 2011
Cool. That works for me UFO

Report message to a moderator

Re: FleetIntel question Wed, 06 July 2011 18:52 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
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 Wed, 06 July 2011 21:05 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
In the meantime, i've changed all variables named "empireIntel" and "EmpireIntel" to "empireState" and "EmpireState". EnemyData class is now EmpireIntel, and OtherEmpires is now EmpireReports.

Report message to a moderator

Re: FleetIntel question Wed, 06 July 2011 22:06 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
Daniel wrote on Wed, 06 July 2011 18:52


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.



This also sounds cleaner to me, specially since working with the current report system works, but it's messy to set them up internally.

The only caveat I have is filing them under EmpireReports (ex-OtherEmpires). 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? Separated by owner? Separated by owned and enemies? On EmpireData? One collection on each EmpireReport?

This data design issues are probably my weak spot right now Confused




[Updated on: Wed, 06 July 2011 22:29]

Report message to a moderator

Re: FleetIntel question Thu, 07 July 2011 05:03 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
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 Thu, 07 July 2011 05:40 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
Sounds good to me, the less nested collections the better.

I'll get started on the interfaces and implement the new reports next.

Report message to a moderator

Re: FleetIntel question Thu, 07 July 2011 05:58 Go to previous messageGo to next message
Musmuris

 
Master Chief Petty Officer
Stars! Nova developer
Stars! Nova developer

Messages: 96
Registered: June 2011
I think I agree... if I understand it correctly Smile

Report message to a moderator

Re: FleetIntel question Sat, 09 July 2011 20:22 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
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 Sat, 09 July 2011 20:38 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
So instead of using an interface, StarReport for example is a very stripped down Star, without Queues, on hand resources, etc. The Star object inherits from it and adds the fields used by owners and omited from StarReport.
Perhaps another name would describe the relationship better... StarBase is bound to conflict with starbases. StarBasic? StarSimple? StarEssential... ProtoStar Laughing ?

And if I understand it correctly, the homeworld for example would be both in star reports AND in owned stars? So the client uses the reports for things like drawing, and the OwnedStar for manipulating them?.

Report message to a moderator

Re: FleetIntel question Sat, 09 July 2011 23:50 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
That is what I am thinking. I would just call it a StarReport / FleetReport. The only problem I see is that inheritance is usually used for is-a relationships (Ship is-a Item, ShipDesign is-a Design) and it does not sound quite right to say a Star is-a StarReport. Hence the urge to call the report a ProtoStar as you suggest; but that does not describe what it is. I think it is ok to use inheritance this way because a StarReport object is what you interact with all the star systems through and then a Star object is a special case of that for Stars you own.


Have fun.

Report message to a moderator

Re: FleetIntel question Sun, 10 July 2011 16:53 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'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).

Report message to a moderator

Re: FleetIntel question Mon, 11 July 2011 03:15 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
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 Mon, 11 July 2011 04:11 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 clear on the references and when to use the collections. My confusion arose from thinking that they would both be Dictionary<string, StarReport> types, since the plan is for a Star to extend StarReport. It would mean that a owned Star X could have been used in both collections at the same time with no casting, since they both can accept the base class by polymorphism. (That's what I meant by "duplicates": using the exact same object in both collections instead of just the base in one of them)

Quote:

No. OwnedStars is a subset of StarReports with a different type definition. ie
Dictionary<string,Star> OwnedStars;
Dictionary<string,StarReport> StarReports;



This clears up what the intent is and my confusion. Although StarReports can still accept Star objects directly. (That's what kludged me Hit over head)

Quote:

StarReports[x] as Star

would be equivellent to
OwnedStars[x]



I assume you meant OwnedStars[x] as StarReport equals StarReports[x]? Unless the 'as' operator can upcast types, since StarReport should be the new base and Star the inherited type.

Report message to a moderator

Re: FleetIntel question Mon, 11 July 2011 04:49 Go to previous messageGo to next message
Musmuris

 
Master Chief Petty Officer
Stars! Nova developer
Stars! Nova developer

Messages: 96
Registered: June 2011
I think what Daniel said was correct (if I'm following this)

Assuming Star is going to inherit from StarReport (as if I've got that wrong the rest of what I'm about to say is bull####)

So we will have

Dictionary<string,Star> OwnedStars;
Dictionary<string,StarReport> StarReports;


StarReports therfore consists of both StarReports AND Stars. So if star "X" is an owned star then:

(StarReports["X"] as Star) == OwnedStars["X"]


However planet "Y" is not owned so

(StarReports["Y"] as Star) == null


as "Y" would be a StarReport and wouldn't be in the OwnedStars dictionary.

Report message to a moderator

Re: FleetIntel question Mon, 11 July 2011 04:55 Go to previous messageGo to next message
Musmuris

 
Master Chief Petty Officer
Stars! Nova developer
Stars! Nova developer

Messages: 96
Registered: June 2011
Of course there is the other option for modeling it as "Has A" - so a Star has a StarReport.

So an owned "Star" has a property Report with the data in there.

In this case I'd perhaps call them EmpireStar and Star so you'd have
Dictionary<string,EmpireStars> OwnedStars;
Dictionary<string,Star> StarReports;


But either idea works for me.

However I quite like those new names now... i.e. StarReport becomes Star and Star becomes EmpireStar?


(( as an aside renaming things like this can be fun, so I tend to choose new names, e.g. StarData and EmpireStar so that all occurences of Star as a class get replaced and avoid the code compiling when it shouldn't! Once all working then at a later date I change the name back to Star ))

Report message to a moderator

Re: FleetIntel question Mon, 11 July 2011 07: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
Musmuris wrote on Mon, 11 July 2011 18:55

Of course there is the other option for modeling it as "Has A" - so a Star has a StarReport.



That sounds so simple and obvious it is rather compelling and I feel foolish for not thinking of it sooner. I can not think of any reason not to do it that way and it certainly sounds better than Star is a StarReport.



Have fun.

Report message to a moderator

Re: FleetIntel question Mon, 11 July 2011 14:44 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
My initial draft before the current model was like that, but the other way around (StarReport has a Star), so it wasn't really useful as Mus' idea which I also find excellent Smile

The current "report" class is called StarIntel, so 'Star has a StarIntel' could work. I'll just move essential data and Item inheritance from Star to StarIntel and see how it goes. The only caveat I have is that to access those essential data we'll have to do it through Star.Report.XX or Star.Intel.XX or similar. Can't think of a meaningful name right now, so I'll go with report.

EDIT: Or wrap them in Properties wich is cleaner.


[Updated on: Mon, 11 July 2011 18:05]

Report message to a moderator

Re: FleetIntel question Wed, 13 July 2011 21:35 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
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 ( Embarassed )

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

Re: FleetIntel question Thu, 14 July 2011 04:53 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
Well, I think it was worth trying and now we at least have a good record of what we have tried and why we are going with the design you have selected.


Have fun.

Report message to a moderator

Re: FleetIntel question Thu, 14 July 2011 05:11 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 just commited r713 with these changes (and some others related as well).

It's just on Stars & Star Reports, so we can still do something else with fleets or change how it works.

I've done the following changes:

  • Item now implements IComparable instead of having a separate SortableItem inside StarMap (was a fixme pri. 5).
  • StarIntel now inherits from Item, but besides that is unrelated to Star OO wise.
  • Star has a method GenerateReport() to return a StarIntel object according to ScanLevel (renamed IntelLevel).
  • StarMap uses only StarReports now.
  • Planet Summary uses StarReports and pulls a couple of things from OwnedStars when needed (Minerals on surface bars mostly).
  • Planet Detail uses OwnedStars only.
  • Moved Star Hab calculations to Race, so that the AI can use them with either stars or reports for colonization. Kinda makes more sense that a race checks hab on a star, than a star for it's race anyway.


Again, I found that the 'has a' approach was equally cumbersome as the 'is a' one, since we would have had to extract a duplicated and modified StarIntel from Star to select proper fields according to ScanLevel, so it was kinda redundant. Having them as separate things feels a bit cleaner and simpler after all the redesign turmoil.

EDIT: Fixed some crashes by making Fleet.InOrbit accept an Item instead of a Star; interested parties can see if it's an ItemType Star or StarIntel.


[Updated on: Thu, 14 July 2011 07:25]

Report message to a moderator

Re: FleetIntel question Thu, 14 July 2011 17:12 Go to previous messageGo to previous message
Musmuris

 
Master Chief Petty Officer
Stars! Nova developer
Stars! Nova developer

Messages: 96
Registered: June 2011
Nice one. Thanks for trying the different ideas Smile

Sorry I've been a bit out of it this week - on holiday and ended up either going out in the evening or just being too tired from the day! Did bring the laptop but not got it out much

Report message to a moderator

Previous Topic: Bugs/Other Trackers
Next Topic: Anyone still around?
Goto Forum:
  


Current Time: Wed Jul 28 06:32:47 EDT 2021