Home World Forum
Stars! AutoHost web forums

Jump to Stars! AutoHost


 
 
Home » Stars! Clones, Extensions, Modding » Stars! Nova - Development » FleetIntel question
Re: FleetIntel question Tue, 05 July 2011 22:00 Go to previous messageGo 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
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

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


Current Time: Sat May 04 15:01:03 EDT 2024