Following my... learning experience from the game jam, I decided to jump right into the passion project I've had on a shelf for I don't know how many years.

The concept is a Mega Man Battle Network styled game, made for mobile. Ultimately, I think this will translate beautifully, and I hope to be able to launch it and actually have a decent success.
However long that might take.

That being the dream, we start off with humble beginnings.

I wanted to get something as an at least semi-decent foundation, to build off of.  I've already concluded that from a technical perspective, the game actually lends itself to a lot of "cheats" in terms of the engine. Everything can be based on coordinate position, and there's literally no advantage to having any kind of physics calculation, if the game is strictly mirroring the MMBN series. Which, right off the bat, tells me that there's no need to physics bodies, or colliders. And being that I want to turn this into an online multiplayer game for mobile, I'm hoping that means less data to transmit and ultimately fewer lag issues. But I'm way ahead of myself.

In order to make other functions down the road more natural to implement, I decided to instantiate nearly everything dynamically. Now this may change in the future, if I run into too many problems, but I expect to find more advantages than disadvantages. Namely on changing properties like the different affects on tiles, or even which tile is which side. I've done all of that in the creation, straight down to the colors getting darker toward the back.

I also nested the generative loops in a way so that the indexes in the 2d  array match up properly with x and y coordinates. So grid position (2,1) would actually be written: 
combatGrid[2][1]

I'm also handling movement in what might be a weird way. It's almost entirely controlled by the arena itself, and "entities" (as I'm calling them) are moved around by a function on the parent object. My thinking on this, is that it makes coordinate tracking a little more consistent and intuitive. Especially as I've used a naming convention on the titles, so that I can use string.split on the names to get coordinate values quickly.

When the entity is added as a child to the "tenant" node, it automatically changes position. I'm not sure how I might animate this later, but for the time being it works as intended and will allow me to apply the same movement logic to anything that might be on the stage (player, enemies, or obstacles).

Finally, because I am thinking about this as a mobile game, there was the question of user input for movement. What I've decided on is that only adjacent tiles can be moved to, one at a time, so if the player clicks (or taps), it will figure out which direction is furthest from the current position and move one block that direction. The math might be a little funky if you're a math person, and I favored the x-axis for priority over the y; which after thinking about it, most dodging happens in the y axis so I will absolutely be changing that. This is what it looks like:

So altogether, this is what it looks like so far: