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

Login with username, password and session length

 
Advanced search

1382183 Posts in 66018 Topics- by 58433 Members - Latest Member: adrchw

September 19, 2020, 11:29:21 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsFell Seal: Arbiter's Mark (FFT style game) - Last 48hrs on Kickstarter!
Pages: [1] 2 3
Print
Author Topic: Fell Seal: Arbiter's Mark (FFT style game) - Last 48hrs on Kickstarter!  (Read 6995 times)
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« on: June 17, 2017, 10:20:13 AM »

Fell Seal: Arbiter's Mark
Facebook | Website Gallery


 Gentleman NEWS! Gentleman

Kickstarter is now live: Kickstarter Link



Basic Description:
Fell Seal: Arbiter's Mark is a Tactical RPG for PC, inspired primarily by Final Fantasy Tactics and Tactics Ogre. The feel of the game should be very much in line with FFT, but with hand drawn 2D landscapes in high-res. The concept is similar: there's a gripping and dramatic story line that leads you through several battles, in which you have a very high amount of troops' customization.



Trailer:



Friendly sprites:
 

Weapons of the lands:


Gameplay examples:

(enemy attacking with a bow)


(using a displacement skill to toss a non-swimming enemy into water)

Basic Introduction:
Fell Seal has been in the works for almost 2 years now, although most of the programming was done part time.

I have worked previously on the indie game Black Sigil: Blade of the Exiled for the Nintendo DS, which took a grand total of 7 years (most of that part time as well), so a lot of the choices that I made this time around come from my experience with Black Sigil and I will try to give context with respect to that when explaining some of the decisions that were made.

Although the overall game is probably only 50% done, the programming of Fell Seal is about 95% done at this point. There's a lot more art needed as well as most of the music.

Team Specifics:
The game runs on Unity and is programmed by Pierre Leclerc. Our music is made by the composer for Black Sigil, Jan Morgenstern and most of the art is made by Christina Leclerc, aided by a large crew of very talented contracted artists (you can find an updated list on our website: https://www.fellseal.com/the-team. The story is written by Daniel Nawrocki and the dialogues and cutscenes by Pierre Leclerc.

Extra Notes:
I'll add more concept art and screenshots asap, but I'm eager to get the actual devlog started (I assume that's what people are interested about ^^), so I'll start on that right away Smiley

If there's any specific topic you'd like me to cover about Fell Seal or even Black Sigil, just ask away (or send me a private message to make sure I don't miss the post) and I'll add it to the list of topics Smiley

Links for quick navigation:
Programming focused dev logs
Basic Design Decisions
Editors
Extra Tools
Unity Specific Decisions
Combat Spell Effects

Gameplay and Design focused dev logs
Game Design - Character Visuals
Game Design - EXP, AP, leveling and extra notes
Game Design - Classes
Game Design - Creating Maps
Game Design - Item Usage
Game Design - Cutscenes Style
Game Design - Spells - Part 1
Game Design - Spells - Part 2
« Last Edit: October 28, 2017, 12:56:15 PM by 6 Eyes Studio » Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #1 on: June 17, 2017, 10:20:43 AM »

Basic design/programming decisions:

As I mentioned before, a lot of the decisions that were made came directly from my previous experience with Black Sigil, a project that spanned 7 years of very hard work. Seven years is way too long, so a lot of the decisions that were made for Fell Seal were aimed at making sure the dev time would be within more acceptable margins. Our initial goal was 2 years, but like most things, that was optimistic and "stuff happens" happened, so we're aiming at a 3 years plan at this point.

Why a tactical RPG?
Multiple reasons, but mainly: my team and I will only work on games that we would love to play. That means RPGs at the core. As far as RPGs are concerned, on top of being great fans of Tactical games, I figure it would be much less programming work than a pure RPG. This conclusion came directly from my work on Black Sigil, which needed a tremendous amount of systems to get everything done. By contrast, a tactical RPG can do pretty much without the whole 'town system' and 'puzzles in dungeons', limiting it mainly to menus and battle system, more or less.

Why Unity?
This comes down to speed of code creation again. While I specialize in C/C++ code, Unity offers a framework that greatly speeds up the basic setup of the game, as well as easy cross platform options and, frankly, C# isn't that bad at all.
Why Unity and not another engine (unreal, etc)? Primarily, I had experience in Unity from previous work in the gaming industry and when our project started was right after Unity (finally!) got their 2D act together with their new 'sprite system', which made it fairly attractive for our 2D plans.

Why in 2D anyways?
We love 2D art. We think there's quite enough 3D go around already and (when we started our project at least >.<) not enough 2D art to go around. Also, our main artist is a pixel artist and has no 3D modeling experience.
I do not think 2D sprite, especially with the high resolution style we are going for, is one of the wiser time investment out there though and that decision is not quite in line with the rest of our decisions when it comes to "making sure this doesn't take another 7 years".
« Last Edit: June 17, 2017, 10:33:55 AM by 6 Eyes Studio » Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
HopFrog
Level 1
*



View Profile WWW
« Reply #2 on: June 17, 2017, 10:32:01 AM »

Oh man! I can never have enough turn based tactical games! Grin

It's a shame we don't get too many quality ones, yours certainly looks interesting though!

Is it very story/lore heavy?
Logged

6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #3 on: June 17, 2017, 10:43:35 AM »

Is it very story/lore heavy?

Hi HopFrog!

There is definitely a lot of story involved yes. The story battle scenes are fairly heavy with 'RPG style cutscenes' (but they can be skipped if someone wants to).

There's a fair amount of lore (no story could stand up on its own without some lore!), but I'd say it's mostly enough to sustain the story/world in a coherent manner and we're not planning on creating eons of extra lore that has no real impact to the matters at hand.

We're also planning on having optional cutscene moments throughout the game (think of private actions in Star Ocean, roughly) where you can see more of the backstory of story characters.
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #4 on: June 17, 2017, 11:31:01 AM »

Editors:

What kind of editors do we use for Fell Seal and what prompted those decisions?

Map Editor:
First, here's the editor we had for Black Sigil back in 2003: (yes, it's in visual basic. It was created in 2003!)


That editor handled map creation, placing sprites and events on the map. Dialogue editing, cutscene editing and so many other things. We also had a monster editor, sprite editor, spell data/visuals editor, items editor... Well, you get the idea.

While those editors were very powerful and ultimately useful, they also took the better part of a year to create. That's a long time, especially w/r to our initial 2 years timeline...

So, what are we doing differently for Fell Seal? The editors I created for Fell Seal took about 3 weeks of part time work to create. Of course, they don't quite do as much... But they do just enough.

Black Sigil was created for the NDS, which has much more harsh restrictions on the way the maps have to be created (tiled, using Nintendo's tiling format, etc), so for Fell Seal, our maps are non-tiled, fully hand drawn maps. This means they can be created straight up in photoshop and don't need a special editor. It also means they take way more memory/disk space than Black Sigil's ridiculously optimized systems, but it's for PC, so no one cares in the slightest ^^

Here's a screenshot of our editor for Fell Seal:


Obviously it's much simpler and has less options. It basically loads the png map, which has been specially drawn to work with a grid. Then We can create the map topography and add some 'props' to the scene and it's pretty much done.

For the cutscenes, sprite placements, chest contents, etc, instead of adding new editor functionality, we have a C# script file for each map and that script handles placing the sprites, the cutscene creation, etc.

The advantage is that all that information is entered in code directly (the script file is just another unity C# file), so it's 100% flexible with what you can do at all times and no new editor functionalities are needed.

The inconvenient is that it's all in code directly, so no one else but a software engineer can easily mess with it and it's not data driven (I won't go over that topic, but data driven is, generally speaking, always the better way to do things).

But, one thing I noticed with Black Sigil is that while I had this crazy editor that could handle all the cutscenes with a simple easy-to-use script, at the end of the day, I still don't have manpower and I'm going to end up scripting it all myself anyways. So, might as well skip the crazy editor phase and just put it up directly in code, using some wrapper functions to make it easy and fast.

The only other editor I bothered creating for Fell Seal is a dialogue editor (mainly to replicate the text spacing from the game as I write it, because I'm very very OCD about my text being spaced 'just so' to create the best cadence and impact ^^). All items, gear, abilities data is created straight in similar script files directly (again, I'm going to be the one inputting all that data anyways, so no real point in making an easy to use editor). The main downside is that this won't be easy to mod, but I will transform the system to a text-based 'data file' if it comes to that.

So, that's the editor situation for Fell Seal. Basically, all editors do 'just enough' to allow the easy creation of data for the game, so that they require the smallest amount of code to write for them. Mainly, decisions were made to ensure we could finish the game in a fast time frame.
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #5 on: June 18, 2017, 12:01:31 PM »

Tools.

Since our project is using Unity, we find ourselves not needing too many external tools.
The one big tool we have is a custom Atlas Packer, for packing all our sprites into atlases.

I won't be drawing too many parallels here between Black Sigil and Fell Seal, mainly because Black Sigil had very different requirements for tools (DS games and Unity games just don't have the same needs there), but the main one I'll mention is that our sprite atlas packer might not be where I was the smartest with our time, both for Black Sigil and Fell Seal.

It has probably taken 2 weeks of solid part time work to create by now and I think there are decent enough 'atlas packers' out there that it might have been better to grab one of those. Still, it does some special processing and works with a command line format that I find really helps streamline things for us.

Sprite Atlas Packers are fairly common and ours probably ends up doing the same than most other packers do, but if anyone wants some more specific information about the code and how to achieve some it, feel free to ask Smiley

So, what does this Atlas Packer tool do exactly?

- I feed it a list of folders and a list of 'options' for those folders.
- It runs through all the images and trims them to their smallest size, as well as doing some special information gathering based on the name of the file (it separates sprites into directions, actions and figures out the play speed of sprites, etc, from the file name).
- Then it creates a 'sub atlas' for all images in a folder (in one folder, we'd have, for example, all the frames used for a specific character).

For example, an armor set might have 116 frames (yes, that many ^^) that are saved as individual PNG files (through an export command in photoshop) in the folder. Its sub atlas will contain all these frames, fully trimmed and with 'duplicates removed' (some actions might share identical frames at times) and an artist can then use this nice atlas to do quick new palettes for the given set of armor.

- After that, all these sub atlases are fed to super giant 4kx4k atlases that tries to fill up those atlas as much as possible.

Command line tool:

Here we see the last few atlases. Those usually aren't packed as tightly as the first ones, as we run of 'small sprites' to squeeze in between the big sprites.

Basic folder with sprites:

Base frames for a clothing set. All sprites are made from a body, a head, a set of clothing and a hat. The player can pick the head, skin color, clothing and hat as well as add some accessories.

Sub Atlas generated from the above:

This contains all 116 frames from above, trimmed and with duplicates removed. Easy for artists to make alternate palettes out of.

Final 4kx4k Atlas from multiple sub atlases:

Filled with madness, it contains as many sprites as it can fit. This specific one uses 95% of the available surface.

The final result is multiple 4kx4k atlases containing a hodge-podge of images. Generally speaking, I feed them in a order that will maximize the chances of 'similar things' being grouped together, which reduces the amount of atlases that need to be loaded at once in the game.
An XML is also generated for each atlas, that contains all the original information of each frame (size, etc) and lots of other information for the sprite system to be able to read the sprites quickly.

Last, there's a master XML that's created that tells the sprite system which atlas contains which sprite, so using the sprites doesn't reference the atlases in any way for the programmer (it's fully transparent). That way, even if a sprite gets displaced to a new atlas by the packer, it's all done behind the scenes.

So, why didn't we use Unity's Sprite Packer instead?
Well, when we started on the project, that packer was only in a paid version of Unity. Also, it doesn't work on Resources assets (those are assets in unity that can be dynamically loaded, rather than loaded statically through a scene, roughly) and our game uses mostly resources (that's a topic for another post ^^). Also, it's very slow and possibly not as efficient as our packer. Lastly, we still need to make the XML because they contain all sorts of useful data, so at the end of the day, our own packer made sense.
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #6 on: June 21, 2017, 09:26:32 AM »

Unity Specific Choices:

Those are some of the choices that we made with respect to how we're using Unity.

Unity plugins:
I think we could have spent more time looking for unity plugins to save some time, but at the same time looking for plugins on the Unity store is fairly time consuming, time that could have been spent making the plugin itself often enough. Still, here are some of the plugins we ended up getting and that we believe are fairly useful:

Textmesh Pro: It's a bit of a mess because it features just SO many options, but at the end of the day, it's still so much better than unity's default font system. It's now free as well, so no reason not to use it. It has a few differences with stock unity text boxes that will require you to tweak a few things in your project, but nothing too bad.

Sprite Mask: Feels a tiny bit hacky at times, but still, the functionality is sorely needed and strangely missing from stock unity. It basically allows the user to use masks (simple rectangles or complex shapes) on Sprites. Unity only allows masks to be used on UI images otherwise (that's crazy o.o).

In Control: Plugin that abstracts the button mapping of most popular gamepads out there (including xbox360, ps4 and many more). Makes it very easy to have a standardized button system for all controllers and our game is targetting gamepads primarily, to increase the 'old school console tactics game' feeling. Only complaints with it and is that it handles poorly the select/start button on controllers (we had to change the source code to fix that).

Scenes vs Resources:
I'm aware that Unity itself recommends people use scenes and never resources as much as possible. Primarily for efficiency reasons they say (it seems their resource system isn't very well done and they can't handle the memory usage as well when it's used).

Still, our project has 1 scene, which contains a camera, a canvas and a few mostly empty gameobject containers. Everything is data driven and loaded dynamically through code. I'm sure Unity isn't using memory as well as it otherwise would, but this saves me from creating about 50+ scenes and has me creating about 3 pages of code instead. A good tradeoff.

At the end of the day, for our purposes, this system is a lot more flexible and robust and our game actually needs a paltry amount of memory compared to 3D heavy games, so it probably hardly matters. Performance is also not really an issue: loading and drawing a few 2D images is fairly inexpensive.

We looked into asset bundles as another solution, but they are still a pain to use at this point and Unity engineer's say it's basically just a wrapper around the Resources at the end of the day, so we'll leave things alone at this point (if it ain't broken...).

UI - Prefabs/objects vs Scripts:
The basic choice here is to create prefabs in Unity (prefabs are basically a bunch of game objects you create in the editor, then serialize them as 'blueprints' and you can then load them later in code) vs creating scripts that simply generate the gameobjects on the fly. Technically, you could use a bit of both,but you'll always need a modicum of code to load your prefabs (unless they are baked in a scene, but then you don't really need it as a prefab, do you?).

This choice is more dependent on your team makeup I believe.

If your team has UI artists or designers that aren't on the tech heavy side, they'll live the prefab model better. They can create their prefabs with Unity's little widgets, etc, and then your programmer can spawn them later in code. Eventually both parties (UI and programmers) will get a good model going and it'll be a breeze, mostly.

If your team is only programmers in that respect, they might like better to just create some classes wrappers. For example, I have a UIText class that inherits from my UIElement class. It spawns a textbox, sets some default values, has a bunch of built in properties to have me work always in 1080p in terms of values and then it automatically scales things to 'whatever resolution is used', as well as putting the 0,0 point where it belongs, the top left corner of the screen! Yeah, that's how it was when computers had 2 colors on the screen and that's just how it should be I say!).

Anyways, we are programmers heavy (me vs no one else, haha), so we went with the class wrappers and everything is done in code.

Sprites and such: Canvas vs SpriteRenderer:
Frankly, I'm not 100% sure what's best there, but we're using raw sprites for everything that isn't flat out UI (so, those sprites aren't on a canvas) and the canvas system for all UI components.

Primarily, when I started working on the game, Unity had JUST released its sprite system and the canvas was either not there yet, or poorly documented, so it was easier to go with spriterenderers for our maps/sprites, which is why we went that way.

I believe we lucked out though, as I think that was the better idea. The sorting system of spriterenders is better suited for free flowing sprites imo and I have heard all sorts of worrying things about the UI system from actual Unity engineers (let's just say it needs further optimizations), which I think don't apply to the spriterenders. I do think the canvas images might be a tad simpler to use than the sprites when it comes to sizing, resizing, tiling, 9-slicing, etc, so the canvas system is definitely more suited for the UI itself.


Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
RofB
Level 0
**


View Profile
« Reply #7 on: June 23, 2017, 05:36:33 AM »

That environment art is gorgeous. I love me so good tactics games, looking forward to this!
Logged

6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #8 on: June 23, 2017, 08:53:41 AM »

That environment art is gorgeous. I love me so good tactics games, looking forward to this!

Thanks a lot for the kind words. Our artist will be delighted to hear this Smiley

Any suggestions on the dev log itself btw? It might be too tech-focused so far? I'll get to the design bits soon enough, but I guess I'm not sure what people are primarily interested in...

Thanks!
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #9 on: June 25, 2017, 01:59:14 PM »

Game Designs - Characters Visuals

In Fell Seal, the player can choose from over 20 different classes for any of his characters. Much like Final Fantasy Tactics, the player can change their class to any other class they meet the requirements for, as well as equip all the active abilities of a second class.


All available standard classes opened for this character. There's still secret classes though ^^

In most tactics games, the classes are handled by having their own unique sprite (so all Squires look the same, but no Squire looks like a Black Mage). For Fell Seal, we wanted to give the player options to customize their characters fully to their liking. This started with making sure we had a large amount of portraits to chose from and then to making sure the player could import their own portraits into the game.

Then our artist figured it would be great to let players fully customize their sprites by letting them pick skin color, head, eyes, outfit, headwear and some accessories. There was a lot of debate over the idea, but eventually we went with this interesting system. I honestly can't say if it saved us time over creating all individual sprites or if it costed us time because of all the numerous sprites that need to be created and the system that needed to be put in place, but we are certainly liking the final result.

The final system allows the player to pick Skin Color, a Head, eyes color, an outfit and its color, a hair style and its color, a hat and its color and an accessory and its color.


This is the player choosing his outfit, all in purple on that screen.


The main downsides of the system are that each sprite renders several sprites, 9 in total (head, body, eyes, hair, hat, outfit, accessory and the hair/outfits are broken into 2 layers for sorting purposes) rather than only 1, which of course is more strain on the rendering.
We also found out that our wanted 'death animation' for the sprites looked funky because of this. The wanted animation was to turn the targets alpha from 1 to 0 gradually, but that would suddenly show what's under some of the above pieces (so, the head, hat and hair would all suddenly show for example) and that was looking weird. We fixed that by fading all the pieces to solid black first, then doing the alpha-out and that actually looks decent Smiley

All in all though, our game renders ridiculously fast (with vsync off, it runs at 1200fps on my computer, which is actually scary, so I leave vsync on all the time) even on low end PCs, so a little inefficiency isn't too hard on the systems and the added customization has been pretty popular with our testers so far Smiley


The final result is an eclectic bunch ^^ (we have a lot more outfit now than when this screenshot was taken too!)

« Last Edit: July 01, 2017, 12:14:45 PM by 6 Eyes Studio » Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
Pixelcomet
Level 0
***



View Profile WWW
« Reply #10 on: June 26, 2017, 12:17:23 AM »

What a gold mine of information  Addicted
Logged

6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #11 on: June 26, 2017, 06:07:08 AM »

Not quite a part of the dev log itself, but we just added a 5mins video showing in detail the first battle of the game. That should give a pretty good idea of what things look like in practice.






What a gold mine of information  Addicted

Thanks! I'm glad someone is liking the dev log Smiley
If there's a topic you'd find interesting, please let me know!
I'll try to eventually cover all relevant things we went through with the project, but it's challenging sometimes to differentiate between what is interesting vs what I *think* is interesting, lol.
I'm a software engineer, so things that *I* think are interesting are definitely skewed in that direction ^^

Thanks again for the kind words Smiley
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #12 on: June 27, 2017, 08:07:58 AM »

Combat Effects System

Here I'll discuss how our system to show spells and attacks during combat/cutscenes works, again with some comparison to the Black Sigil system I created back in the day.

First, here are a few spells, to get an idea of what things look like:

The "Flowing Flourish" ability used by the Duelist. The Duelist specializes in strong single target attacks, usually with an element attached to them.


The "Firestorm" spell used by a Sorcerer. Sorcerers specialize on global map spells, targeting both allies and enemies with powerful, but very costly, magics.

I don't really have Black Sigil screenshots at this point, but the spells were similar in nature, if not in quality (Fell Seal's are made for 1080, the NDS was 192).

Both Fell Seal and Black Sigil operate on a similar system at the end of the day: each spell is a compact little chunk of data, that contains a list of sequential instructions with their arguments. A simplistic example would be:

- Show Casting Motion on Caster
- Spawn "FireEffect1" on Target
- Wait for FireEffect1 to end
- Show Damage
- Reset actors to original actions

But there are a lot more instructions than that, involving moving things around, fading things, color changes, etc.

For Black Sigil, I had opted for a full editor, where the whole spell could actually be played/shown in editor and with a visual interface. It was actually pretty convenient and allowed me to outsource a few spells to a friend with a mild programming background. But, on the flip side, it took several weeks to get all the kinks worked out.

For Fell Seal, I opted to just create a simple class in C# and to add script-like methods to it. The upside is that i didn't need to spend weeks on an editor. The downside is that I need to 'boot the game' to actually see the spells in action and that it's fairly programmer-centric in its usage. The new script system I created is also simpler than my original Black Sigil system was, which made it a bit less flexible, but less prone to bugs/errors.

As for the system itself, Fell Seal aims to keep things simple and bank on the fact that PCs don't care much about storage space, so almost everything is an actual sequence of pngs played one after the other, all created by our (really awesome) spell pixel guy. It uses the exact same system as all the other sprites in the game, which made it easy and fast to setup and less likely to have bugs.

For contrast, Black Sigil had a custom system to slice images into tiles to optimize the NDS memory, as well as a lot of procedurally generated shapes/effects to save space and a lot of HLine, HBlank, VBlank interrupt effects to create custom windows, wave effects, etc (I DO miss interrupts on modern systems. So freaking powerful...)

The advantages of Black Sigil's system was that even a programmer could make pretty good spells with the generated shapes, masks, heatwave effects, etc, and our lone artist was already overworked. The downsides is that it took a long time to create all of those. Also, it took almost no cartridge space.

The advantage of our current setup with Fell Seal is that it's simple and didn't cost too much time. And since we can afford to dedicate an artist just to spell effects, might as well. Also, we don't care about "cartridge size", so the added strain of all these images is no problem.
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #13 on: July 01, 2017, 11:48:51 AM »

EXP, AP, leveling and some design goals

Let's start with EXP and AP.

So, EXP is used to level up (whenever you get 100 EXP, you level up and it starts back at 0). Leveling up increases your stats (str, int, vit, hp, mp, etc), depending on the class you're using and your character is thus permanently stronger.

You gain EXP in combat, by taking actions (so, healing, attacking, etc). You get different amounts based on the action and its outcome (roughly speaking, killing someone will give you a bonus and healing actions generally give you more than a regular attack action, since healers can't kill anyone).

You could theoretically level to 99 in a single battle, but that would be ridiculously time consuming (you get less EXP if you are of higher level than the thing you're healing/attack). For those familiar with FFT, you know the best way to level (without weird strategies) is actually to beat/heal your own people, as their levels keep going with yours, while the enemies usually don't level up much in a single battle. That's actually still possible within our system (if people want to game things, it's on them and we don't want to curb their play style).

At the same time, most battles have the enemies level always match yours, up to a maximum. So, if you really need to grind, you can eventually grind past the enemies, but at the same time, if you're a completionist and doing everything the game has to offer, it doesn't mean you'll necessarily jump above everything in levels (which tends to be boring).

AP is used to purchase abilities for classes (more on classes and abilities later). Without getting into the details yet, getting AP is what will allow you to use and equip more abilities, which in turns makes you more powerful and versatile in combat. At the end of the day, a lot of the fun of tactical RPGs is learning new abilities and customizing your warriors with specific sets of abilities and passives to achieve an exciting fighter that represents a style YOU find interesting. So AP is important Smiley

You earn AP only at the end of a battle. The amount you earn is more or less fixed, but varies somewhat per map, per story completion and if you earn some special bonuses. The idea is that you can't just sit in a battle and endlessly grind AP. Enemies levels might keep up with yours up to a point, but if you grind AP, enemies AP wouldn't necessarily follow, so things would get out of whack fairly fast. So, you need to run a full battle to get some AP, which reduces the need/want to grind, but also makes it so you won't get it quite as fast. To compensate, the AP requirements of abilities is, in general, much less that it was in a game like FFT, comparatively.

Another thing we're trying to achieve is to encourage the player to use more recruits than they normally would. So, you can only field 6 troops during any battle, which in turn means that most people will only bother creating 6 characters they care about and only use those. We have lots of classes and options for the player to discover, so in a bid to increase their options, we're making it more attractive to have more than the base 6 characters you care about.
To do that, we're using a system akin to the new XCOMs' infirmary system, where characters that die in combat sustain injuries and need to rest in camp to recover from them. The system isn't too crippling at this point: you get a 10% malus to all stats for every injury you have and you get 1 injury from dying in combat. You can still go in combat with an injury, but you'll sport that -10% to stats. Or, you can rest for 1 battle (meaning you don't participate) and you'll recover.
We're hoping that will encourage the player to have more than only the 6 basic troops and setup a rotation for them.
To help with that aspect, players will get AP on all benched troops at the end of combat, not just participants. Participants will get a bonus AP, so they'll still be ahead, but your benched people will be able to keep up/catch up if you so desire.

I think that covers the EXP, AP stuff. Next... classes Smiley
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #14 on: July 01, 2017, 12:13:43 PM »

Classes

First thing to mention, is that our class system is going to be very reminiscent to Final Fantasy Tactics to most players.
That was actually one of our goals. Not only do we think FFT's class system is probably the best one out there out of all tactical RPGs, but it's also very popular and we think a lot of people are going to be happy to get an improved/revamped version of it.

Let's go over the basics:
There are over 20 different classes in the game.



A character isn't locked into a specific class, but can change at any time they can access the menu, provided they meet the requirements for another class

Class requirements are primarily based on knowing enough abilities from other classes (to unlock Wizard, you need to know 2 Healer abilities, for example).

Every class learns a certain amount of active abilities (usually 7, but some classes have more), 2 passive abilities and 1 counter ability.

The player learns abilities by spend AP points. Each ability costs a specific amount of AP and the player must follow a skill tree to acquire them (so, to buy your last ability, you'll need to have purchased a certain number of previous abilities). This helps with creating a progression for the abilities.


-- Design notes tangent --
As an example, FFT had very hefty MP costs for stronger abilities (or sometimes just hefty AP costs), so even if the player learned Firaga first on a Black Mage, they still couldn't cast the spell, at it would be gated by their max MP, which in turn was gated by equipment, which in turn was gated by Story progression.

At the end of the day, it's important to gate things, so you offer a progression to the player and you ensure they keep having something to strive for. If you started with the absolute best gear in the game, you might not ever bother checking out shops or opening treasure chests, as you wouldn't be looking forward anything.

But at the same time, a case can be made that gating/controlling things too much makes the player feel like they are "on rails" and that their gameplay decisions aren't very meaningful. Also, without a little randomness being possible, replays can easily be stale and the progression too repetitive.

So, a balance must be struck. In our case, we're using the skill tree to gate the 'very best abilities' on a class, but at the same time, about 50% of the skill tree (generally) can be skipped if you want to race to a specific ability, so it's striking a decent balance of making sure the player has things to look forward and that they have a lot of control over what they can pick next. Coupled with specific mana costs, ap costs and the unlocking requirements of classes, we have a lot of knobs and levers to adjust to try to find a great balance in that respect. Hopefully, we're succeeding Smiley
-- End of tangent --

So, when a character is a Mercenary, they have access to the Mercenary abilities they have learned through "War Craft", the Mercenary's abilities group.

But, to allow for customization of your characters, you can also equip 1 ability group for any other class you have access to, and thus be able to use their abilities (if you have learned them). So, you could equip "Lay Waste", from the Sorcerer on your Mercenary, giving you some very different options in combat.

On top of that, you have access automatically to the 2 passives of your current class, assuming you have learned them. Mercenaries have access to Sturdy Grip (allows you to use a 2Handed weapon in 1 hand) and Heavy Blows (increases critical damage by 50%), which means that as long as you learn these passives, they will always be active if you are currently a Mercenary.

But, we mentioned customization and how we like to give the player a lot of that... So you can also equip 2 passives of your choosing from any you learned (and that you aren't already equipped with). So, say you learned Dual Wielding from the Assassin class and Know Weakness from the Ranger (that increases your Critical Hit chance)

Now, you're dual wielding 2 2Handed Mauls and have a base critical chance of 20% on each and they do 50% more critical damage. Ouchies!

Lastly, you can equip a counter ability from any you know from any of your classes. Counter abilities activate upon certain conditions being met, usually involving you getting smacked around.

(White abilities are those that you can change, gray ones are those that are tied to your current class and can't be changed, unless you change classes).

As mentioned, the class system should be very reminiscent of FFT, but with some revamping and modifications. We're using the Tactics Ogre concept where you start the battle with 0 MP and it builds up every turn, so you can't just unleash your absolute best attacks immediately (at least not without special setup, as there are passive and active abilities centered around restoring/providing MP), but also your mages don't become dead weight in a protracted battle either.

The final note about the class system is that we're also adding secret classes, that must be unlocked using a craftable item. Using the item will unlock the class only for 1 specific person, but once the class is unlocked for them, it is always available (so you don't need to expand further items on that person).

Another one of our goals has been to make non-story recruits still an attractive proposition, rather than just stacking story characters, since they usually come with a custom special class. We want people to be able to use story characters if they want to (they have a special sprite and usually a special class, so they should be fairly attractive), but also to feel like they're not being silly if they decide to keep around their trusted recruit they made on the very first town if they want to. To that effect, some of the special classes that require items are only available to non-story recruits (for example, one such class could be, say, the Lich class... Do you *really* want your protagonist to be a Lich anyways? Creepy...)

I think that's the basics of our class system and of the various design choices we faced when we set it up. Let me know if you have questions or suggestions! Smiley
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #15 on: July 05, 2017, 10:17:45 AM »

Map Making Process

Here I'll detail the process our artist uses to create a new map.

First, we create a 'design map' of the level. That contains the general layout of the level, including tile heights and blocked area. Our artist will then add a few visual cues to that map, to start planning for her hand-drawn version of it.



Next, our artist will create a hand drawn version of that map, adding a lot of details. In the early days of the project, we used some 'isometric paper' to help with that process, but we later realized that that paper was actually not very reliable, as minute printing errors/inaccuracies (of which that paper was full of) on something so small would throw things off by (too) many pixels in game. So now we have a premade grid png that is 30x30 'tiles' and we rely on that exclusively to make sure the image is lined up correctly.



Next step, our artist will use photoshop to create the final map version from her scan (note that the background is actually not baked in that image, as we usually have a 'moving' background for most map, as well as different backgrounds depending on the time of day, etc).



Finally, we add 'props' to the map (props are objects on the map that will generally speaking need to be shown over/under sprites depending of their position on the map, but it could also just be objects that are generic enough that we want to reuse on other maps, such as rocks, boulders, bushes, etc)



The last step to getting a functional map in the game is to run it through our map editor and create the layout/etc (see: https://forums.tigsource.com/index.php?topic=61403.msg1340157#msg1340157).
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
Ashedragon
Level 2
**



View Profile WWW
« Reply #16 on: July 05, 2017, 06:46:32 PM »

Very interesting. Looking forward to seeing where this goes!
Logged

Czerkas
Guest
« Reply #17 on: July 06, 2017, 08:57:23 AM »

Looks very interesting.As a huge FFT fan,I'm pretty much sold on the game.I love the artstyle but the sprites are hard to differeniate from the map.I'm not criticising the pixel art(which is great BTW) but they need to stand out from the environment.
Logged
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #18 on: July 06, 2017, 09:52:46 AM »

Looks very interesting.As a huge FFT fan,I'm pretty much sold on the game.I love the artstyle but the sprites are hard to differeniate from the map.I'm not criticising the pixel art(which is great BTW) but they need to stand out from the environment.

Hi Smiley

Thanks for the kind words! We're huge fans of FFT here too and I think we have a good chance at delivering something the fans will enjoy Smiley

Differentiate sprites: I admit I'm not seeing it myself. Do you think you could point to a specific screenshot where you think the issue is pronounced? That would help me understand better I think Smiley

Thanks! Smiley
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
6 Eyes Studio
Level 0
**


Fell Seal


View Profile WWW
« Reply #19 on: July 09, 2017, 07:04:32 AM »

Request for Opinions

Hi!

If possible, I'd like to get some opinions and feedback from everyone!


Looking at this image, you can see that we're using the standard tactics "walking in place" animation for the characters when they are not engaging in any specific actions.

We went for this approach for 2 reasons:
- It's one less animation to create for sprites, which translates to several hundred less frames to draw over the whole game.
- It's the way all the classics handled it and we are trying to recapture that vibe.

That being said, we've been getting more people than we expected complaining about it (wanting a dedicated idle animation), so I'm wondering what everyone's opinion is about those visuals? (The GIF also cuts on frames, so things will be even jerkier there than the videos).

Feedback/comments are quite welcome, thanks! Smiley
Logged

Fell Seal: Arbiter's Mark, Tactical RPG for PC.
https://www.fellseal.com/
Pages: [1] 2 3
Print
Jump to:  

Theme orange-lt created by panic