Thoughts Around Making a Turn Based Strategy Game

Turn based games are completely possible in Project Spark, but there aren't any shortcuts to making them. This means you have to do the heavy lifting yourself. This is probably one of the more brain heavy game types, so some familiarity with brains would be a good idea before jumping in, and this complexity is reflected in this write up, as I don't go into specific koding details.
Disclaimer: I don't have access to spark right now, so writing everything off memory. Take tile names and any kode written with a grain of salt.
The first thing you have to figure out is the style for your turn based game. I think the traditional options are tile based or stamina based. Since PS has no built in support for tiles, you have to make your own, making the mechanics of a tile based game more difficult. That said, I'll spend more time discussing the tile based option since it is the more common game type.
==Some stuff to help with making a turn based game==
===Snap to grid===
Snap to grid is just a useful tool in general for setting up your environment, but it is exceptionally useful when making a tile based game since you will want to work with the built in grid system.
Toggle snap to grid mode by holding down on the dpad. If using mouse or touchscreen, click/touch the magnet icon on the right side of the screen.
===Having units act, only when you want them to===
One of the important parts about any turn based game is that your units sit around waiting for orders until you interact with them. This means you don't want them to have a brain that causes them to rush out and attack the nearest enemy when they see it. That said, you do want to them to be able to do so, either when you control them (if it is one of your units) or during the enemies turn (if it is an enemy unit).
There are a few different ways to achieve this, so I'll go over them all, though I definitely have a favorite.
===Enabling/disabling brains===
You can turn off an object's brains at any time by using the [disable] tile. The [disable] tile can either turn off the object using it, or if you specify an object
after it, you will disable the specified object.
This is a quick way of shutting down objects when you don't want them to have any intelligence. The units will still play hit reactions and can still be pushed however.
===Switching pages===
You can define different behaviors in the different pages of your object's brain and switch between them to change behavior. For example, you could have a page called Wait, with nothing in it, that just has the unit stand around doing nothing. Then, when you are ready to use that unit, you can switch its page to its "Attack Closest Enemy" page, which could potentially switch right back to the waiting page when it was done.
This method provides a bit more flexibility rather than just on/off. For example, you could switch a unit to its "guard" page, which could do something during the enemy's turn.
===Pushing and popping brains===
Another option is to push and pop brains from your units. Pushing a brain onto a unit means that, whatever brain was pushed is now his brain, until he is told to pop his brain. This allows you to set up a brain for different behaviors, and push them onto the units as needed. For example, you could set up a "Moving" brain, that all it does is moves to the location you specify, then pops itself. Meaning the unit will go back to its default "do nothing" behavior when it is done moving.
This one is my favorite method. It provides all the flexibility of switching pages, but also allows you to share useful brains between multiple units instead of having to duplicate your brains for each unit. I like having brains for things like attacking, moving, different types of enemy AIs and whatever else I want to use to make my game unique.
===Multibrains===
Mentioning this here as well, with a criminal lack of info. I haven't been able to try this yet, but it sounds like multibrains will be the best way to build a brain from multiple smaller brains. Will need to investigate some more.
==Stuff for tile based turn based strategy==
===Show grid===
There is a world setting called Show Grid that is really nice to use when setting up any game that makes use of square tiles. It just draws a grid on the ground that you can see when placing units or even when playing the game.
To enable Show grid go to World Settings and turn Show Grid on.
===Creating a grid of logic cubes===
This probably isn't strictly necessary, but I find it really useful to place a logic cube on each tile to keep track of things like whether a unit is on it, or what type
of terrain is there, etc... I'll discuss some ways to use it below.
You can manually place cubes, or you can generate them in a brain. To generate them, I usually do two [for each of] loops to handle rows and columns.
Something I like to do is have the cubes use their sensors to figure out who their neighbors are, what type of terrain they are and if they have a unit on them right when they are first created.
===The logic cube as a tile===
Having a logic cube to track a tile is useful, because it can store information for you. Useful things to track are neighboring tiles, whether a unit is on this tile, what terrain type it is, whether the active unit can move to the tile, etc... Something else I like to do with these objects cubes is place a square under them, that just comes over the surface of the ground, color it blue, then make it visible when I want to highlight the tile. I thought it worked really well. I could probably have made the square white and then colored it different colors to show different things.
===Can Move To Algorithm===
One of the more complex pieces of a turn based strategy game is probably calculating where a unit can move to. I think the easiest way to accomplish this is a modified form of Dijkstra's algorithm that, instead of finding the shortest path between two points, just expands fully until the "cost of movement" exceeds the current unit's speed/movement points.
This is a reasonably complex topic, but I'll try to simplify as much as possible. You start by taking the tile that your selected unit is standing on, and assigning it a "move cost" of 0 (meaning it costs 0 "movement points" to move to that square). Then you add the current tile to an object set of tiles to check the neighbors of. Then you get to the meat of the algorithm, which I will pseudo code below:
For each of the tiles whose neighbors you need to check
 if this tile's move cost is less than the total distance the unit can move
 For each of tile's neighbors
 cost of movement = current tile's movement cost + neighbor's terrain difficulty
 if neighbor has no move cost OR its move cost > cost of movement
 neighbors movement cost = cost of movement
 add neighbor to list of tiles whose neighbors you need to check
I'll try to explain at a high level what this is doing. Basically, starting with the tile you are standing on, you tell each tile the "cheapest cost" to get to it. If the square already had a cheaper cost to move to it, then you leave it alone, but if you have a cheaper route to that tile, you update the movement cost of the tile. Every time you update the movement cost of a tile, you then add its neighbors to the list of tiles whose neighbors you need to check. However, once the movement cost of a tile is the maximum that your unit can move, then you don't have to continue checking neighbors.
===Moving to specific locations===
Once you confirm that a unit can move to a location, you can move them to said location by using the [move] tile and specifying the location to move towards, but there is a catch. When you do this, it doesn't necessarily move all the way to the point you specify. Also, you need to actually know when you arrive at your destination, because PS doesn't tell you.
To fix the first part, give the [Minimum Distance] modifier to your [move] tile and specify a min distance of 0.
To fix the second part, you can track your distance to the location you are heading and when you get close enough, teleport to the final position and end your move.
Now, the thing about this type of moving is that it just walks in one straight line, and doesn't necessarily reflect the route you wanted your unit to take. You can fix this, but it is a little bit more work. You'd need to track the path you want to take while keeping the order of each step recorded somehow (perhaps as a custom linked list since no ordered lists are built in right now). Then you'd need to move one square along the path at a time.
If there is interest I can discuss making a custom linked list in spark.
==Tip for turn based games without a grid (like Valkyria Chronicles)==
===Limiting a single unit's turn===
Usually when you don't have a grid, what you instead do is give each unit a stamina bar, a maximum distance or a time limit.
The time limit is probably the easiest, as you'd use a countdown timer that would basically end the turn when it runs out, or at least stop the unit from moving.
The stamina bar is probably the next easiest. What you do is, when your unit is moving, you steadily decrease their stamina. You'd probably want to set it so that the rate of decrease of stamina is tied to how fast the unit is moving.
To give units a max distance, you can clamp their movement to be within a certain radius. For example, you could have kode that said, when the distance between a unit and its starting point is greater than some value (say their speed) then pull them back so they are just on the edge of that range.
Some things I didn't go into, but could if there is interest:
1) Dealing with verticality
2) Using hexagons instead of square tiles
3) Koding details
That's what I have come up with so far. Was this useful? Incomprehensible? Let me know!