architecture - Timestamps as ids in an entity manager?

I've built my own entity manager, as I found out some days ago, it is very similar to the Artemis framework.

For now, I just use integers as entity ids. Behind the scenes, there is a simple integer counting up every time a new entity is created so that the ids are handed out in incrementing order by the manager.

But recently I faced the problem that I cannot load multiple savegame files into the same scene. The issue here is that two savegames could use the same entity id for different things, causing a conflict when being load into the same scene.

Anyhow, the ability to load multiple savegames is useful to keep separated player data (his skills, inventory, custom items and tools he crafted) with scene data (rocks, trees, players in a town) and data from mods (cool new weapon pack).

So I need unique ids among every savegame file that will be created at all, without them knowing about each other. The idea that came to my mind is using timestamps as entity ids instead of consecutive integers.

(Since multiple entities might be created in the same millisecond, the timestamp should contain microseconds. And to play safe there could be also a mechanism to suffix a consecutive number if multiple entities are created in the same microsecond. To be honest I don't know how fast modern CPUs are and if they could do that, but I guess they can.)

Since I haven't heard of other people doing that, I assume that there is a trade-off. What are the disadvantages of using timestamps as entity ids? I think the performance hit will be minor and be can neglect that point.

Answer

Timestamps are a terrible thing to use for IDs, even with a high-precision timer 2 entities do not necessarily have to have a different ID (think how little time can have passed between 2 calls to CreateEntity()). Also you cant fit time into a simple 32bit integer. If you're going to load entities from two different sources there is a much easier fix. Load the first set of entities, find the highest ID and add this number to all IDs in the second set while loading.

Also, since you're talking savegames I'm not sure how ever 2 entities can have the same ID even though they are saved in multiple files. If they contain a saved state from the same game then all IDs should be unique.

Other scenarios you mention, like weapon packs and stuff should be wired by factory methods, which assign each component from the weapon pack fresh IDs while loaded. Wiring everything together instead of relying on predefined IDs.