• Welcome to Final Fantasy Hacktics. Please login or sign up.

Camera-Locked Map Proof of Concept

Started by lirmont, September 27, 2013, 09:37:31 am



I hear what you're saying about the current goal, but I think you're underestimating the relationship between the original image and the 3d model. Unrelated to that, as far as Tethical cares, you don't even need a map, so long as its server application is fed a programmatic list of tiles. That list of tiles can be hand-crafted (which is a terrible approach that should be avoided) or it can be auto-generated (guessed) by the programming I wrote which averages top-facing geometry into rows, columns, and slopes.

The actual map, on the other hand, is visually important. If the 3d geometry were invisible and you just used programming to show the image, you'd also have to use programming to occlude characters as they go behind things. That's a very seriously undesired outcome considering its expense to both time and complexity, which will likely result in you splitting up the rendering process into at least 2 passes where you probably use that invisible geometry to occlude characters anyway.

The paradigm I've been working on this stuff under is: keep art as just art. A 3d map and the map's image belong inseparably together in that paradigm. When they are together, you benefit by doing as much work as possible outside of the engine. In this particular case, you also benefit by being able to make implicit use of 3d features, like the graphics context's depth buffer. When characters are physically behind some part of the map I made, here's the list of things that happen:

  • Characters will really be behind or in front of the map's physical geometry.

  • Characters will really be behind or in front of the image's color data (as it was projected into 3 dimensions via a camera in blender onto the geometry).

  • On the client, no additional instruction is needed other than: "Show the map. Place the characters."

So, anyway, with that in mind, when I talk about the skirt, I'm suggesting that the geometry you have for it is not physically tall enough to encompass the long skirt Mobius drew. Obviously, if you have no intention of doing anything else with it, these considerations are just considerations for the future.

Other Systems

The radial map selection system (from Arc the Lad) can be implemented as a client-side abstraction of the code Tethical already uses. Imagine a square-based targeting system. In that system, imagine any symmetrical pattern.  Draw a circle around that pattern where every out-facing edge of the squares fall along the circle. Client-side code can pick the closest square (bounded by the original list of options the server application sent). No big deal.

The meter-based movement/activity Valkyria Chronicles uses is basically just forcing the player to choose a path interactively with their gamepad rather than having the code pick a path. Yes, other things happen, but that's basically what's going on. The client would just need to wait until the player has chosen to end their turn (bounded by the meter length the server would have to provide in the form of a game mechanic) to send back the final location to the server.


I like much of your logic here. It has taken me a while to absorb it all. I'm a huge proponent of efficiency and you are definitely focusing on decreasing redundancies and consolidating data and processes. However, will you ever truly get a perfect native resolution display using your approach? What about processing power? Man power, cutting up the sprite into layers isn't that hard either?

Also what are your thoughts on the equilateral triangle vertex movement proposed by Matsuno? I think it is pretty ingenious right now. It seems much more natural than a grid, while still structured. I'm not sure it would work in a strictly isometric view however. I'm going to start some experiments.

This also brings up a new strategy for our current discussion around using 2D sprite maps. Instead of planes the character is restricted to, it could simply be vertices. Thing 3D points as destinations with paths of movement between each vertex. That would have to be much less process intensive. However, then the question of accounting for projectiles hitting obstacles would also be needed. There would still need to be some plains to account for obstacles and calculating trajectories. OR! You could have all this data pre-calculated for all the permutations between vertices and just grab it from an array.
Current Projects:


February 08, 2014, 02:55:38 pm #22 Last Edit: February 09, 2014, 10:06:56 am by lirmont
Projection-Based Area Selection Functions

This is basically what I think they're suggesting in that update.


Yes, you will get an exact native resolution display (of the original image) so long as your camera is set up with the exact same dimensions and scale (of the original image) at the moment you project that image through the camera in blender onto geometry (note: this requires you to actually have geometry that's form-fitting, like I've pointed out earlier). Projections are just equations. All you're doing is projecting an image through a camera onto geometry. It comes back exactly the same when it's projected backwards through that same matrix (re: you couldn't change the rotation of the camera and expect THAT to be pixel perfect or to even make visual sense). You can do this process as many times as you want in blender to see it for yourself. When you do it, you'll probably understand. There is no cutting involved in this process, so long as you have a vision correct geometric proxy (i.e. the mesh).

Now, about equilateral triangle-based movement, the vertices of a map would only work if you had the simplest of maps. For one thing, if there's any vertical delta, there goes the equilateral nature. Additionally, you're very unlikely to ever encounter the equilateral triangle enough in an actual model to depend on vertices to act as boundaries. That said, there's certainly nothing stopping you from using triangular geometry to represent a target function (rather than squares); the important point is really just that the center of that shape represents the union of the character's feet and the ground (if the feet were touching the ground). Using the same idea as in blender, a game engine could project the image of a triangle-based movement function onto a map (at a 2-dimensional point). You've no doubt seen this process done in other games you've played. Some texture shows up on the ground, following the geometry. Same thing.

As for projectile calculations, I think anything you add on top of just the map (i.e. some invisible geometry) is likely just going to confuse you. Make your stuff form-fitting, and you can just use that geometry. I haven't written the projectile equation into the engine yet, but it would be a damn shame if it were even more work at the map design level (considering it's something that can be calculated in real-time). Additionally, pre-calculating wouldn't give you access to the geometry (such as it is) of the character. For sprites, you don't want a projectile being a hit if it whiffs through the background of the sprite (it's container). Similarly, you don't want a projectile doing damage if it hits some 3d geometry representing a character's sheath (which is likely attached to them). And furthermore, what if you want to add or subtract geometry (like summonable defenses or destroyable walls)? You want that done in a context that has all the pieces, in my opinion.


Ack how did I miss that awesome youtube video update. Lirmont you work crazy fast, setting up those different systems probably took you less time to do than for me to make a map of equilateral triangles. I'm still just getting the basics of blender down.

Anyways, I did my little test image to see what the triangle system would look like in a 2D isometric view. Not great, but pretty decent. The concept of vertices as opposed to the center of squares is pretty interesting. I think I need to do some sketches to really help my brain absorb how this would alter level design in terms of spacing objects. However, the largest problem is the spriting of the characters. The attack angles along the connections between vertices are just at odd angles. Neither the normal isometric sprites or the direct angle sprites we are so accustomed to really work with the triangle arrangement. Perhaps there is some amount of rotation that would make it work better? Hmm opening photoshop.
Current Projects:


Yeah, sprites would need 6 directions (3 poses + 3 mirrored poses) as opposed to the 4 directions FFT uses if you want them to attack along those lines. I believe the SW-NE pose of an FFT sheet can remain untouched, but there's still 2 brand new poses to make after that. Obviously, using a 3d character instead would be an indie-achievable solution.

Another option is to just move the character into the appropriate range with a standard square-space walk routine, have it attack, and then move it back (maybe even spice up the animation of a regular attack so that it doesn't look like a game of punching robots). I mean, what kind of a lazy (or chivalrous?) warrior, A, stands directly in front, beside, or behind the target of their attack so that the enemy can almost certainly be in range for a follow-up attack and, B, doesn't bother to attack during anyone else's turn? That way: squares for movement and attack, and triangles for how much space you have to stay away from any given enemy to not just have them auto-attack you the moment you're not looking (like stealing a base in baseball). Adding to that, maybe even determine who moves out of harm's way after an attack, maybe based on some statistic (like Forcefulness) or the type of attack (Advancing versus Quick Striking). That way, you can use a hybrid system to keep all your old sprites. Or, you can develop new sprites and exclusively use a triangle system.


Unlike the pure Isometrics of FFT, mirrored sprites don't actually completely work with the triangle system. So it is actually a more angles that are also odd/inconsistent in relation to the camera.

I get what you are saying about combining the isometric movement with the triangle grid, but I'm just not sure it is worth it. Lets change this around a little bit. What are the benefits in terms of gameplay of these various systems?

PS: You completely lost me with the baseball metaphor stuff. Some clarification on your thoughts on making SRPG combat more dynamic would be interesting.
Current Projects:


Using a completely different system from FFT doesn't have any intrinsic value except how well it allows you to select something or how well it matches up with your graphical assets. Basically, if one system more appropriately lets you model (and therefore select) some action, then why not use that?

For example, let's consider a real-life fire. A real-life fire has a burn pattern. A fire spell in FFT, on the other hand, burns out in a uniform, area-of-effect, stepped fashion. Wouldn't it make more sense to model a selection function's display against what would really happen? I mean, a lot of games provide a choice of name, visual effect, and damage, but, really, are they that different when looked at as tools of war (in a battle that will not be decided by one single move)? You really ought to just pick one at any given opportunity from fire, ice, and lightning, then call it day (unless you really need some bonus damage, the enemy literally can nullify that particular type of damage, or you're an AI that can think at the microsecond level to pick the best-use option).

Providing a more interesting (or more correct) pattern would have the benefit of differentiating a spell's actual utility, for one benefit. For instance, imagine if a lightning spell had an area selection system that modeled the path of least resistance that real-life lightning is subject to. Maybe you could hit enemies around a corner, or maybe you'll have a 0% chance to hit anything because your target is near a tree (and the tree provides the least resistance). Are triangles that system on their own? No, but neither are squares.

As for the baseball analogy, a pitch is taken at the opportunity cost of a pick-off (a pick-off being a mechanic used to prevent a steal by threatening an out). Similarly, if you show up in front of someone on the battlefield, I admit you can stare them down. If another enemy shows up behind you, realistically, you defending against that new attack (like with a block that requires turning around) should be seen as an action taken at the opportunity cost of staring down the first enemy (who probably wants to kill you). Why wouldn't they strike at that point? Time is moving forward even by the game's standard.

Anyway, the dynamic I most want to see are more traditional approaches to combat. For instance, someone carrying a throwing spear (in addition to a primary weapon) might expend and visually demonstrate, in one cohesive action, running forward and hurling the spear into the enemy crowd (a way battles have been started in history). I also think a moving, melee-based, combination move that lets you target more than one enemy would be interesting. Maybe a first strike is very unlikely to land any damage, but maybe the point was just to get that unit physically out of the path for the actual strike on the enemy behind the first enemy. Instead of butchering everything in your way, I'd think a more tactical choice would be something that doesn't waste time on a non-objective goal (though, this assumes the game hasn't relegated you to a "Kill Everything" goal) in favor of something that makes more goal-oriented sense (like "Capture the Leader").


I disagree about different systems making little impact beyond graphical and user interface. I think it can make drastic differences in gameplay and game design, particularly in the logic that drives them. I'm struggling to organize all my thoughts around it without some graphical representation, I will do some mockups to continue the conversation.

I like the way you are thinking here with the fire and lightening examples. Gameplay diversity is key, with cost and benefits related to various choices that can also alter situationally. However, I do believe that various Grid Systems to have a significant impact on what can be done, how it is done, and the logic behind it. For example: What I'm currently intrigued about in regards to the Equilateral Triangle system is how the six connections to each vertex can relate to team attacks or synergy between multiple characters. Such as in this image:

Now this system can and has been done with a grid system (Joan of Arc), but it is more flexible and intuitive with the triangle system.

Regarding baseball and throwing spears. I like your ideas, but I'm struggling to fit them into a traditional SRPG format. Turn order is just so crucial with single character turns at a time and no real time combat. Valkyria Chronicles is close to what you are talking about, and Frozen Synapse is kind of closer but also much farther away. Both games and strategically very cool and different than FFT. I guess what you are looking for is more AI driven passive/reactive skills for your units.
Current Projects:


For the sake of this argument, let's imagine the active unit (who was not drawn with a left leg) in the image your referenced goes to attack "Enemy A". Using the target's rotation as the relative starting point, let's compare the normalized angle of attack. The angle is 0 degrees different from the angle of the line the attack is traveling. Conceptually, this is a frontal assault. That's nothing new.

Let's say, on the other hand, "Ally C" were to attack "Enemy A" when "Ally C" is the active unit. Comparatively speaking, the angle of the attack might be -60. Conceptually, this is still an attack that "Enemy A" would have in its field of vision (assuming "Enemy A" has a normal human range of peripheral vision), a front-arc attack.

It's tempting at this point to say this grid system is a direct upgrade from the standard square-based system. However, we should now consider "Ally B" (the purple archer) attacking "Enemy A". Comparatively speaking, the angle of a non-vertical attack is 90 degrees (geometry; parallelograms). Conceptually, this is a side assault. Also nothing new.

Now, let's transpose those same attacks into different systems. Here's what all 3 of those scenarios look like. First, the triangles. Second, quads taking the place of triangles. Third, quads adjusted to where they would normally be.

Figure 1 - Triangles

Figure 3 - Non-Aligned Quads

Figure 3 - Map-Aligned Quads

So, let's consider what the actual difference between the attack angles of figure 1 and figure 3 is. Attack #1: 0 degree difference. Attack #2: -45 - (-60) = 15 degree difference (15 / 360 = 0.04166 difference on the unit circle). Attack #3: 90 - 63.50 = 26.5 (26.5 / 360 = 0.07361 difference on the unit circle). So, if you literally need to have melee attacks at 60 degree delays, that and the limitation of 6 adjacent units is the sole mathematical benefit of that system (and you couldn't ever directly backstab a unit at 180 degrees). Squares allow 8 adjacent units at 45 degree delays (assuming you allowed characters to attack like that).

The point is that the grid system you use doesn't determine the geometry of the world (unless you make it do that). You can project any grid system onto any geometry. That's just how it goes. Because of that, I really think the benefits (beyond what I mentioned last time) are negligible unless you need some specific angular delays or limitation on adjacent characters. Now, limitations may be important due to the illusion of sprite geometry or the size of character meshes, but, outside of that, it's really just a visual thing. Other than that, relative angles (like 3d coordinates) don't suddenly take on some extra meaning because you represent them with some new arrangement of colorful geometry. It basically just comes down to angles of adjacency.