|
Re: Need to move away from using names as IDs |
Fri, 24 June 2011 21:28 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
Yes, this also extends to races. Sorting everything manually by "RaceName/some#" is cumbersome and hard to mantain. Preferably this variable should be as automatic as possible.
The Item base class has a Key property which returns an already formed <Owner/Name> string for use on collections but it's used mostly on the Design Manager for now and that still poses problems. But it's a starting point. Players are also already asigned a number at game creation.
We can either use something like racename+playernumber to identify each empire, or generate a unique empire number and use racename+empirenumber, which I'm leaning towards to in case we want to implement multiple players per empire as Evil suggested. That solves the duplicate race issue I believe.
EmpireData should hold ShipDesignID (0 to 16), StarbaseDesignID (o to 10) and FleetID (0 to 512) counters to use as part of the unique keys for designs and fleets, and to also keep track of the amount of them.
I'd rather not do this myself yet though, as the refactoring I'm doing now is big enough. If someone else does it I'll still merge it ot the branch and update any conflicts that may arise.
EDIT: This also extends to the methods of comparison we are using now. We use Race.Name to check for ownership everywhere, we should change it to the new ID method we choose to apply, as Owner should be a Key ID and not a simple race name.
[Updated on: Fri, 24 June 2011 22:34] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Need to move away from using names as IDs |
Mon, 27 June 2011 06:04 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
Edited my last post, it should have read "properties", not "keys".
Let's consolidate the specs until now:
* Empire shall have a unique Id
* 'Owner' variable on all objects that require it shall match it's owning Empire's Id.
* Empire shall have three counters with configurable upper bounds; FleetCount, DesignCount, StarbaseDesignCount.
* Fleets shall have a unique FleetId composed of EmpireId+FleetCount.
* Designs shall have a unique DesignId composed of EmpireId+DesignCount.
* Starbase Designs shall have a unique DesignId composed of EmpireId+StarbaseDesignCount.
* All Ids shall be Ints.
* All Id calculations shall be abstracted in Properties
We might require to add prefixes as you said, for design separation between ships and starbases. Or we could begin the SB Ids at the normal designs upper bound.
And for clarity, let's drop the "Key" nomenclature and call them all Ids from now. It's getting confusing. In fact, I would vote that the properties are also all named Id; ie. Fleet.Id, Design.Id, Empire.Id. Looks more consistent and clear.
[Updated on: Mon, 27 June 2011 06:06] Report message to a moderator
|
|
|
|
Re: Need to move away from using names as IDs |
Mon, 27 June 2011 07:09 |
|
Daniel | | | Messages: 179
Registered: April 2006 Location: Nowra, Australia | |
|
Aeglos wrote on Mon, 27 June 2011 20:04 | Edited my last post, it should have read "properties", not "keys".
Let's consolidate the specs until now:
* Empire shall have a unique Id
* 'Owner' variable on all objects that require it shall match it's owning Empire's Id.
* Empire shall have three counters with configurable upper bounds; FleetCount, DesignCount, StarbaseDesignCount.
* Fleets shall have a unique FleetId composed of EmpireId+FleetCount.
* Designs shall have a unique DesignId composed of EmpireId+DesignCount.
* Starbase Designs shall have a unique DesignId composed of EmpireId+StarbaseDesignCount.
* All Ids shall be Ints.
* All Id calculations shall be abstracted in Properties
We might require to add prefixes as you said, for design separation between ships and starbases. Or we could begin the SB Ids at the normal designs upper bound.
And for clarity, let's drop the "Key" nomenclature and call them all Ids from now. It's getting confusing. In fact, I would vote that the properties are also all named Id; ie. Fleet.Id, Design.Id, Empire.Id. Looks more consistent and clear.
|
Sounds good to me.
Have fun.Report message to a moderator
|
|
|
|
|
|
|
|
Re: Need to move away from using names as IDs |
Wed, 29 June 2011 02:06 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
I commited r669 in which I implemented Id properties for EmpireData and Item. Also Owner property for Item which I left commented for now due to conflict with the Owner string variable; refactoring pending.
Empire.Id should be set on game creation only from an int 0-127. It internally left-shifts into a range of 0x01000000 to 0x7F000000.
Item.Id gets or sets the lower 24 bits of it's private itemId variable. As Mus suggested that gives us over 16 million unique Ids per empire.
Item.Owner gets or sets the upper 7 bits of itemId, and it should be set from it's owning empire's Id.
The only concern I have is that design Ids can match fleet ids... for example fleet 1 and design 1 will have the same Id on the same empire. It shouldn't cause any issues though, since those are never on the same collection and there's the Type variable to distinguish them (which, btw, we should migrate to an enum).
So next step, migrate to the new Ids. We can probably work on that at the same time without too much hassle. EmpireData still needs to be assigned an Id, and needs it's counters. I'll work on that now.
EDIT: Empires are assigned Ids based on playernumber for now. EmpireData now contains counters for fleets and designs, and I added some global ints to define limits for them (need to be moved to the new game wizard).
I have a concern though: int counters have a problem. When a fleet or design is deleted, we cant simply reduce the counter by one; we would also need to re-index all designs and fleets. We need a way to tag available numbers on the counters. Perhaps use a dictionary<int, bool> with with <item.id, isUsed> instead of plain ints?
EDIT2: Working on applying Owner property now.
[Updated on: Wed, 29 June 2011 04:19] Report message to a moderator
|
|
|
|
|
|
Re: Need to move away from using names as IDs |
Wed, 29 June 2011 06:54 |
|
Aeglos | | | Messages: 142
Registered: May 2011 Location: Chile | |
|
Well I commited now, as I need to get some sleep
Item.Owner property is now used everywhere, as is Empire.Id. There is a Global.AllEmpires constant if something adresses everybody, like messages (It's set to 0 right now, so fleets and designs should start from 1 and reserve the 0 id for this special case) and another Global.NoOnwer (0 too, they are aliases) constant for things like unhabited stars.
What remains to do is to assign a proper Id to fleets and designs, and sort collections by Ids as I only changed AllEmpires and AllDesigns from the ServerState.
There will be plenty of GUI errors, as before this the GUI displayed race names through the Item.Owner string, and now it will display an ugly Hex value, if at all. In fact, the game is not even playable right now, as collections are indexed even worse than before. At most you can load the game and generate turns with no orders.
We need to sort out some client intel to something like EmpireReports or MetEmpires, so the client can locate their race names.
I think the sanest thing to do is send each client an aditional collection of EmpireData objects, which contain information from the other empires. Or perhaps a new slimmer object EmpireReport which contains their Id, Icon, RaceName and known designs... then we get rid of RaceIcons, AllEmpireIds and AllDesigns from the Intel object, and EnemyDesigns from the ClientState.
But for now, sleep ... this restructuring turned out to be damn long and messy indeed.
Report message to a moderator
|
|
|