Yes, it's been awhile since we posted. We are not dead... completely. Much has happened in the past week or so. Here is a brief overview:
-NASA announced the discovery of an Earth-like planet only 1400 light-years away
-Bruce/Caitlyn Jenner said some shit
-Miranda Lambert and Blake Shelton are getting divorced
Now, on the Bevontule development front:
-Several days were spent downloading a new Unity demo (and Unity 5.1.2 grooooan), which provided us with a few new character models/terrains/ideas. This was a truly painful experience for a number of reasons, but without getting into too much detail, we have a pretty kick-ass model for Apolith, which we will show at some point... maybe. One day.
-Random battle transitions are now working properly (mostly), including the BattleZone framework (discussed in a previous post). This allows us to assign 'areas' within the world map, which describe the type of enemies to be encountered there as well as their probabilities of being encountered. Additionally, the encounter rate can be set as well. Once battle is completed, the character is returned to the original position in the world map. However, if only one character survives the battle, the game goes into an infinite loop for some reason. I maintain that this is a feature.
-A new animator framework has been implemented using the override controllers discussed in a previous post as well. This is a pretty huge deal. Without going too much into it, we can use the same controller for literally every character. Huge savings on memory, runtime performance, complexity, et cetera, which are things we all like.
-The combat turn bar has been completely reworked. Characters now execute their abilities correctly and this is reflected in the turn bar. There will definitely be a battle video in the upcoming week or so showing this.
-Targetable enemies/allies now glow/highlight when they can be targeted. Previously, there was no indication of which enemies you could target aside from looking inside the target area itself. Now there is.
-We have greatly expanded our list of assets/animations/materials et cetera. Yes, money was spent. We are not happy about it. But it was necessary. I mean, really, having a roof above your head isn't uh... that important, is it?
-Much research has been done in terms of scene optimization, including object batching, light map/light probe creation and utilization. This will probably cause us to redo some of our scenes from the ground up, but it will be well worth it (we've noticed framerates tanking pretty hard in certain situations).
-The scene for Molsha (our first real 'dungeon') has been created and we're both working through what that should look like. It's pretty sweet. I'm not biased though.
Talk to ya'll in a month or so!
Friday, July 24, 2015
Friday, July 17, 2015
Skillz
In this tumultuous economy, it has never been more important to have marketable skills. Whether you are the only person in the world who can successfully emulate Mel Blanc's Porky Pig or you're a little skinny asian guy that can eat 140 hot dogs in one sitting, it has never been more important to carve out your own little niche and follow your dreams.
For the residents of Onich, this is no different. Actually, it's way different. The job market in Onich is absolute shit these days (thanks Obama) and there aren't really any hot dogs to speak of. But that does not stop them from trying. And eating.
So, what does an RPG skill system typically consist of? Well, you have your actual skills, first of all. Each individual skill possesses a number of attributes. For instance, Bodom has a skill called Lunge. This skill, like all active skills, has the following attributes (this will be simplified):
(Area of Effect) - Is typically circle, line or cone. This describes the 'shape' of the skill. Lunge has a line-based area of effect. Internally, these are sphere/box/mesh colliders.
(Target(s)) - Indicates who will be affected by this skill. Possible choices are enemies, allies, self, all, et cetera. In the case of Lunge, the target type is enemy.
(Damage Type) - Either physical or magical. In Lunge's case, the type is physical.
(Scaling attribute) - Represents the character attribute(s) that affect the damage done by this skill. In most cases, physical damage uses STR (strength) and magical damage uses INT (intellect), but these are not guaranteed. (Healing spells scale off the user's INT and the target's RES (resilience)). In the case of Lunge, this is STR.
(Modifier) - Represents the base modification value for the attribute(s) used by this skill. In Lunge's case, this value is 1.00x. This means that the typical physical damage formula is applied using Bodom's actual STR value.
(Description) - Straightforward. Represents additional effects or benefits that the skill provides. For instance, Lunge's additional effect is that it moves Bodom along its target area of effect until he collides with the targeted enemy OR another enemy.
(Charge Time) - Little bit of background: there are two time/interval-keeping mechanisms in battle. The first is a turn, which is straightforward and represents everything a character does after his turn has begun and before ending it. The second is a cycle, which begins once the fastest character begins his turn and ends once the slowest character has ended his turn. A turn is 1 unit, but a cycle elapses once a turn has occurred for every combatant. Five combatants, five turns in a cycle.
Anyhow, the point of this is that ability charge times are measured in turns: Basically, the first number in the charge time represents the 'charge count', which is how many units of charge gained each time a turn elapses. The second number represents the 'charge total', which is the number of units that must be accumulated in order for the ability to execute.
For instance, Bodom's ability Lunge has a charge time of 1/2. This means that on Bodom's turn, if he chooses to use Lunge, this ability will effectively enter a 'queue'. Once two turns have elapsed, Bodom's skill will execute. To continue, the user's own turn counts as well. So, when Lunge is used, it enters the queue with a charge time of 1/2 already. Basically, once one more turn has elapsed, Bodom will execute the ability. This is where the concept of combos come in, because executing an ability also counts as a turn.
For example, say that the person acting after Bodom had an ability that also cost 1/2 and he uses it on his turn. Since a turn has elapsed, Bodom's charge time will move from 1/2 to 2/2 and the subsequent character's charge time will move from 0/2 to 1/2 (Remember, all abilities enter the queue with one unit of charge. Once Bodom's ability enters 2/2 and is executed, this will count as another turn, which will then boost the subsequent character's charge time from 1/2 to 2/2, at which point, the subsequent character's ability will execute. Basically, abilities that are executed in this back-to-back manner inflict extra damage (at a minimum) and depending on the skill, other effects as well.
To continue, basic attacks have implicit charge times of 0/0, thus, they will always execute immediately once they are selected ahead of anything else in the queue. This is much easier to show than to explain and hopefully there will be another battle system video showing this (It's implemented, but not particularly pleasing to look at.)
(SP Cost): The 'cost' to use this skill in battle. Every character has a finite number of SP (skill points) that are consumed when a skill is used. For Lunge, uh... I don't know what the hell it costs yet.
(EP Cost): The 'cost' to equip the skill for use in battle. Basically, in addition to SP, each character has another attribute called EP. The purpose of this attribute is so limit the number of skills that a character may equip and use freely in battle at once. For example, Bodom starts out with something like 5 EP. If Lunge costs 2 EP, but another ability costs 4 EP, he cannot equip them both at once. EP, along with SP, increase as the character levels up.
(AP Cost): Yet another cost. This represents the amount of AP needed to actually 'unlock' the ability to even gain access to it. You can think of all these costs as 'gates'. Do you have enough AP to unlock the ability? OK, you unlocked it. Do you want to equip it and do you have enough extra EP? OK. Finally, do you want to use it in battle at a particular moment? Do you have enough SP? Jesus, this sounds like some bureaucratic shit. Also, AP is accumulated on a per-battle basis along with EXP and can be used at any time outside of combat to unlock abilities.
Now that we have all of that out of the way, there are multiple flavors of abilities: you have your actives (can be used directly in battle and in some cases, outside of battle) battle passives (grant an additional effect while in battle, but are not 'used', ie, do not have SP costs. They do, however, still have EP/AP costs.), world passives (Same as before, but these passives apply globally. For instance, a passive that reduces enemy encounter rates OR increases the amount of money obtained from enemies, et cetera.) and special abilities, which are essentially actives/passives with much stronger effects (and larger costs/charge times).
So, how do you actually go about obtaining abilities? Each character has access to a unique set of abilities, and specifically, each character has a specific 'skill tree'. Again, pretty standard. Basically, the skill tree is a group of nodes (skills) that are connected by different branches. I drew a picture of this once, but I don't know what happened to it, so...
Also, I'm sick of writing and I need more coffee. We'll continue this another day...
For the residents of Onich, this is no different. Actually, it's way different. The job market in Onich is absolute shit these days (thanks Obama) and there aren't really any hot dogs to speak of. But that does not stop them from trying. And eating.
So, what does an RPG skill system typically consist of? Well, you have your actual skills, first of all. Each individual skill possesses a number of attributes. For instance, Bodom has a skill called Lunge. This skill, like all active skills, has the following attributes (this will be simplified):
(Area of Effect) - Is typically circle, line or cone. This describes the 'shape' of the skill. Lunge has a line-based area of effect. Internally, these are sphere/box/mesh colliders.
(Target(s)) - Indicates who will be affected by this skill. Possible choices are enemies, allies, self, all, et cetera. In the case of Lunge, the target type is enemy.
(Damage Type) - Either physical or magical. In Lunge's case, the type is physical.
(Scaling attribute) - Represents the character attribute(s) that affect the damage done by this skill. In most cases, physical damage uses STR (strength) and magical damage uses INT (intellect), but these are not guaranteed. (Healing spells scale off the user's INT and the target's RES (resilience)). In the case of Lunge, this is STR.
(Modifier) - Represents the base modification value for the attribute(s) used by this skill. In Lunge's case, this value is 1.00x. This means that the typical physical damage formula is applied using Bodom's actual STR value.
(Description) - Straightforward. Represents additional effects or benefits that the skill provides. For instance, Lunge's additional effect is that it moves Bodom along its target area of effect until he collides with the targeted enemy OR another enemy.
(Charge Time) - Little bit of background: there are two time/interval-keeping mechanisms in battle. The first is a turn, which is straightforward and represents everything a character does after his turn has begun and before ending it. The second is a cycle, which begins once the fastest character begins his turn and ends once the slowest character has ended his turn. A turn is 1 unit, but a cycle elapses once a turn has occurred for every combatant. Five combatants, five turns in a cycle.
Anyhow, the point of this is that ability charge times are measured in turns: Basically, the first number in the charge time represents the 'charge count', which is how many units of charge gained each time a turn elapses. The second number represents the 'charge total', which is the number of units that must be accumulated in order for the ability to execute.
For instance, Bodom's ability Lunge has a charge time of 1/2. This means that on Bodom's turn, if he chooses to use Lunge, this ability will effectively enter a 'queue'. Once two turns have elapsed, Bodom's skill will execute. To continue, the user's own turn counts as well. So, when Lunge is used, it enters the queue with a charge time of 1/2 already. Basically, once one more turn has elapsed, Bodom will execute the ability. This is where the concept of combos come in, because executing an ability also counts as a turn.
For example, say that the person acting after Bodom had an ability that also cost 1/2 and he uses it on his turn. Since a turn has elapsed, Bodom's charge time will move from 1/2 to 2/2 and the subsequent character's charge time will move from 0/2 to 1/2 (Remember, all abilities enter the queue with one unit of charge. Once Bodom's ability enters 2/2 and is executed, this will count as another turn, which will then boost the subsequent character's charge time from 1/2 to 2/2, at which point, the subsequent character's ability will execute. Basically, abilities that are executed in this back-to-back manner inflict extra damage (at a minimum) and depending on the skill, other effects as well.
To continue, basic attacks have implicit charge times of 0/0, thus, they will always execute immediately once they are selected ahead of anything else in the queue. This is much easier to show than to explain and hopefully there will be another battle system video showing this (It's implemented, but not particularly pleasing to look at.)
(SP Cost): The 'cost' to use this skill in battle. Every character has a finite number of SP (skill points) that are consumed when a skill is used. For Lunge, uh... I don't know what the hell it costs yet.
(EP Cost): The 'cost' to equip the skill for use in battle. Basically, in addition to SP, each character has another attribute called EP. The purpose of this attribute is so limit the number of skills that a character may equip and use freely in battle at once. For example, Bodom starts out with something like 5 EP. If Lunge costs 2 EP, but another ability costs 4 EP, he cannot equip them both at once. EP, along with SP, increase as the character levels up.
(AP Cost): Yet another cost. This represents the amount of AP needed to actually 'unlock' the ability to even gain access to it. You can think of all these costs as 'gates'. Do you have enough AP to unlock the ability? OK, you unlocked it. Do you want to equip it and do you have enough extra EP? OK. Finally, do you want to use it in battle at a particular moment? Do you have enough SP? Jesus, this sounds like some bureaucratic shit. Also, AP is accumulated on a per-battle basis along with EXP and can be used at any time outside of combat to unlock abilities.
Now that we have all of that out of the way, there are multiple flavors of abilities: you have your actives (can be used directly in battle and in some cases, outside of battle) battle passives (grant an additional effect while in battle, but are not 'used', ie, do not have SP costs. They do, however, still have EP/AP costs.), world passives (Same as before, but these passives apply globally. For instance, a passive that reduces enemy encounter rates OR increases the amount of money obtained from enemies, et cetera.) and special abilities, which are essentially actives/passives with much stronger effects (and larger costs/charge times).
So, how do you actually go about obtaining abilities? Each character has access to a unique set of abilities, and specifically, each character has a specific 'skill tree'. Again, pretty standard. Basically, the skill tree is a group of nodes (skills) that are connected by different branches. I drew a picture of this once, but I don't know what happened to it, so...
Also, I'm sick of writing and I need more coffee. We'll continue this another day...
Wednesday, July 15, 2015
More Battle Details (Transitions/Enemy Leveling)
Decided to take a break from fixing up animator controllers and focus on some of the code and thinking behind battle transitions and combat in general. As it stands now, battles are currently initiated by coming into contact with an enemy character. Within actual areas (not the world map), enemies roam around freely, doing whatever it is the hell they do. This principally consists of waiting forever on the player to deliver unto them an ass-kicking.
Any character can have a series of waypoints set up (talked about in a previous post) and enemies additionally contain battle scene transitions, which are just special scene transitions that load the specified battle scene. We had toyed around with the idea of having battles take place in the exact area in which the enemies are encountered, ie, it would not load a specific battle scene.
There were drawbacks with this, mainly in that we would need to tailor our maps very carefully to ensure that areas in which enemies could be encountered were conducive to actual battles. This also posed questions with enemy/ally placement, would you have to physically collide with the enemy or just be within a certain radius for the battle to commence?
Having the battle take place in the same area would simplify a few things, too, however: we wouldn't need to load separate scenes at all. Obviously, a major drawback is that we will need to create battle scenes specifically for each area. This can be simplified, though, by loading a single scene and by creatively altering ally/enemy positioning.
As it stands now, the battle scene contains several entry transitions. We plan on having these chosen randomly--currently, this is a property of the actual battle scene transitions, which again, are contained within each enemy. Additionally, battle scene transitions contain their own screen transitions, which can be customized depending on the encounter (swirl, fadein, blur, et cetera).
Finally, each battle scene transition contains a list of the actual enemies that will actually be fought when the battle scene is loaded. These are literally the prefab names, representing the prefabs that will be loaded when positioning combatants.
When in areas, enemies can be tagged as docile or hostile, which indicates whether a particular enemy will chase the player when the player steps into a given detection radius. Other behaviors are planned as well (for instance, having a tree-like enemy that blends in with a patch of trees and jumps out when within a certain proximity. Or other ambushes (no pun intended)) When the player leaves the enemy's detection radius, the enemy will go back to whatever it was they were doing.
For simplicity, it would be nice to keep the transition loading framework the same, even when we are on the world map. Since enemies will not actually appear on the world map, we have elected to use random encounters when the player is moving around, which is pretty standard, as is our method of initiating these encounters.
We essentially use a threshold distance (say 500 units) and allow the player to move that many units on the world map before a battle can be initiated. After the character has moved this many units, for every additional 10 units, the probability of a battle occurring will increase by a certain percentage (0.25% or so). Pretty straightforward.
I guess this is a good point to stop and talk about a particularly controversial aspect of the game. Full-frontal male nudity. OK, just kidding, that isn't controversial, really.
From a philosophical standpoint, I've always felt that RPGs are a tad on the easy side (for the most part, although there are outliers). Granted, I've been out of the RPG game (redundant acronym) for quite some time, so I cannot attest to the difficulty of contemporary RPGs. Do they even still make them anymore?
There are a shit ton of options for handling difficulty in an RPG, but most challenges can almost always be overcome by grinding. For those unfamiliar, grinding is the act of repeatedly fighting enemies and increasing your level and combat stats until the enemies are vastly underpowered compared to you and your party. Grinding sucks, let's face it. At best, it can be somewhat sugar-coated and daresay I, fun--at worst, it can be the sole reason why a person decides to quit playing a particular game. (Looking at you, FF13. JK, I never even got to the grindy part.)
I was always a fan of Final Fantasy 8 (get dem pitchforks out) and particularly, the fact that enemies leveled with the character. Granted, FF8 is hardly the first or only game to have a system like this, but it stands out in my mind the most. If not for the rest of FF8's broken-ass combat systems, this might have actually helped keep the difficulty consistent.
However, even if enemies do level with the character, the character can almost always outpace them anyhow by accessing new abilities, increasing attributes, et cetera. Enemies do not typically have this level of customization, thus, the player still ends up kicking their asses usually--but they have to grind in order to do so.
For Bevontule, I would like to minimize the amount of grinding a character will have to do. Granted, every single person that makes an RPG says this but I mean it! -spit-
There are two ways in which I am wanting to minimize this: the first is to have enemy levels scale with the character, to a certain extent. For instance, the world map area between Cephaline and Auvane (the first 'playable' area) will have a specific enemy level range of something like 1 - 3. Basically, you cannot encounter any enemies outside this level within this region. (May be caveats to this...)
Additionally, the enemy levels will be determined based on the average level of the party. So you won't randomly encounter a group of Level 3 DeathShitters (this is a real enemy. You should see his concept art.) as your first combat experience. Instead, you'll most likely encounter a group of level 1 infant unicorns beanie babies. Or something.
So, if you're above level 3, what happens? The game crashes. OK, not really. Not in that case. Nothing really changes, except that you will encounter the maximum level enemies there consistently, which in this case, is 3.
Which brings me to the next thing: experience caps. I know, I don't really like this that much either, but I think it will work. Essentially, if you are fighting an enemy that is lower-level than you are, you will receive significantly reduced EXP. I'm thinking 1% or so. This means that if you are a sadist, you can still grind. But the diminishing returns make this pretty unattractive. However, this also means that you can grind to the highest possible (feasible) level in each area without a significant amount of hassle.
I'm not entirely sure how in love I am with this system, but I think we're going to go with it for now. Keeping the difficulty high is one of the foremost goals of this game--I feel like allowing for a small amount of grinding helps the player gain an advantage--but not too large of one.
Anyhow, got a little side-tracked there... back to battle transitions. Our current thinking is to essentially divide the world map into areas using various colliders. Each area will contain either a list of all enemies that can be encountered in that area with a mapping between that enemy and its encounter rate or alternately, it might make more sense to have each area store a list of lists that directly represent the enemies that you can encounter in a battle. This is basically a question of having precomputed permutations versus the game figuring out what enemies to fight dynamically. Probably makes more sense to do it the latter way (saints).
Determining the enemy levels should be straightforward... we would essentially take the average level of the party and try to set the enemy levels to something similar, while respecting the minimum/maximum level of potential enemies in that area. Honestly, this would probably just use the experience of the character directly to allow for fractional levels (not in practice; just in the computation of enemy levels). We could also use a ceil function on this to (perhaps randomly) spike an enemy level. This means that you could encounter enemies that are actually a higher-level than you. It might also make sense to set the minimum level of an enemy encounter in a particular area to the same level as your party.
For instance, let's say you got to level 4 in an area where the enemies are in the range (1-3). Good job. You are now being sued for having unlawfully gained access to our source code, and having implemented features that we ourselves do not yet have. (After you make bail, which we will pay, we're gonna have to get them changes, yaknowaddimean?)
The next area contains enemies that are in the range (3-6). Of course, it doesn't really make much sense to encounter any enemies that are level 3 because, per our shitty rules above, they will give you practically no experience. Maybe we can add something that sets the minimum level in a particular area to the level of your lowest-level party member/average. I don't really know. For that matter, the 'range' could actually just be a single number which indicates the 'spread' of the enemy levels, rather than a min/max. I'm actually not sure... hadn't really thought much about this particular case.
OK, that's enough for now. Maybe next time we'll talk about the skill system....
Any character can have a series of waypoints set up (talked about in a previous post) and enemies additionally contain battle scene transitions, which are just special scene transitions that load the specified battle scene. We had toyed around with the idea of having battles take place in the exact area in which the enemies are encountered, ie, it would not load a specific battle scene.
There were drawbacks with this, mainly in that we would need to tailor our maps very carefully to ensure that areas in which enemies could be encountered were conducive to actual battles. This also posed questions with enemy/ally placement, would you have to physically collide with the enemy or just be within a certain radius for the battle to commence?
Having the battle take place in the same area would simplify a few things, too, however: we wouldn't need to load separate scenes at all. Obviously, a major drawback is that we will need to create battle scenes specifically for each area. This can be simplified, though, by loading a single scene and by creatively altering ally/enemy positioning.
As it stands now, the battle scene contains several entry transitions. We plan on having these chosen randomly--currently, this is a property of the actual battle scene transitions, which again, are contained within each enemy. Additionally, battle scene transitions contain their own screen transitions, which can be customized depending on the encounter (swirl, fadein, blur, et cetera).
Finally, each battle scene transition contains a list of the actual enemies that will actually be fought when the battle scene is loaded. These are literally the prefab names, representing the prefabs that will be loaded when positioning combatants.
When in areas, enemies can be tagged as docile or hostile, which indicates whether a particular enemy will chase the player when the player steps into a given detection radius. Other behaviors are planned as well (for instance, having a tree-like enemy that blends in with a patch of trees and jumps out when within a certain proximity. Or other ambushes (no pun intended)) When the player leaves the enemy's detection radius, the enemy will go back to whatever it was they were doing.
For simplicity, it would be nice to keep the transition loading framework the same, even when we are on the world map. Since enemies will not actually appear on the world map, we have elected to use random encounters when the player is moving around, which is pretty standard, as is our method of initiating these encounters.
We essentially use a threshold distance (say 500 units) and allow the player to move that many units on the world map before a battle can be initiated. After the character has moved this many units, for every additional 10 units, the probability of a battle occurring will increase by a certain percentage (0.25% or so). Pretty straightforward.
I guess this is a good point to stop and talk about a particularly controversial aspect of the game. Full-frontal male nudity. OK, just kidding, that isn't controversial, really.
From a philosophical standpoint, I've always felt that RPGs are a tad on the easy side (for the most part, although there are outliers). Granted, I've been out of the RPG game (redundant acronym) for quite some time, so I cannot attest to the difficulty of contemporary RPGs. Do they even still make them anymore?
There are a shit ton of options for handling difficulty in an RPG, but most challenges can almost always be overcome by grinding. For those unfamiliar, grinding is the act of repeatedly fighting enemies and increasing your level and combat stats until the enemies are vastly underpowered compared to you and your party. Grinding sucks, let's face it. At best, it can be somewhat sugar-coated and daresay I, fun--at worst, it can be the sole reason why a person decides to quit playing a particular game. (Looking at you, FF13. JK, I never even got to the grindy part.)
I was always a fan of Final Fantasy 8 (get dem pitchforks out) and particularly, the fact that enemies leveled with the character. Granted, FF8 is hardly the first or only game to have a system like this, but it stands out in my mind the most. If not for the rest of FF8's broken-ass combat systems, this might have actually helped keep the difficulty consistent.
However, even if enemies do level with the character, the character can almost always outpace them anyhow by accessing new abilities, increasing attributes, et cetera. Enemies do not typically have this level of customization, thus, the player still ends up kicking their asses usually--but they have to grind in order to do so.
For Bevontule, I would like to minimize the amount of grinding a character will have to do. Granted, every single person that makes an RPG says this but I mean it! -spit-
There are two ways in which I am wanting to minimize this: the first is to have enemy levels scale with the character, to a certain extent. For instance, the world map area between Cephaline and Auvane (the first 'playable' area) will have a specific enemy level range of something like 1 - 3. Basically, you cannot encounter any enemies outside this level within this region. (May be caveats to this...)
Additionally, the enemy levels will be determined based on the average level of the party. So you won't randomly encounter a group of Level 3 DeathShitters (this is a real enemy. You should see his concept art.) as your first combat experience. Instead, you'll most likely encounter a group of level 1 infant unicorns beanie babies. Or something.
So, if you're above level 3, what happens? The game crashes. OK, not really. Not in that case. Nothing really changes, except that you will encounter the maximum level enemies there consistently, which in this case, is 3.
Which brings me to the next thing: experience caps. I know, I don't really like this that much either, but I think it will work. Essentially, if you are fighting an enemy that is lower-level than you are, you will receive significantly reduced EXP. I'm thinking 1% or so. This means that if you are a sadist, you can still grind. But the diminishing returns make this pretty unattractive. However, this also means that you can grind to the highest possible (feasible) level in each area without a significant amount of hassle.
I'm not entirely sure how in love I am with this system, but I think we're going to go with it for now. Keeping the difficulty high is one of the foremost goals of this game--I feel like allowing for a small amount of grinding helps the player gain an advantage--but not too large of one.
Anyhow, got a little side-tracked there... back to battle transitions. Our current thinking is to essentially divide the world map into areas using various colliders. Each area will contain either a list of all enemies that can be encountered in that area with a mapping between that enemy and its encounter rate or alternately, it might make more sense to have each area store a list of lists that directly represent the enemies that you can encounter in a battle. This is basically a question of having precomputed permutations versus the game figuring out what enemies to fight dynamically. Probably makes more sense to do it the latter way (saints).
Determining the enemy levels should be straightforward... we would essentially take the average level of the party and try to set the enemy levels to something similar, while respecting the minimum/maximum level of potential enemies in that area. Honestly, this would probably just use the experience of the character directly to allow for fractional levels (not in practice; just in the computation of enemy levels). We could also use a ceil function on this to (perhaps randomly) spike an enemy level. This means that you could encounter enemies that are actually a higher-level than you. It might also make sense to set the minimum level of an enemy encounter in a particular area to the same level as your party.
For instance, let's say you got to level 4 in an area where the enemies are in the range (1-3). Good job. You are now being sued for having unlawfully gained access to our source code, and having implemented features that we ourselves do not yet have. (After you make bail, which we will pay, we're gonna have to get them changes, yaknowaddimean?)
The next area contains enemies that are in the range (3-6). Of course, it doesn't really make much sense to encounter any enemies that are level 3 because, per our shitty rules above, they will give you practically no experience. Maybe we can add something that sets the minimum level in a particular area to the level of your lowest-level party member/average. I don't really know. For that matter, the 'range' could actually just be a single number which indicates the 'spread' of the enemy levels, rather than a min/max. I'm actually not sure... hadn't really thought much about this particular case.
OK, that's enough for now. Maybe next time we'll talk about the skill system....
Saturday, July 11, 2015
Animator controllers
WARNING: LONG, BORING POST AHEAD
On my end of things, I decided to pretty much break everything that had been working. OK, I didn't decide this, rather it was forced upon me in the form of a botched Unity merge in which it decided to strip all of the animations from the various controllers I had worked on up to this point. An animator controller is something that essentially holds all of the animations for a given character and is responsible for... you know, why talk about it when I can just show it to you (fellas, do not try that line on the ladies... it does NOT work):
Within Unity, this is what the animator controller for say, Bodom, looks like. Or looked like. Let's be honest... something like this is not really sustainable (this is just for ONE cutscene, really) and the fact that Unity fubar'd all of the animations (literally set them all to None) was pretty much all the reason I needed to redo this thing.
So that's what I've been doing for the past few days. It's sucked. Not gonna lie. I cried seven times. But it has been entirely necessary and will actually make things much better. I've learned quite a bit as well and am going to talk about some of these Unity concepts that have made our lives easier.
The first is the concept of avatar masks/layers. While cobbling together our animations, we have had to make due with a lot of... uh... imperfections (tamest PG word I can think of atm). For instance, you have an animation of a guy laying something down on a table, but for some reason, he decides to slide his legs in about the most unnatural way possible, while still somehow not incurring any significant medical trauma.
But, as it turns out, the part where he actually places the thing on the table is golden (his upper body/arms/head)... in fact, if I could just use that portion of the animation and leave the legs straight, I'd be one happy fella.
And with masks/layers, that's exactly what you do. You designate a layer for each animation state (one of the little gray boxes in the previous picture). For instance, we have layers for all of the major body parts: head/arm/torso/leg/hands. With a little bit of caressin' and sweet-talking, Unity can be coerced into allowing this to work. For instance, for the PlaceObject state, we have the legs/feet/root position being controlled by the Idle animation, while the rest of the body is controlled by the PlaceObject animation. The result is much more natural and smooth than it was before (previously we had just relied on people not looking at the bottom half of the screen so that they could not see the legs and/or blindfolds/duct tape.)
The other cool thing about this is that we are using the Idle animation to control the legs, but we could easily change this to another animation. For those unfamiliar, an Idle animation is basically a 'default' animation in which the character is standing in a neutral pose. (Like how you'd stand at the BMV on a hot day with lots of people... ok, this is probably more of a Pissed animation, but still.)
So if we want our characters to be sitting in a chair instead of standing, we can make that happen. And then any animation state that the character can use while standing, they can also use while sitting. Pretty cool, huh?
OK, so, I lied to you, it's not quite that simple. There is still one other crucial ingredient that is missing, and this little SOB is known as an Animator Override Controller (terse, huh?). We're gonna call this an AOC for future reference... actually, let's just go with SOB. Before I tell you about this SOB, we're gonna talk about why we need him.
Each state (any of the gray boxes up there) contains several key pieces of information: the animation clip to play, the speed at which to play it, whether Foot IK is used (ALWAYS ENABLE THIS... er, sorry, got carried away...) and a few other things. This is where we would specify the Idle animation or the Sitting animation. It looks like dis, as an example:
Easy then. We just make a whole new controller and replace every Idle animation with our Sitting animation. Woo. Time to have a beer.
Not so fast though, ya drunk bastard. Let's say we want to be able to perform these animations from other states... laying down, crouching. Let's say we want to be able to wave, but we want to be able to do it while we're walking and/or running. Maybe we want to have Bodom ride a unicycle while snorting a line of coke off the top of the accordion he is playing. (DLC anyone?)
All right, well, we'll just make a separate animator for every single... uh...situation... yeah. No, we're not going to do that. Granted, this was sadly the original plan going forward: make a different animator controller for each character and each cutscene (you'll notice the first picture refers to a AtoniaOutside animator controller.) Yeah, that's bad. Real bad. But as any real-world programmer knows, you basically do things the worst way possible until a certain point. This is the "Does-It-Work? No. Does it work now? Yes. Rewrite it." paradox.
Trust me, if we could have gotten by with having multiple controllers, I would have gladly done it. But we can't. So, the question this really forces you to ask is... is it possible to have everyone use the same animator controller? Wouldn't it be nice to just have one of those sitting around instead of having one for every character/cutscene/blood type etc?
And as it turns out, you can. (You're 2/2, Unity, on answering questions with satisfactory responses.) And we can do it using this SOB thingamabobajig that was spoken of earlier. While it does have a rather ridiculous and intimidating name, it's actually quite simple.
We make a new SOB and we say, use a specific controller. In the current redesign, we have one controller called "Generic" that contains ALL of the animations that any character can perform. We hook this up to our little SOB here, which looks like this:
As you can see, this thing contains every animation state and clip present within the "Generic" animator controller. This means that all we have to do to replace this is to change the "Idle" animations above to "Sitting". And from there, we will have birthed a character whose default state is "Sitting" and who can then perform any of the actions above from a sitting pose and not a standing pose.
The only drawback to this is that it broke nearly every damn cutscene we have made. Fortunately, there are only about five or six thus far (and I have become rather adept at fixing them). But you gotta break a few eggs to make a chicken or something along those lines.
I know that's a lot for just a small portion of our development, so we'll save the other junk for another day. Thanks for reading!
The first is the concept of avatar masks/layers. While cobbling together our animations, we have had to make due with a lot of... uh... imperfections (tamest PG word I can think of atm). For instance, you have an animation of a guy laying something down on a table, but for some reason, he decides to slide his legs in about the most unnatural way possible, while still somehow not incurring any significant medical trauma.
But, as it turns out, the part where he actually places the thing on the table is golden (his upper body/arms/head)... in fact, if I could just use that portion of the animation and leave the legs straight, I'd be one happy fella.
And with masks/layers, that's exactly what you do. You designate a layer for each animation state (one of the little gray boxes in the previous picture). For instance, we have layers for all of the major body parts: head/arm/torso/leg/hands. With a little bit of caressin' and sweet-talking, Unity can be coerced into allowing this to work. For instance, for the PlaceObject state, we have the legs/feet/root position being controlled by the Idle animation, while the rest of the body is controlled by the PlaceObject animation. The result is much more natural and smooth than it was before (previously we had just relied on people not looking at the bottom half of the screen so that they could not see the legs and/or blindfolds/duct tape.)
The other cool thing about this is that we are using the Idle animation to control the legs, but we could easily change this to another animation. For those unfamiliar, an Idle animation is basically a 'default' animation in which the character is standing in a neutral pose. (Like how you'd stand at the BMV on a hot day with lots of people... ok, this is probably more of a Pissed animation, but still.)
So if we want our characters to be sitting in a chair instead of standing, we can make that happen. And then any animation state that the character can use while standing, they can also use while sitting. Pretty cool, huh?
OK, so, I lied to you, it's not quite that simple. There is still one other crucial ingredient that is missing, and this little SOB is known as an Animator Override Controller (terse, huh?). We're gonna call this an AOC for future reference... actually, let's just go with SOB. Before I tell you about this SOB, we're gonna talk about why we need him.
Each state (any of the gray boxes up there) contains several key pieces of information: the animation clip to play, the speed at which to play it, whether Foot IK is used (ALWAYS ENABLE THIS... er, sorry, got carried away...) and a few other things. This is where we would specify the Idle animation or the Sitting animation. It looks like dis, as an example:
Easy then. We just make a whole new controller and replace every Idle animation with our Sitting animation. Woo. Time to have a beer.
Not so fast though, ya drunk bastard. Let's say we want to be able to perform these animations from other states... laying down, crouching. Let's say we want to be able to wave, but we want to be able to do it while we're walking and/or running. Maybe we want to have Bodom ride a unicycle while snorting a line of coke off the top of the accordion he is playing. (DLC anyone?)
All right, well, we'll just make a separate animator for every single... uh...situation... yeah. No, we're not going to do that. Granted, this was sadly the original plan going forward: make a different animator controller for each character and each cutscene (you'll notice the first picture refers to a AtoniaOutside animator controller.) Yeah, that's bad. Real bad. But as any real-world programmer knows, you basically do things the worst way possible until a certain point. This is the "Does-It-Work? No. Does it work now? Yes. Rewrite it." paradox.
Trust me, if we could have gotten by with having multiple controllers, I would have gladly done it. But we can't. So, the question this really forces you to ask is... is it possible to have everyone use the same animator controller? Wouldn't it be nice to just have one of those sitting around instead of having one for every character/cutscene/blood type etc?
And as it turns out, you can. (You're 2/2, Unity, on answering questions with satisfactory responses.) And we can do it using this SOB thingamabobajig that was spoken of earlier. While it does have a rather ridiculous and intimidating name, it's actually quite simple.
We make a new SOB and we say, use a specific controller. In the current redesign, we have one controller called "Generic" that contains ALL of the animations that any character can perform. We hook this up to our little SOB here, which looks like this:
As you can see, this thing contains every animation state and clip present within the "Generic" animator controller. This means that all we have to do to replace this is to change the "Idle" animations above to "Sitting". And from there, we will have birthed a character whose default state is "Sitting" and who can then perform any of the actions above from a sitting pose and not a standing pose.
The only drawback to this is that it broke nearly every damn cutscene we have made. Fortunately, there are only about five or six thus far (and I have become rather adept at fixing them). But you gotta break a few eggs to make a chicken or something along those lines.
I know that's a lot for just a small portion of our development, so we'll save the other junk for another day. Thanks for reading!
Monday, July 6, 2015
Insert Title Here
Yes, I know, I missed a day. I am now pregnant.
That aside, we're going to make up for it with this post. OK, no we're not, but it sounded good. Just a few things to say today, specifically, that it is now possible to play about 10-15 minutes of the game uninterrupted. Previously we had all of these little sections finished and hadn't worried about gluing them together, but now you can play all the way through from waking up on the beach until being dumped on the world map. Granted, the 'playing' here mostly consists of cutscenes, but hey... they are done. To quote Joe Biden, this is quite a BFD.
Also messed around briefly with a few animations: specifically, I found a nice sword-sheathing animation to use for Apolith and added a ControllerBehavior script (these are basically callbacks that fire at specific moments when an animation is played) that allows Apolith to actually draw/sheath his sword. It actually looks surprisingly nice, but could be tweaked. Additionally, this framework can be extended for all characters, so that's always nice.
Andy fixed a few dialogue bugs today... specifically, issues where the dialogue bubbles would not properly follow characters as well as ironing out positioning issues in general. I believe we are now using a dedicated GameObject to handle the positioning directly, which, honestly, is a better approach than the ouija board/sextant combination we had previously relied upon.
Until next time...
That aside, we're going to make up for it with this post. OK, no we're not, but it sounded good. Just a few things to say today, specifically, that it is now possible to play about 10-15 minutes of the game uninterrupted. Previously we had all of these little sections finished and hadn't worried about gluing them together, but now you can play all the way through from waking up on the beach until being dumped on the world map. Granted, the 'playing' here mostly consists of cutscenes, but hey... they are done. To quote Joe Biden, this is quite a BFD.
Also messed around briefly with a few animations: specifically, I found a nice sword-sheathing animation to use for Apolith and added a ControllerBehavior script (these are basically callbacks that fire at specific moments when an animation is played) that allows Apolith to actually draw/sheath his sword. It actually looks surprisingly nice, but could be tweaked. Additionally, this framework can be extended for all characters, so that's always nice.
Andy fixed a few dialogue bugs today... specifically, issues where the dialogue bubbles would not properly follow characters as well as ironing out positioning issues in general. I believe we are now using a dedicated GameObject to handle the positioning directly, which, honestly, is a better approach than the ouija board/sextant combination we had previously relied upon.
Until next time...
Thursday, July 2, 2015
Waypoint Handling
Took some time today to work on something that I had been putting off for awhile. Previously, our waypoint handling system was uh... how should I say it... janky? Is that a word? To elaborate, each waypoint was essentially treated just as a separate transform and that was it really. There was no additional logic in the waypoints themselves and they were pretty much just positions at that point to be followed and switched to by the WaypointHandler logic.
This meant that, even if we wanted to do something simple, like perhaps add an optional delay before starting towards the next waypoint, it had to be done on a global basis. Rather, each waypoint belonging to a handler used the exact same delay. With the new system, we can do a lot of different things that we were previously unable to do:
-Each waypoint can have its own delay (Character walks to the edge of an overlook and takes a minute to admire the view before continuing along his way)
-Each waypoint can set an animator bool/trigger (basically allows you to play an animation at the end of a given waypoint and the character will not advance to the next waypoint until it has completed. Imagine you have a bartender who is walking around (actually, drunk herself), and you would like that bartender to pour drinks when she gets to a table of belligerent high-school-aged males on Spring Break (Was that a doubly nested parenthesis??) )
-Each waypoint can change the speed of the character when the waypoint is passed over. (See subsequent example)
-Each waypoint can call a specified method when the waypoint is passed over. (Imagine that you have a little shitty kid running to the end of a path, but he gets tuckered out because he's asthmatic, and there aren't any inhalers in Onich, nor are there really asthma diagnoses, but nevertheless, this kid feels like he is onto something and sets out to tell the world about his breathing woes. Anyhow, we can force him to walk back when he passes over the transition, by calling a custom function AND setting his speed to something lower. Not a contrived example at all, really. Happens all the time.)
There is more we can do on this front, such as using splines/curves to smooth out the turning rates of characters, but for now, it works quite nicely. The only downside now, is that all of the Cephaline NPCs need to be changed. :/
There isn't really much more to say about the world map at this point, which is the unfortunate part of working on assets. I will say that it is looking better than it did yesterday (which, if you recall, it looked pretty awesome). Here is to hoping that it looks even better tomorrow.
This meant that, even if we wanted to do something simple, like perhaps add an optional delay before starting towards the next waypoint, it had to be done on a global basis. Rather, each waypoint belonging to a handler used the exact same delay. With the new system, we can do a lot of different things that we were previously unable to do:
-Each waypoint can have its own delay (Character walks to the edge of an overlook and takes a minute to admire the view before continuing along his way)
-Each waypoint can set an animator bool/trigger (basically allows you to play an animation at the end of a given waypoint and the character will not advance to the next waypoint until it has completed. Imagine you have a bartender who is walking around (actually, drunk herself), and you would like that bartender to pour drinks when she gets to a table of belligerent high-school-aged males on Spring Break (Was that a doubly nested parenthesis??) )
-Each waypoint can change the speed of the character when the waypoint is passed over. (See subsequent example)
-Each waypoint can call a specified method when the waypoint is passed over. (Imagine that you have a little shitty kid running to the end of a path, but he gets tuckered out because he's asthmatic, and there aren't any inhalers in Onich, nor are there really asthma diagnoses, but nevertheless, this kid feels like he is onto something and sets out to tell the world about his breathing woes. Anyhow, we can force him to walk back when he passes over the transition, by calling a custom function AND setting his speed to something lower. Not a contrived example at all, really. Happens all the time.)
There is more we can do on this front, such as using splines/curves to smooth out the turning rates of characters, but for now, it works quite nicely. The only downside now, is that all of the Cephaline NPCs need to be changed. :/
There isn't really much more to say about the world map at this point, which is the unfortunate part of working on assets. I will say that it is looking better than it did yesterday (which, if you recall, it looked pretty awesome). Here is to hoping that it looks even better tomorrow.
Wednesday, July 1, 2015
More scene transition bs
OK, this really will be a short update. Worked on more scene transition bs. I can say happily that I have the previous cutscenes linked up with the playable section of Cephaline... still need to add blockers to the exits and scene transitions for buildings that are accessible (which, really, is just the pub/inn). But much progress is being made, especially on the front of figuring out little details that I had put off until the larger picture had emerged.
The world map is coming together quite nicely as well and I am excited to show off what we have in the upcoming days .Or week. Maybe.
The world map is coming together quite nicely as well and I am excited to show off what we have in the upcoming days .Or week. Maybe.
Subscribe to:
Posts (Atom)
