Recent Posts

Pages: [1] 2 3 ... 10
1
Editor Development / Re: The Sphere Studio v1.2.1
« Last post by Fat Cerberus on March 23, 2017, 01:23:57 am »
I just added a SourceMapper class to Sphere.Core to allow debugger plugins to easily remap line numbers for transpiled code.  I needed source map support to be able to switch to TypeScript in miniSphere (since it doesn't have an option to preserve line numbers), and I figured it was better to make it a generic function in the editor rather than hardcoding it into the miniSphere plugin.
2
Sphere General / Re: Sphere v2 API discussion
« Last post by Fat Cerberus on March 22, 2017, 09:53:29 am »
That's a good point; games may also want to access another game's data that it wouldn't necessarily need to share a save directory with.  I like the idea of enforcing read-only access too.  I'll add an issue on GitHub about it, thanks for the idea. :)
3
Sphere General / Re: Sphere v2 API discussion
« Last post by casiotone on March 22, 2017, 09:46:38 am »
5.0 will change the save data handling so that games no longer have to share the same save file folder.  How that works is you set a "save ID" in the JSON manifest and miniSphere uses that as the name of the folder.  If you have want to have sequels be able to share save data, you can just give them the same save ID.

I'm thinking there should be a standardized format for save IDs to avoid clashes, something like this maybe (inspired by Android app IDs):
Code: [Select]
com.authorname.gamename
Could this not be set at runtime? A game may want to have its own save directory but still be able to access previous game data.

Perhaps the game ID could be set in the manifest, but an optional one also at runtime - and enforcing read-only access if it isn't the ID in the manifest.
4
Game Development / Re: RPG battle system balancing
« Last post by Fat Cerberus on March 21, 2017, 02:52:47 am »
As a followup to the OP, one of my big pitfalls, even after discovering the linear/quadratic mismatch, was to try to finagle the caps for different things to try to work around it.  I'm telling you now: That doesn't work.  At all.  While multiplying two variables--say, skill power and user level--that both range 1-100 and grow at about the same rate is obviously quadratic, what wasn't so obvious, to me at least, is that it's still quadratic even if you change one of the variables to go from 1-20 instead.  Assuming the rate of growth remains proportional over the course of the game, the curve doesn't change at all because any value is functionally identical to a percentage of the maximum--and then you're on the same scale again.
5
Game Development / Re: RPG battle system balancing
« Last post by Fat Cerberus on March 19, 2017, 01:56:41 pm »
Wow, that's a lot simpler than the FFX formulas.  FFX actually uses a cubic factor on STR, but only a square factor on MAG for some reason.  And the Defense calculation in that game is damn near indecipherable.  I won't complain too much though, because the squaring and cubing means that small stat differences really matter.. Which does help cut down on the need for long grinding sessions.
6
Game Development / Re: RPG battle system balancing
« Last post by mezzoEmrys on March 19, 2017, 01:34:29 pm »
I personally like examining the forumlas for the weapons in Final Fantasy 12, like this formula for the greatsword:


A lot of the weapons in FF12 scale like this, with a straight (damage * random) - defense, then a multiplier from stats
7
Game Development / RPG battle system balancing
« Last post by Fat Cerberus on March 19, 2017, 12:44:26 pm »
So I had an insight the other day while struggling to balance the damage output in Spectacles.  For a while I'd been trying to balance things by changing multipliers, but no matter what I did, making one battle fair negatively impacted battles at other points in the story.  Then I realized: In a modern JRPG battle engine, input variables are normally multiplied in some fashion, not added.  Thus, the most important thing for balance is the number of variables in the formula, not the specific factors used.

It turned out that I had a fundamental imbalance due to a mismatch in the number of variables between the Max HP and damage formulas.  Max HP is a linear progression:
Code: Javascript
  1. // note: statAverage is weighted, heavily favoring VIT
  2. 25 * tier * statAverage
  3.  

All storyline bosses save for the final boss are defined as Tier 3, so that over the course of the game boss HP rises linearly, directly proportional to the stat average.  Damage on the other hand is calculated as:
Code: Javascript
  1. 2.5 * pow * weapon * str / def
  2.  

str / def, being on the same scale, cancel either other out on average.  So for this purpose we can treat the damage formula as having two variables: move power and weapon power.  Therefore, over the course of the game the damage increase is quadratic.  Depending on the factors used, that either means you do far too much damage to late-game enemies, or else not nearly enough to early ones.  In order to balance, HP also needs to be quadratic.  Without introducing a new variable in the HP formula, this can be accomplished by squaring the stat average.

Just thought I'd share this experience as it was kind of a big eureka moment for me after a long balancing struggle.  I think as amateur game developers we tend to take things like RPG battle formulas for granted, but there's actually a lot more nuance to it than it seems at first glance.
8
Engine Development / Re: miniSphere 4.5.7
« Last post by Fat Cerberus on March 14, 2017, 10:25:53 pm »
New branch policy for the Git repo: Development of the next version (right now planned as 5.0) with on "dev" branch, while "master" will be latest-stable.  Historically I've developed directly against the trunk, which is starting to delay major overhauls; by committing everything directly to master, patch releases only intended to fix bugs end up getting breaking changes too, so I end up holding off on doing them.  Which slows down development.
9
Engine Development / Re: miniSphere 4.5.7
« Last post by Zechs on March 14, 2017, 01:42:49 pm »
Agh, I did look at it and wonder if the filename was the issue, as I remember you mentioning the integration of .mjs. I didn't try it, though it couldn't have hurt.
10
Engine Development / Re: miniSphere 4.5.7
« Last post by Fat Cerberus on March 14, 2017, 01:40:03 pm »
Yeah, related to the default Cellscript having an "import" statement, which now needs it to be a .mjs file.  The new project had it named as Cellscript.js which caused it to fail.
Pages: [1] 2 3 ... 10