Archive for September 2013

The Interplay of Momentum and Pace   Leave a comment

Welcome back to Gratuitous JRPG.  Updates this week are going to be a little slow due to sleep readjustment and more attempts on my part to find gainful employment.  Last time, we covered the difficulty of writing, the necessity for outside opinions, and the matter of dealing with criticism.  As a lot of my exploits over the last month have been writing-related, it’s time to bring the subject back to game design with a couple of points.  The first has to do with momentum; not the game’s own momentum, or the plot’s, but your own momentum as a game developer, and the complications resulting from losing said momentum.  The second is something I feel would be incapable of even being approached before the outlines for the game’s plot could be laid down: pacing.

With game development, especially as a sole undertaking, momentum will be a very real thing.  It also applies with teams, but is much more apparent on single-person undertakings.   All projects require time devoted to both writing and gameplay, and as noted previously, teams will at their base split their development along the two.  A single-person project is difficult because both must be focused on, and it is naturally easier to devote one’s time and resources to one at a time.  The problem comes when it’s time to jump from one to another; momentum is lost, and the developer loses time and possibly progress as they have to sit back and take stock of what they were doing before they can determine what to do next,  It can be frustrating and

Largely thanks to the fact that I have spent around a month on writing duties alone, I too have found myself subject to momentum loss on the mechanical end, returning to it and wondering what I was working on again.  This feeling of disorientation is something that will come naturally, and is hard to completely prevent outside of working in a team.  Teams can prevent this easily through placing people in one constant role where they won’t have to jump around, but for those who aren’t or don’t want to be on one, there are two means by which to mitigate this loss of momentum.

The first of these measures is simple: if spending too much time on any one aspect makes you lose your place, then jump around more.  That way, the aspects remain fresh in your mind as you keep going back and to them.  However, this may be difficult when any particularly intensive work, such as storyboarding, comes about, which may require you to actively break into phases and in turn make it hard to build momentum to begin with.  If you can keep more momentum this way, the better.  For those who can’t, the second option is one taught early to anyone who intends to become a programmer: documentation.  Take and keep good notes on everything you make, especially if you have to take a break from it in an incomplete state.  The better notes you can put down, the faster you can get back up to speed on the project

With the issue of momentum out of the way, the next relevant subject to cover would be pacing.  When I speak of pacing, I am referring to the gameplay aspect of it.  To elaborate, in a gameplay context, I am referring to pacing as the timing, rate, and spacing of the introduction of elements of the game: character levels, skill acquisition, dungeon placement, town placement, character acquisition, and skill acquisition, alongside optional content placement.  This cannot effectively be done before the rough storyboarding–if you don’t know where the story goes, you cannot effectively place all of the gameplay elements.

After all of this is said, however, part of the problem with pacing is that it is another aspect of game design that is not a science, but an art.  There are two general extremes that are to be avoided with plot to gameplay segment pacing, but other than that, it’s largely to one’s preference.  The first of these extremes is easily identifiable by the exemplar game of its problem: Xenosaga. (Note: WordPress is being finicky and won’t let me upload the image)


Yeah, I’m going there.

Xenosaga, for those who were not paying attention to early-PS2 era JRPGs, was an attempt on Monolith Software’s part to create a spiritual retelling of Xenogears, a cult classic PSX-era JRPG that sadly had its budget fed to Final Fantasy 8.  They were, to say the least, less than successful in this endeavor for varying reasons, with Xenosaga 1 being thoroughly mocked for one thing in particular above others: an excess of cutscenes that could arguably threaten to outnumber the gameplay in sheer proportion of in-game time it took.  Furthermore, these cutscenes did not add nearly as much as they could.  In short, it is important to remember that what you are creating is not a movie or a novel, but a RPG in this case.  If you have the game dominated by cutscene after cutscene, you will either need to cut down on the cutscenes, or figure out how to work in the gameplay some more than you have; especially if the gameplay elements feel far too short.

The opposite extreme, however, is similarly undesirable.  While I generally agree with adding more gameplay to a game, there are points where it becomes less the addition of gameplay, and more a case of padding out the gameplay–filler dungeons, filler sequences, and the like.  Padding is exactly what you would imagine in this case: throwing extra meaningless content into the game to fill out the playtime more than anything.  This extends from extra dungeons, to extra bosses where there isn’t a need, to required pointless minigames that appear once in the entire game’s running time and do nothing at all but frustrate the player.  I could name examples, but I won’t; it’s essentially the video game equivalent of the Big Lipped Alligator Moment.


To be fair, I suppose anyone who can make a big-lipped singing alligator with their own trippy musical sequence actually work in the context of a game deserves some form of credit.

For equipment and skill acquisition, I will note that there is much more in the way of solid methodology for both, and note for the sake of reference that equipment that exists for the sole purpose of granting skills (in the way Sigil Crests do in this game, or Materia in Final Fantasy 7) still counts as equipment for the purposes of determining how the developer places it within the game.  In regards to skill placement, skills that are not learned through specific plot-related events that require the advancement of the game are ideally placed in a fashion that allows a new skill or upgrade to a skill on a regular basis (roughly every 1-2 dungeons.) as to continually introduce abilities and prevent characters from becoming stagnant mechanically in a JRPG–or if using a point-based learning system, enough points to facilitate learning at a similar or greater rate.  Deviation from this can occasionally happen (Labyrinth of Touhou is a notable example), but those games must be designed around that nonstandard format.  At the same time, obsolescence is a notable risk, and should be planned around if it’s in existence.

Equipment availability is something there are generally more options for, with several options for progression.  The first, and most obvious option is to have a direct upgrade to every usable weapon available every town.  This is predictable, but has a few notable drawbacks.  The first is that it’s easily predictable; you go to a town, you get new equipment every time.  The pattern can get predictable and annoying to those, wearing out the pleasant surprise that new equipment availability can give.  The second is that unless towns are less common than dungeons, there is less room for sidegrade equipment to be discovered in the latter.  This issue can be somewhat mitigated by having dungeons drop upgrades from the next area, but this is more of a stopgap fix than a solution.  The last, and most notable issue, is that this may provide issues for balance in moderate- or long games where there may be a large number of towns.  Once you get so many upgrades, it is possible to have problems if the character advancement is too slow by comparison.  If characters advance too slow and equipment advances too fast, then one of two issues is bound to occur: Either there are pointless equipment upgrades that can be skipped, or equipment begins to outstrip and overshadow characters.  Both of these outcomes are to be avoided in general.

If advancing every new town does not work, then what other methodologies are available?  The next is a staggered approach, where new equipment upgrades do not come every new town, but instead every few towns, usually with multiple dungeons in between.  This has a notable advantage over the previous method insofar that it retains the newness of equipment upgrades, and allows for sidegrade or special gear to be found within dungeons without worrying so much about perceived clutter or lack of room for these pieces of gear, and will generally can be considered the “standard” progression in many games.

Games with crafting systems are trickier to work with.  In most cases, advancement will be similar to the previous systems, excepting that instead of based on reaching the next town, it is typically based on getting access to components one hasn’t been able to before.  Due to the ability to get stronger equipment than normal if this is not the case, most crafting systems will typically either restrict materials by the area of the game or restrict equipment by level to make sure players cannot get equipment that’s comparably too strong.  An exception to both is Star Ocean 3, where crafting only was based on money and you could easily gain game-breaking equipment for the relative point in time you were at in the game for up through…two thirds to three fourths through the game.  Comparably, crafting in SO4 was restricted to materials that could be found–which is notable when the second material-gathering character could not be gained for the first third or so of the game, leaving equipment crafting largely unavailable until then.

Lastly, there are nonstandard upgrade patterns, with a few notable examples in this case.  The first example of this is the Suikoden series, where one has the potential to argue that weapons as equipment don’t exist so much as weapons as a character statistic or aspect–rather than obtain a new weapon, characters can have a blacksmith improve it one step for a price, repeated times.  More skilled blacksmiths would be needed to upgrade weapons past a certain point, notably.  Wild ARMs games past 2 also employ this concept, with character ARMs in 3, 4, and 5 being upgradable along several parameters.  Which ones were best depended on the character and the weapon in question, but this was similar in that sense (5 added a weapon slot by having ARM cartridges be an equippable type, mixing standard and nonstandard advancements).  Lastly is the third and fourth Epic Battle Fantasy series entries, where equipment in general was not a form of advancement.  All equipment was on a similar tier, but with different parameter boosts.  Each weapon and armor could be upgraded, but all pieces of equipment at the same level of upgrade were on the same tier.

To tie this in with the project as it stands, I’ve laid out the plot as it stands and am looking at around eight required towns or townlike areas (with more optional ones available for those willing to go to them) and roughly 15 required dungeons.  18-20 if you break the multipart dungeons into their components.  This means on average, counting revisits and the like, there will be roughly two towns to a dungeon.  I’m feeling that, between dungeons and overworld, PCs should level up roughly twice per combined overworld/dungeon segment, with maybe +1 level for those who go through the optional places–you can see how statistical progression would occur a few posts back.

As far as equipment goes, I want to stagger weapon availability for a large amount of early-game.  So for baseline weapons, I’ve decided there’ll be seven tiers.  This may sound like it’s roughly on par with one per town, but between revisiting at different points in the game and other events, it’ll be drawn out further than that.  Tier 1 (crappy starting) gear aside, there’ll be roughly two tiers for every third or so of the game.  The general available order for weapons by tier can be described as follows, actually.

[note: changed Caecilia’s name to Karina because I kept thinking Wild ARMs when thinking of her original name, and it was distracting me to no end.]

  • Tier 1 (very start of game): Heavy swords(Leo only, initial), Daggers(Renaud only, initial, fixed), Staves(Alexis only, initial)
  • Tier 2 (first storeboughts): Heavy swords, Daggers, Staves, Bows(Azalea only, initial, fixed)
  • Tier 3 (Available through end of first third): Heavy swords, Daggers, Staves, Bows, Spears (Valeska initial) Axes (Kiri initial, late purchase), Light Swords (Karina only, initial)
  • Tier 4-7 All weapons available for purchase–though tier 4 weapon availabilities are staggered.

Staggered availability is there for two main reasons.  The first is to introduce new weapons with new characters in part–bows open up roughly after Renaud permajoins and on Azalea’s temp form, spears open up around when Valeska joins, Axes around when Kiri joins, and you don’t see store-available light swords until after Karina joins.  This also forces players to get accustomed to most of the new weapon types, since in the first third or so, there’s always going to be at least one character who has only one available weapon option.  It’s worth noting that while armor may fall under similar tiers, other equipment types will largely -not-.  Sigil Crests are all on the same tier, and accessories and a majority of offhand items will not fall under tier progression either.  This also does not include the varied sidegrade weaponry the player will encounter in dungeons, though it’s unlikely that they’ll be sequence-breaking weapon availability either way.

All in all, pacing for a game involves a lot of moving parts.  At this point, however, I feel there’s only so much that can actually be done while the game is still in the planning phase.  For this very reason, next post I’ll be breaking the game from pre-production to a production phase, and at this point the blog will start to be more about the actual production of a RMVXA game than high-level game design.  Until then, this is Epic Alphonse, signing off.

Posted September 30, 2013 by EpicAlphonse in Uncategorized

Ragequitting: What Causes it and why not to do it   Leave a comment

Welcome back to Gratuitous JRPG.  This is Epic Alphonse, back from a writing hiatus with new content to give!  Just in time, too, since Nonfiltered’s college schedule has become soul-crushingly brutal.  Over the time I was gone, I wrote out my game’s entire storyboard.  Storyboard writing may sound simple enough, but when it’s being done for a full-length JRPG it is anything but.  Over this time I also sent it over to two people I knew to look over and critique it.  However, this will be covered later in the post.  Right now the main focus is on the storyboard.

I will have to ask forgiveness for not revealing the entire storyboard.  It takes up nine pages on a document, single-spaced, and would inflate this post’s length to measures that may well break WordPress.  The task of writing one is grueling, in-depth, and required a lot of time simply planning out the game’s pace.  And to put it bluntly for anyone trying it themselves: this is the first hell for game designers, and one of the parts where you realize everything you take for granted in a game you may play–you are going to have to plan out the entirety of the general plot.  Up to and including the transitions and   I cannot offer any advice in attempting this task on your own aside from the fact that you will have to push through it.  It may be easier for the more writing-inclined, but for the less so like myself, this will be one of the harder parts.

By the time you are done, chances are you will detest the entire thing, and want to scrap it and start over from scratch.  This is a natural product of exhaustion, and more of an indicator that you need to take a notable break.  At this point, it would be ideal to get an outside opinion and critique on your storyboard at this point.  Someone knowledgeable in writing would be ideal, though not required.  The point is to get somebody outside the development process to look at what is present and give some form of critique.  For the best results, send it in to two to three people and have them critique it separately.  More opinions help, but only to the point that they don’t start to run together.

What comes next is the hardest part of showing your work to anyone else: taking the critiques you asked for.  If you’ve felt invested in your work at all, this will be painful.  This brings me to one of my biggest points in the whole blog, so read this closely, and recite it daily.  Bookmark this post and read it again if you forget it.  You will need thick skin to survive in anything related to game development.  Or for that matter, any creative pursuit where your works are shown to a portion of the public.  If you intend to release your game, you and your work won’t simply be subject to the opinions of your peers and those you personally send work to for looking over.  In today’s world, courtesy of the internet giving everybody a voice to be heard over a long distance, many people will voice them.  A good portion of these voices will not necessarily have positive things to say.


Imagine these on you at all times.  And the more well-known you are, the more accurate they’ll get and the more of them there will be.  This is why you will need to get thick skin.

The type of statements varies depending on the person.  There is detailed feedback, that is based on the work itself–the best of which will typically have time given to it and written out in full, or at least directed as precisely as possible.  This you should look at, since there’s often something to derive from those.  Next comes the general feedback–the casual one/few-statement matters.  Take these with a grain of salt, especially if they’re not clarifying what they’re specifically talking about.  Going down the line, there’s the uninformed feedback.  Uninformed feedback does exist, and is typically a result of basing one’s opinion of the full game on the first impression–such as the first hour of the game.  Hi there, IGN and Gamespot, you may sit back down now.  If they are generally in line with each other and some of the more detailed feedback, however, there may be some substance

Then comes the feedback that is at the most, barely relevant to the game.  The first is peripheral feedback, which is when somebody outside of your standard audience has feedback on the game.  This may, for example, be a WRPG fan giving commentary on a JRPG, or a consumer of horror giving commentary on fantasy.  This can be notable if it’s insightful or from a non-core group you are attempting to reach out to, but sometimes it falls straight into the uninformed feedback bin.  Then there’s the genre-based feedback.  This is typically not worth listening to, since this sort of feedback is what occurs when you give someone who hates JRPGs a JRPG and then expect feedback from them.  It will typically result in something along the lines of “I hate this game because it’s a JRPG and it should be less of a JRPG, because as is it, and all videogames are all the worse for the sole reason of this game being a JRPG.”  Often with more colorful language.  This may, and frequently does, cross with peripheral feedback.  Ignore it.

The last category of feedback is one that has caused no small amount of problem among all sorts of people worldwide: abusive feedback.  This differs from all the other types of feedback because it is not meant to provide information.  It is somebody using feedback as a means through which to verbally attack.  This sort of feedback comes in two varieties.  The first is what is considered standard trolling–simply trying to get a reaction.  My advice for the genre-based feedback goes double for these sorts–ignore them, and whatever you do, do not respond to them in any way.  Doing so will only worsen the attacks.

To be more serious for a moment, the second type of abusive feedback is something much more vile, insidious, and sadly, prevalent in today’s world.  These are the attacks not for the sake of trying to provoke a reaction, but directly at the person, for who they are or what they’re doing.  These are the people who will throw in personal, racist, sexist, and hateful attacks.  Even worse, they will make implicit or explicit threats against one’s own person, friends, or family, and sometimes for the most petty possible reasons.  The most notable case of abuse I can think of is that of Jennifer Hepler, a writer who worked for Bioware on Dragon Age 2–who had threats leveled against herself and her children, by irate and vocal fans of the series who blamed her for the game’s problems.  This, sadly, is not an isolated incident, nor is it limited to writing.  David Vonderhaar received threats of violence for announcing a patch with minor statistical alterations to Call of Duty: Black Ops 2.  And these are just the high-profile cases.

Many other people in creative works, be it game development, writing, art, film-making, and so on, are attacked viciously, for varied reasons.  This is, sadly, a very real problem in the world today.  Whatever the reason, if you are getting attacks over message boards, e-mail, or any other form of online communication that are sexist, racist, or otherwise hateful, or contain implicit or explicit threats, there is something seriously wrong.  I sadly do not have much advice to give, nor any I feel qualified to give, on this issue should you encounter it other than this: find help.  Nobody deserves these attacks for any reason.  For those of you who wish to read more on the incidents mentioned earlier, feel free to read the following links below as a start:

Back to the matter of having your work critiqued, I suppose, for all I’m not sure how to really segue back into this.  This will apply down the line at testing as well, but it is vital to ignore your first emotional reaction to the responses you will get from those who you ask to look over your work.  And your second, at that.  What is most optimal is to step back from your work and look at both your work and the comments from an objective viewpoint.  Once you get through that, you can start to edit your work, keeping in mind the perceived problems and high points.

With the feedback I got from my storyboard, to fill out an example, I started to work through and break my problems into five specific groups.  Severe problems were those that would require extensive changes across multiple scenes throughout the game to fix–which is a reason to catch them early–the later a problem comes up in development, the harder it is to fix.  Thankfully, I only had one such.  Major problems are those that require a significant change to or removal of one scene overall–I have a couple, but thankfully not too many.  Moderate problems are those that only require a part of a scene to be added, edited, or dropped–and probably the second most common sort of problem I had in my storyboard.  Minor problems, my most common, are those that can largely be addressed through working with the actual writing of the game itself, and are meant to be resolved then.  And lastly are preferential issues, which are more the perceived result of the reviewer’s preferences than anything else–something that I personally doubt is an actual problem that needs fixing, but is good to note nevertheless.  This last one is a reason why it is good to know your reviewers and testers, rather than to throw it to people who don’t know you.

With the end of that, I must make two personal admissions as to mistakes of my own during the process.  The first is that I rushed the finish of my storyboard, which left things particularly bare during the second half or so.  This was an inexcusable foul-up of mine, and a result of wanting to finish writing it already.  In other situations, this may be the result of strict deadlines, but mine had less of a reason.  The second mistake I will be committing is that I will not resubmit my storyboard for critique after applying fixes.  Ideally, I would resubmit at least once, if not twice or more so that issues would be cleared up and new ones not introduced before being planted into the game.  However, as a function of this blog is to show the process of how a game would be made, and I made a deliberate decision to sacrifice additional writing revision to have more time during which to show the full game creation process.  This is something I would advise not doing, as I am certain the quality of my game’s writing will suffer as a result.  All in all, I am not perfect, and I will be showing my mistakes as well as my successes as I go along here.  And this is two of my first.

Writing for a game is hard.  Writing for a JRPG is even harder.  And even harder yet is taking criticism on a project that you have invested at least a small portion into, never mind a personally significant project.  You need to be able to take feedback well, and not lash out emotionally at it.  But keep in mind that no matter the quality of your game, it is not a reason to receive abuse that you, as a person, do not deserve.  Keep at what you’re doing, you’ll get something out of it.  This is Epic Alphonse, signing out.

Posted September 16, 2013 by EpicAlphonse in Uncategorized