To get some practice with SpriteKit, entities and components I built a little demo.

I created a SKNode subclass (IsometricMapNode) which renders an isometric map. It does so by adding SKSpriteNode (TileSpriteNode) subclasses to itself.

The data of the map is stored in a platform agnostic class IsometricMap which manages IsometricLayers and Tile objects. The map can do things like loading a TMX file and generate tiles which carry information (type of tile, texture name, ...).

The map is then passed to aforementioned IsometricMapNode and displayed.

All is working fine but then I read about GKEntity and I wonder if I can introduce the concept of entities into my code. I was wondering if every tile in my map should be an entity which would then get a render component and maybe a physics component or a particle component.

What I don't understand though: Would my model class Tile become a GKEntity, or its visual cousin TileSpriteNode? Or is it just philosophical?

If Tile is the entity, users of my map would add new entities to it, hopefully with a render component attached to them.

If I keep my Tile model class, the map would internally create entities from this class, add some standard components (mainly rendering) and allow the user to change those components later.

Is this making sense at all? :-)

  • 1
    \$\begingroup\$ The whole terrain should be an entity \$\endgroup\$ – Bálint Jan 4 '17 at 8:53
  • \$\begingroup\$ That's.....not really helpful.... :-) Maybe you want to explain a bit more and make it an answer? \$\endgroup\$ – Krumelur Jan 4 '17 at 12:00

Note: I've never used SpriteKit, so the below answer is agnostic. Someone else may be able to provide a SpriteKit specific answer.

There are many other questions here that discuss what an Entity-Component design paradigm is, so I'm going to be intentionally brief in that part of the explanation:

  • The entity is an identifier - in a lot of systems, the class just wraps what essentially boils down to an integer
  • The components decide what the entity "is" - do I have a position? Am I renderable? Does the player control me? etc.

Whether your map is tile based doesn't change this a whole lot.

While you -could- make every tile into an entity, and assign a position+render component to each one, you may find it better to let your tilemap renderer render any cosmetic tiles on it's own, without assigning entities/components. Entities/Components are generally most useful when you have something that affects gameplay logic - a spike trap, a breakable object, a pickup, a turret.

Regardless of whether you make all of your tiles into entities, or just specific ones, your entity should likely have a component that references the Tile object that the tilemap controls, as opposed to holding the Tile itself.

The tilemap renderer itself shouldn't know, or care, that you want to render the Tile because it's part of an entity. You'd just want to add code that manages the creation/destruction of those objects if you encounter an entity that has a Render component.

In an ECS setup, this would be handled by a Render system, that processes the components, and interfaces with the map renderer to create/destroy tiles based on the components set up for the entities.

The map renderer isn't "really" part of the Entity System itself, all the map renderer cares about is, "oh, I have a list of tiles, better render them".

|improve this answer|||||

I would say that tiles are not entities. You can think of Entities as things that are added to your scene e.g. The Player, Enemies, Obstacles, Collectibles etc. These are objects in your game that have functionality that can be modelled with components.

Tiles are not like objects. They don't have functionality, though they may have metaData e.g. in SpriteKit you can have userData associated with tiles, but this userData applies to all tiles of that type.

Another point to note is not to forget about the System part of Entity Component System. It's overlooked in most examples I see. In SpriteKit you can inherit from GKComponentSystem<GKComponent> to create your own systems.

Entity: Just a number. Nothing else.

Component: Which is just data. Nothing else.

System: This is where the logic sits.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.