Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1370253 Posts in 64449 Topics- by 56501 Members - Latest Member: liquidpigstudios

December 09, 2019, 03:36:28 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsBolero: Turn-Based Fantasy Tactics
Pages: [1] 2
Print
Author Topic: Bolero: Turn-Based Fantasy Tactics  (Read 2936 times)
paulmyers
Level 0
**



View Profile WWW
« on: January 04, 2019, 01:34:09 PM »

Bolero: Fantasy Tactics

Hello everyone  Hand Metal Left Hand Metal Left Hand Metal Left

Engine is Godot, all game assets, mechanics, and code were developed by me
Bolero (working title) is a turn based tactics RPG that's been swimming around in my head for a long time now. You have your team of units on a tile map and your primary goal is to wipe out the enemy.





The mechanics are somewhat similar to Final Fantasy Tactics or Tactics Ogre games. Units take turns as they come up in a queue and move across a tile map in order to attack/support one another in a variety of ways. There are many more mechanical details which I will get into in subsequent posts.

Style

Graphically, my main inspirations have been the Tactics Ogre and FFT series as well as Fire Emblem. Also, Breath of Fire IV because that game is beautiful! I've recently been updating a thread at pixelation.org (https://pixelation.org/index.php?topic=29687.0) where their users have been super helpful with my developing pixel art style.

Progress: Update #0

So, there are a few things I still need to program in order to make the game more playable. First off, there need to be more animations, menus, and audio. The background also needs a bit more work. Also, the code for the units only accounts for player units and enemy units. Also, attacking only has a placeholder UI and code accounts for adjacent spaces whereas final game needs to allow for attacks at different ranges.

The most complex thing I've programmed for the game so far is the movement system. The game uses a Djikstra algorithm to find all the shortest paths to the tiles within range. Also, the ordering of depth of all the UI and graphical elements has been a headache.

For the past couple weeks I've been working on the graphical elements. I have some background in the visual arts and have been having fun making them, but it is so difficult and takes up so much time that I'm not sure I should continue doing it until I have made the game completely playable.

So the next goal is making the unit object able to account for different battle roles and have different stats and stuff. Then I guess the attacking system.

Tigsource

I began this project as something to be able to show in my portfolio, but it's getting to a place where I think it is actually becoming fun to play (which I guess was always the goal). I plan on continuing work on it until I could release some kind of build that someone can actually play and have fun with.

I really hope for feedback on this project! I'm posting here because I don't have any communication with other developers and would really like to! I'll be trying to post updates frequently. Thanks!
« Last Edit: November 09, 2019, 03:21:03 PM by paulmyers » Logged
paulmyers
Level 0
**



View Profile WWW
« Reply #1 on: January 07, 2019, 01:16:56 PM »

I'm planning on posting a minor update soon and have a question. I am seeing that many other devs are generating animated gifs to show off smaller snippets of mechanics etc. Is there a specific method of making the gifs that most use? Thanks

edit: welp, it doesn't seem very difficult to do with Photoshop. Still curious, are there other ways anyone prefers?
« Last Edit: January 07, 2019, 02:01:40 PM by paulmyers » Logged
Cobralad
Cowardly Baby
Level 10
*****



View Profile
« Reply #2 on: January 08, 2019, 03:41:35 AM »

liceCap
Logged
paulmyers
Level 0
**



View Profile WWW
« Reply #3 on: January 08, 2019, 02:11:50 PM »

Update #1  Wizard

Since the last post, I've further developed the background tiles to a point where I'm almost satisfied. I've also redone some of the unit code so that it is much closer it should be in the final game, allowing for each and every unit on the battlefield to hold their own appearance and stats.

I will go into some further detail on the game mechanics here.

Recovery Time
A combination of a few of a unit's stats defines how many actions they can take on each of their turns. In this first demo draft, I've made it simple. Each unit's "Speed" stat is set to a number which allows them to incur that number of RT, or "recovery time" on each of their turns. The more RT a unit incurs on their turn, the longer before their next turn will come up in the turn queue. I'm still messing around with what combination of stats defines the RT number for a unit. Equip weight and strength may play a role as well.

If you spend no RT, you'll just come up again, right? I solved this by having a minimum RT incurred on "wait" for each unit at about 12. This min RT could also be effected by stats, but it could just be constant for all units, not sure.

Attacking
Right now the game is barest of bones with units having a "damage" variable which they will deal to another unit's "HP" variable when an attack is executed. That's just the current state of things, but I plan to fully implement my own version of a tactics combat engine. I've figured quite a bit of it out, but balancing is another story. This is all a learning process!

Movement
I've finished this element of the combat engine (for the most part). Each unit has a "movement cost" variable which determines how much RT it takes to move 1 tile. When the player selects "Move" from the menu, my code finds the shortest path to every tile within the range that spending all of their RT would let them go. This max range isn't super useful because you would rarely want to move that far and not be able to do anything afterward. This is why I color coded the movement tiles for how many attacks the units could perform from that tile if they moved there. The number of attacks is also displayed in the little icon above the arrowhead.

At any point in your turn, you can perform a combination of movements and attacks or waits. This has the potential to let units have very convoluted turns! Here, you can see the swordsman unit moving and still having enough energy for 2 attacks, bringing his RT to maximum.

The attack interface is very rudimentary, I basically just made enough of a UI to be able to get through the actions. The final version will allow for attacks at specified ranges, not just the adjacent tiles.

I also made this gif just to show how the game will display the shortest path to whatever tile you have selected. If you want to take a non-optimal path to a destination, you can just use a combination of move actions instead of 1.


Topography
I decided to add an element of height to the battlefield akin to FFT, unlike Fire Emblem. It is an experiment and it is mostly just for visual flare at this point. Units can traverse stairs which spends a certain multiplier of a unit's move cost. This battlefield only has 2 height levels, but I've designed it so there can be any number of them. The way it is set up now, it takes the cost of 2 tiles movements to traverse the stairs, and the cost of 3 tile movements to jump up to a higher levels, and the cost of 2 tile movements to jump down. All of that can change, but it sort of makes sense to me that way?

This gif shows that there are situations where jumping down the ledge is more efficient in certain situations. Units can only walk through allied units, so restricting your enemy's movement can be a big part of your strategy.
« Last Edit: January 08, 2019, 03:18:27 PM by paulmyers » Logged
MattEbbs
Level 0
**


View Profile
« Reply #4 on: January 08, 2019, 08:11:34 PM »

I really dig the tileset, nice work. What might help me understand the topography is if the "lower" tiles (the ones above and below the set of stairs) had a cast shadow painted on them from the tiles to their left. I think that would really sell the depth. I see that you did that with the stairway casting a shadow on one of the tiles below it, and I think it works great.

Keep it up,
Matt
Logged

paulmyers
Level 0
**



View Profile WWW
« Reply #5 on: January 28, 2019, 04:24:01 PM »

What I've been working on mostly is the combat system; design and implementation work. I read through this excellent FAQ of the battle mechanics in Final Fantasy Tactics, the game I'd say mine takes most inspiration from
https://gamefaqs.gamespot.com/ps/197339-final-fantasy-tactics/faqs/3876?fbclid=IwAR2jYhTtqAhAdBIFfK3-nccw9Z8oHhj8lmc04UvkDtZb5MMApn-LD2dNWx4
It got me thinking about the design decisions I had decided upon and why they might be fun/not fun.

So this post is gonna be super mechanics and jargon heavy. I don't really expect many people to read it. I'm mostly writing it to have a record of how all the mechanics function. If anyone wants to go through it and give me feedback though, that would be super awesome too! Also, here's an updated Acolyte animation.


Something I will write which I got from that FFT guide is a 'clock tick', which means when the game decreases every unit's RT (recovery time) by 1.

My original idea of players being able to freely move and attack, fluidly accruing RT (example turn: move 1 space, execute attack, move 2 spaces, execute second attack, etc.) was granting way too much play complexity to the act of just moving your character! FFT units incur recovery time from moving (not exactly, but its a similar enough system), but it doesn't matter how far they move and the RT is not super significant. This struck me as being for less cumbersome and easy to understand for players. I'm not really designing my game with the end goal of simplicity, but I see why it is desirable. So I changed how my game's turns work quite a lot for the sake of less mind-boggling strategic complexity. But first, these are the stats I've settled on

Stats
MHP - max hit points
MTP - max Technique points. Like mp, but for any kind of skill magic or physical
STR - strength, influences physical skill effectiveness
MAG - magic, influences magical skill effectiveness
CST - constitution, influences the max RT units can incur in a turn, accuracy with physical skills
CCT - concentration, influences TP regeneration, accuracy and evasion with magical skills
SPD - speed, influences the RT cost of actions, physical and magic evasion

Weapons stats
WPW - weapon power, factors into skills performed with weapon
WGH - weight, factors into RT cost and accuracy of skills performed with weapon
weapons also have stat requirements to equip and can have elements applied to them
Also, each weapon has a default weapon attack skill which will be a unit's default attack when they are equipping it.

Armor stats
HPU - HP up, a hit point boost
PDF - physical defense, factors into physical damage taken
MDF - magic defense, same for magic damage
Have class rank requirements (more on that later) and elemental resistances

Accessories provide a host of different effects as well as various stat boosts

Character Progression
Each unit will have a class. In the demo I'm working on now, I've designed the Bandit and Acolyte classes.
Each class will have a set of ranks, each with 10 upgrades which you spend EXP (experience points) to buy.
Once a unit buys a certain number of a rank's upgrades, upgrades from the next rank will unlock.

Class upgrades include stat boosts and executable skills. An example progression would be if a class has 5 stat boost upgrades and 5 skills, you need to buy 3 of each to be able to reach rank 2.

Class Turn
The thing I'm most excited about is the combat system. Each class's turns will function differently. They will have different menus and different mechanics governing how you can spend your turns. I'll go through the Bandit and Acolyte here.

Bandit
The recovery time incurred by a Bandit's DWA(default weapon attack) determines the RT cost of every action they can take.
Example:
This Bandit's DWA takes 6RT and their stats indicate a maximum of 19RT. That means the bandit can execute 3 actions. The movement cost of 1 tile is 2RT, so a move action will let them move up to 3 spaces, always costing 6RT. So in this bandit's turn, they can move 3 spaces then use Slash then Grapple, or move up to 9 spaces, or use 3 Slash in a row, etc.

Acolyte
An acolyte gets 1 move and 1 other action on each of their turns. They are planned out at the same time and executed at the same time. First, you select a spell or other skill to execute which incurs a certain amount of RT, and then you can move a number of spaces calculated from your remaining maximum RT.
Example:
This Acolyte's has maximum 17RT. They have a spell 'Embers' of range 3, 10TP cost, and 9RT cost. When the player selects Embers to cast, the player than is presented all the targetable tiles within a range of 7 (Embers range of 3 + a movement range of 4). If the player desires, they can press tab and see the moveable tiles in range 4. Selecting one of these tiles will effect the range of the spell though. Once the player plans out where they want to move to and the tile they want to target, they move to that tile and begin casting Embers.

Magic
The way magic works, spells don't technically cost RT, they just freeze the caster unit for that number of clock ticks. For embers, the unit is frozen in a 'casting' state for 9 clock ticks, at the end of which they cast the spell and their RT will begin decreasing as normal. This means if a spell is canceled at some point, the unit will than leave the casting state and the total RT cost of the spell isn't really paid. This differs from FFT in that the caster still has their next turn delayed the same amount no matter when a spell is canceled.

In addition to all this, there are so many more details to figure out and its all a work in progress. I've implemented a considerable number of these concepts in the code, but I haven't done much UI and I haven't coded the new turn structures. So there's a lot left to do before I can get the first demo uploaded. Itch.io is the normal place people usually post that stuff, right?
« Last Edit: January 29, 2019, 10:06:11 AM by paulmyers » Logged
paulmyers
Level 0
**



View Profile WWW
« Reply #6 on: February 02, 2019, 06:42:57 PM »

I've finished most of the animations for the Acolyte class. I may do a death animation, not sure. I've gotta do walking and hurt for Bandit, regardless.
Logged
Leopotam
Level 0
*


View Profile WWW
« Reply #7 on: February 08, 2019, 12:35:32 PM »

Another idea for game mechanics - initiative throws (dices based on unit params) on battle start and then - "actions" in this order. Each full-tum action is 6 seconds long and each unit can do one full-turn action or 2 fast actions. It will help to simplify calculation and split abilities in 2 categories - fast and long actions. Good example of this mechanic - "Warhammer: roleplay" and "Pathfinder".

Btw, why godot and not unity, for example? What about 3d instead of pixelart?
Logged
paulmyers
Level 0
**



View Profile WWW
« Reply #8 on: February 21, 2019, 07:35:17 AM »

I'm aware of those systems. I just thought this one lended itself to the game I wanted to design. I grew up on those japanese tactics games so I'm also just more familiar with them. I think I'll be able to make more engaging gameplay with this.

I've been developing in Godot because I started a much smaller project with it and I was just testing the engine out. After a certain point, the scope expanded considerably and I decided I didn't need to change engines because Godot was working out just fine Smiley . Pixel art is the style because... it looks great! Also, this specific pixel art style is not something I am seeing done very often.

Also, I've made a lot of progress implementing the class centric turn system. I had to completely rewrite all of the turn structure stuff I had written as placeholder and also put it into a modular framework that would be malleable for what I want to be doing. The bandit class is pretty much done, than I apply what I made for that to building the Acolyte turn.

Work has been slower lately because I began work on someone else's project, but I'm gonna find time to put together another update post here. Hopefully with more gameplay gifs and spritework to show it off. It looks sweet right now!
« Last Edit: February 21, 2019, 07:44:46 AM by paulmyers » Logged
ChrisLSound
Level 0
***



View Profile WWW
« Reply #9 on: February 21, 2019, 09:19:53 AM »

Loving this - great work!

Is there any sort of traditional "level up" mechanic, or is EXP only used for buying upgrades? I find the latter pretty interesting and refreshing!

How many classes are you planning to have?

The different menus/mechanics per class sounds really cool and exciting, though I worry it could get too convoluted. Ideally, the player would be able to intuit what's going on with a new class on the fly. Of course tutorials could help if that's what you'd want to go for (personally I like when mechanics are taught as wordlessly as possible). Basically what I'm saying is make sure you don't get too bloated with different mechanics Smiley
Logged

Composer, Sound Designer
Website/Portfolio
Twitter
paulmyers
Level 0
**



View Profile WWW
« Reply #10 on: April 08, 2019, 06:48:07 AM »

Update #3  Gomez

Hi Tigsource! It's me, Paul.

So basically, I've implemented everything I wrote in my last update. All of those mechanics are in the game and working now. It was a lot of work but it's totally functional and feels like a real game (finally).

The biggest challenge was for sure designing and coding the two different classes, Bandit and Acolyte. Part of the difficulty was that I sort of designed and coded them simultaneously... yeah, planning ahead is very important! But I have them both at a place where I think they make intuitive sense.

First, I should reiterate what RT is. Every action a unit can take will increase their recovery time (RT). So it's something I'll be mentioning a lot.

Bandit: When a Bandit unit is initialized, his weapon's Default Weapon Attack (DWA) is analyzed and his turn plays out by performing actions which accrue Recovery Time (RT) equal to the RT it takes to perform that DWA.

Their move actions are given in increments of how far that DWA's RT would move them. In this demo, the DWA costs 6RT and it costs 2RT to move 1 tile, so a move action will get you 1-3 spaces and cost 6RT. There is a handy bit of UI at the tip of the Bandit's movement arrow which shows how many actions will be available after moving to that tile.

Another disclaimer, none of these assets are final. Especially not the UI!!!



All of the Bandit's "Brawl" skills also accrue the DWA's RT, but their power levels are balanced by the amount of Technique Points (TP) they take to perform. So if this Bandit has a maximum of 22RT they can accrue in a turn, they will be able to perform 3 6RT actions. Once they have 18RT, they can only do secondary actions (none of which I've designed yet, if there even are going to be any).





Acolyte: This is a magic oriented class. Their main action is to "Plan" out their turns. The Plan command presents you with a list of the performable skills and lastly the "just move" option.

Every unit has a minimum RT - the amount of RT set to them if they end their turn with any less than that minimum amount accrued. "Just Move" will let the Acolyte move as far as that RT amount will take them. In this demo, every unit's min RT is 12, so this will let an Acolyte move 6 spaces.

If a skill is selected in the Plan menu, the user is presented with the tiles they can move to. The range of movement is judged by the RT they will have left over after performing the skill they selected. So if their max RT is 16 and they select Embers to cast, which cost 8 RT, they will have 8RT left over and a move range of 4. For every space you move, that amount of RT is accrued. Also during this move phase, the resultant attack range is always displayed.



After the destination tile is selected, now you select the target panel within range of that destination.



Now, the Acolyte makes their movement action, and they begin charging their spell. As the world clock ticks by, the spell will eventually be cast once the charge time has past. An Acolyte's RT doesn't go down as while they are charging. In this gif, it shows the player confirming the spell, it switches to the bandit's turn, they wait, then the spell is cast, and the next unit (another bandit) gets their turn next.



So yeah! That's the general outline of how the classes work. There are a few more intricacies I shouldn't go over here but you can get into once I release the demo (I'm planning on sharing it here).

The next thing that was interesting to figure out was the functioning of skills. Between the two classes, I've designed 7 and each one took some meticulous attention.

The Bandit's moveset:
Slash - Default weapon attack, deals light damage
Reckless Blow - medium damage but user takes recoil damage
Grapple - incurs RT on a target, delaying their turn
Shove - pushes a target away from unit to a tile of equal or lower elevation.

All of these work great! As an example, here is Shove in action:


The Acolyte's moveset:
Mage Armor - No charge time, Increases user's defense for a bit of time
Embers - A slower spell, but hits a cross shaped area so higher damage potential
Dark Blast - higher range, more accurate, lower charge time, just doesn't have AOE

The Acolyte's skills necessitated I design a "target pattern" system that allows for area of effect skills like embers. These patterns don't have to be cross shaped, I can make them as big or as weird as I want lol. Also, Mage Armor had me develop the status system as well as stat modifiers.

Anyway, that's what I can show for this update. All of this stuff was done mid-March but I've been caught up with a few other things in my life. I really want to get back to some good progress on Bolero soon, though.

I think my goal for the next update will be just making the UI look better and also more flare to the action animations. Also, animating movement in some way.
« Last Edit: April 08, 2019, 06:57:08 AM by paulmyers » Logged
Ashedragon
Level 2
**



View Profile WWW
« Reply #11 on: April 08, 2019, 07:34:34 AM »

I'm really liking the look of this so far! One thing though, the heads and torsos staying completely static during most of the animations does make them come across as very stiff. Is this something you already intended to address?
Logged

paulmyers
Level 0
**



View Profile WWW
« Reply #12 on: April 08, 2019, 08:41:25 AM »

Not really. With the volume of animations I need to produce, shortcuts like those are quite helpful. Also, if units have fuller ranges of motion in their animations, it then becomes difficult to contain the sprites within their tiles and they clip into adjacent characters, with this art style anyway. I always want to make my animations appear as fluid as possible within the constraints I'm working with, so I thank you for the feed back  Kiss
Logged
paulmyers
Level 0
**



View Profile WWW
« Reply #13 on: April 19, 2019, 05:26:03 AM »

I've worked on the screen and display so that it is proper 16x9 resolution and there is a panning camera which follows the current UI element, usually the cursor. So, here is a screenshot showing that off Smiley ! The background sky is not illustrated by me (found it here. Will not be in final, just placeholder).
Logged
paulmyers
Level 0
**



View Profile WWW
« Reply #14 on: May 02, 2019, 01:38:27 PM »

So there is this indie gaming meet-up late May here in Chicago, and I've decided it would be a good deadline for me to work towards for finishing up a build to show off. This means I gotta get back to work! For this demo-thing, I want to have 4 distinct classes for the player, I'm not sure how many I'll have AI ready for, but my tentative goal is two. But this means I have to hammer down what these two classes will do.

I've been workshopping a few different ideas for the 3rd and 4th classes. The 4th I'm going to work on will be someone who draws their actions randomly from a deck of 'action cards' that the player has control over. The details for this are in flux and not my immediate focus, I just think it could be interesting!

The one I'm actively trying to figure out is the Guardian class. I have some of the details for mechanics, and some tentative spritework for how I want them to look.

Guardian
So basically, the Guardian will choose an ally to follow and protect while they wait for their next turn to come up. Most, if not all of their skills are purely reactionary.

Turn start:
select an empty tile. Then select an allied unit to guard on an adjacent tile, if possible.
Move to the selected tile.
Select which reaction skill to set.
Most reaction skills come with a range and some reactive action for enemies which do something within that range.
I'm thinking the guardian might take the guarded unit's damage in their stead by default
If the unit the guardian is guarding ever moves, the Guardian follows their movement by selecting an empty tile adjacent to the guarded unit's destination.

So I'm gonna be trying to program and animate more of this Guardian class. I'll have a larger update and hopefully some progress on enemy AI pretty soon!

Edit: I'm actually thinking of changing the perspective for the game. This will involve a complete overhaul of a few systems, but I think it'll be worth it. I just think this perspective looks way better! I still enjoy the front facing camera as opposed to the diagonal a la Final Fantasy Tactics, but the wonky perspective (which didn't make realistic sense) was just so irksome for me. It was easier at the beginning to have neat squares, but these will make things easier in the end, I think.


edit: its subtle, but I have change the perspective once again to increase tile visibility. This perspective is the most complex, but I feel it gives it a better quality. It is most analogous to a classic isometric orthogonal view but with two dimensions.
« Last Edit: May 05, 2019, 04:03:26 AM by paulmyers » Logged
The Armorman
Level 2
**



View Profile
« Reply #15 on: May 06, 2019, 01:51:36 AM »

your pixelart is great but i would massively suggest color balance or upping the contrast between areas somehow. looking at ur screenshots, its very difficult to tell when units are on diff. levels.
Logged

BELOW FOR GOGNIOS

ABOVE, FOR GOGNIOS
ProgramGamer
Administrator
Level 10
******


The programmer of games


View Profile
« Reply #16 on: May 06, 2019, 06:21:40 AM »

Yeah, I agree with armorman here, it's a bit hard to distinguish different elevations right now. Otherwise, really nice looking game!
Logged

paulmyers
Level 0
**



View Profile WWW
« Reply #17 on: May 08, 2019, 06:15:23 PM »

I added shadows. Hopefully that helps? The wall tiles need some extra work, I suppose they should be darker for readability
Logged
The Armorman
Level 2
**



View Profile
« Reply #18 on: May 13, 2019, 12:15:14 PM »

Now it's sexy. As Borat would say, "it's very good."
Logged

BELOW FOR GOGNIOS

ABOVE, FOR GOGNIOS
paulmyers
Level 0
**



View Profile WWW
« Reply #19 on: May 23, 2019, 08:00:16 AM »

3 hours worth of work, -100 lines of code. Feels good!!!

I'm going to have a pretty big update in a short time. I've done a bunch since the last update!
Logged
Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic