|
|
|
|
|
|
|
|
Re: I've branched the Codebase |
Sun, 26 June 2011 19:16 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
To be honest I was thinking of merging back soon. The big bug hunt of the initial StarIntel is already done so I know what to look for when the FleetIntel gets plugged. I'll probably merge back later today and end the branch. This way more important changes like IDs can get done now rather than later.
I wanted to get some input on data design though. Currently the StarIntel object holds Age, IntelLevel (determined by the server, and mandates how much info you get) and a Star object. The server populates the Star object form a full game star and the IntelLevel and you can access it on the GUI with StarIntel.Star. It will only have information that the server sent you, so for example colonists will be 0 for all stars you don't own.
While this works, I find it... flaky. Having a Star inside a StarIntel just feels weird. It would probably feel more robust if StarIntel extended Star and just added Age, IntelLevel and the Update method to set data according to IntelLevel.
Passing only data is not an option since a Star has a number of Properties and methods that are useful on the GUI, like GetResourceRate() and the ProductionQueue, same as Fleet like Mass mass and FreeWarpSpeed. Coding those again is redundant.
For fleets I'm contemplating a similar issue. Fleet has much less variables to set, but the property of FleetComposition which gets the Design Names and Qty, which is extremely convenient for the GUI, depends on the Fleet having proper Ships, which if passed fully to the GUI would defeat the purpose of the FleetIntel in the first place.
I also thought of adding IStar and IFleet interfaces and making Star, Fleet, StarIntel and FleetIntel all from those, sort of use the composite pattern but decided against it since it would be over complicating things.
I will go for StarIntel and FleetIntel extending Star and Fleet. It simpler for the GUI to manipulate them that way, and the data setting logic would be almost as containing them as objects.
I'm doing this on the premise that there should be just one collection for fleets and one for stars, both owned and enemies, and that only data amounts differ.
Report message to a moderator
|
|
|
|
|
|
Re: I've branched the Codebase [Merged back into trunk] |
Tue, 28 June 2011 01:26 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
Ok guys i've merged the branch back into the trunk. I haven't deleted yet it in case something went wrong.
I got several tree conflicts which I tried to manually fix and the merge seems to be working here (my Windows machine), if you are on Mono and it breaks, please let me know so I can see where messed up. (I'm weary cause I had some tree conflicts with some .resx files and .designer files for the cargo dialogs).
The ClientState and GUI now uses StarIntel and FleetIntel objects for it's data. There are some bugs that I know of and will fix shortly:
1. Homeworlds loose track of their starbase after the first turn. This is an issue that needs to be adressed after implementing the new consistent Ids as collections are being sorted and serialized in different ways sometimes.
2. The Server/TurnSteps/ScanStep.cs file which contains the server's Scanning turn step (new turn tentative structure) has a logic bug. It modifies some collections during a foreach and invalidates it's own iterators. The game works until you actually scan an enemy fleet with your own fleets. This TurnStep has a plethora of loops to handle scanning and can surely be refactored so that it's cleaner and more efficient, as I coded it rather hastly.
3. Orbiting fleets are not drawn (ellipses around a star) as they were previously determined client-side and that functionality is gone. The Star variable OrbitingFleets is not even serialized, so this needs some work and to be done server-side now.
4. Fleets expose too much information when scanned, this has to be revised. It's simple though, just move variables on the FleetIntel class Update() method up a higher level of intel amount... I didn't yet because some fleet unset variables cause a bunch of null reference crashes (like ship components).
Again, if something broke badly in the build i'm really sorry. You guys were right... SVN merging is a chore.
I filed bugs for #1 and #3 to the tracker. #2 I intend to revisit soon and those algorithms are temporary anyways, as is #4 which is a WIP.
[Updated on: Tue, 28 June 2011 01:32] Report message to a moderator
|
|
|
|
|