Dungeon crawl in Ash

[Daniel Krejčí]

Hey

I am currently working in team trying to create dungeon crawl like game. It's using WebGL, 3rd person view and 3D calculations and stuff.

As usual, game board will be divided into square tiles. Each tile having some Position and Display component in essence. I would like to have one RenderSystem that can handle rendering of entities based just on those mentioned components. It will render tile floor, wall, some torch on that the wall, web in the corner and so on.

Now let''s say that level size will be rather huge, could be even like 10M tiles with 500 torches in total. That's a lot of entities. However it will be a lot about light and shadows so only small portion of map is currently visible to player. There will be LightSystem making these checks and adding/removing "Visible" component to/from particular entities. And here I am getting stucked a bit. Performance issues.

As I am rather newbie game developer, I am probably missing something totally obvious. Currently it looks like, that during each update I have loop through all entities and check, if those are visible to player. I can imagine, that it could be limited just to entities with Tile component. However I am wondering it's ok, to keep dynamic array of entities, that are in that component. It's really bad habit and thinking blocker from OOP. From what I have read here, it's not really recommended to have entities list kept elsewhere.

Anyway even if it would be allowed, it's still 10M tiles to check. I could imagine some spatial indexing for OOP approach. For ES it's quite foggy imagination as the nodelists are component driven, There is no possibility to keep list of tiles based on X/Y coordinates.

Can someone push me in the right direction please ?

[James Wrightson]

As you are beginning game development, I would strongly advise you against making such a large game.

Start smaller, learn what is needed, and move on up the ladder of project scope.

On that note, why not use a typical spatial partitioning structure within an ASH system and just process
entities that have a specific "SpatialPartitionCom"?

The end result is to add/remove a display or render component to prevent that entity from rendering.

[Daniel Krejčí]

Thanks for reply James. Sure, it may seem as big, but I am not alone, game has very nice design document and very talented assets creators. For now it's quite small prototype of the game just to make sure it can be done with ECS easily.

Anyway, can you please elaborate more about that SpatialPartitionCom ? Do you mean to have special component for each indexed area ? Or I don't really understand. Having same component with just some identifier of indexed area cannot help. You would have to iterate over all of them and it's losing all advantages.

What about keeping this index privately in the system that takes care about calculation what can be seen ? It would simply contain list entities, that are in particular area. But this is just wild guess, it's not that easy probably...

Daniel K.

Dne neděle, 10. listopadu 2013 12:33:37 UTC+1 James Wrightson napsal(a):

[James Wrightson]

I can assume that some visual entities in your game will want to be statically places (UI elements etc) and others will want to be clipped so you do not render elements
outside of the zone.

If you give the elements you want to process in your spatial graph, simply give them a component (such as a SpatialPartitionCom) that can be used to identify them in a
spatial partitioning system.

All that system needs to do is for each node, check if the node should be rendered, and if it shouldnt - simply disable that entity from rendering (maybe a IsVisible) value in a display com.

[Daniel Krejčí]

Oh, I think I am getting there. You mean assign SpatialPartitionCom to entity when it is created, so it can be used later. That makes sense. I was lost in the idea where this indexing will happen and thought I will need iterate over everything to make this index.

This also means, I don't need to worry about linking other entities on the tile together. By this indexing, there will be just a few entities to iterate over, so it not a big deal.

Thank you for the help, James.

Dne neděle, 10. listopadu 2013 13:52:08 UTC+1 James Wrightson napsal(a):

[James Wrightson]

No problem Daniel, ask any time!

I have planned to write a series of articles around entity driven games, with a real-world focus

here.

I do not have much content yet but could be worth a peek! :P

Also, do you have any links to your project? Or is it early/hidden etc?

I would be interested to see what you are developing :D

[Daniel Krejčí]

Sure, there is micro site we have launched recently ... http://mrammor.com

Dne pondělí, 11. listopadu 2013 11:48:13 UTC+1 James Wrightson napsal(a):

[Daniel Krejčí]

You have nice blog there James, keep up with more posts please. I have saved it in my RSS reader :)

I am wondering about one more thing. Is it a good idea to have shared components ? I mean for example there will be a torch on the wall. I can presume that all torches have same properties about light they are emitting. Nothing can change that, it's fixed information coming from the item definition. Would it be too much againts rules to use same Light component for all torches ? It would save some piece of memory.

Same applies to things like weapons. One type of weapon has the same fighting stats, that cannot be changed within the game. However we can decide to do some change that should propagate to the new and old weapons.

It seems like a good idea to me . I am not entirely sure how it would be handled in the code, but it¨s should be hard to do.

DK

Dne pondělí, 11. listopadu 2013 11:52:37 UTC+1 Daniel Krejčí napsal(a):

[James Wrightson]

Thank you for the support!

Having shared components can be a good idea although I wouldn't do it if its just to save memory.

The only problem at the top of my head you could run into, is if you suddenly need to process the shared components differently, then 
you run into a singleton like issue concerning references.

This could fall into a trap where if you remove a light entity or anything using that shared component, you might as a developer expect
that component to be removed from the engine. But of course, its not... Could cause some headaches if your working in a team.

I tend to pass around shared components as you would akin to inheritance. Parent/Child relationships can benefit from that for example...

I have a PlayerInventorySystem that when a new holdable item is equipped, I pass on the players TransformComponent to that item entity so
it has a spatial location in 2D space.

[Daniel Krejčí]

Well for the persistent world in multiplayer game it could be helpful to save some memory. It's not client I am worried about, but since the server will be running ECS too (NodeJS), it would need to hold components of the all active areas of the game in memory. Having some of them shared could help in overall.

I am aware the risk that sudden need for change in shared component usage could cause a problem, but it can be handled, since all components will be held in database. I can quite easily look for all entities using this shared component and create new one for each of them. However thanks for pointing this out, I will keep it in mind while designing whole thing.

There will be a lot of items in the game, that means a lot of situations where this could be used, I want to create more generic approach, so it will be part of the engine and everyone will expect such behavior. I am even thinking about using this idea for marker components as you have mentioned in blog post. From what I know, Javascript likes using a references instead of new objects more.

Could you please elaborate more on that inheritance ? In the blog post you have essentially banished any inheritance. I am bit confused here.

Dne pondělí, 11. listopadu 2013 21:39:44 UTC+1 James Wrightson napsal(a):

[James Wrightson]

Sorry for the confusion, what I meant is that entities can inherit components from others.

Basically just a phrase describing the format of shared components.

:D

On a side note, I may be working on an entity driven multiplayer game soon...

[Daniel Krejčí]

Oh, I understand, ok than :)

It would be great to share experience from this field. Multiplayer brings a lot of issues there.

Dne úterý, 12. listopadu 2013 11:17:45 UTC+1 James Wrightson napsal(a):

[James Wrightson]

One the issues I am interested in tackling, is that when developing on a client-server model...

...The entities being polymorphic (the state changes over time, components added/removed/changed)...

...How to handle the very dynamic nature of sending and receiving data from the server.

Games that are not ecs tend to be easier to filter out and normalise the smallest amount of data needed to be sent,

but this could become an interesting issue with the ecs.

Could be much easier, I all ready have a few ideas that can leverage it nicely, but interesting too.

[Daniel Krejčí]

Hi James, I have replied to your mail address.

Dne úterý, 12. listopadu 2013 11:53:54 UTC+1 James Wrightson napsal(a):