StrigoiTyrannus wrote:
Why can't all the characters be Gameobjects? Party would have information of its own and have a list of Character GameObjects which it holds. They could of course be just Character Objects, but then I would have to create a component system myself? Would GameObjects use too much memory or what is the problem?
Oh, they can be GameObjects, sure! I usually just try to pick low hanging fruits when it comes to efficiency, and a "all characters are the same" situation would have been one of them

But apparently, things are a bit different after all.
Edit / Note: GameObjects / Components do have an overhead over storing something in a list, but a very small one. It starts having an impact when you think about what each object
does - just storing 10k objects is fine, whether or not they're Components. But when you start to have each of them render and update itself once per frame, query them, let them exchange information, deliver messages, and so on, you can easily arrive at a point where it makes sense to choose a more efficient approach. Take a particle system: If each particle is its own GameObject with a Transform and a SpriteRenderer, you're going to have a bad time with 10k of them in an effect you spawn, because each of them gets the full GameObject treatment as if it had nothing to do with any of the other particles and could turn into a Building, a Tree or Whatever any second. You're paying for a kind of flexibility that the particle effect use case doesn't need. By modelling particles instead in a single ParticleSystem object, that itself simulates and renders all particles in one batch, you can reduce the overhead to almost zero.
You're probably dealing with a few hundred Characters, not 10k+ particles, so it should be fine - this is just to illustrate the point

Reading your update, I'd still argue towards modeling on a party level though. Not for performance or memory reasons this time, but because a party seems to be the main item that you interact with, both from a user side and from a gameplay side. Characters won't ever do a thing except in the context of a party, even if that party happens to consist of just one character, right? So this is where I would start to model things based on.
StrigoiTyrannus wrote:
They could of course be just Character Objects, but then I would have to create a component system myself?
If you have, say, a
Party class that's a Component, it could just have a list of
Character instances, which are not Components. There's no need to create a custom component system for this - for just modelling the classes it won't actually matter that much whether a Character is a Component or not, except that you don't need to put them on GameObjects.
Then again, if they
were Components, you could actually just add them as children of the Party object and inspect each Character of each Party in the Scene View, which is nice too. In that case, I'd probably go with a design where a Character GameObject doesn't actually have a Transform, or a Renderer at all, but is simply a "data object" child of a Party, which takes care of positioning, rendering and gameplay logic. In that case, a Party wouldn't need an "explicit" list of Characters, but could just iterate over its child objects to retrieve them.
Or maybe something inbetween! There's really a lot of ways you could go here. Don't read my postings as a guideline, but as some inspiration. You know your game better than I do.