All Questions


posted to: Wiring entities

Sprite Vs Tilemap.

What is the benefit of doing it this way to find neighbours and update the sprite as opposed to using the inbuilt tilemap?

  • Razoric replied

    1. Consistency. Since entities are a complex set of layered, animated sprites, collision polygons, components and scripts and groups, it makes sense for them to be entities instead of tiles. Thus, making wires into entities makes them consistent with all other entities.

    2. Only a single event for machines and wires. The entity_placed and entity_removed events pass in the entity in question. If we used tiles to represent the wires, we'd have to pass in either an integer (representing the autotile ID) and check whether it's an Entity or an integer, and not be able to identify what it is at a "glance" - especially if we later add other entities that are tiles instead of nodes. We'd need a separate "wire_placed" and "wire_removed" and keep track of what ID represents the wire autotile (which can change number as we modify the tileset and add/remove tiles.)

    3. Groups. We use groups to identify wires so they can be found by the PowerSystem whenever we add an entity. Tiles don't have access to groups, so if we want to check if a given entity (which, for tiles, is going to be an integer representing the autotile). This is an exacerbation of #2.

    So a bit of a TL;DR summary: consistency with other entities, and consistency in the code (everything that is an entity is an Entity, not an entity OR an integer), and we can use the same facilities for everything (groups.)

  • Razoric replied

    It also lets us connect the wire entity to the wire blueprint in the Library (which in part 1 is part of the EntityPlacer). When you're holding a wire blueprint, you are placing a wire entity instead of flipping an integer. So, again, fewer exceptions.

    Hope that all makes sense~

  • Nathan Lovato replied

    I'd add to this that while the code can seem a little complicated at a glance, and while we generally recommend using what's built-in, in a case like this, you can end up having to write un-intuitive code to rely on the tilemap vs writing your own that you understand well.

    In the TRPG series, we also coded a grid resource instead of using the TileMap, which implements grid features, because if you use the TileMap's methods, you end up having to work around subtle design choices that aren't adapted to your game. And coding the Grid class took me like 5 minutes.

  • p
    produno replied

    Yep awesome, thanks for the answers!