Initial Sprite Location

[MonsterOfCookie]

Hey People

Hope everyone is well!

Question for the floor.

Previously in my platform games I have always used another tilemap layer as a way of placing sprites in game (e.g. enemies, player starting location) then pre-processed it on load of a level to place things.

My question is, is there a better of doing this? Have I done this completely the wrong way?

Cookie

[princec]

Works for me!

Cas

[MonsterOfCookie]

Awesome, thanks.

Always best to check before ploughing on!

Games published by our own members! Check 'em out!

[Cero]

use a script file

spawn enemy_x 400 500

something like that

[MonsterOfCookie]

Interesting idea, personally thought I would prefer the tile map approach as then you can easily see placement and have the pre-processing take care of the precise X&Y coordinates of the sprite.

Thanks for the input though

[Best Username Ever]

Probably not a great idea. I would use it if it saved me time, but there is an alternative that would save more time. Just read three ints (enemy type, x, y) from a file and loop until you reach the end. An extra tilemap layer could use up to twice as much disk space.

If you had to load things at run time and could not store every enemy in memory at the same time, then you would not want to use that method. However, since you're reading everything in once at the start, I would just use whatever saves the most space or saves programmer time on writing a preprocessor.

[MonsterOfCookie]

Hmm - You make a good point, never thought about that.

Perhaps the tilemap soln mixed with your idea. So there is a process at build stage that rips out the enemy tile layer and produces a type -> x,y file.

[princec]

We're already using a map layer anyway for this - we have an "item" layer, and one of our many items is "spawn droid g101". At map load we scan the map item layer for tiles and process them. So we not only create droids, we're also creating turrets, lights, doors, and terminals. It's a very handy mechanism because what's going to be spawned can be represented in the map editor as a tile and so you can see what it's all laid out like and edit it in exactly the same way as you edit any other tile.

Cas

[alesky]

I work with more tiled map layer

i use different tiled map based on different scope, this give you a flexibility to manage this stuff separate also in the code
instead to have a bundle of code that have to think of all, you ave different pieces for specific scope

1 tile for background
1 tile for solid items
1 tile for enemy
.....
.....
.....
1 tile for final grafica effect


and if you manage all this logic with the pattern chain and the pattern command together,
you can introduce every time more layer with little effort

 

[Best Username Ever]

We're already using a map layer anyway for this - we have an "item" layer, and one of our many items is "spawn droid g101". At map load we scan the map item layer for tiles and process them. So we not only create droids, we're also creating turrets, lights, doors, and terminals. It's a very handy mechanism because what's going to be spawned can be represented in the map editor as a tile and so you can see what it's all laid out like and edit it in exactly the same way as you edit any other tile.

Cas

That brings up a good point. It is a good idea to visually represent those objects as extra layers in a tile map editor, assuming you only have at most one object of each type per grid location or can support different sized grids if you need to. If you have a good tile map editor already, then it's less work to treat it as a tile in a tile editor. If much less than one third of your grid is filled with enemies or other objects, then I would still use a "list" of tiles and not a "2D array" of tiles for those layers in my file format, even if not in my map editor UI.