Others have suggested along these lines, especially the Sims players on LoversLab because obviously you can play multiple characters at the same time. It's interesting but I'm not sure how difficult it would be to implement, but I'll look into it.
Keeping fingers crossed....
About city, actually randomized buildings are saved centrally and there is only ever one version of each map that your game loads whenever you load a save, if you go into C:\Users\{Username}\AppData\Local\LifePlay\Saved\SaveGames , there should be a Nice.sav file there - both Marc and Eve saves will use this same file.
Actually, the way map saving works is why I start thinking about profiles. Currently, if I make 2 player characters playing the same city, without backing up 1st, and I don't want them to be "linked", it's impossible, cos the map will be overwritten by starting a new game with the 2nd character.
Idk how well such simulated "life" would work for characters you would populate LifePlay with though. and how they would interact with each other. Interesting thought though.
Actually, the new proactive family scenes opens up new possibilities. What if the "AssignResidents()" be extended to detect the actual WHERE clause and act accordingly. Each types building then can have proactive scenes. But that alone is not enough.
Consider the "naked_with_doctor" scene. The doctor and nurse in that scene are temporarily generated every time the scene fires. I've modded that scene so that the doctor and nurse are regular NPCs. Part of the motivation is I don't see a way to have doctor and/or nurse contacts apart from actually working in the medical industry.
But I ran into a logical problem. There are multiple hospitals and clinics in the map. Suppose by way of the modified "naked_with_doctor" scene I got the contacts of doctor A and nurse B. Then I go to another clinic, and the scene fires again, starring doctor A and nurse B. That would suggest that doctor A and nurse B works all over the place.
I'm thinking, what if every NPC can be assigned an apartment to live, an somewhere to work. That solve the above problem, while helping the "AssignResidents()" API should it later support non familial settings. Combined with per NPC flags, there are tons of interactions now logically consistent.
However, implementing NPC interacting with each other will face a significant hurdle. It will have to track the relationships between NPCs, and it will require significant resources to track. In my game, each "profile" already has 500+ contacts each. Tracking their interrelationships means tracking 500*500 = 250,000 stats. That's only for one profile and only relationship stat, not including rapport. That's not an easy feat.
As a comparison that I know of, "Hentai Highschool" (HHS) limits the total citizen of a city to 1600 people (default, can be changed by tweaking the settings). Unlike LifePlay, all the 1600 people is generated at once at game start. Moreover, that game keeps track NPC interrelationships, as well as per NPC day-to-day schedule (i.e. what time to work, at home, etc; this impacts who will you meet in the street at what time, etc). To handle that, it relies on SQLite. However, the events scheme is different with LifePlay. HHS events is more geared to be story driven, hence the event condition is more simplified. LifePlay doesn't have that luxury, cos it's more simulation based. IDK the performance impact of using database backend on event polling in LifePlay.
