Final Fantasy Hacktics

General => Archives => Tethical => Topic started by: lirmont on September 27, 2013, 09:37:31 am

Title: Camera-Locked Map Proof of Concept
Post by: lirmont on September 27, 2013, 09:37:31 am
A short foreword, this is a map created by Mobius for one of his projects. The texture for this map is special because it only exists properly in one view (re: the camera's view).

Front View (3d render at a different size than the source image)

(http://darkabstraction.com/showOff/ffhackticks/msr-map-001.png)

Other views: left (http://darkabstraction.com/showOff/ffhackticks/msr-map-002.png), back (http://darkabstraction.com/showOff/ffhackticks/msr-map-003.png), right (http://darkabstraction.com/showOff/ffhackticks/msr-map-004.png).


Geometry
(http://darkabstraction.com/showOff/ffhackticks/msr-map-005.png)


UV Map (Texture Coordination)
(http://darkabstraction.com/showOff/ffhackticks/msr-map-006.png)


--

Anyway, long story short, if your map texture is isometric, it's a trivial process to make a 3d model to act as a proxy over your drawing. This becomes the map, and that map is usable just like any other map (except you should lock the camera's view by ignoring the key presses for rotate map and changing eye level).

This took me about 3 hours to finish, and this was the first time I'd ever tried to do something like this. The core concept is unwrapping the map (automatically) by projecting coordinates from the camera's view. Set up your camera, use the texture as a background image, make the map proxy over it. Unwrap the map. Add a material that uses the texture on the UV map. You're done.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 21, 2014, 03:58:53 pm
Wow this is incredible, how did I never see this thread before.

Where can I find more information on your map designing tools?
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on January 21, 2014, 04:21:13 pm
99% of the work is done in a combination of Blender and the graphics editing program of your choice. You can find Blender here: http://www.blender.org/

It doesn't matter if you use blender specifically, but that's the only 3d modeling program I can help out with if you get stuck.

If you don't want to do the boring, repetitive legwork after the fact to get the map internet-ready, you should follow the actual dimensions of an FFT map (how they export from map2gl) or this tutorial: http://ffhacktics.com/smf/index.php?topic=7153.0

That ensures my control panel application can read all the geometry and figure out the movement squares and slopes.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 21, 2014, 10:04:49 pm
Interesting, I will have to look into blender. However, let me explain my situation and perhaps you will have some ideas on solutions or resources because I haven't had much luck.

So Mobius and I have continued to work on our "2D" SRPG indie game concept. I was starting to tinker with some isometric map designs in photoshop. How I do this is make isometric blocks and other standard shapes and then put them together like legos. See the attached image. The idea is that these simple mockups are easy to edit and test as 2D plains, and then when we have a design we like Mobius can just do the full pixeling over it. This works fine but it is a little slow and we loss out on all the potential of having it being actually 3D as we will need that three-dimensional data later on. So I started searching for isometric graphics tools and found this:


Pretty sweet, but it appears to be a dead project. Any thoughts? What I really want is a tool that will allow me to make simple isometric mockups by placing a variety of isometric blocks/shapes in a 3D space. For my purposes, I mostly need to export a nice clean image and also keep all the 3D data to correctly place characters on the map later (along with attack trajectories and other factors). This could also be used for more traditional FFT 3D maps as you would simply keep all the 3D data and then apply textures to the blocks. Though there are additional factors for functional 3D maps as you well know. Also, the blocks should be able to intelligently resize the size of the blocks/objects; so that it would be more flexible for various users and games. Just saying, it would be a great easy to show off tool for our SRPG toolkit.

Alternatively I might need to look into using blender to do isometric work. See this link:
http://flarerpg.org/tutorials/isometric_tiles/
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on January 22, 2014, 05:53:06 am
Any tool that spits out an image (and I'm sure there are tons just like the one you posted a video of) is a good candidate for blender. I didn't do anything special with Mobius' image for the map in the proof of concept. Blender lets you set up a 3d camera that matches the dimensions of the image (width, height), camera type (orthogonal; re: 2d), and angle (-45 degrees around Z, 60 degrees around X; re: isometric). From there, it's just a matter of loading the image into blender and creating the geometry over it. There are many vision-correct answers for each vertex, but you'll only ever be changing 2 axes at a time (i.e. you're either operating on X-Y, Y-Z, or X-Z, but never X-Y-Z). The final step is a repetitive process of projecting the image onto the model from the camera (blender does this for you).

I imagine most level editors out there that do similar processes use images and draw order instead of textured geometry, but there probably is at least one that does use geometry. The fancy skirt Mobius draws around his maps is likely not going to be supported wherever you go. Similarly, the anomaly features (like the rocks and jutting thing on the left) are also unlikely to be supported (they'd point straight up in the 3d space). Isometric design just isn't the tool for those things. It wasn't too much of a big deal correcting for the rocks on the right, but the jutting thing on the left is almost certainly too complex to even suggest its actual dimensions.

Long story short, blender is the best tool for map design; making a tool to replace it is folly. People may not think it's simple enough, but even it could do exactly what you want (coming up with interesting base meshes) as part of its normal operation. The added benefit of that is that you don't have to guess at what the shape of the map is like I did for this proof of concept. Just set your camera up like I've described, and, when you render the thing out, you'll have an image in that isometric space. To get the pixel-perfect nature (i.e. jagged edges), just make sure no sampling is taking place in the render properties.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 22, 2014, 01:35:23 pm
Well Lirmont as usual you are correct. Blender is certainly not simple, but it is definitely powerful. I have been messing around with it for a few hours for the first time and I can see that it will more than likely do what I want. Getting the exact rending resolution might take some tinkering, but not all that bad. Now that I understanding the camera a bit, the next step is learning how to actually manipulate and arrange objects. I have attached what I have so far. A few more hours and I will likely have reproduced what I already had in photoshop, but now as a 3D model. The only nagging thing is that it will likely never be absolutely pixel perfect, but I think it will be so minor that it might even be better that way.

Making a whole bunch of standard ISO blocks will take a bit, but likely much less time than doing it as pixel art. The best advantage of this will be getting the lighting and shadows really accurate.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on January 22, 2014, 02:09:38 pm
Shift+D will duplicate an object in object mode (or selected geometry in edit mode), and Alt+D will duplicate a linked copy of the object. In other words, you can make your toolset of pieces, put them on a layer (M key) that doesn't get rendered, and duplicate linked copies of those things (so any future changes you make to the mesh apply throughout). To unlink a linked object (maybe you want to make a broken staircase element from a regular one), you can press U and then choose to unlink the "Object & Data". For translation (movement), you can use the G key, and then a coordinate (like X, Y, Z), followed by numbers or mouse movement.

As to the pixel perfect nature of the render, you have total control over the image size of the render, the orthographic scale of the camera, and the camera's rotation. That's probably enough to meet the needs of the formula found here: http://en.wikipedia.org/wiki/Isometric_projection

For instance, the proof of concept image (as made by Mobius) is 660x440. I set the render resolution to 660x440. Then, the camera's orthographic scale that I used was 6.515 with the camera being physically rotated by (60, 0, -45). According to the wikipedia article, that X rotation should maybe have been 54.736 (which is 90 - 35.264). Anyway, something to go on.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 23, 2014, 12:08:39 pm
Well I'm slowly getting closer. I have my basic board, but still need to be making more shapes. This is definitely a slower start, but will ultimately be much faster. Figuring out where to put the light should be interesting. I might remake a couple of my favorite FFT maps like this just to see what it looks like.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on January 23, 2014, 12:23:54 pm
Assuming you want the block-like shapes from the earlier image, you should be aware of several commands.

For stairs, CTRL+R (in edit mode) and mouse wheel (or tool info panel shown with T in a viewport) to cut your block into subsections. Do that twice, then you can just delete the edges you don't want (with X). Then, you can select 2 exposed edges on either side and make a face out of them (with F). You'll eventually recreate those stairs.

For the column, E (with the top face of a cube selected in edit mode) to extrude, except here you should just hit escape. Then, you can scale the new geometry down with S and mouse movement. Follow that up with another extrude (E), but lock it to the up vector by pressing Z after. Then you have a column. You can apply a texture (color) to specific geometry or you can separate out the column part by selecting only that geometry, then pressing P.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 23, 2014, 06:15:31 pm
Well the accuracy of this program is starting to impress me. In the last preview you can see a few stray black pixels, turns out I had misplaced a duplicated block. Now that I know how to constrain to a grid, things are going a lot faster. I now have exactly what I had made before but now in 3D and more building blocks.

Lirmont do you happen to have a list of all the different block types commonly used in FFT? I think I'm going to start by reproducing Magic City Gariland. Thanks for all the tips, it is making things go much faster, plus lots of youtube tutorials.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on January 23, 2014, 06:25:40 pm
Looking good. You want the models (.blend) in this folder: https://github.com/Kivutar/tethical/tree/master/client/fft/models/slopes
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 23, 2014, 07:50:04 pm
There were a limited amount of slope models, however the maps will be very useful. Is there a tool I can use to export the FFT maps into blender? I see that the texture file is in there, but is there a way to quickly apply it in blender?
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on January 23, 2014, 08:35:00 pm
As long as you use the same relative directory names, it would show up. You can change it in blender by selecting the map, then selecting the Texture tab of the properties panel, then picking the image texture, and then opening the image file you want to use. Not all display modes are designed to show the texture on the model in the viewport, though. You might have to render the scene out to test.

As for other models, you can export any of them to OBJ format and import them into blender with map2gl. Elric wrote a tutorial here for what you have to install: http://ffhacktics.com/smf/index.php?topic=10013.0

However, it's windows-oriented. You'd need to look up how to install the individual python 2.x packages for your OS. Then it's just a matter of running the python application, loading a map, and picking the menu option to export it. It outputs one OBJ file and one image file per map.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 23, 2014, 11:45:15 pm
Wow lighting lighting makes a huge difference, this looks so much better with Ambient Occlusion, and I haven't even messed with cycles yet. I have all the building pieces now as well. I could probably mess around and get the map to export, but it will be better practice to do it manually. Hopefully I will have a chunk of it done tomorrow to show off.

Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on January 24, 2014, 06:58:25 pm
I'm essentially done with modeling here, just forgot the grass bluffs. It came together pretty quickly considering I am still very much learning the program. This is all quite exciting and I am amazing how good just simple isometric blocks can look without any real color or texture. Thanks for the great advice Lirmont, this will definitely really help Mobius and myself out. This process definitely brought up the question of scale for the maps in our project. I forgot just how out of proportion FFT maps are. I wonder what barriers we will run into designing more naturally proportioned maps.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on January 24, 2014, 07:27:53 pm
It looks good indeed. Blender is ~20 years in the making, so it ought to be amazing. :P
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on February 04, 2014, 01:13:14 am
My own attempt at recreating Mobius' Plains level with simplified geometry. It is still a bit rough and there is one area where I think I need to stray from the original map a bit to make work.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on February 04, 2014, 01:41:11 am
Looks pretty good. The rock and skirt features won't turn out vision-correct like you have them, though. There are three cases. Case 1: the image for the texture is transparent there, and projecting the image onto the map through the viewport will result in a visual hole (though the geometry will still exist). Case 2: the image for the texture will be of something that isn't the rock, and projecting the image onto the map through the viewport will result in any geometry (re: players) behind the rock standing visually behind the not-supposed-to-be-a-rock part of the image (that got mapped onto the rock geometry). Case 3: your skirt geometry will miss out on the edge of the skirt as defined in the original image. Long story short, you need to adjust the geometry of the rocks and skirt so that it lines up with the image. Blender makes this easy for you. You can map an image right into the camera and draw around it. However, for that to work as is necessary for this particular process, you'll need to adjust the render settings to match the dimensions of Mobius' original image.

Also, since you're near the point of turning all the geometry into a single cohesive mesh (i.e. one single object rather than duplicated pieces), you should be aware of the following features in blender for after that step: (1) in edit mode, unwrapping the model from a viewport projection with U -> Project from View (Bounds), (2) loading Mobius' original image in the UV/Image Editor for comparison, (3) attaching that image to the texture of the material of the object as an image with the coordinate setting of "UV" and the UV map that was created by step 1, (4) setting that texture to affect at least Diffuse Color and Diffuse Alpha, and (5) in the material of the map object, turning Z Transparency on with a base Alpha value of 0.000 (0 + image alpha is the resulting equation that happens behind the scenes). Step 1 is the only step you'll just be repeating over and over again until you get it exactly right. It may require you to change your camera settings (re: the orthogonal scale), so maybe make a duplicate of the original camera and store it to another layer as a backup. View -> Cameras -> Set Active Object as Camera is how you'd switch between the two (after selecting the one you want).
Title: Re: Camera-Locked Map Proof of Concept
Post by: Mobius on February 04, 2014, 10:14:23 am
Im just going to jump on board here to say that I'm getting a new machine soon, but for the time being also I'll be on Skype for chats and updates. (Cheetah) Morocco was hectic but now everything is back to normal in Spain once again.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on February 05, 2014, 01:16:04 pm
Excellent info Lirmont. I fixed the odd geometry a bit in the middle right and fixed the graphical glitches on the skirt. The issue was simply that there were to faces in the same spot of different material, I knew what the problem was I just had to spend some time learning an efficient method of getting rid of it. Lirmont, was your first paragraph addressing the skirt graphical glitches or something else. You have mentioned the skirt being difficult a few times and I'm still not quite tracking.

Overall I believe I have a very different, and less impressive, goal for this 3D model than your original. Instead of applying the original pixel art as a texture to a mesh, I simply want to create a geometry to guide character movement and projectile collisions. My current plan is to have the basic pixel art map, with appropriate layering for objects such as the rocks, as the only visual for the map. The geometry will then be matched to the pixel art, but invisible, to guide character movement so they move around the plain as if it where a 3D object. Does that make sense?

My next question then relates to tile based movement. Right now I'm envisioning a similar movement system as FFT or tethical where everything is tile based. How are you handling this in tethical and how should I be designing maps in mind to take advantage of this.

The alternatives would be a radial system (Arc the Lad: Twilight of the Spirits) or a meter based system (Valkyria Chronicles). These would be cool and would make more sense with a focus on long distance projectile weapons, guns, but it sounds difficult to merge with 2D pixel art. Thoughts?
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on February 05, 2014, 02:24:25 pm
Maps

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:

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.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on February 08, 2014, 02:10:44 pm
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.
https://www.kickstarter.com/projects/482445197/unsung-story-tale-of-the-guardians/posts/740862?ref=dash (https://www.kickstarter.com/projects/482445197/unsung-story-tale-of-the-guardians/posts/740862?ref=dash)

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.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on February 08, 2014, 02:55:38 pm
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.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on February 12, 2014, 01:00:06 am
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.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on February 12, 2014, 01:33:34 am
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.
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on February 12, 2014, 02:52:02 am
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.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on February 12, 2014, 03:32:21 am
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").
Title: Re: Camera-Locked Map Proof of Concept
Post by: Cheetah on February 12, 2014, 11:03:45 pm
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:

(https://s3.amazonaws.com/ksr/assets/001/607/239/69526271a0a4853a25015e044976389d_large.jpg?1391743095)

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.
Title: Re: Camera-Locked Map Proof of Concept
Post by: lirmont on February 13, 2014, 01:50:25 am
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
(http://darkabstraction.com/showOff/ffhackticks/tri-vs-square.png)

Figure 3 - Non-Aligned Quads
(http://darkabstraction.com/showOff/ffhackticks/tri-vs-square-1.png)

Figure 3 - Map-Aligned Quads
(http://darkabstraction.com/showOff/ffhackticks/tri-vs-square-2.png)

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.