Adam's Lair Forum

Hi!

I'm planning a tile based game, in which a random map would be created. I wish to be able make a rather big map, but how much tiles is too much? The game would also include very many characters (probably thousands at some point). These would not be shown in the map though, they would reside in lists within the tiles. Opening the tile menu would show a character icon though, 15 bears for example (one bear icon next to the list item). Individual characters still need to be distinct gameobjects right? Will so many characters cause problems? Movement would be handled by moving the character (party) from one tile's list to adjacent tile's list. Does this make sense? Also, would Dualitys tilemap logic work well in this, or should I create logic of my own?

-Thanks!

PS. Probably going to ask a lot more questions regarding this project later on.

Hey there, and welcome!

One key thing to keep in mind when doing large scale games is: Not everything needs to be a GameObject. Especially for a tile-based game where units can only be at one tile, but not move freely otherwise, and one tile can house a lot of units, it can make sense to model them without GameObjects, and simply store them in an array somewhere - like in a management object where you have only one per level. Especially when expecting very large numbers (1000+) of units, it can make sense to simulate and render them using a single GameObject. And for 2D tile based storage, you could take a look at Grid<T> data structures as well.

When using the Tilemaps plugin for Duality, the map itself will be modeled with exactly this in mind, using only a few GameObjects to describe and render the entire map. They don't have an update overhead for the most part, and rendering will lookup only the part that is currently visible. Both renderer and tilemap itself have been designed to work well with very large maps, so I don't think you'll run into any issues from that side.

Hope this helps!

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Thanks for your reply! This will definitely push me to the right direction! Questions arise though.

If they are not GameObjects would they just be a class of their own? Then, this Character class would have all other information as attributes? Or sub-classes. But sub-classes are kind of against the point of Duality? Or can I attach components to other classes/objects than GameObjects?

The bear was a bad example as they are most likely going to be generic (all of them are the same). Let's say we have Character. It's race is Apeman. This race would give bonuses to Agility attibute, bonus movement and work efficiency in jungle tiles and open a unique ability to build buildings on top of trees. This character would be Citizen of Pizza Land (random generated / user generated) and this nation gives other bonuses like better combat ability when using pizza shovels and lets say bonus to researching food related technologies to make their pizzas better. The attributes and skills a character has would be semirandom and these things previously mentioned would affect them among other things. Then there are skills which would give bonuses to various things like combat, woodcutting, pizza making etc, and these would be atleast partly determined by the characters actions, basically some sort of experience system (Hmm, perhaps I must include pizzas in the game ).

When I first thought of this game, I had a hierarchical logic in mind. Concerning the characters for example, the bears won't need that much functionality, as they would mostly be generic and just move around and be a minor threat. So they could be like Character>Wild>... Without all the mechanics related Nations/Civilizations, working, etc, which Character>Citizen would have. The component system seem appealing as it offers so much flexibility and basically anytype of character could be a combination of different components, and I feel this way I could make very interesting character/nation types.

What do you think? Should the characters be just a object class containing information? Can I use components in that case? Is Duality good for this?

-Thanks!

Well, using a Component-based approach or not is not linked to any game engine per-se, being a generic programming paradigm; Duality's ECS is tailored around the use for GameObjects and providing them with the capabilities needed to interact with the engine.

In your case, you could either roll out your own Character-Component system if you need to have a real granular control over each single Character options, or you could also manage it with simple objects and interfaces in case each Character has the same broad characteristics with just minor differences in behavior.

i.e. in your example, you could either have a Component-based approach such as

With the possibility to combine basically everything, but at the same time opening yourself up to bugs (or not) where your Bear is actually a Citizen.

On the other hand, if all your characters have a Race, a Behavior, and so on, you could simply define it as


so you could have your Bear(WildRace, WildBehavior) and your Pizzaman(ApemanRace, CitizenBehavior(PizzaLand, BakerJob))

It's just a matter of preference and perspective though

_________________
Come on Duality's Discord channel. We have cookies!

I'd also like to point out that you mentioned something that could be very important to your design here:


The way I read this is: A nation has multiple, or maybe even just one type of unit, but each actual "instance" of that unit is the same as any other unit of the same type. There is no "unit individuality", they do not have individual stats, and if a unit of type A has special feature X, all units of type A have it.

With this in mind, you (for the most part) only need to describe a unit type, not a unit itself. This simplifies things a lot. Regardless of your design (components, hierarchies, whatever), you only have to deal with one per type (a handful, probably), rather than one per unit instance (hundreds? thousands?). There's much more freedom in how you approach the topic, if performance is off the table!

That said, you still have to deal with how you express unit parties and per-party modifiers, but you can probably still group them. You could, for example, have a party move around on the map as a single GameObject, and store how many units are in there, what type the units are, and what party-specific modifiers are on them.

That way, the actual number of units would be irrelevant to performance, as you're only dealing with the party as a whole. You could then have one Component describing the party, one for rendering it on the map, one for controlling it, or whatever makes sense given the desired behavior - point being, they all deal with a party of units, not with a single unit.

There are definitely other ways to approach this too, depending on what you want on a per-unit basis and how fine grained / micro managed you want the game to be.


What SirePi said There's not really the one true way to defining what exactly is expressed as a Component, or how it is expressed. It depends on your game, it's scope, and your preference too.

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Actually that is precisely not the case. One of the most important aspects of the game would be HRM (human resource management). Lets take the Apeman example. There is a Apeman, who we call Abe. He has all of the above mentioned bonuses of an Apeman race and a Pizza Land -citizen. He has low Strength and Constitution attributes, making him ill-suited for physical work and combat. He has due to his character traits +3 Intelligence, which makes him good for intellectual work and +5 Cooperation which makes hes party around him work better. He also has a Cook -educational trait, making him good at and teaching cooking. (Cooking = the skill to turn food ingredients into proper meals, increasing the food gain compared to just consuming the ingredients by themselves) He has been working in a Pizza Place for a while and has his cooking skill raised to lvl 5. There are also 5 other people working in the Pizza Place. They have lvl 1 cooking skill. Because of Abe, their experience in cooking increases faster, as he can share some of his vast knowledge to these beginner cooks. Their overall work efficiency is also positive, as Abe's and their's Cooperation skill ends up being +3.

Then we have another Apeman. Lets call him JWB. He also has the Apeman and Pizza Land racial and citizen bonuses. He has positive Strength and Constitution, making him suited for physical work and combat. He also has positive Agility, giving him a movement speed bonus. He is a beginner Hunter in a party of experienced hunters. Because of his lack of experience he actually lowers the overall hunting ability of the party, but it is important to train new hunters, as the people of Pizza Land love their signature Zebra-Pizza so much that they need more and more Zebra-meat each year. Because of that he has been taken along. Also, due to the many experienced hunters in the party, he should learn pretty fast, and because of his attributes being good for hunting, he should become a great hunter one day.

And so on...

So, each character is an individual and has individual stats. Many things would be handled in the Party perspective though (movement, combat, overall work output? etc.), in which each individual would contribute to. Even in a party somethings could happen in individual level also. (Party = 1..n characters doing something together as a one unit NOTE: a party can have only 1 character. ALSO NOTE: that basically means all of the characters would be in a party, some of them by themselves, some of them in party with 1 to n. more characters.).

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?

-Thanks!

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.



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.

_________________
Blog | GitHub | Twitter (@Adams_Lair)

Hey!

Testing out the engine and tilemaps and I'm running into problems. I made a tileset of 3 tiles and it works fine. I made a Map_Manager component, which as a test is supposed to change the size of the tilemap. At first I put the resizing into OnInit so that it would run the code when the component is activated. Well, the component activates the moment I run the game (in sandbox mode). The question is, how can I activate components when I want? Not when the component exists, but something like Map_Manager.Activate(); or when X happens Y is activated? I tried to fix the problem by making the component not implement ICmpInitializable, but as having GenerateMap() function. This function would be called by Map_Controller component, which implements ICmpUpdatable and in it it listens if I press spacebar and when I do, it should call Map_Manager.Generate_Map(); Even now, when I go to the sandbox mode, it immediately resizes the map. Why is this happening? Also, when I run the game, there is just black screen, It worked fine at first but for some reason nothing is showing in the screen anymore.

Damn, beginnings are difficult .

-Thanks!

Just realized that I could add the component to the gameobject when spacebar is pressed and then shut it down when it is no longer needed. How do I shutdown a component by the way? By removing it from the gameobject?

You can either remove it from the GameObject with

or, in case you might actually need the Component again, you can just toggle it's Active property

_________________
Come on Duality's Discord channel. We have cookies!