The Keepers- Tactical RPG

Greetings all! Wanted to show off progress on a concept my brother Jeff and I've been working on in my spare time.

The concept is a story-driven Tactical RPG in the vein of Tactics Ogre, Final Fantasy Tactics, Fire Emblem ect. It will be available on the PC and hopefully on mobile in some form.

The Story- You are the leader of a secret organization known as the Keepers, whose purpose is to collect and guard powerful items or "artifacts" (similar to Warehouse 13) in order to keep any of the world factions from using them to gain total control over the others. When I get the chance to sit and flesh out the story, I hope to explore some deeper themes- the power of truth, the greater good vs nationalism, ect.

The player will be involved in a tangled web of politics in the region- his dealings with powerful individuals will have a tangible effect on the game world at large.

The world will be just a nudge outside of common fantasy fare- men, elves, dwarves, orcs/goblins. We're striving for things to feel familiar enough to be accessible and understandable, but still have enough room to stretch the stereotypes.


The concept sketch above is an early idea of men and an "elf-like" race. The wildersung would be focused on hit & run tactics- with abilities based on restricting/slowing the enemy, dealing damage quickly and retreating, rushing, and directing opponents into compromising positions.

At first, We decided to try going the fully 3D route- XCom had a lot to do with that. Since an RPG is about story and the characters- We thought we should be able to set up dramatic camera angles and cinematic shots to enhance the storytelling throughout battles. However, we found the time investment required by 3D asset creation to be too great, and currently, we are pursuing 2D character graphics. Some environmental assets might still be 3D.



This is an early test of doing characters in 3D- Jeff was trying to capture the "pixel" feel of games like Disgaea in 3D, but ultimately he was unsatisfied with this approach. Currently he's doing some tests using Sculptris and Blender.

I wish I could show off more art, but I'm mainly a programmer, so I'll talk more about gameplay systems and mechanics next.

 

a Tactical RPG was completely new territory for me, but I had a few ideas on how to proceed.

I started by going as simple as I could. I kept it 2D, and I cut all AI and pathfinding logic. Just a board, randomly generated pieces with a few stats, and mouse controls.

The grid is procedurally generated from a 2D array, and a manager keeps track of all the Units and turn order. During a team's turn, the manager chooses the first unit in the list for that team, and runs a check on where it can move, and highlights valid tiles. User clicks the highlighted tile, and the unit is moved. If the unit has more moves left, it repeats. if not, it activates the action Panel in the UI and the user can attack or wait to move focus to the next Unit.

If the attack button in the UI is pressed, it checks who is in range to attack, and valid tiles are highlighted. It doesn't show in the video, but a console message reports how much damage was done.

With the basics down, it was time to get more complicated.

 

This is one of my favorite resources I have ever used. Procedurally generating terrain mesh from a datamap has come in very handy on this project.

I worked out the 3D terrain next- Perlin noise and all, the randomly generated terrain looked something like this screenshot from the Student Game Dev tutorial I linked above.



I did a few tests and quickly realized that terrain in SRPGs doesn't look anything like that. hills and valleys get in the way of the characters and what is going on- that's why you'll see most terrains in those games are pretty flat, or they slope in one direction. They are always carefully designed to grant the player a decent view of what's going on- from at least one camera angle.




So, with this in mind, I knew I'd have to design the maps by hand. So I soon worked out a Custom Editor for the Terrain mesh.

This was my first major editor, and it works rather marvelously! the block textures are defined in a byte 3D datamap. the value of each byte corresponds with a "brush" that defines what parts of a texture gets mapped to what face on the block. A library keeps track of the brushes that go with a specific texture.

 

Next up, I implemented cursor and Camera movement.



The cursor is controlled by the keyboard- and moves relative to the camera angle. The camera can move to 4 different empties positioned at corners of the map, granting a view from any angle. If the cursor moves outside of the "sweet spot" of the camera, it will move to the correct position.

With that working, I added in Units. I went online and found some free 3D Castle Crashers models, so I used them for stand-in graphics.



Applying some of the system I used for the 2D test, a manager focuses on the Unit whose turn it is, and instantiates the appropriate cursors. The white cursors represent valid moves, the blue is the currently focused unit.

I'm really excited to do some tests with AI- The best way I can think of to handle it is with a series of value-assessments. The Unit chooses a goal for this turn based on 1.) its type and abilities, 2.) its condition (ie. health, stamina) 3.) its surroundings (ie. outnumbered, wounded ally nearby, wounded enemy nearby)

After the goal is determined, a second value assessment is done on it's abilities and ranks them by how much they help accomplish the goal. A check is done on each ability in that order for viability- if the unit wants to attack, but no enemy is in range, he'll use a buff instead.

After the ability is chosen, if movement is required, a third value assessment will be done on all tiles in range based on which is the most advantageous position for accomplishing the goal and using the ability.

Let me know what you think! I'm especially open to advice about the AI, and I've given hardly any thought to the gameplay outside combat where the player has to deal with politics of several factions. Please comment your thoughts!

 

4 months of free time on nights and weekends later, a good deal of progress has been made on the functionality front.


The Action Menu is a touch-friendly way of presenting the actions a character can take. It consists of 5 buttons- 2 of which are common to every character- Wait and Move. The rest are filled in according to what Techs or skills that character has equipped. up/down arrows will allow you to change pages- that is, repopulate the buttons with the next set of options, should there be more than can be displayed at one time on the menu.

Whenever the cursor is over a unit, the corner graphic slides into frame with name, HP and stamina info on the unit.


When the move action is selected, a range grid is laid down according to the stats of the unit. The stamina cost of the move appears above the cursor.



Techs, or skills, are built on a component basis- behaviors employing interfaces reduce the amount of scripting required. If specific functionality is required, I can use the interfaces to code it in without breaking anything or making any adjustments elsewhere.

ITargeting takes care of laying down range grids.
IRequire checks if the conditions are right to execute the skill
IEffects are executed in the order they appear as components, and they only execute after the preceding effect has completed.

 

Hey man this project looking really good! You may want to check out Fantasy War Tactics which came out for android device on google play a few months ago. It is extremely similar and good tool to watch and see how well they do.

 

@Azmar -
Thanks for the feedback! Yeah ever since FFT got ported there has been a surge of similar games, lots of clumsy monetization schemes and a ton of reliance on pvp to drive IAP and retain users... I hadn't heard of the one you mentioned though, I will look it up!

 

Hi LMan, this looks like it's coming along nicely. It makes me wish I'd started taking screen-shots and notes about my own project's development cycle

I have a question about your Techs, if I may. From a project structure perspective, are those components added to just an Empty? Where do those empties representing each Tech live? I have been struggling with designing a skill/perk type system, and was going back and forth between hardcoding each skill into a unique class/script, vs creating a "library" object that lets me configure them similar to the way you show here. I opted for the specific scripts approach, but I'd like to hear more about how the other option works.

Good luck with your project.

 

Thanks, I'm glad you like what you see!

Each component is added to an empty- the "Technique" component is more of a manager- it grabs all the components off the gameobject and sorts them into lists according to what type they are- "Requirements", "Targeting System", "Effects" and takes care of running which components when. The whole ensemble is then saved as a prefab.

When I want to use a tech, I instantiate the prefab, and the Technique component handles its stuff, and calls an event when it's done.