Final Fantasy Hacktics

Thanks for the kind words guys.

Content in the game, such as characters, stage layout, animations, events and skills are defined by various XML files with a special schema defined for each XML file type.

Sprite support for characters is still very fluid and is a work in progress. As it stands, you need a PNG sprite sheet and some familiarity with XML files. 2D characters are drawn using a method called billboarding, which I believe is what you described. There's a lot of tweaking left to do with this system before I can say what will and won't be possible.

For the engine as a whole, square movement tiles are all that I plan on supporting. Overworld support will also be limited to a map with predefined paths and locations as opposed to free range movement like earlier Final Fantasy games.

3D animated character models are currently supported. If you're looking for some AAA quality end result, I don't think I'm skilled enough to reach that.

As for my normal updating, I hope to have another up to date demo out before the weekend is through. Mostly just bug fixes.

Thanks. I hope to keep on trucking.

Update
I've recently been more consistent on coding for this. Most of the work is related to fixing some bugs with animation code. For now, animation will remain simple, with things like "Do y on frame x of animation" not being supported until later. Only major issues left for animation are when two animations are assigned to a unit at the same time and applying actions to all members affected by an attack instead of the first target in the list.

Current Focuses

• 2D Support - MON support mostly implemented. Need to test with a few other sprite sets.


• Overworld Module - Locations - Currently designing the structure for this


• Overworld Module - Party System - Nothing yet


• Battle Preparation Module - Nada.


• Battle Module - Bugs - Don't know of any that aren't animation bugs.

The "I'm not dead yet" Update
Been very busy as of late and haven't had a shred of time to work on the engine. I have had time to do some brain storming and come up with ideas for the skills/cinematic system, but those ideas won't be implemented anytime soon. This update isn't completely void of value though. I've spent my night modifying the source code for ShiShi (thanks melonhead and Glain) to dump frame data.

2D Sprite Support
I think I've dumped what data I needed from ShiShi. I'll need to organize things and group the frames up for the various animations. This shouldn't be too time consuming as only core animations (dead, walk, attack, cast) will be supported for now.

Current Focuses

• 2D Support - Create all necessary sprite animation set files for TYPE1, TYPE2 and MON files


• Overworld Module - Tie stages to locations and allow random encounters.


• Overworld Module - Create basic party system


• Battle Preparation Module - This'll be a new module and allow the placement of units.


• Battle Module - Continue bug hunting

Some sprite progress

Quote from: Cheetah on January 05, 2016, 07:24:19 am
Any chance of an OS X build for me to test?

Might give the below a shot. A rebuild for OSX may not be necessary.
http://www.mono-project.com/docs/about-mono/supported-platforms/osx/

I'm currently unable to reproduce the slowdown, but I'll see what I can figure out. It's on the throne room map with the AI test, correct? 5 blue slimes vs 5 orange?

The game actually uses my own engine, which in turn uses OpenTK to interface with OpenGL. XNA was pretty awesome, but it is indeed dead. It has been replaced with Monogame and some other frameworks with cloned APIs.

I think C# is a fine language to use for just about anything. The major flaw that I can't really argue against is that the garbage collection can cause inconsistencies in performance. C# can stockpile objects that need to be disposed of and then decide to do it all at once, creating temporary lag. There are ways around it such as reusing objects and things like that.

I personally haven't ran into any real performance issues with C#. It's been fast enough for the pathfinding, AI, interfacing with OpenGL and just about everything else I've thrown at it.

Demo
First, apologies for quadruple post. Second, a demo is now available on Itch.io
here
I expect a lot of issues to be uncovered, so please be sure to report them. There's a discussion board on the page or you can PM me whatever problems you encounter. I expect quite a few people to be entirely unable to run it, but with enough information, I'm sure I can fix it.

Thanks to all of you for your interest thus far and have a merry Christmas.

Thanks,
HDGD

Minor update today. Fixed the outline shader and restructured some minor things for it. I'd wanted to just change the shader program and reuse the same code for rendering an object, but that wouldn't have been as pretty as I wanted. So stage objects such as characters, props, etc now have a "Render" and "RenderOutline" method.



Worked on the mantis animations briefly and added a rather lazy idle animation. As you can see it has some clipping issues. I'll throw together the rest of the critical animations when I have time.

I don't have a demo ready, but I have an older game I made using the same build of the engine. Would anyone be willing to test it?

It's just a simple pacman clone as seen here.

https://mega.nz/#!gFB0EaZT!tVD1R0r80TWxexUl93EwH61t1UUvMc4JoeslnZbHeAA
Does it run?
Does sound work?
What does the FPS counter say?
What does the MSPF counter say?

If any errors are encountered, take a screenshot if possible and PM me a brief description of the error.

Requires .Net Framework 4.5 or Mono for Linux/Mac. I've only tested a little bit on linux. My linux laptop died recently so I'm not expecting it to work well.

Overworld Module
Nada.

Battle Module
More of an overall engine improvement, but I've started moving a majority of rendering to shaders, with an example being 3D animation. Originally I'd taken the lazy route and let the CPU handle the tweening between keyframes and streaming to the video card. This worked okay with a handful of units, but began to experience intermittent performance hits with anything above 7 units. I decided to let the GPU do its job after discovering that...

Now I can apparently handle this many. I don't know what the upper limit is, I got bored and stopped adding units before reaching it. The outline shader is temporarily broken, but that's a pretty easy fix that I didn't have time to get to tonight.

Current Focuses

• Documentation - Made some headway on this. I have something to use as a quick reference for Events and the actions related to said events now. Still needs a lot more detail.


• Art Assets - Did some experimentation and managed to recreate the "Sanguine Blade/Night Sword" attack that Gafgarion uses within the game. I need to add some additional support for actions, such as dimming the stage and units. Not much done for 3D models. Will finish working on some of the slime stuff and maybe add an idle animation to the mantis. Human template could also use some love.


• Demo - I've got some life stuff that's going to delay this, nothing bad by any means, but time consuming. I'll see what I can do and aim for sometime in December.

Stage Design
I agree with both of you on most everything.

The more vertical stages were very fun to play, such as the church level with Delita where that religious jerk is up on top of the building. It did seem to be utilized a lot though with your party needing to fight uphill. I'd like to see about doing the opposite and giving the player the higher ground while giving the AI near overwhelming material to work with. Such a dynamic is kind of broken by what Kaijyuu mentioned with the lacking LOS spells. I think that's also part of why archers sucked in comparison to mages in FFT. When I get to the point where stage geometry is more defined to where I can check for LOS, it's something I'd like to look at.

The character to building proportions are off, but I understand why they did it and it's probably something I'll also use since it minimizes the scale that a stage has to be if it features part of a city.

I think having maps with multiple floors could also be interesting. I don't recall FFT having many levels that took advantage of this. I don't currently support multiple stories on a map, but I've written all the pathfinding code to be agnostic about, so it should hopefully require minor modifications to add support. Fighting through and clearing a tower floor by floor would be interesting and would naturally offer choke points at stairwells. It'll be interesting to see what does and doesn't work.

Overworld Module
Not much has been done. I'd like to add random encounters to the wilderness areas. They would link to whatever scenes and stages I have on hand as opposed to anything that makes sense, but it's progress. It might give me a reason to look at implementing a very simple party system and deployment. Shops/towns/castles are at the bottom of my priority list. I need to actually implement items before I bother with that.

Battle Module

Finally implemented 3D animation to some degree. Video is pretty brief, but wanted to have something to show. The major thing that's missing in the code is support for transitions between states, such as falling down after dying and stuff like that. I use keyframe animation as opposed to skeletal for simplicity, but adding support for skeletal might be something I do in the future.

Current Focuses

• Documentation - The game is getting increasingly complex, complex enough that I'm needing to take a look at the code when writing things like scenes or character definitions. This also needs to be done if anyone's going to experiment with it.


• Art Assets - Need more content to work with. If anyone has an idea for another simple monster to make, let me know. Slime will probably act as a medium range caster and the mantis is a glass cannon. Need something to be the slow, hard hitting tank and a healer.


• Demo - I have a few friends already testing some things, but figured it might be a good idea to put something small together. Current idea is to just package the slime version of the church battle from Tactics after getting some more animations done.

Stage Design
What qualities of a stage do you guys think are most important? I think the scenario and enemies play a major role, but ignoring that, I'd have to pick a stage like Barius Valley as my favorite. It has an interesting layout with a deep river splitting it in half. This allows for tactics more complicated than just running at the enemy to be used, such as establishing fronts and choke points. The changes in elevation mixed with the aforementioned choke points give ranged units a bigger role. You can actually defend an archer with a single knight and not worry as much about a chocobo just circling around and murdering the archer. Anyways, just wanted to see what other people thought.

As always, if you have any questions, feel free to ask.

Thanks,
HDGD

I'm not quite done with the curves yet. The curves are broken up into segments/rectangles, which result in the straight lines that you can see in the curved path. There are gaps that appear when using more extreme curves without enough segments. I have read about on how to fix that, but I haven't tried to look into it quite yet. Luckily there is quite a bit of material to read about bezier curves, so it wasn't too bad to figure out.

I have thought about adding button controls to navigation in addition to the fake mouse cursor, but it gets a bit tricky if you have a location with more than 4 connectors coming out of it, also the relative angle between your start and end add more complications. As an example, the bottom right city of that triangle of locations, which path do I assign to "Left"? What if there's a third connector from that segment that runs up? I'd worry that I'd have a difficult time making it not only intuitive, but also accurate.

The map scaling needs to have a bit more intelligence added to it since it makes some assumptions like your map image being larger than your resolution. I'll eventually fix that, but it works for now. The code identifies which dimension of the image is smallest and then scales it to 1.5 times of the matching resolution dimension. I think there are some cases where this won't work correctly, but I'll fix those as I encounter them.

Zooming is in its early stages and has a few bugs, but is overall pretty simple. Despite being a 2D map, it's still essentially in a 3D world. I just have the camera zoom out and all the locations and connectors stay in place.

For the character model, it's hard to say on how much is too much at the moment. The model I uploaded has a subdivision modifier applied, bringing it to 4128 triangles. Without, we're at 1032. The slime man is at about 3092 with the subdivision modifier. I've not noticed any performance issues yet with 10 of them on the field. It is certainly something I'm keeping my eye on though.

Thanks for the feedback.

Overworld Module
Project isn't dead! I've been busy with some work and life stuff. Certainly nothing negative, but too busy to provide much of a look on what I've been up to. Overworld module is coming along nicely. Currently supports:

• Displaying PNG format map with auto scaling.


• Locations/Places - Currently cities are not differentiated from wilderness.


• Links between locations. Includes support for bezier curves to make things look nice.


• Basic cursor support. Can't really click on locations yet.

Art is a bit rough and a work in progress. But I figured I'd throw something together and record it. Switching to the overworld module has been a nice change of pace since this stuff is a lot easier than the battle module. There is still a lot of work to do such as events, random encounters and shops.

Updates
My character modelling skills require a lot of work still. I think I have a base human model down as far as proportions, but I need more experience in the fields of rigging and designing a riggable mesh. I plan on taking a break from the human model and designing another enemy monster to use for battle. Here's a slightly out of date example of the humanoid template. I have a much easier time with stage creation than character modelling, but I'm sure I'll get faster and better at both the more I do it.

For 2D support, I've done zilch. If I have time this weekend I'll revisit it and see what I can figure out.

As always, feel free to let me know what you think, good or bad.

Thanks,
HDGD

Thanks Andrew. Compliments are certainly helpful. Also, feel free to provide any feedback on stuff or ask any questions. I know graphically I'm not presenting much yet to look at, but I'm working on it.

2D Sprite Support
Animated Sprite Test
A character can be linked to an image file and a "flat" file. The flat file contains the animations, frames and rectangles that define everything in regards to representing a character as a sprite.

The following code segments contain snippets from one of the "flat" files. This block defines a required "idle" animation and contains a sub anim for when this animation is viewed from a 45 degree angle.
<animation id="idle" >
<anim angle="45" flipFrame="true" >
<frame id="3150100" time=".125" /> <!-- Neutral -->
<frame id="3150101" time=".125" /> <!-- Front 1 -->
<frame id="3150102" time=".2" /> <!-- Front 2 -->
<frame id="3150101" time=".125" /> <!-- Front 1 -->
<frame id="3150100" time=".125" /> <!-- Neutral -->
<frame id="3150103" time=".125" /> <!-- Back 1 -->
<frame id="3150104" time=".2" /> <!-- Back 2 -->
<frame id="3150103" time=".125" /> <!-- Back 1 -->
</anim>

Frame Definition
<frame id="3150100">
<rect id="14"/>
<rect id="33" x="0" y="11"/>
</frame>

Rect Definition
<rect id="14" x="160" y="40" width="32" height="40" />


I did most of this by hand to get something working. Anyone familiar enough with ShiShi's source to point me to where it's reading the rects and offsets from the iso? Figure I might be able to modify ShiShi to do this work automatically. I'm dropping this a bit further down on the priority list for now.

Gamepad Support
Currently only an XBox 360 controller is tested. I suspect it probably won't work with much else for now. But I think I add future support later.

Stage Select

I've implemented a stage select screen that scans all available stages and scenes, then lets you select a scene by cycling through the stages. Will probably have it display additional information such as a stage description in one window and scene information in another. A few annoying bugs identified by testers have also been fixed. I'm not currently aware of anything outstanding, but I'm sure there are more issues to shake out.

The video also contains the first recording of a complete battle between two teams controlled by AIs: Berserk and Tactician. Berserk is mindlessly aggressive, but Tactician is aware of its other skills and of more complicated decision making, such as picking one target over another if it can eliminate the 2nd target. Personality for Tactician is not yet implemented.

Current Focuses

• Gamepad Support - Primitive Support For XBox 360 controllers added. (2015-10-04)


• 2D Sprite Support


• Overworld Module

Thanks Cheetah. I'm trying present some sort of update every one or two weeks. I'm afraid this update will only consist of words. Major goal is to make the game more tester friendly. Even started working on some primitive documentation with TiddlyWiki.

Updates
Graphics related work has been temporarily put on hold as I work through various battle engine bugs that I've encountered. When I get back to work on this, my focus will be on 2D character support.

I refactored the code related to charged skills and how they work and what happens if they fail. Code has been put in place to eventually allow a failed skill to result in a different skill being cast on a different target. Such as a mage blowing themselves up for not meeting skill requirements.

Refactoring for stages is mostly complete. There are now just two stage classes: "Stage" and its child "GraphicalStage". How important do you all feel about support for dynamic stages? I'm by no means planning on implementing it as it is currently out of scope, but was curious. An example would be a bridge collapsing. Probably nothing as dynamic as skills deforming a stage.

Currently planning out basic controller support as well. Game currently just supports keyboard. I will just do something basic for now and have the game look in the user directory to load custom controls that map joystick input to the keyboard. OpenTK has some degree of support for joysticks, but I'm not familiar with it. Should hopefully be simple.

As always, let me know if you have any questions.

Thanks Toshiko. That tool helped me partition the spritesheet correctly.

Updates
Still working on 2D support. Can currently create new animations in XML pretty quickly, but need to add layering support.

Working on some heavy refactoring of the battle module. I didn't like how fractured and specialized the stage class and its children were getting. Adding actors/props was also getting bothersome since you have to pay attention to the rendering order in OpenGL.

Also started working on the "overworld" module. World navigation will be the same as Tactics. It seems like the best method in this situation because it's simple, works well and doesn't require loads of content to be created for it.

2D Sprites
Doing some restructuring on the code related to character rendering and figured I'd see how difficult adding a class for 2D characters would be. Is there a guide on how sprites are put together? I think I can decipher it on my own if need be, just didn't want to do redundant work.
2D Sprite Test

Skills
As far as visualizing skills are concerned, I have a fairly simple system in place that can replicate some of the more basic skills such as "Fire". There's certainly a lot of room for improvement though.

Changing Priorities
I'll probably be refocusing and start looking at content as opposed to the engine. That ship from a previous video desperately needs texturing and I'd like to rig the human character that's in the above video. I think once I have a basic human rig, I can start playing dress up with the base human model and start creating characters for my game.

Thanks,
HDGD

Thanks for the compliment and thanks for your offer, but I think I'm going to continue working on this solo for now.

Not a giant update, but I did manage to accomplish some primitive skill visualization:


The "code" for this is again XML. Multi-target spells are not supported yet. Instead of a timeline, actions are grouped in layers. I'll eventually add support for a real timeline, but this was a bit easier to implement and I think will cover a vast majority of scenarios. The "prop" element should eventually support more types, such as a particle emitter, animated sprite, or a 3D object. All the camera actions shown in previous videos are also supported and I'll be adding more as needed.


<event id="2" type="normal">
<prop id="pellet" type="billboard" width="1" height="1" imagePath="Texture|effects|tex_Energizer.png" alpha="false"/>

<!-- Initial Settings -->
<action id="1" type="SetActorPosition" actorId="pellet" layer="0" position="user" toCam="true" offset="0,0,0"/>

<!-- Look at user/caster -->
<action id="2" type="LookActor" actorId="user" direction="targetNode" layer="0"/>

<!-- Prepare initial animation  -->
<action id="3" type="AnimateCharacter" actorId="user" state="cast" layer="+1" />
<action id="4" type="MoveActor" actorId="pellet" layer="0" position="user" offset="0,1,0" toCam="true" speed="5"/>

<!-- Throw projectile -->
<action id="5" type="AnimateCharacter" actorId="user" state="attack" layer="+1" />
<action id="6" type="MoveActor" actorId="pellet" layer="0" position="targetNode" toCam="true" offset="0,.5,0" speed="6"/>

<!-- Hit target, display damage -->
<action id="7" type="AnimateCharacter" actorId="user" state="idle" layer="+1" />
<action id="8" type="AnimateCharacter" actorId="target" state="result" layer="0" time=".5"/>
<action id="10" type="RemoveActor" actorId="pellet" layer="0"/>
<action id="9" type="DisplayEffects" actorId="target" layer="0" time="1" />

<action id="11" type="AnimateCharacter" actorId="target" state="idle" layer="+1" />
</event>


Xmls are very easy to read, write and change. A database can be a lot less friendly in all of those categories. I can make changes in Notepad to an XML, not so much with a database.

As for selling the engine, I would like to think I could license out the engine one day, but it's a bit too early to be thinking of that. Adding things in like a script interpreter would be nice, but with me being a lone developer, it's a bit outside the scope of the engine as it stands. A proper overworld would also be nice and possible, but one of the biggest enemies of any project is scope creep.

With the camera now in a much better state, my focus has moved to the visuals for skills and allowing for truly animated models. The skill visuals can luckily use the same framework I already have in place for the cinematic stuff featured in the first video. I hope to have something to show soonish.

New video:
Tactical RPG Camera Demo
Nothing major in this video. Just demonstrates some of the new smoothed out camera movement and the orthographic projection, along with another musical track courtesy Youtube. Thanks again for the compliments.

As for direction, I have a story I'd like to share and I think this genre is the perfect medium to tell it with. I've played FFT avidly since I got my hands on a PS1, probably replaying it once a year or so. During that time, I've worked on acquiring the knowledge to do the programming, modelling, texturing, etc required to make my own game. I've been aware of this site for a while as well, along with some of the impressive things that have been accomplished by the people here. I've also noticed that the feedback provided is often direct and correct. Based on that, it makes sense to show what I've got and see what users here think.

A "brief", very malleable feature list:
Single Player

• Story Driven Campaign




• World Map with towns, shops, etc


• Random Encounters


• Side quests/Multiple paths (lowest priority)




• Allow randomly generated or selected battles to be played/replayed.


• Horde mode - Would be easy to implement and be interesting to me.

Multiplayer
This is generally a big no-no for a lone dev, but I've got some experience in this and have written the engine from the beginning to support this. It'll probably use TCP since the packets don't need to reach the destination in real time, which should simplify things.

• Cooperative - Allow simple battle, story coop and horde mode


• Pvp




• Map selection


• Unit level limitations




• Unit Control




• One person vs. One Person


• One person vs. Multiple - Single controller team vs team of units controlled by multiple people


• Multiple vs. Multiple

Battle System
I plan on going a similar route as Final Fantasy Tactics with units having a sub job, passives and counter actions. I'd like to add some new elements such as skills related to setting up traps, persistent spell areas, and unit displacement spells. Anything related to actual map deformation is definitely in the pipe dream category, but it could be something I'd revisit. For items/equipment, I would like to add some stat requirements to gear. I probably wouldn't outright deny use of something, but it'd come with severe drawbacks. As in a feeble mage in heavy armor would probably have a movement penalty.

Mod Support
Outside of the 3D models, everything is basically just stored in various XMLs that essentially form a database. The 3D models are all just OBJ files and the images are in PNG format. My own content formats might change, but I plan on supporting these much simpler formats throughout development of the engine. Since I currently use the same methods that a modder would have access to, they could do most anything I could.