TacticalRPG Engine

[HowDoGameDev]

Hello all, just wanted to show off something I've been working on for the last six months or so.

The game is built on top of my own OpenGL graphics engine. The engine is written in C# and utilizes OpenTK. Although I've not started any kind of extensive testing, I have found that it will work on Ubuntu with the Mono libraries installed.

The battle engine has a majority of the required features implemented, including movement, status effects, skills and AI. A very primitive job system has also been implemented. The architecture is server/client, with server commands and client request/confirmations controlling the flow of the game.

The end goal is to have a multi-chapter single player campaign with gameplay further supplemented by cooperative and PVP game modes. The game currently loads all of its data using XML files, which should be very mod friendly. Currently only 3D characters are supported, but with enough interest, I can see what 2D sprites would require. Let me know what you all think!

Demo Now Available
Itch.IO page is here
Please report any issues on the discussion board or message them to me.

Thanks,
HDGD

Demo Available Here

[Kaijyuu]

Looks like you've got a good amount of work in. Certainly not the most polished thing ever but a good proof of concept.

Keep it up.

[Angel]

Oh god, the fisheye perspective X____X
Do flatten the focal length out. It's such a staple of SRPGs that it's heresy to do anything else.

That aside, it looks like it's working as intended. The world could use more SRPG engines available to hobbyists, and I know I like playing around in all of them. Do keep it up! <(^.^)b

[3lric]

I saw this on YouTube a week or so ago. It looks like you've put a decent amount of work into it and it would be nice to see that continue. My only personal issue is how the camera moves during battle, it seems to kinda jump around without a smooth transition. Other than that and what Toshi said, I have no complaints. Well done.

[HowDoGameDev]

I would definitely agree, the camera as it stands is garbage. Most of it was hacked together quickly so I could get something on screen. Camera movement in battle is certainly jerky and something I'll work on. The methods needed to smoothly scroll are there, but I haven't gone back and changed the "snap to" methods out for the "scroll to" ones. I'll add the camera to my primary focuses.

When you refer to the focal length, you mean the distance from the camera to the objects, right? Would something like the below be easier on the eyes for the time being?
http://imgur.com/98WVgCn,3GKE2en#0

My to do list currently consists of:

• Simple visual skill effects system


• Camera


• Rigging human model

I'll probably keep the visual effects simple for now and take a page from FFT's book where it appears to just be a 2D animation billboarded over the world.

For those curious, most of the data is stored in xmls. A skill looks like this:

Code Select Expand

<skill id="1000" name="testAttack" aoeCalc="single" targetting="normal" speed="0" hRange="1" vRange="1" rangeUser="false"
frate="f(N:100|-|S:pev|*|N:2))" srate="f(N:100|-|S:pev)" brate="100">
<effect id="2" custom="true" exffvalue="0" effvalue="f(U:str|*|N:-3.6|*|S:pdef)" />
<xeffect id="8" />
</skill>

Some of the attributes are a bit cryptic, with things like "frate" being the calculation for hit chance from the front. The effect elements point to effects by id in the "Effects.xml", and include things like "AddStatus", "ChangeHealth", etc. I've got a decent formula parser as well that I've written: f(U:str|*|N:-3.6|*|S:pdef) evaluates as "current user strength" times base number times "current target phys defense". Not really familiar with the tuning or methods for RPG formulas, so it's all subject to change.

Thanks for the interest and feedback guys.

[Angel]

No, focal length is what causes THIS crap:



A flat focal length (referring to a flat lens that distorts an image to the opposite direction) is what makes every FFT tile look distortion-free no matter where it's positioned:



As you can see, the game would look no different (aside from rotations) were it drawn entirely with sprites rather than polygons. This is a staple of SRPGs.

[HowDoGameDev]

Oh! I know what you mean now. You want an orthographic projection: http://wiki.blender.org/index.php/Doc:2.4/Manual/3D_interaction/Navigating/3D_View

I'll see what that'd take later tonight.

[Angel]

Exactly. I was just using physical camera terms. 8D

[HowDoGameDev]

How's this?
http://imgur.com/7egt9Ki,BVJyIRY#1

[Angel]

Brilliant! Exactly what I wanted to see.

[Kaijyuu]

Gotta agree that that looks much better.

[HowDoGameDev]

Thanks for the feedback. I've switched to the smoother camera movement and it's looking much better. I have to fix a few minor bugs and write up code for skill visualization then I'll try to release a "playable" build.

[Darkholme]

This looks really cool. Color me intrigued.

What direction do you intend to take this project in?

[Mudvayne]

This is really, really cool. I have no idea what you intend to do with it, but it's still really cool simply because you made it from the ground up.

I'd love to see where this goes in the future.

Pretty cool how you have the skills worked out, it seems pretty user friendly to create your own abilities. 

[HowDoGameDev]

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.

[Darkholme]

Very cool.

Out of curiosity, why did you choose to go XML instead of a real database?

I bet if you opened this up the way of RPGMaker and sold your engine+editor on steam you could probably make some decent sales.I'd be quite interested in it, particularly if the gameplay mechanics were in editable scripts (even just interpreted Java/C#/whatever) rather than hardcoded and precompiled. It's got a fairly polished look to it with how you're rendering things, you would just need a good collection of sample art assets, which could be the ones you use in the game you're working on anyways. Ideally you'd want the option to compile the finished game to several platforms, like the newer RPGmakers can. (Otherwise people still might feel a need to go with something like Unity).

I'd like to make my own 3d SRPG at some point, and you can bet that something which saved me months of work I would otherwise have to do would be something I would be willing to pay for, and I doubt I'm the only one who feels that way. People do, after all, buy RPG Maker.

Though, I'd prefer a proper overworld, rather than the map-menu from FFT.

[HowDoGameDev]

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.

[Darkholme]

All fair points.

I look forward to seeing your next version.

[Bladegrasp1997]

WOW! This is awesome. I don't know if you have seen this topic
http://ffhacktics.com/smf/index.php?topic=10806.0
but I've been trying to do something like this. I'd like to help if I can.
I've made a few character models already and I'm working on level designs using the original levels.
I can do rigging and animations as well.

[HowDoGameDev]

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.

Code Select Expand


<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>