FreeOrion

Ship designs, as they were implemented in Zach's preliminary Universe code, are being stored within the ship objects themselves. I tend to think it would make more sense for the ship design objects to be stored in the Empires and referenced by the ships. It seems like they'd need to be stored there in any case so that each empire can list the ships available to be built by them, so we'd have an unnecessary duplication if that information is stored in full in each ship. I'm planning to make this change, but would like to solicit comments here first in case there is some reason for keeping the current system that I'm not thinking of.. Any thoughts?

just a suggestion, will there be a mechanism to transfer new model (custom) of ship from one player to the group in multiplayer?

thanx

_________________
i'm no longer a lama.

There certainly is nothing like that in the plans right now. But this would be a good thing to suggest to the design team. They should be keeping (if they aren't already) a list of requested features.

_________________
Programming Lead

I actually played around with a design class when I was putting the empire headers together, but I decided to hold off on it.
IT will definitely make more sense to store the ship designs in empire and have the ships reference them, especially when ship designs start getting elaborate.

My original plan was to have a design manager that holds all the ship designs, and have the empires maintain a list of their buildable designs, in much the same way that the tech items are stored now. (Objects in a central location, with empires and universe objects referencing the IDs)

This, however, raises design questions. Are we going to allow custom refitting of individual ships (a la moo2?) If so, each ship will need to store copies of the stats, since they will be unique. If this is not the case, it's sufficient to have the ship store a reference to a design object thats stored in the Empire module somewhere.

_________________
Empire Team Lead

In any case the Empires will have to keep a set of designs, whether there are refits or not (so that ship designs don't have to be recreated each time a player wants to issue a build order). And looking more closely at at Zach's comments in the code, I think he was anticipating that this would be the case. I think the question is just whether we want to have this data duplicated in full in the ship objects or just referenced by them. And refits (and other mods, I suppose (experience, special events, leaders, etc)) are a good reason to have this duplication..

I think you should go ahead and add the capacity to store ship designs to the empires. You can use the design struct in the universe/ship.h file. One change that I'll make to it will be to add a design ID which will be used for reference purposes instead of the names (as the current comments suggest) so that players can use duplicate names if they choose. I'll upload that tonight or tomorrow so you can use it for your coding..

_________________
Programming Lead

Ship design with ID has been committed.

_________________
Programming Lead

I'll put a list of design objects into the Empire class.

This should be sufficient to support refits (add a new design to the list), captures (add the captured ship's design to your own list), and anything else we want to implement.

I will probably want to modify the design class to add whatever overhead I need to store and track designs.

I probably wont be able to get to it before Sunday, so if you need something to do between now and then, have at it Otherwise, I'll try and have it comitted by sometime next week.

_________________
Empire Team Lead

The whole point of having all the ship stats duplicated in each ship was that you could potentially make unique modifications to each ship, a la MOO2. But these should not necessarily become new designs per se. How much space do you think all those duplicate design stats will take up? 1MB? 2? Do we care about this much space enough to bother with a more complicated design?

Each empire needs to have a list of "buildable" designs, so we can populate their list of shipbuilding options in the UI. That, in itself, is a reason to have a set of designs in the empire object, and to have a "ship-stats" class which is distinct from the ship itself.

As to the memory problem, It depends on how big we want our fleets to get. We're trying to plan for the future when designs get much more elaborate. I figure a ship design class could probably take up at least 50 bytes, and maybe close to 100 in the worst case (with lots of weapons and special gear)

100 bytes is roughly 1 MB per 10,000 ships. If our fleets are MOO2 sized (say, no more than 500 ships per empire), then this is no problem, since 500 ships * 10 empires = 5K ships = a measly 512KB. If they're MOO1 sized, however (tens of thousands of ships per empire), then that will create memory problems if we represent the ships individually, and store copies of the designs. 40K ships per empire * 10 empires = 40 MB, worst case. If we're planning on huge fleets, we probably aught to ditch the idea of a ship as a distinct object, and just do it the way MOO1 did (but with an infinite number of designs per side)

Now that I've done the math, If we intend to keep the fleet sizes small, I'd actually like to duplicate this data, since it would allow captures, custom refits, etc etc to be supported with little effort (you just change the individual ships, no need to tweak the design "schema").
If we're planning on huge fleets though we'll need to have designs seperate and put references in ships, to avoid hogging too much ram.

We probably need the design team's input to decide the question of fleet size.

_________________
Empire Team Lead

The designs are separate from the ships in my design, but when each ship is created, it is given a design object that keeps a local copy of, that defines its size, shape, weapons, whatever. That design can be changed on a ship-by-ship basis, captured with the ship, etc. This flexibility is why I set things up the way I did.

The original designs should indeed be placed in the Empire that creates that kind of ship; I only put copies into each ship.

And for the worst-case scenario you outlined above, 40MB is not a huge deal (though it is significant). I have 512MB on my machine, and by the time this project is ready to have huge fleets an multiple players, 40MB will be even smaller in proportion to contemporary memory sizes.

Well, if we have the server and 10 AI clients running on the same machine, we could have a problem. The server would eat 40M
And if each client empire had, say, 30K ships, we're looking at minimum 3M per client, in addition to any ships they're storing that belong to others, (say 1000 per rival empire * 9 rivals is another Meg, give or take)
Now we're up to 80 M, and it could conceivably go higher if we have more players, or good sensors so you see more ships. We'd have to spec a minimum of 64M ram for single player (they'd use lots of virtual memory), and this is just for the ship designs. Again, this is worst case, assuming REALLY large fleets. I dont know if our game will end up having that many ships or not.

Just something to keep in mind. I'm actually starting to think we should try your way first, but be prepared to use references if we find our performance unsatisfactory.

_________________
Empire Team Lead

Again, I refer you to the fact that my computer's memory is 512M, and 1G memories will be commonplace in two years or so. If we use up 16% (for 512M) or 8% (for 1G) of our memory on the largest memory requirement, we'll be fine. Even if someone has a 256M memory, that's only about 31%. And this is the "worst case".

But this actually misses my main point, which is that you should only optimize when you need to, and moreover when you have the numbers to prove that you do. Premature optimization will lead to needless complexity; that has real costs in terms of correctness and coding time. I believe Joe's way is more complex to implement and mine simpler, which is why I'm arguing for my way.

I'm not disputing doing it your way. That's the way I plan to implement it. I'm just pointing out we may need an alternative later on down the road, if it turns out we're eating too much RAM. 80MB is no problem for the two of us, and probably most of the team, but for somebody running with 128M it might get burdensome. For now, lets do it your way, but we might want to change it in the future.

_________________
Empire Team Lead

Why dont use both?

U create a list of ship-design and store it in the empire.
When you bild a ship, you link/reference the ship-design to the design in the empire.

When you refit a ship, you simply give the ship itself the new values.

So, you would have only a few bytes per standard-ship like (id, place, belonging_to_empire, using_design)

When you refit it, you just add the variables, and delete the using_design.

After a little thinking about, thats not much easier than storing designs empirewise and creating new designs for each refit...


On the other hand, i dont think optimizing to early is a bad idea, this sort of decision cant be optimized later, once it has been used, so we should make a long term decision now.

Depends on how the ship classes are coded, but if they're designed well, this shouldn't be too hard to optimize later. All we'd have to do is change

ShipDesign the_design;

to

ShipDesign* the_design;

_________________
Empire Team Lead