THEORY QUESTION: How To Minimize Mechanics

[Victor_Roland]

Greetings all,


Its been a while since I picked up RPG Maker VX Ace, and yet here I am, trying to work on my pet project once again. I have come to realize a grievous fault in my design process. I have always operated under the mantra: story first, gameplay second. And that's great ... If I'm making a visual novel. The problem is, I realize that I made a half-way decent skin to drape over a game. Not the actual game. Therefore, I come to you good people asking, "how do you make the bare-bone essentials for a game using the RPG Maker VX Ace engine?" I know how to event and to implement scripts, I'm just curious as to what the next step is. Math was never my strong suit, so please, bare with me. I have created skin, sinew, and bloodstream for the game ... but I completely forgot the skeleton needed to make it anything remotely functional.


Again, I'll poise the question: how do you make a simple, narrative driven game?


My general idea is something of sanity system. I was thinking, what if the sanity system was tied to the player's MP, or replaced the player's MP, and magic, while extremely powerful, requires one's sanity to use. In other words, on the field map, it would function as Eternal Darkness or Amnesia: The Dark Descent (a resource that you must manage as you explore, least the monsters attack more frequently, and other bad things happen, like hallucinations), and on the battle screen, it functions as the player's MP/TP. The two modes of gameplay would be linked, but ultimately could be tailored to different play styles.


And don't even get me started on designing the player classes. *shudders*


And while I would love to have combat, that might be a little ambitious at this rate. Even so, I'd like to edit the combat engine to design something far simpler and more user friendly, something ala. Paper Mario or Fire Emblem. What are some good pieces of advice that you can give a noob who is willing to learn, and wants to make his game a game, not just a pseudo-interactive novel? What worked for you? What didn't? Also, please note, I'd like to focus on game design and mechanics, not plot or character, as I think that would be a good dressing to lay over the bones of the game itself. 


Any thoughts or critique are welcome. I have much to learn.


Thank you all,


Victor_Roland

 

[hadecynn]

You've made it clear that you don't want to make a visual novel, but I'm not sure you are communicating what kind of game you want to make, and therefore I'm not sure how/where to help. You mentioned your hesitation dealing with math, player classes, and combat, but I think you might want to take a step back and look at the big picture before you even start worrying about those technicalities.


I would start by thinking about the fundamentals of what makes a game a game, and define it according to the unique experience you want to deliver to the player. That is,


What are the goals of the game? (eg. defeat a boss? make X amount of money? completely explore a map?)


What are the rules? (ie. what causes a game over condition? eg. 0 HP? going into debt? there's a time limit to your exploration?)


What are the challenges? (eg. enemies are constantly reducing your HP? you need to spend certain amounts of money on food each day to survive while saving up? you have to figure out how to cross oceans and scale mountains to reach new unexplored regions?)


How do players interact? (eg. you can choose your own gear and commands in battle? you can sell different items and set your own prices? you help NPCs with quests for new forms of transportation?)


After you have these answers, I think you'll have a much better sense of how to actually go about delivering that experience. Not all games have to have combat, not all games need player classes; if you are really intent on making a good game, you need to ask yourself why you are putting in each and every one of your game designs/mechanics, much like how a writer would scrutinize over each and every word used.


At the end of the day, you might even find that for the story you've written, you are actually better off just delivering it through a visual novel.

 

[Titanhex]

The greatest issue with "Story First, Gameplay Second" is that it's like saying "Story First, Movie Second" and expecting a well-made movie to come from this. Imagine if I was writing a book and I said "Story first, Sentence Structure and Grammar Second" It ignores the mechanics inherent to the medium you're using.


It's why most book to game adaptations are often bad.


I personally hate the notion "Story First." It's absolutely wrong.


Your story should always support the gameplay. And the gameplay should in turn support the story. In order to do that, you have to understand the power of interactivity and what it can do to ENHANCE a story.
That's what Undertale did right. It didn't just ask you a choice, it took the way you played the game and created a reaction of the game from it. It also forced you to face your choices through the gameplay, as you chose to give mercy or kill mercilessly. It's part of the gameplay, which makes it such a great example of good game design.

Another good example is Chrono Trigger, and that is best broken down by a man who wrote an article on Reverse Breakdown of Chrono Trigger, dividing Chrono Trigger into two different parts.
I have a link to the site where he mentions this, and I suggest going and giving it a read.


He also breaks down FF6, and that too is highly helpful.


My point is, gameplay should support the story, and the story should be part of the gameplay. It requires deep thought, and certain skills and talents you develop through the years. It also takes a certain level of awareness.
Practice it and think hard about the elements of gameplay that go into your story, and making sure the story and gameplay exist within one another, so that they cannot be separated.

 

[LaFlibuste]

I'll go in the same general direction as the other. Imagine you are designing a vehicle. You have decided its color and general looks first and now you are scratching your head over the kind of energy it should use, but you haven't given any thought on wether it is going to be a plane, a car or a boat. What good is it thinking about the influence of the "Sanity" stat on magic if you are not going to have a battle system?


I get you, by the way: he story is the actual cool think to create. But it really has to be done in parallel with the gameplay. Also, it's likely not going to be what makes or breaks your game.

Aside from experiencing your awesome story, what do you actually want your players to do in your game? What's the "game" part of it?


Is it about exploration, lush mazes and stuff like that?


Is it a puzzle game? If so, what kind of puzzle should it be about?


Do you want to have battles? If so, what should it look like? Traditionnal turn-based? Tactical? Action? Card-based? Some sort of rhythm gimmick? Automatic battles with a few player inputs to control the flow, like in games such as Ogre Battle? What's your stance on randomness? Etc. etc.
As a rough estimate, the typical JRPG blends a bit of these three things (not accounting the story), I'd say about 0 - 10% puzzles, 20 - 50% exploration and the rest is the battle system.


Think about what kind of general gameplay you want for your game. Think back on games you've played: what did you like, what did you not? What kind of system could serve your awesome story best? Once you've got some sort of general idea, you can start wondering about the influence of the Sanity stat.

@Titanhex You should have put up the links on the articles you spoke of, I would've been interested in checking 'em out

 

[Titanhex]

I have it linked already on this forum in a thread that is right next to this one in the game design list. 

 

[Victor_Roland]

Okay. This is helpful. And common sense now that I think about it. Anyway, so I should design a core gameplay mechanic(s), is what it sounds like. An RPG would be a mixture of two modes of gameplay: one of exploration/puzzles and one of turn based combat, as far as I understand. The player interaction comes froms solving puzzels, navatigating locales, finding equipment on the map that impacts varabiles and statistics on the battle mode. Do any of you have some examples on how to a turn based battle system works? There's a difference between knowledge and understanding, and I would like to understand better the basics of combat, and why it works the way it does.


Sorry, it took me so long to get back to all of you, as I have a day job.


Again, any help would be great!

 

[LaFlibuste]

Hey, no worries! You're not alone to have other things to do!

As far as turn-based battle systems go... Well there are lots of kinds and variations. Let's drop the question of stats and maths for now and talk more over-arching concepts. From your cluelessness I'm going to deduce you maybe have not played a lot of JRPGs or RPGs in general and link some example video, but don't be insulted if I've misjudged you.

The two classic turn-based battle systems (I'm going to give them name but they may not be the official names) would be simultaneous turn battles and Active Time Battle.


What I call simultaneous turn battle is when at the beginning of each round, you give commands to all of your party members. Your party members will then execute their commands in a certain order depending on their speed. Opponents will also act in order. Everyone will (usually?) act exactly once per turn. It's kinda like the DnD system (if you're DnD savvy), although DnD offers delayed actions and stuff that mix the concept a bit (although I guess you could incorporate this in your system). It's possibly the oldest, most classic battle system and is a staple of the Dragon Warrior series, for instance.


Active Time Battle (AT is the classic Final Fantasy battle system. The characters' turn to act come up depending on their speed and a round count is not strictly enforced. This means, in theory, a fast enough character might act twice as often as a slower one. A variation on this is Conditionnal Turn Battles (CT, in which instead of waiting for timer gauges to fill up, the acting order is predetermined by some algorythm, is known and shown and can be influenced by various actions.


Incidentally, those two videos also show the two staple battle-views: front view (as in Dragon Warrior) and side view (as in Final Fantasy). Each have their pros and cons. Of course there are other possibilities if you are willing to put in the work. You could go front view but still seeing you characters' sprites fight it out if you dislike the impersonal Dragon Warrior approach, such as in Lufia or 7th Saga (showing this one for the different art style), you could even scrap battle backdrop and just use the map as in the first Lufia title. A lot of front view system (RPG Maker's default system being one of them) makes a compromise by showing facesets. Facesets could also have varying expression depending on health levels or stuff. Another option is the ever-popular on-map concept of Chrono Trigger.


As far as systems go, there are other ideas out there. For instance characters could act at exactly the same time as monsters and it becomes a guessing (or not) game of trumping the opposing side's action. A game that does something like it, off the top of my head, is Guild of Dungeoneering. Okay, in there case it's card-based and it's very simplistic, but it shows off the concept. Other systems include action point systems, like in the old Fallout titles for instances. Sure, in this case it involves moving around a map and is a bit more strategy-oriented, but who says you couldn't have an initiative stat for the turn order and an agility stat (or whatever the names) for the amount fo action points a character gets every time he gets to act? You can also incorporate tons of other gimmicks: roulette-like hit-o-meters, combo-input systems (either on a per-character basis like in Legend of Legaia or on a party-wise scale like in Valkyrie Profile), Timing input gimmicks like in Legend of Dragoons, etc.


There's also the question of how battles are started. Random encounters like in most classic JRPGs? Static enemies shown on map like in Mystic Quest? (Usually) shown on map and sometimes avoidable like in Chrono Trigger? Shown on map and moving, starting battle on contact, such as in Lufia II or Earth Bound? And surely others I can't think off of the top of my head.



And of course, I am purposefully leaving out action systems and tactical systems.


While I encourage you to not think too much about technical and artistic barriers when designing your system, you should still keep in mind that is not classic front view (or side view if you use MV) is going to require that you customize the engine with scripts and plugins. Anything other than classic front view will also require that you come up with a lot of art assets. Seeing your characters fight is really could and is a must-have for many gamers but it requires that you actually create the sprites and animations that you plan on showing. Depending on the system and the style you pick, it can represent an exponential increase in required art assets.


Well it's been quite the write-up! Hope it gives you some ideas! Seriously though, if you're not too sure about this, play different games, try the systems out and see how they feel, how you like them. You can also read up on the subject. I cannot recommend enough reading the reverse designing articles shared by this individual. It's a long but worthwhile read.

Good luck thinking this out!

 

[Victor_Roland]

I've played plenty of RPGs, I think I might have phrased my question poorly. I mostly just needed the information relayed so I have a better understand on how to design a combat system through deconstruction. I've also read the reverse design articles and those were EXACTLY the kind of stuff I was looking for. I know a lot about how RPGs play, just nothing on how to make them work and function like they should.

 

[hadecynn]

I'm going to be straight up front: if you are looking to better understand how to design an RPG turn-based combat system, then you're going to need math and Excel. There are a number of ways to approach the problem, but they will ultimately all converge on a spreadsheet eventually. That's just how it is.


Having said that, here's one approach (among many) that will hopefully give you some insights into how you could approach this problem. 


First, let's talk about scale and proportions.


How long do you intend for your game to be?


How do you intend on allocating the above total play time among the story, the exploration/puzzles, and the battles? (and possibly more, I'm just taking the three you've mentioned so far)


By answering these two questions, even if its just a rough idea, you will at least have some sense of the size of the canvas that you'll have to work with. To illustrate, if you intend on making a 5-hour game, with combat taking up only 20% of playtime, then that's only an hour's worth of battle content. If that's the case, forget about implementing multiple classes, you might be able to get by with just one or two playable characters and a handful of skills and equipment. If, on the other hand, you envision making a 20-hour game that's 50% combat, then you'll need enough variation, mechanics, and other elements to keep players entertain and engaged during the combat for ten hours.


Going one level deeper, if, for example's sake, we assume that you decide to have around five hours of battle content, then we can do more math by thinking about how long you want each battle encounter to be, and in turn, how many battle encounters you would then expect to have. Some RPGs unravel down to just button-mashing the "Attack" command to win, so battles in those games probably won't take very long. On the other hand, other turn-based RPGs require you to use several layers of buffs and skills to "set up"  you characters before you unleash all your firepower during one turn; these would take longer. This is why, like I mentioned in my previous post, you need to fully understand why you want to put in and use certain mechanics over others. I don't know enough about the "sanity" system you have in your mind, so I can't comment on it, but you need to think about how this would change the flow or pace of battle and what the implications are for having that mechanic (and every other mechanic) in place. At the end of the day, going through this exercise will help you figure out how many turns you expect players (and enemies) to get per battle on average, which can be used to further derive other variables at play, such as the total number of commands a player can give depending on the number of characters in the party.


Once you've figured out the approximate pacing/flow of battles and the number of commands, you can start thinking about difficulty by using damage-per-turn (DPT) and heal-per-turn (HPT) as units of measure. For traditional RPGs, regardless of what the skin looks like, battles at the core is just an HP race; deplete the enemy party's total HP before they deplete yours. Everything else is a measure against that, even if its not immediately obvious that that's the case. For example, MP might seem like a completely separate resource that has nothing to do with HP, but in fact it has everything to do with HP. By expending MP to cast offensive spells, the expectation is that you will be able to raise your overall damage output and DPT because magic attacks usually deal more damage than 'resource-free' physical attacks; by raising your DPT, you are more likely to be able to "beat" the enemy in the HP-depletion race. Likewise, a recovery spell works the same way. You are healing the party so they stay on the battlefield longer, but to do what? Dish out more damage to the enemy. If you are able to "see" these relationships between stats, then it becomes very easy (though time-consuming) to derive the numbers you need to make the system churn out the kind of experience you want to deliver.


Want a difficult battle? Make the total DPT on the enemy's side equal (if not slightly greater than) the maximum HPT on the player's party side. That is, if my total party HP pool is 500 HP, and my healer can heal a maximum of 100 HP per turn, then I'll know that, if I want my players to have one of those sweaty-palm, adrenaline-fueled boss battles, I would set the enemy's DPT to be maybe around 125 ~ 150. In this way, even if the Healer is foregoing attacks and doing heals every turn, the player is still consistently losing 25 to 50 HP per turn. Meaning that after 8 - 9 turns, they'll be dead. That implies, in reverse, that unless you are making this a frustrating unwinnable experience, the enemy party's total HP should be just around enough to last 8 ~ 9 times that of the expected player party's DPT. Of course, by designing this to be an 8 ~ 9 turn encounter, you would also need to check whether the Healer has enough MP to cast healing spells for 9 turns straight, among other things.


You can also use the same idea to think about difficulty and stat gains. You might be clueless at first on even where to start, but let's start with a random number, plug it into our system, and see what happens. Let's say for every additional level gained, your character gains 10% more of HP, MP, and HPT. If that's the case, how would the boss battle I describe play like to a player who is 2 levels above what I designed the fight to be at? By have 20% more HP (600) and being able to heal 20% more (120), you can see that, even if I didn't increase the DPT, the sheer fact that the player can now virtually cancel out the incoming damage each turn PLUS having a larger HP pool will mean that the battle will become cakewalk. On the other hand, if a player is 2 levels under-leveled, you are now looking at an almost unbeatable fight. This will indicate to you that, unless your game has some way of tightly controlling the player's progression, maybe 10% increases per level is too much. OR, you might decide that the enemies have too much HP. See how all of this just builds on top of the previous layer, but all of it is grounded on a very solid understanding of your own game rules, objectives, and challenges?


In closing, I hope this is along the lines of what you're looking for, and that you've gotten a much better grasp of how to approach battle design. Doing all this by hand is obviously very painful, which is why I said right at the start that you'll need Excel and spreadsheets. While I don't believe that most RPG Maker games are using such a sophisticated, well-thought-out approach, I can confidently say that Excel(spreadsheets) IS the industry standard for game design. This is actually very comforting, because even if our games don't remotely look or sound as pretty as next-gen AAA titles due to our lack of resources, all of us DO have access to the best tools we need to make a game PLAY well. 


Regards,


hadecynn

 

[Titanhex]

Having practiced design extensively, I can tell you this much.


An hours worth of gameplay will probably be a months worth of work. That only counts when the game development is smooth, with near continuous, full time work 3 out of 4 of those weeks. That means no sitting on your hands planning the next part, but rather working fluidly on implementation and asset development.


You can cut that work back by pushing asset design into pre-production, but you have to do a lot of game design planning to pull it off without wasting the artists time. Even then you'll probably need to create assets during production.


Yet still, the whole pre-production, design documentation process is mainly to create a cohesive game experience, and have each person responsible for asset production and your designer on the same page.
When working solo, it simply helps you keep to a consistent work flow by knowing the next step at all times. (<<Extremely important)


That in and of itself is a skill, and having the right software to do it is important. It's akin to project management.


Barring these disciplines, if you want to create a game right off the bat, you need to know your limitations.

@hadecynn gives some good advice, but it's very particular advice. He tells you how to use numbers, and his advice is effective, but game design isn't just numbers. You have to take abstract concepts (like sanity), and turn it into real results, things that can be implemented. Often times those results are numbers. Other times they can be tools. It depends on your creativity and ability to recall sources for inspiration.
Numbers are the simplest thing you get to work with as a designer. But it's unlikely numbers will be all you work with. You'll probably be working with some abstract ideas.


In that regard, you need to turn your idea of a sanity system into something that can be implemented into a game. Is sanity counted in numbers? Is it counted on a bar, or perhaps shades of color on the screen? Does it alter gameplay, or limit it?  How visceral is sanity? Should it also psychologically disturb the player, and if so, how?

The more abstract the mechanics, the more work and brainpower you'll be forced to use, and the more overwhelming your project will become. So I suggest simplifying your mechanics and keeping them limited if this is one of your first 5 projects.


The best way to learn how to do it is to do it, just try to keep in mind adding mechanics on top of other mechanics can create an exponentially more difficult game to implement.

 

[LaFlibuste]

Something else I do as far as numbers are concerned is delimiting my boundaries, determine the minimum and the maximum for the system to work. What's the lowest of the low for a stat at lv1, without any equipment or anything? And if a player was min-maxing like hell, was the best possible class and wore the absolute best equipment, what should the maximum be for the system to not be broken? Then it's just a matter of decomposing those and creating a formula. Fine, you've got your maximum: what's the stat part and what's the  equipment's part? Then it's jsut a matter of determining pacing and progression. "By the end of chapter one, I'd want them to be Lv10 and they should have about that much HP", for example.

 

[Victor_Roland]

All very helpful. Great advice. I have this and the reverse-design docs bookmarked now. Fascinating how everything is totally intricate and reflective of the things around it. Makes sense, but this is also why I ask these questions. There's a difference between knowing how to navigate VX Ace and how to make a game. I've made a few terrible experimental projects. But this is all great to know. I know I have a game in me, I just have to rework everything using theory and the right homework. I had an idea by just coming up with a story concept and a one-hour mockup of a demo and releasing it on here for feedback. Based on that, I'll try to make something longer or something else entirely. I figure I should start SMALL and build up.

 

[Tai_MT]

I'm not sure if my advice is going to be helpful at all, as my experiences in life (and often the conclusions I draw from those experiences) are fairly atypical.  But, I'll let you decide and hopefully you don't find what I have to say too outlandish or weird.


When I write stories, I start with a general outline of what I want to do and basic character sheets of who the major people are, their goals, hopes, dreams, fears, etcetera.  This is a lot different from how I approach video game design.  By necessity, in fact.  A "story first, gameplay second" approach is the way you write a book, a novel, a play.  What you do when you write a story is get the whole story planned out, a first draft written, and then you go back over it again and again to refine it with proper spelling, grammar, punctuation, elaboration, etcetera.  You've got the story, so you refine it through several iterations.  I'm not sure if this can be applied to "visual novel" style games, as I've never played one, and certainly never made one...  But, I imagine even that is different from just writing a story.


So, with game design, I've found that an approach of two basic outlines is what is required before you ever start.  You need the barebones story (as in, very barebones as it will change as you go along.  Part of the storyboarding process of creating a video game of any kind is to decide what systems you want, why you want them (or even why you're inventing all new systems), what purpose they serve, and how they will affect the story as a whole.  Your systems inform your game world and the universe your story takes place in (something later Final Fantasy games don't take into account because... reasons, I guess.  How DO you hold 99 Demis?  In your pocket?  How are they stored?  How do monsters get turned into cards?  How the heck does a gunblade even work without breaking your wrist when you swing it?  Does pulling the trigger do more damage?  Is a Sphere Grid a tangible thing?  It must be if I'm getting orbs to put on it... But how does that work?  The list goes on and on).  The point I'm making here is that creating a story, your systems, your world, and your characters, should really all happen at once.


I generally start with the basic outline of the story I want to tell.  How I want it to start, who I want it to involve, 5 major plot points (five is the ones you will definitely include, no matter what, you cannot deviate... and your story must hit all those five points... anything else is ancillary), and how I want it to end.  These 7 places the story hits never change, they must remain absolutely the same to have any semblance of workable story to tell.  They're my road map and how I always know where I'm going.  After that, I decide what systems I want in my game and how I want them to work.  If I want a crafting system, why do I want it, and what purpose does it serve in the world?  Can anyone craft?  Other appropriate questions apply.  I use these systems to then build up the world around my plot.  They help inform me of how my world operates and what kinds of people are in it.  From there, I jump to the Database and fill out absolutely every aspect of it that I know I will need (or think I'll need, leaving some spaces empty in case of story reasons or gameplay reasons, so I can update them as I go).  If you're like me, you'll be spending the vast majority of your time in the Database because it's frankly one of the most important places in any RPG Maker and houses so much of the data of your game. You'll want to take care of that immediately so that you don't have to stop what you're doing every time you're eventing in order to create a new asset, new character, new class, new whatever.


After the big mess of the Database is done (trust me, this takes a lot of time), I generally jump into mapping (as a rule I always have a single "Test Map" created in order to test things in my Database like skills and sytems, other than that, I create no maps until the database is completed) I start creating maps as the story demands them.  The story starts here with this, so I set up a map for it.  I then event everything I need on that map before creating the next one.  Map transitions are usually the last thing I event.


But, even just the map design helps inform my story.  Do those random mountains there have any impact on the local wildlife?  How about villages nearby?  Wars?  Trade?  What about that forest?  What kind of village is this?  How far does the territory of this kingdom spread?  Where are the borders, actually?  What kinds of culture have sprung up in these areas?  What kinds of quests might need to be done in these areas?


So, when I start mapping... that's when I start telling my story.  The story that I've pieced together from that rough outline, those systems I implemented, those things I put in the Database, and those map features I created.  It all rolls into one for the eventing and turns into a real story at that point.


Think of marrying gameplay to your story as part of your rough draft of telling the story.  You have to have it as part of your rough draft, because it becomes difficult to add it in much later.  Especially when you're married to what story you've put in without the gameplay elements existing.

 

[RogdagoR]

I kinda do like Tai_MT, i'm still developing story and game mechanics(on paper) and i like to weight them the same way, 50-50, not story first and gameplay second, becouse i noticed if i do so my game will not be immersive.


I follow the rule that everything is connected, battles and gameplay mechanics are also part of the story, they help you to feel the flow of the events(atleast is what i'm aiming at).


For this reason i'm continuosly adding and removing little things to both and refining them as long as good ideas come to my mind(or inspiration).


Then i will proceed to fill the database and then mapping/eventing.