map

[7yl4r]

We need to load a map into the game. Eventually we want to be able to load in ground textures, building locations, enemy spawn points, etc.

LibGDX includes a generic maps API. This can be used alongside a map editor like Tiled, but we may want to roll our own solution instead.

[7yl4r]

I'd like to prioritize this enhancement in particular, because it will allow me to start working on more of the art. Do you have any further thoughts on this @BrianErikson? I can try to work on this a bit, but I might need some guidance.

[BrianErikson]

@7yl4r, a couple questions:

• Do we need a grid behavior?

We could load the background 'map' as an image and render the player and everything else over it. The only advantageous behavior we get with deriving from a Tiled or Tide map is the simplicity of map creation. It can get quite hairy with spaghetti code if you have more than a couple layers (for game events, or spawn points). Also Tiled allows you to place colliders manually over the tiles as a separate layer.

• Do the buildings intend to exist as orthographic tiles, or as separate game objects?

The reason why I ask this is that when you create a Tiled map, or any orthographic map, all of the objects are statically set -- so no animations (I think), and no movement. If we roll the buildings as seperate from the Tiled map, it basically renders the Tiled map useless and just a basic background, aside from scenery and things.

So, really, the usefulness we could potentially derive from a tile-based map, is ease of coordinate systems, event triggering, static collision placement, and map design.

The downsides are: static colliders, scenery, object placement, and non-precise colliders (rect only I think).

To roll our own from here if we don't wish to have a grid-based map and event triggering based on map layers, we will need to:

• generate a polygonal collider for various shapes (Some LibGDX classes help with this)
• find an easy/useful way to generate spawn points in the world
• create a trigger system for game events
• and define the interactions between the CA generation and the player

This is obviously a non-exhaustive list of potential pros and cons, but hopefully this helps stir some discussions. I'm going off the cusp here :)

[7yl4r]

grid behavior vs map image

I guess I was thinking grid because of the potentially huge size of the image, but on second thought, that won't be a problem like it is when doing a web-game, right?

buildings as orthographic tiles, or separate game objects?

I think we want game objects, because I really want some of them to be destructible (vyroid-spawing portals, for instance), animated, and they will be closely tied to the CA layer(s).

That pro/con list is really helpful, but it's hard for me to internalize all of it, since I have no experience with using a tile-map. I don't think we want to use the default handlers for the tile-map because of the unique considerations we have with procedural collision meshes and mutable buildings/scenery.

The way I am imagining the map:

1. a terrain-map layer which is primarily aesthetic
2. an object-spawn-location system, which places objects at preset co-ords on the map.
3. multiple grid divisions which overlay the map to allow CA to be spawned in them from the objects. For example: one grid may have 4px size squares, another may have 1px size squares.

That last one is what is throwing me off, since I think that means we will want buildings/objects to be grid-aligned, or else snap the CA-spawn-points to the nearest grid...

[BrianErikson]

I think you could treat the CA grid as an overlay to the game scene, although that may cause some tricky math when converting from map coordinates to grid coordinates for CA rendering (if they're operating at different resolutions). We will have to devise a projection conversion to convert between each layer

After laying all this out, though, I don't think Tiled is the way to go. Even if simply due to procedural components

[BrianErikson]

Completed

• Collision workflow with proof-of-concept
• Drawing objects in the scene

TODO

• A spawn-location system
• Render a background
• Flesh out CA interactions

[7yl4r]

Background rendering should be fairly straightforward and the CA interactions are still TBD, but what can we do on the spawn-location system? I'd love to be able to use a map builder of some kind, but I'm not sure what existing solutions are out there. Regardless, all this includes is a list of objects including location and a object id, right?

[BrianErikson]

It really would be nice to have some sort of map editor that simply displays the map and allows you to pick locations for a certain entity and output the locations and entity type to a JSON file. Maybe we can have a class that can be plugged into a scene to override the normal functionality and provide more of an editor feel. If we keep it simple, it really wouldn't be hard to implement

[BrianErikson]

Either this (really simple to implement), a drag and drop system from a list on the side of the sceen (harder), or a mix of the two; keep the list on the left side of the screen, select an entity, and then select a position (medium).

[7yl4r]

Your mockup is exactly what I had in mind, but I think we want to avoid getting caught up developing a map-maker. There has got to be something out there we could use.

If there really isn't, then I think I could use inkscape to make maps in svg and we could read in the layers & positions of objects from that. Even writing a script to convert that (or another layered image type) into json would probably be easier than making a custom UI for this.

[7yl4r]

here's a screenshot of the map svg I just pushed with arrows to help explain the layers. You should be able to open it using inkscape if you so desire.

More layer explanation:

1. notes: map-maker notes. ignore when loading into game.
2. chars: character placemarkers
3. buildingsAndScenery: non-mobile objects
4. bg_paths: an example of cosmetic over-map-texture effects we might add to the map. These will be ignored when loading into the game and will be included in the mapAreaTexture.png.
5. backgrounds: these are the base background textures the_edge.png in this case.
6. editor_tools: another map-maker only layer. Ignore when loading into game.

If you open up the raw file you'll see a lot of junk, but inkscape lets you manually add ids or other properties to help us pull out what we need. So the .svg can then be used like xml basically... but with this nice visual editor.

[7yl4r]

actually... looking at the way images were linked here, this probably won't work for you guys in inkscape

    <image
       width="300"
       height="304"
       xlink:href="file:///home/tylar/cell-rpg/android/assets/building-round-1.png"
       id="image8002"
       x="-6654.3447"
       y="67.237366"
       transform="matrix(-0.97553143,-0.21986002,-0.21986002,0.97553143,0,0)" />

maybe images need to be in a subdir of the .svg's dir to link relatively rather than absolutely.

[BrianErikson]

Finished map loader https://github.com/EmergentOrganization/cell-rpg/commit/e7cafceb3ebcbde68920727575f8c62842907eff

Refer to issue #20 for further work on this topic