Problem With Tilemap Prefabs

0 favourites
  • 8 posts
From the Asset Store
This is a black tileset with 2 tilemaps, props, one animated character and more.
  • I'm creating an endless runner game with several different pre-made platforms using Tilemaps - my thinking was that being able to quickly edit each tilemap would be good for the prototyping process, as well as the eventual performance gains versus using large sprites. The Tilemap for each platform is currently a single 128x128 checkerboard image that i'm using to pain each platform, so each platform has its own instance of this image. Because I'm going to be randomly selecting these platforms, I'll be generating and destroying them at runtime without a need to have a first instance on the stage at the beginning of the game.

    What I'm struggling with is understanding how to work with the prefabs/Object types in my project and making changes to these. If I have an instance of a particular platform/tilemap on my stage and make changes to it, any further instance placed on to the stage will reflect the changes that I've made. This is totally fine and what I would expect to happen.

    However, if the final instance of the object is removed from the stage (but is still in the project), when I drag it from my project list onto the stage, it reverts to when it was first created. Except, sometimes it doesn't and it retains the changes as I would expect. Has anyone else come across this?

    Is there something about tilemaps or the Object Type/prefab workflow that I'm not understanding? Is there some way of committing changes back to the original prefab? If I was working with a Sprite, I would simply double-click on the original Object Type in the project and make changes that would be reflected in all subsequent versions of that object. But with Tilemaps, all I have access to is the original tile/sprite used to create that specific Tilemaps.

  • Tilemaps weren't really made to work as instances, and they definitely weren't made to work away from the base grid. Ideally it should be a single map, and worked on in chunks if you want to go that route.

  • Thanks for the input; I had a feeling that might be the case. Maybe I'm missing something, but is there a sprite/tile-based workflow in Construct that might be helpful for the kinds of platforms that I'm generating (i.e. in the gif)? I can see how placing individual tiles in a static level might work, but when I'm stitching together the world randomly from a bunch of different platform possibilities, I'm a bit lost - particularly because they can be different heights/lengths.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • It depends on how complicated you want to get. It can be as simple as taking the noise from the x axis from the Advanced Random plug or some formula:

    github.com/mxgmn/WaveFunctionCollapse

    Level design is hard. Making it easier is hard.

    If you're just experimenting, go nuts with the formulas, if you're wanting to make a game, make sure what you're doing is commercially viable.

  • Thanks - I understand that process. I'm specifically trying to make this work with hand-painted/illustrated tiles. Coming from Unity, it's a process that could be handled in an empty gameobject because you can make reference to translational values, so I'm trying to emulate something along those lines in Construct - just surprised that it seems more difficult in many respects.

  • I wouldn't use Tilemap, but sprites with their collision polygons. Laid like an endless rail. Chunks, not tiles.

  • I think the technical solution with sprites is straightforward (I have a working version with them) and I'd prefer to work with them. My main concern is that having sprites of 'complete' platforms will be an optimisation nightmare later on (i.e. some of these would be, like, 512x1024) though maybe I'm worrying too much given that these are destroyed as soon as they go off-screen.

  • Then it just comes down to speed. How fast the camera can move and how much swap memory you can have. Garbage collection can be an issue with this kind of situation.

    Its not great on HTML5, and likely never will be.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)