Proposal: Subpackage to handle level-loading through .tmx files.

[lolbinarycat]

Oak does a good job of handling most common things that games would need to do, but level loading, something that nearly all games have to do, seems lacking. I nearly developed my own format and editor, but fortunately I stumbled across the tiled map editor.

One problem is that there doesn't seem to be a definitive choice for a .tmx library, but I've been using this one.

The main benefit I believe would be better integration between oak's fileutil system and tileset graphics, which is currenly a bit of a hassle to implement.

I would also be willing to help implement this, but I don't know how helpful I could actually be.

here's my current function for loading tmx files.

func LoadTmx(mapPath string) error {
	levelMap, err := tiled.LoadFromFile(mapPath)
	if err != nil {
		return err
	}
	fmt.Println(levelMap)


	fmt.Println(levelMap.TileHeight,levelMap.TileWidth)
	// for each _Loop, the contents of the loop are ran once for every _
	LayerLoop: for _, layer := range levelMap.Layers {
		/* RowLoop: */ for i := 0; i < levelMap.Height; i++ {
			BlockLoop: for j := 0; j < levelMap.Width; j++ {
				tileIndex := j+(i*levelMap.Width)
				if tileIndex >= len(layer.Tiles) {
					continue LayerLoop
				}
				tile := layer.Tiles[tileIndex]
				if tile.Nil == true {
					continue BlockLoop
				} else {
					sprite, err := render.LoadSprite("assets/images","wall.png") //sprite is hardcoded, this is because of aforementioned difficulty with loading sprites from tilemaps
					if err != nil {
						return err
					}
					e := entities.NewSolid(
						float64(j*levelMap.TileWidth+layer.OffsetX),
						float64(i*levelMap.TileHeight+layer.OffsetY),
						float64(levelMap.TileWidth),
						float64(levelMap.TileHeight),
						sprite,
						nil, event.CID(100+tileIndex))
					e.Init()
					e.UpdateLabel(labels.Ground)
					_, err = render.Draw(e.R,1)
					if err != nil {
						panic(err)
					}
				}
			}
		}
	}
	return nil
}

[200sc]

It wouldn't be terrible to implement-- we have a game we're doing that we could try integrating with tiled and see what roadbumps we run into, splitting that functionality out into another package.

We'll probably talk about it internally in a couple of days.

[Implausiblyfun]

I think that it is true that this is a pretty common use case that can be covered much better by oak.
When implementing this there should be a consideration for how standard tile and map loads should be handled/supported and what subset of ingest strategies make sense.

Namely I would argue that if in an x package there is a tmx importer then perhaps there is also an importer for the json variant of tmx as well.
There is probably a very strong argument to minimally support the basic tile and map import if we can just figure out where in the repo it makes sense to implement :)

[lolbinarycat]

One thing I feel is that we should also support "objects", at least rectangular ones. This would add much more flexibility to the system because it would mean that even if you didn't want tile based levels, you could still use the system.

[Implausiblyfun]

First pass we are thinking of has the following:

• package in oak that deals with ingest of 2d tiled maps
• potential separate repository for tmx to oak conversion

Second pass may try update tmx repo to handle objects but that will be out of scope for first pass.

[200sc]

Closing this issue, refer to oakmound/grove#3