Arena definition

[donbonifacio]

The player's puppets will be placed on the arena. We need a simple way to represent arenas/maps/boards. They may all be alike, but we should be able to evolve. Having a string representation can be quite usefull.

String representation

#######################
#      1 2 3 4 5      #
#                     #
#                     #
#        E  E         #
#######################

We can split the structure with the looks. This represents where the player's five puppets start and two enemies that are known as E. We have something that prevents players from moving on to it (walls). We can also represent other elements via ascii, but we can leave the visual for another side information.

We should be able to load this string representation to clojure data structures and vice-versa. If we do this, we will be able to write pretty neat unit tests. Imagine: given the following board, if I perform a action A and B, then the resulting board should equal....".

We can build very simple arenas just for unit testing, and we can have a collection of the actual levels.

Arena API

This is tricky, I made several mistakes on OBB on this. This to consider:

• How to represent coordinates? [1 2]?
• How to represent the collection of elements? (an hash with coordinate as key? an array?)
• Should coordinates have a Z level? For example: floor(0), on top of floor(1), flying(2)

We need an API to:

• Get all the elements (to render)
• Get all the player/ai puppets
• Get the puppet at a given coordinate
• Place a puppet on a given coordinate
• Remove the puppet from a given coordinate (as in, it was destroyed)

This API will allow the game's logic to do anything.

[jqmtor]

I have a few comments/suggestions here. Let me just tell that the ASCII representation seems a great idea. There's a lot of value in separating the structure with the delivery mechanism and the testability of a simple representation is indeed very important. :+1:

Regarding my doubts:

• If we use just E for the enemies, won't we have problems identifying exactly what enemy is in a specific position? Don't we need a unique identifier just as we did for the players?
• Wouldn't be useful to treat the enemies just like another team, leaving the door open to PvP combat? Or even to allow players to control both sides. For example, it could be interesting if we provide the possibility to play a level with the goal of surviving 15 minutes, and afterwards with the goal of destroying the enemy in 15 minutes. I know we're not thinking about it and that this concern should not even be addressed now but, generically speaking, we could treat both sides as teams... Let me know what you think.
• The coordinates representations should be something more idiomatic in my opinion. While I like the simplicity of [1 2], I don't like the way we tangle ourselves to the coordinates ordering and array size. Wouldn't it better to make it a map with x, y and possibly z coordinates? I know the structure is a little more complicated, but I also think it is a lot more self-explanatory. Also, I think a map is more extensible. if you use a 2 coordinate system at the beginning, it is easier to start using 3 element maps and default the third coordinate to 0 than using the same strategy for arrays. We could certainly do the same for 2 position arrays but it would look more hackish. In a map we could also give the coordinate {:z 2} a default value for x and y and, in a array this wouldn't be so easy. Maybe I wrote too much but I hope you get my point.
• I implied this on the last bullet, but it would be great if we designed the system with 2 coordinates and made it easy to extend for the third, but I like the simplicity of starting with 2. Maybe we could assume the third and always provide the z coordinate as 0... I am not sure.
• Regarding the collection of elements, I would like to understand what are the operations we expect to do with it, to better decide the structure. Can you provide more details of what you're thinking? What are the use-cases?

[donbonifacio]

Arena representation

Really liked the AI as another squad ideia. We can just register several squads on an arena, and they are independent of whom controls them. We can have a map like this:

#######################
#      1 1 1 1 1      #
#                     #
#                     #
#      2 2 2 2 2      #
#######################

And as part of the level setup, we assign a human player to position 1, and a specific AI to position 2. This way, we can 3 or 4 squads on each level (like a last man standing), and of course PvP or my favorite, PvE (massive boss that can only be beaten by 2+ human squads).

Coordinates

My mistake on OBB was that all the system knew the coordinate's format. Could we make the implementation details private to the coordinate namespace? I believe so. Array or map is just a detail. What do we need?

• Create a coordinate given x, y and an optional y
• Use that coordinate to associate in the arena to some elements (puppets, walls, scenario, etc)
• Utilities like: distance between two coordinates, if two coordinates are adjacent, etc

Using a map is ok, it's more verbose, but it's more extendable.

Arena operations

Both arena and coordinate are just data-bags. The represent data and provide operations on that data. To setup a level we might have something like:

• Load a level (via string)
• Assign puppets/squads on the possible positions

With this, the engine/core will receive an arena, operate on it, and yield a new version. For example, if we are processing move action from A to B, the engine will verify if the move is possible, then it will remove the element from A, and add it to B, and return this new arena.

This is so powerful. This way we can have actions that do anything we would like. Want an action that destroys all enemies? Teletransports all puppets? Transforms all puppets into bunnies for X turns?

Operations:

• What element is at a given coordinate (validations, ai analysis)
• Remove/Add element to a coordinate (moving/destoying things)
• Get all elements from a given squad (for the AI, for each available element, process actions)

A basic representation:

[{:coord (coordinate 1 1}, :puppet (puppet ...) :squad 1, :effects []}
 {:coord (coordinate 1 2}, :puppet (puppet ...) :squad 2, :effects [{:froozen 2}]}
...]

We can also have an hash that maps coordinate to the element. That's pretty fast and we'll need that because we'll query the arena a lot. But having a complex object like an array/hash as key is troublesome when serialializing to json (and we might need that). We can also have this fast hash, and have specific serializers that optimize for that.

[jqmtor]

I feel we're getting somewhere here. :) I liked your suggestions and agree with almost all of them. The only suggestion I have regards the possible hash that maps coordinates to the elements.

I had an idea that might be worth exploring. Like you said, it would be great that this map had a simple key, and not a complex object. What if the representation of this map was not exactly coordinate -> element, but a transformation of coordinate -> element? What if instead of the actual coordinate {:x 1 :y 2 :z 3}, we used the integer 123 as the key of the map, where 1, 2 and 3 are the ordered values of the coordinates? If you think about it, each coordinate as a unique combination of values, making it a perfect candidate to be used as an ID. If we don't want to perform a few arithmetic operations on each arena lookup, we might even consider computing it up front and include it on the arena representation you provided above. In this case, a arena position would be represented as follows:

{:coord (coordinate 1 1), :id 11, :puppet (puppet ...) :squad 1, :effects []}

Mind that if we use a 3 coordinate system, the ID would be 110 instead.

What do you think?

[donbonifacio]

I think that the id would need to me more complex. For example, how to map 11, 1 and 1, 11. And yes, I believe that we'll have big coordinates. One disadvantage of the id is if we need to operate on the coordinate based on it. Give 123 we'd need to parse it to have the components to operate on them. And that is more CPU intensive than the direct coordinate (but also less mem consuming). Some time ago I also thought about that kind of IDs. I think they're great for human representation but lack on usefulness. Even so, that concept might come in handy in serializares.

Again, we can follow Sandi's advice and be independent of the key used. :)

[jqmtor]

Yeah, my suggestion is bad because I was only considering fixed sized coordinates and that will definitely not be the case. I must confess that I gave that suggestion as a first impression on the subject but what I've been really thinking about since then is a bitmapped version of the coordinate.

On your first post, you convinced me that it would be good to have a way to query a given coordinate very fast, and I still think it would be a good idea. I may have been confusing on my response but I don't think this representation should be used to replace the coordinate itself, nor should it be used for anything else other than this fast querying. So, I don't think we would need to perform any kind of transformation on this representation. I must also confess that I don't find the idea of having a complex data structure as the key of a map very appealing.

Anyway, I think it would be better to go with whatever you think is best, as I trust your judgement and think you have better information and more experience on the subject. If you still think it might be worth it, I will gladly ellaborate on my proposal.

[donbonifacio]

So, are we missing something in the Arena? (no counting the code :P)

[jqmtor]

My only doubt is if something is missing on the string representation, like obstacles or something. I think the representation you used is enough, right?

[donbonifacio]

I think we may need some more, but we can find some more ascii codes (for example, water/void flor).

[donbonifacio]

Because of elements (#9) I think that the z coordinate should be mandatory from the start.