FreeOrion

Hi

I've looked in "programming work" and thought about doing the changes to the Design Window.
However, I don't understand item #1 - seems to me there are only 2 types of slots, and each item can only go to one of them - so what exactly should be done there?

There are 2 types of slots, but some parts fit into both types. So, my guess is, this function could look for those kind of parts to move into another type, to free the type of slot, they are currently occupying and then add the selected part into the free slot.

I see.

In that case, I think I'll start working on that. In order to do that, I'd like to seperate the "Design managing" functionality from the UI, and put it in a "design manager" class that will also contain the various finished designs, instead of them being directly in the "Universe" class.

Is that acceptable?

Can't comment on this, but here is a scenario picturing the situation.

Could you explain why you want to do this a bit more and what benfits it would have?

The set of ShipDesigns that exist in the Universe really is part of the state of the Universe, unlike, for example, the set of techs that could be researched or types of buildings that could be unlocked, which doesn't change over the course of the game. The point of the manager classes for those is to load them all up, and provide an easy way to access them.

With ShipDesigns, there is a PredefinedShipDesignManager for the designs specified in a text file before the program is run and which are used during universe creation, and which you can use to look up the designs by name in cases such as creating predefined fleets using the design name, since you wouldn't know the internal design ID before the game is run so need to refer to designs by name.

But for designs created by players during a game, there's no obvious, to me, context in which they're needed where accessing them by design ID is insufficient. Every ship stores its design by ID, so it's easy enough to look up a design in the map using that ID. Each Empires has set of its called m_ship_designs which stores which universe design IDs that empire has access to, which is presently just designs that empire creates and ones added at the start of the game.

If you wanted to make it possible for player to manually store and retreive ShipDesigns they've created, then there might be more of a case add a manage for these, although the existing PredefinedShipDesignManager could probably be modified to do that job as well.

Just basic software design principles, I guess.
Separating the view and the model, and unify all the ship-design operations in one central class in case it's needed outside of the UI(Differant UI? Computer AI mgiht be designing ships?), and abstract the access to ship designs.

What "all" ship design operations do you want to unify?

Most of what's done with ShipDesigns is creating them, deleting them, copying them, and accessing them by ID number (and checking the data contained in each, but that's not an issue for the manager class). That is as much or more than is done with HullTypes or PartType, which have managers to track them, so it's not unreasonable to suggest using a ShipDesignManager based on that set of operations. If you want to add saving and loading user-created ShipDesigns, that would be a good motivation for using a manager, although as above, there already is a PredefinedShipDesignManager which could probably be adapted for that purpose.

Empires track internally which ship designs they have access to, which should stay as part of the empire.

Unlike the available parts or hulls, though, the existing ShipDesigns are a part of the gamestate, and can change during a game. (Hulls, parts, techs, etc. are predefined game content, as opposed to in-game situation or gamestate.) Having a ShipDesignManager would make its contents also part of the gamestate, and you'd have to adapt the existing Universe::GetShipDesignsToSerialize function to send only the designs each empire knows about to each player, and make sure the ShipDesignManager's contents are properly stored and restored when saving or loading the game, and when sending turn updates to players.

ShipDesigns are already available outside the UI, as they're stored in the Universe and can be gotten using Universe::GetShipDesign, or the free function GetShipDesign that gets the requested design from the Universe. What do you mean by "abstract the access to ship designs" ? The use of the free function GetShipDesign is identical to the use of GetHullType or GetPartType that look up HullType or PartType objects in their respective managers.

The AI can already design ships by issueing a ShipDesignOrder, which is the same thing that happens when the human player creates a design in the UI by clicking Confirm New Design.

Within ShipDesignOrder::Execute, all that happens besides safety checks is
1) a copy is made of the stored ShipDesign in the order (which is how what design to create is specified)
2) the design is inserted into the universe
3) the empire that created the design has the design added to its available designs

I intend the manager to support the following:

1. Creating/copying a design
2. Deleting a design
3. Obsoleting a design
4. Accessing a design by id (other parameters to be added as needed)
5. Adding a part to a design (could be in the design class i guess, but i think game logic should be in the managers, not the data classes)
6. Loading predefined designs
7. Saving and loading available designs for a "running" game
8. Filtering the design list by empire (Ultimately abstracting the way the "designs per empire" is stored, which is mainly what I meant by abstraction) , active/obsolete, hull type/size and other params as needed (Can colonize? Combat? Transport?)

Although ship designs are accessible outside the ui, what I mean is that putting the "add a part" logic in the UI won't enable AI or other UIs yo use that logic without coping it.

That said, I am aware I'm a newcomer and might not see the full picture.
If you say that this isn't a good idea, I won't argue any further, add it to the UI class and leave the rest as it is.

These sound reasonable, although note that there is a distinction between deleting a design entirely from the game, and an empire deciding to remove the design from its available designs (which might be replaced with obsoleting, now that I think about it...).


Point 3 and the part of 8 about changing how designs an empire has are similar (ie. storing which designs an empire has access to, and which of those the empire considers obsolete). This might not be a good thing to *store* in a ShipDesignManager, though. Right now, which designs an empire has are stored within that empire, and presumably if obsolescence was added, it'd also be stored in the empire. This makes sense because these are logically a property of the empire, rather than of the design itself.

For example, it would be easier for tracking what information one empire knows about other empires to keep this information within the Empire class. There will probably eventually be a map<int, map<int, Empire*> > in the gamestate. This would be a map from empire1 ID to: map from empire2 ID to Empire object, where the contained object is the information about empire2 that empire1 knows. What ship designs empire2 has would be important information to track, so that espionage could be used to find out this information. If you stored the information about what empires have access to in a separate DesignManager class, you'd also have to separately track what other empires know what empires have access to those designs, which seems to needlessly complicate an already complicated situation.

Also, if you want to track which designs which empires have, storing that in a separate DesignManager class could be awkward, because if an empire was removed from the game, you might then need to loop through all stored ShipDesigns and update them so that they aren't owned by the nonexistant empire... But then you'd lose the historical information that the removed empire had access to that design before it was destroyed (whereas if stored in the empire, you could leave the information in place and just flag the empire as removed, as occurs now). Alternatively, one could leave the data in the DesignManager that the removed empire had access to the design in question, but that might be misleading if one is looking up which / how many empires (implicitly still in the game) have access to the design... Which probably isn't as big of an issue as I seem to be making of it.

Anyway, what I'd suggest is, if you make the ShipDesignManager, it could provide convenient accessor functions to get all the designs owned by a particular empire or other filtering as you feel appropriate, but you should leave the information about what designs various empires have access to or have obsoleted within the Empire class. The manager can easily poll the empire class to find out what designs an empire has or has obsoleted, so the filtering functions can still be implemented.


You might be slightly misunderstanding the function of the DesignWnd::MainPanel::AddPart function. There actully isn't a ShipDesign object created until the Confirm New Design button is pressed by the player. ShipDesign actually has almost no way to modify it after it's been created. The way the design screen works is that a list of parts and a hull are created by the user selecting or dropping them into place. AddPart just tries to find a place to put a part without the user needing to specify which slot, and adds the part to the list of parts in the UI. Only after the Confirm New Design button is pressed is the list of parts and hull used to create a new, but temporary, ShipDesign object, which is then passed into a ShipDesignOrder, which is both sent to the server and executed locally on the player's gamestate, which adds a permanent copy of the temporary ShipDesign to the Universe's stored designs.

So, one / I could argue that AddPart is mostly a UI logic issue. Deciding where to put a requested part or how to rearrange parts already added isn't really a game logic concern, so much as a player design decision that is being automated... The use isn't actually for modifying an existing ShipDesign, but rather is for modifying a list of parts in the UI that may later be used to create a ShipDesign.

AddPart also probably wouldn't be of much use to AIs, as they'll need to consider the whole situation with all the available slots in order to find a way to arrange all the desired parts... AddPart is intended as a tool to aide interactive ShipDesign creation, which is not how AIs (I expect) would do the designing. For example, if writing a ship design creation AI, I wouldn't just use AddPart repeatedly and hope all the parts I wanted to add get in the design... Rather, you'd check the available slots, and decide on all the parts to add all at once, never attempting to add a part that wouldn't fit due to lack of suitable slots.


I don't really understand this point. Presently, the content manager classes mostly store and retreive game content objects. Content classes, like BuildingType or ShipDesign, encapsulate that bit of content, which determines details of how game objects behave. Gamestate classes, like Building or Ship encapsulate the game state, and have various methods for modifying that state or interacting with other bits of gamestate, or are manipulated by the Universe or Server or Order type classes, which collectively contains all the various bits of game logic. I'm not seeing how game logic fits into content manager classes...


A ShipDesignManager is not a bad idea, but some details of the scope of the class' function and the internal implementation need to consider the bigger picture.

If a player accidentally duplicates a ship design, or misspells the name or description, it would be annoying if the ability to just get rid of it completely wasn't there. A list of "obsolete" ship designs doesn't need to be cluttered up with repeats and spelling errors.

_________________
Warning: Antarans in dimensional portal are closer than they appear.

A reasonable point.

Either way, there could be a warning popup if a player attempts to create a design that exactly duplicates an existing design.

Aside: Designs created by different players but which are otherwise identical are NOT considered duplicate designs. Using espionage or reverse engineering, a design could be stolen from another player (allowing production of ships of that design, which just capturing a ship wouldn't necessarily allow), and there could be effects which act on ships differently depending on who designed the ship... A potential situation arising from that would be having to consider whether to upgrade your ships or design new ones because an enemy has stolen the plans, and would get the benefits from you researching upgrades to the design. /Aside

Changing the name or description of an already-existing design is somewhat problematic. Other empires might have acquired the design (see above re: who created the design) and a player renaming a design s/he created would then potentially rename that design for other players, which could be confusing or exploitable.

Only allowing renaming of designs that no other empire has access to or has ships of could be an exploit, in that it might allow empires to determine whether / when one of their designs has been copied, and this would be kind of annoying to keep track of, and possibly an annoyingly arbitrary-seeming limitation for players (as opposed to "no renaming!" which would be perceived as just how things are).

If we forced players to wait a turn between creating a design and being able to build it, despite the annoyance that this would cause, we could make it possible to undo new design creation orders on the same turn they're issued. This would allow cancelling created designs on the first turn only, which might fix a large chunk of the potential problems.

As I've said, I'm not really in the mood or a position for a debate on this topic. I'll just do the changes straight in the UI class, and leave refractoring to some future point when/if it's needed.

As for deleting ships - I don't think actually removing them from the game entirely is a good idea, for all the things you've said (tracking, what if someone has a ship with that design, ect). They should just be marked as deleted and not displayed to that player.

As for renaming a design - I don't see a problem, as "stealing" the design (or selling it) would be just making a copy of the design (unless you're going to tell me that after I stole a design once I keep getting "free update packs" )

That would seem to mean deleting a design would be the same as obsoleting it, for reasonable defintions of "obsoleting"...


I'm making a distinction between using an existing design, which would require an espionage act or trading designs to enable one player's empire to use a shipdesign created by another empire. This would be distinct from a player just looking at a ship and making a new design with the same hull and parts, as the new design would be created by the player, not the original creator of the original design.

Exactly what the mechanics of upgrades or refinements for parts and hulls and shipdesigns are isn't fully determined, but I imagine there could be cases where there are advantages to using another player's design, if that player had more advanced upgrades than the player building the ship, or if the player who designed the ship had some bonus to engineering which would make ships designs they create better than other empires' ship designs with the same hull and parts.

That doesn't necessarily mean a ship would get bonuses from techs researched by a its designer but unknown to its owner, as those techs would probably have conditions in their effects to limit their scope to ships owned by the empire that researched the tech.

1. Almost the same. Imo, you should be able to see/steal obsolete designs with the right filter, but not delete designs, and should not be able to delete designs that are in use.

2. I... don't follow. I guess I'll leave it for now and get back to it when there's actually trade/espionage systems designed.