Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsROOTS'S PROFILE
Roots
14
Close
I'm a professional software engineer. I've spent my spare time over the last several years working on an open source RPG project that I founded.
Search
Filter
All
Game Pages
User Statuses
Improving Menu-Based Battle Systems
Sorry if this sounded too much like a promotion. I've had more general discussions about this in other game development communities back when we were still proposing ideas and figuring out what direction we wanted to move forward. But those communities weren't specific to RPGs, hence why I wanted to find out what other RPG enthusiasts seek.
I agree with your initial criticisms about this type of system. If I could turn back time, I would probably instead try for a battle style that is more similar to the Secret of Mana series, where battles take place on the map. But we're way too far along to make such a drastic change.
I'm glad you like Feature 2. Its not much more difficult to implement than your common place status effect system. One of the things I found annoying with RPGs was dealing with status effects all the time, and having to use a different spell/item to cure each type of affliction. Instead, our items and skills are just a "cure all" type ability, with weaker cures only reducing the intensity by one degree for each affliction.
I share your concerns with feature 5. Its a little bit easier to see once you are in the game (provided you play in full screen) as the enemy is larger on your screen and easier to see. That spider is the smallest size we have for our enemies (64x64 pixels). We have to be somewhat conservative when we create the various damage frames, because we blend them together and it would look really weird if an enemy lost an arm or a leg in one frame, as you would see the limb gradually disappear. This is a rather easy feature to add though, and creating the additional frames once we have a finished enemy isn't too difficult for even a beginning artist like myself to do. The idea for this feature, by the way, is taken from Final Fantasy Mystic Quest, an often criticized RPG. In that game each enemy had three damage frames (I think) and the frames were transitioned instantly instead of gradually. So they were able to get away with much more dramatic changes in their enemies (lost limbs, changes in position/posture, etc). But the transitions weren't natural and smooth as we've been able to do.
I agree with your initial criticisms about this type of system. If I could turn back time, I would probably instead try for a battle style that is more similar to the Secret of Mana series, where battles take place on the map. But we're way too far along to make such a drastic change.
I'm glad you like Feature 2. Its not much more difficult to implement than your common place status effect system. One of the things I found annoying with RPGs was dealing with status effects all the time, and having to use a different spell/item to cure each type of affliction. Instead, our items and skills are just a "cure all" type ability, with weaker cures only reducing the intensity by one degree for each affliction.
I share your concerns with feature 5. Its a little bit easier to see once you are in the game (provided you play in full screen) as the enemy is larger on your screen and easier to see. That spider is the smallest size we have for our enemies (64x64 pixels). We have to be somewhat conservative when we create the various damage frames, because we blend them together and it would look really weird if an enemy lost an arm or a leg in one frame, as you would see the limb gradually disappear. This is a rather easy feature to add though, and creating the additional frames once we have a finished enemy isn't too difficult for even a beginning artist like myself to do. The idea for this feature, by the way, is taken from Final Fantasy Mystic Quest, an often criticized RPG. In that game each enemy had three damage frames (I think) and the frames were transitioned instantly instead of gradually. So they were able to get away with much more dramatic changes in their enemies (lost limbs, changes in position/posture, etc). But the transitions weren't natural and smooth as we've been able to do.
[Poll] Optional Content: How much is best?
It depends on the game. But all of my favorite RPGs have around 10-25% optional content. I want the optional content to enhance and expand the story and character development, not just reward the player with rare/unique items and equipment. For myself, the story is everything and most of my motivation with any game I play comes from a desire of wanting to find out what happens next in the story, or learn more about a character.
Improving Menu-Based Battle Systems
I've been developing a 2D RPG (link) built from scratch with a custom engine for a number of years that uses a menu-based battle system. One of my areas of concern is that your typical RPG menu-based battle is pretty dull, and I want to try and improve that with my game. So I'm going to throw some ideas at you guys and I'd like to hear your comments and suggestions, as well as receiving any ideas you all put forward to address the issues. Almost all of these ideas are already implemented and working in our current build of the game. We are still in the process of refining and improving them.
Before I begin with my ideas, first, let me list what I believe are the major downside to such battle systems.
Most battles require little skill from the player. Games typically have a basic "Attack" function that you can spam and win over half of your battles without a problem. These types of battles are not fun, and only serve to consume the player's time. Boss battles, on the other hand, typically require more focus and decision making from the player.
A significant percentage of the time spent in a battle involves the player taking no action. They are either waiting for some stamina/action meter to build up so that they can select an action for their characters, or they are watching action unfold on the screen. In turn-based systems, what often happens is that the battle is "paused" while you select actions for your characters. Then when your actions are selected, the player sits and watches (and does nothing) while the battle unfolds. The result is a "stop-and-go" system that is not very engaging, nor is it very fun in my opinion. Even if the battle does not pause while the player selects actions, they are still waiting a significant amount of time to select their actions or (in some games) watching certain abilities be used.
Here's a video of an old demo release of our game. If you watch the battles in this video, you can clearly see that our battle system suffers from those problems and that our battles are not very interesting.
Now allow me to present the ideas that we've been testing to solve these issues. While we were brainstorming these ideas, we made sure to keep in mind the three primary design goals we have for this title because we wanted these ideas to align to them as well.
Feature #1: Allow actions to target specific areas on an opponent
This is one of the oldest and most fundamental ideas for our battle system. Essentially, both enemies and characters have multiple areas on their bodies that can be targeted (arms, head, legs, wings, torso, etc.). Each target on the body has different strengths and weaknesses that can be taken advantage of. For example, target a warrior's arms to lower their attack strength. A successful hit to an opponents head will deal more damage, but the attack is more likely to miss. A hit to the legs may have a chance to lower an enemy's speed. And so on.
The idea with this feature is to increase the number of strategic options available to the player. They can choose to try and target high-damage areas to dispatch a foe more quickly. Or if the foe is annoyingly quick, the legs can be targeted to lower their speed. Many familiar RPGs sort of had a feature like this on certain boss encounters where you could target different parts for different effects. We simply expand this idea to apply it to essentially every enemy (and playable character) in the game.
Feature #2: Status Effects Have Multiple Intensities
Nearly every RPG implements some sort of status effect like poison, mute, etc. The problem with these is that it can be annoying to cure a status ailment, only to have the same enemy re-afflict the status on a character soon after they are cured. Often, status effects are simply ignored as they do not impact the characters enough to be worth the time to heal (for example, a characters with 5000HP that is poisoned only losses maybe 40HP a turn to the effect).
In our game, we have four different intensities for a status effect. The lowest intensity for poison only removes a small amount of HP from a character (say 20HP/turn), whereas the most severe status is much more devastating. The player is faced with a less clear decision of whether it is worthwhile to spend a turn to cure the status effect based on the intensity that it has.
Additionally, we allow all negative status effects (poison, stone, etc.) and positive status effects (strength+, agility+, etc.) to naturally dissipate over the course of the battle. Without the player doing anything, over time these status effects will gradually lessen in intensity until they disappear completely. The player must also consider this information in choosing whether or not to immediately cure it. Finally, all status effects are completely cured when a battle ends, meaning that the player doesn't have to go to the menu screen after battle and cure the various afflictions.
This is a simple change that makes status effects much more interesting. As was mentioned in idea #1, status effects may also be triggered simply by striking certain targets of enemies with an attack (a hit to the legs may reduce agility, etc).
Feature #3: Allow the player to pre-select actions for their characters
While the characters are in their idle state, the player can select the next action that they would like the character to take. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's no reason really to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
We also allow the selected action to be changed by the player at any time before they execute the action. If we didn't do this, players would be hesitant to pre-select actions because they may need to change their strategy based on what actions the enemy performs. We have this feature implemented in our game now and its working out pretty well.
Feature #4: Skills have a warm-up and cool-down period
For each character skill, we have a period of time where they need to prepare to use the skill, and another period where they have to recover from using the skill. The most basic skills do not have long periods of this time, while the more powerful attacks take considerably longer. Additionally, we've played around with the idea of making a character more vulnerable during these periods.
The purpose of this feature is to introduce more strategic depth to the player. In addition to the player having to consider the resource cost (MP) of using a powerful attack, they also must consider the additional time it takes for the skill to be used.
Feature #5: Blend damage frames together for enemies
This is more of a graphical feature than a design one, but it can still influence battle decisions. Instead of having a single static image for an enemy, we create four different images of the enemy representing various states of damage. We blend two of these frames together based on the current health percentage of an enemy. This way the player can get an idea of how badly hurt an enemy is.
Here are some examples of this from enemies in our game.
There are a few more features to our battle system, but I don't want to overwhelm this first post with our entire feature list. I'll add the others here later to add to the discussion. So what are your thoughts on these first five features? Do you like the ideas proposed? Do you think they help solve the fundamental problems in this type of battle system? Do you feel they would make battles more interesting and engaging, or more complicated and tedious? I look forward to hearing the opinions of people in this community. :)
Before I begin with my ideas, first, let me list what I believe are the major downside to such battle systems.
- Lack of strategy
Most battles require little skill from the player. Games typically have a basic "Attack" function that you can spam and win over half of your battles without a problem. These types of battles are not fun, and only serve to consume the player's time. Boss battles, on the other hand, typically require more focus and decision making from the player.
- Lack of player engagement
A significant percentage of the time spent in a battle involves the player taking no action. They are either waiting for some stamina/action meter to build up so that they can select an action for their characters, or they are watching action unfold on the screen. In turn-based systems, what often happens is that the battle is "paused" while you select actions for your characters. Then when your actions are selected, the player sits and watches (and does nothing) while the battle unfolds. The result is a "stop-and-go" system that is not very engaging, nor is it very fun in my opinion. Even if the battle does not pause while the player selects actions, they are still waiting a significant amount of time to select their actions or (in some games) watching certain abilities be used.
Here's a video of an old demo release of our game. If you watch the battles in this video, you can clearly see that our battle system suffers from those problems and that our battles are not very interesting.
Now allow me to present the ideas that we've been testing to solve these issues. While we were brainstorming these ideas, we made sure to keep in mind the three primary design goals we have for this title because we wanted these ideas to align to them as well.
- Design the game such that the major focus is on gameplay and story, not advanced 3D graphics and physical simulations.
- As much as possible, remove the tedious, meaningless, and micromanaging aspects of many historical and modern RPGs.
- Require a high level of strategic thinking and planning from the player, and less mindless "button mashing" found in many RPGs.
Feature #1: Allow actions to target specific areas on an opponent
This is one of the oldest and most fundamental ideas for our battle system. Essentially, both enemies and characters have multiple areas on their bodies that can be targeted (arms, head, legs, wings, torso, etc.). Each target on the body has different strengths and weaknesses that can be taken advantage of. For example, target a warrior's arms to lower their attack strength. A successful hit to an opponents head will deal more damage, but the attack is more likely to miss. A hit to the legs may have a chance to lower an enemy's speed. And so on.
The idea with this feature is to increase the number of strategic options available to the player. They can choose to try and target high-damage areas to dispatch a foe more quickly. Or if the foe is annoyingly quick, the legs can be targeted to lower their speed. Many familiar RPGs sort of had a feature like this on certain boss encounters where you could target different parts for different effects. We simply expand this idea to apply it to essentially every enemy (and playable character) in the game.
Feature #2: Status Effects Have Multiple Intensities
Nearly every RPG implements some sort of status effect like poison, mute, etc. The problem with these is that it can be annoying to cure a status ailment, only to have the same enemy re-afflict the status on a character soon after they are cured. Often, status effects are simply ignored as they do not impact the characters enough to be worth the time to heal (for example, a characters with 5000HP that is poisoned only losses maybe 40HP a turn to the effect).
In our game, we have four different intensities for a status effect. The lowest intensity for poison only removes a small amount of HP from a character (say 20HP/turn), whereas the most severe status is much more devastating. The player is faced with a less clear decision of whether it is worthwhile to spend a turn to cure the status effect based on the intensity that it has.
Additionally, we allow all negative status effects (poison, stone, etc.) and positive status effects (strength+, agility+, etc.) to naturally dissipate over the course of the battle. Without the player doing anything, over time these status effects will gradually lessen in intensity until they disappear completely. The player must also consider this information in choosing whether or not to immediately cure it. Finally, all status effects are completely cured when a battle ends, meaning that the player doesn't have to go to the menu screen after battle and cure the various afflictions.
This is a simple change that makes status effects much more interesting. As was mentioned in idea #1, status effects may also be triggered simply by striking certain targets of enemies with an attack (a hit to the legs may reduce agility, etc).
Feature #3: Allow the player to pre-select actions for their characters
While the characters are in their idle state, the player can select the next action that they would like the character to take. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's no reason really to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
We also allow the selected action to be changed by the player at any time before they execute the action. If we didn't do this, players would be hesitant to pre-select actions because they may need to change their strategy based on what actions the enemy performs. We have this feature implemented in our game now and its working out pretty well.
Feature #4: Skills have a warm-up and cool-down period
For each character skill, we have a period of time where they need to prepare to use the skill, and another period where they have to recover from using the skill. The most basic skills do not have long periods of this time, while the more powerful attacks take considerably longer. Additionally, we've played around with the idea of making a character more vulnerable during these periods.
The purpose of this feature is to introduce more strategic depth to the player. In addition to the player having to consider the resource cost (MP) of using a powerful attack, they also must consider the additional time it takes for the skill to be used.
Feature #5: Blend damage frames together for enemies
This is more of a graphical feature than a design one, but it can still influence battle decisions. Instead of having a single static image for an enemy, we create four different images of the enemy representing various states of damage. We blend two of these frames together based on the current health percentage of an enemy. This way the player can get an idea of how badly hurt an enemy is.
Here are some examples of this from enemies in our game.
There are a few more features to our battle system, but I don't want to overwhelm this first post with our entire feature list. I'll add the others here later to add to the discussion. So what are your thoughts on these first five features? Do you like the ideas proposed? Do you think they help solve the fundamental problems in this type of battle system? Do you feel they would make battles more interesting and engaging, or more complicated and tedious? I look forward to hearing the opinions of people in this community. :)
Game Programming: Which Languages do you prefer?
I'm a software engineering professional and I've used about a couple dozen different languages throughout my studies, career, and hobby projects. The answer to "which language do you prefer" strongly depends on the type of project that I am working on. The reason why there are so many languages is that each have their own strengths and weaknesses, making them better suited for different types of applications and target systems.
I'll give my brief opinion on the languages that I know about.
C++
Very powerful, but also very difficult to learn how to use well. This language is "closer to the hardware" and as a result can extract maximum performance from the system as long as you know what you are doing. I wouldn't recommend this language to anyone who doesn't wish to invest a significant amount of time in understanding computer science concepts.
Java
Great for making applications that can run across a variety of platforms. You really don't need to do much to make Java programs run on Windows, OS X, Linux, or whatever. The garbage collector also makes it impossible for you to accidentally introduce segmentation faults or similar types of run-time errors, making the code somewhat more robust. However, performance suffers as a result, but for simple games this shouldn't matter.
Ruby
Ruby is a scripting language, not a systems language, and thus you don't even need to compile it to run your programs. I've only used it a little bit, but it seemed similar to Python, but had some very cool features that made it easier to write certain pieces of code. The problem with scripting languages like Ruby is that the performance never matches a systems language like C++ or Java.
C#
The only language on the list that I haven't used. I stay away from this one because it is embedded in the Windows world and I don't like any language that is biased toward one particular operating system or the other (yes, I realize there is Mono and that C# applications can run on non-Windows systems). I have heard great things about the language though, and it seems like it's sort of "in between" C++ and Java to me, in terms of potential for performance and easy-to-use.
I've been using C++ in game development for 8 years and I disagree that it is miserable to use. It is probably miserable if you don't have a really solid understanding of the language, design paradigms, and a firm understanding of computer systems as a whole. The reason why game studios use C++ is because it produces the highest performing code. You can write C in C++ programs, and furthermore you can insert assembly instructions inside your C++ code if you need to. If you're a AAA studio making cutting edge games, you need to extract all the performance that you can. But if you're simply making mobile apps or puzzle games, you could easily get away with using a language that doesn't perform as well, but is easier to use.
The reason I use C++ is because I already had a firm understanding of computer science and the language itself when I started my project. But my project could just as easily be written in Java or Ruby and probably work the same, as we don't have any super-high performance requirements for my game. Although since we wrote our own engine from scratch rather than use an existing one, or using toolsets like XNA, it's a lot more sensible because you always want your engine to run strong and perform well.
In summary, if you are wanting to learn a language to write a game, you need to ask yourself these questions:
- How much does performance matter? (e.g. am I making an immersive 3D MMORPG, or a simple 2D action game)
- Do I have a firm understanding of how computer systems work, and if not am I willing to invest some serious time studying to learn this?
- Is my goal to starting writing a game ASAP, or do I want to really study and master a language before I begin writing games?
Based on your original post, I would recommend you stick with an easier language like Ruby. There's no reason to go hardcore C++ unless you're looking to get into the gaming industry as a developer or you're working on some serious next-gen type game or engine.
I'll give my brief opinion on the languages that I know about.
C++
Very powerful, but also very difficult to learn how to use well. This language is "closer to the hardware" and as a result can extract maximum performance from the system as long as you know what you are doing. I wouldn't recommend this language to anyone who doesn't wish to invest a significant amount of time in understanding computer science concepts.
Java
Great for making applications that can run across a variety of platforms. You really don't need to do much to make Java programs run on Windows, OS X, Linux, or whatever. The garbage collector also makes it impossible for you to accidentally introduce segmentation faults or similar types of run-time errors, making the code somewhat more robust. However, performance suffers as a result, but for simple games this shouldn't matter.
Ruby
Ruby is a scripting language, not a systems language, and thus you don't even need to compile it to run your programs. I've only used it a little bit, but it seemed similar to Python, but had some very cool features that made it easier to write certain pieces of code. The problem with scripting languages like Ruby is that the performance never matches a systems language like C++ or Java.
C#
The only language on the list that I haven't used. I stay away from this one because it is embedded in the Windows world and I don't like any language that is biased toward one particular operating system or the other (yes, I realize there is Mono and that C# applications can run on non-Windows systems). I have heard great things about the language though, and it seems like it's sort of "in between" C++ and Java to me, in terms of potential for performance and easy-to-use.
author=CyberDaggerauthor=FlyingJester
C++ is absolutely miserable for making games.
Heh. My experiences with C++ aren't too happy either. It seems like C and Java got drunk in Vegas one night and C++ was the result. But even so, almost every game studio seems to use C++. If it's so "miserable", why is it so popular?
I've been using C++ in game development for 8 years and I disagree that it is miserable to use. It is probably miserable if you don't have a really solid understanding of the language, design paradigms, and a firm understanding of computer systems as a whole. The reason why game studios use C++ is because it produces the highest performing code. You can write C in C++ programs, and furthermore you can insert assembly instructions inside your C++ code if you need to. If you're a AAA studio making cutting edge games, you need to extract all the performance that you can. But if you're simply making mobile apps or puzzle games, you could easily get away with using a language that doesn't perform as well, but is easier to use.
The reason I use C++ is because I already had a firm understanding of computer science and the language itself when I started my project. But my project could just as easily be written in Java or Ruby and probably work the same, as we don't have any super-high performance requirements for my game. Although since we wrote our own engine from scratch rather than use an existing one, or using toolsets like XNA, it's a lot more sensible because you always want your engine to run strong and perform well.
In summary, if you are wanting to learn a language to write a game, you need to ask yourself these questions:
- How much does performance matter? (e.g. am I making an immersive 3D MMORPG, or a simple 2D action game)
- Do I have a firm understanding of how computer systems work, and if not am I willing to invest some serious time studying to learn this?
- Is my goal to starting writing a game ASAP, or do I want to really study and master a language before I begin writing games?
Based on your original post, I would recommend you stick with an easier language like Ruby. There's no reason to go hardcore C++ unless you're looking to get into the gaming industry as a developer or you're working on some serious next-gen type game or engine.
Revolutionizing Menu-Based Battle Systems
That's a good point and I believe you are right. Thinking as a player myself, if I knew an attack had a high miss rate I'd probably select a different action. I still feel like I want to have weak points that the player (and enemies) can exploit though, so it's just something we have to balance carefully I suppose.
The Screenshot Topic Returns
Revolutionizing Menu-Based Battle Systems
Your point is very valid, and something that I've been concerned about myself. I think we'll have to be careful about balancing the targets so that it's not always hitting the head 99% of the time like you said. I think that maybe making the head very easy to miss but giving it a great benefit for a hit, such as a stun effect, could make a difference.
Also I think that we could add AI to enemies so that if they find they are being targeted in a particular way, they activate a status buff or other ability that makes that target temporarily invulnerable or causes a counter attack to occur. Something like that anyway. In general, I'd like to see better enemy AI so that they are reactive to what the player is doing and address weaknesses that are being exploited.
Also I think that we could add AI to enemies so that if they find they are being targeted in a particular way, they activate a status buff or other ability that makes that target temporarily invulnerable or causes a counter attack to occur. Something like that anyway. In general, I'd like to see better enemy AI so that they are reactive to what the player is doing and address weaknesses that are being exploited.
Revolutionizing Menu-Based Battle Systems
author=Marrend
I'm pretty sure what Craze wanted to say was that there are games that totally eliminate the "wait time" by... simply not having a "wait time" mechanic?
Fair enough. And now I do realize how the thread topic may come off as arrogant, but I didn't intend it to be at all. I should have clarified in the beginning that I'm speaking mostly about ATB-type battles. I know that there are turn-based systems that are good at solving many of these problems. Final Fantasy X, for example, had an awesome battle system in that you could see the turn order and act accordingly, so the only time you were waiting was when you were watching someone perform an action.
author=Liberty
The second one is Suikoden 2 and is awesome. The battles have many dynamics that people don't realise are there just by looking - characters protect each other when they're low on health if they have a closeness, they can attack at the same time when targeting different enemies, there's combination attacks between certain characters, you can choose to either let an enemy go or bribe it to leave you alone, depending on your level vs theirs, there's an auto-battle option which is pretty fast, there's a front and back row mechanic that depends on the range of a weapon and the menu is clear, concise and very easy to use.
Wow, that sounds pretty awesome. I especially like the idea of characters automatically protecting each other if they have a deep connection. I'm not a fan of any "auto battle" option though. I know that one of the early Breath of Fire games had this option, and it made battles even less engaging, as you literally just sat there and waited until you won.
author=Crystalgate
One idea I want to try is to give actions both offensive and defensive properties. In a lot of games, you can dodge enemy attacks and attack them at the same time. In RPGs however, if you want to, say buff defense, you have to give up an action that you otherwise could have used to attack instead. This often leads to problems where a player needs knowledge to estimate the usefulness of a defensive skill, but the more a player knows, the more likely it is that the player can figure out a way to win the battles without needing said defensive skill. So, I figure that either you have to force the player into using their defensive skills (not that bad of an idea IMO as long as they don't have to use specific defensive skills) or they can use defensive strategies without having to give up offense.
I agree with you. In a typical battle for a typical RPG, defensive type skills and buffs usually aren't worth the turn it consumes to activate them. They only get used for the most difficult battles. If you make some defensive skills that trigger a powerful counter attack, that may get used more often. Or if you design your game such that you have to use your skills to make them more powerful.
author=Crystalgate
Anyway, I like the four ideas, but they seem to streamline battles rather than revolutionizing them. Further, they don't address the design goals much.
You're absolutely correct. I didn't even realize this until you pointed it out. Those ideas were developed to make battles more engaging and fun, rather than the stop-and-go, sit-and-wait type of action I described in the previous post. We do have features that have been a part of our design since the beginning that address these goals. So let me share those now.
-----
Idea #5) Move the "Run" mechanic from the battle to the map
In the beginning, Allacrost had a random encounter system like many other games do. I've never had a big problem with it, but nearly everyone else on the team was livid about removing it. So we did, even though it requires us to make some additional artwork. Now we have enemy sprites that roam around on the screen, and if you get too close they will typically chase after you. Naturally when you touch them, a battle occurs. You have a limited stamina to run away, so you can "run" from enemies before a battle occurs. Once you are in a battle, the option to run away is no longer available. Screenshot below kind shows a dungeon in an older release of the game.
Idea #6) Enemies on a map are more/less aggressive depending on relative strength
This goes along with the feature above. The behavior of enemy sprites wandering around a dungeon changes depending on the player's strength and status. For example, an enemy may choose to run away from the player's character if their level is too high. If their level is about even, they may cautiously approach the player. If the character party has an average XP level that is compartively low, the enemy will aggressively seek out the player and try to engage them in battle.
One of the cool things about this feature is that if you are revisiting an old dungeon that you've already fought through and are much stronger, you won't be bothered by annoying battles with enemies that aren't worth your time to kill. Similarly, if the player is trying to grind in an area, they may have to actively try to corner an enemy who runs away from them.
Idea #7) Status Effects heal automatically after battle
I've always found it incredibly annoying having to heal my characters from poison, stone, etc. after a battle ends. Having to navigate through the menu and find/use the appropriate status healing item or spell is just tedious. So, status effects only last for the battle duration. Simple.
Idea #8) Status Effects have various degrees of intensity
Sometimes a status effect it is such a minor consequence that it can be completely disregarded, particularly in later stages of the game when the characters are powerful. For example, a poison status that only consumes less than 1% of a character's HP per turn. We decided to make status effects have various degrees of intensity, and that they can be stacked upon one another. For example, the weakest level of poison may only consume 1% of a character's HP, but the next highest intensity may consume 2.5%, the next 5%, and the max a whopping 10%. And if a poisoned character is poisoned again, the intensity will increase by an appropriate amount. Suddenly, the player has to decide when is a status effect debilitating enough that it must be remedied? This works with status buffs as well. You could increase a friend's defense by 3%, 5%, 10%, or 15%. And for status effects like sleep, the higher the intensity of the effect, the longer the character will remain asleep.
Idea #9) Status effects naturally decrease in intensity
To add an additional factor to the player's decision of when a status effect needs to be remedied (or re-applied in the case of a status buff), all effects naturally reduce in intensity over time until they are at a neutral level (ie, inactive). Perhaps this is rather obvious, but other games either let a status remain active indefinitely until the player does something about it, or chooses to let some effects "instant heal", such as when a sleeping enemy awakes.
Idea #10) Characters and enemies may be attacked in pin-point locations
This is one of the original ideas I had when I started the game, and one of the key features. Every character and enemy has one or more "targets" that may be, well, targeted. A target may be an arm, leg, head, or torso. Or on an enemy could be a claw, wing, etc. Each target has it's own defense and evade modifiers. So for example, hitting the head deals more damage because it isn't as well protected, but it is more frequent to miss this target because it is a smaller area and more agile than say, the torso. So you can choose if you want to take a risk to deal maximum damage, or you can play it safe and select a target that you are more likely to have a clean hit on.
But the really awesome thing about targets is that they can naturally trigger status effects. For example, attacking an enemy's legs will reduce it's agility. Attacking a character's arms has a chance to reduce their strength. Attacking the head can reduce magic power. And so on. So if you are having trouble hitting a fast-moving enemy, target the legs and reduce their ability to dodge.
Not all skills can target specific points like this either, so you have to decide if you want to select a skill that may not be very powerful, or consumes a lot of mana, to register this kind of status change. The main drawback of this feature is it requires one additional item that the player must select (in addition to selecting "action" + "target", they must select the "target point" on the target). Another is that it may not be apparent what status effects trigger on what points (if any at all), but we try to make this as intuitive as possible.
Revolutionizing Menu-Based Battle Systems
Thanks for the kudos. It's not amazing yet, but we're getting there.
Yeah, I totally agree. It's not that difficult to add the feature with our current code. But it will be difficult to design it well so that it is not a frustrating experience for most players, as I'm sure some would be overwhelmed by all of the action. I think it would definitely be a "love it or hate it" kind of feature. Related to it, I had the idea of making battles kind of intense like Starcraft 2 matches are, where you have to be good at multitasking and very quick about entering commands. But I don't think the majority of RPG players would appreciate a battle system of that intensity.
I'm not quite sure what you mean by this. I never claimed that I am a savior, or that no one has ever tried to improve RPG battles before. I'm merely proposing some ideas to improve upon the lowest common denominator of menu-based RPG battles. I know that many games have made their own improvements (indeed, several of my design ideas are inspired by other RPGs). But posting a couple of game screenshots and not sharing any information about what makes their battle systems awesome, or even stating what the titles of these games are, is not helpful in furthering this discussion. :/
author=supremewarrior
I think the most hardest one to implement would be your idea #4, having multiple characters attack at once, it would be really fun if you ever did pull it off well and would be a very attractive feature in your game.
Yeah, I totally agree. It's not that difficult to add the feature with our current code. But it will be difficult to design it well so that it is not a frustrating experience for most players, as I'm sure some would be overwhelmed by all of the action. I think it would definitely be a "love it or hate it" kind of feature. Related to it, I had the idea of making battles kind of intense like Starcraft 2 matches are, where you have to be good at multitasking and very quick about entering commands. But I don't think the majority of RPG players would appreciate a battle system of that intensity.
author=Craze
with the message "you are not our savior, play some games"
I'm not quite sure what you mean by this. I never claimed that I am a savior, or that no one has ever tried to improve RPG battles before. I'm merely proposing some ideas to improve upon the lowest common denominator of menu-based RPG battles. I know that many games have made their own improvements (indeed, several of my design ideas are inspired by other RPGs). But posting a couple of game screenshots and not sharing any information about what makes their battle systems awesome, or even stating what the titles of these games are, is not helpful in furthering this discussion. :/
Revolutionizing Menu-Based Battle Systems
A couple years ago I was having a discussion online with some fellow open source game developers and the general consensus was (and I agree) that menu-based battle systems usually aren't that much fun. In a typical RPG, you wait, select an action (that 80-90% of the time is just "Attack"), wait again, select attack again, and repeat until you win. The battle pauses each time and so this action is really stop-and-go. This kicked off some gears in my brain and I started thinking about ways to improve this formula. I want to share my ideas with you guys and get a discussion going.
---
I'm going to start this discussion off by talking about it in direct reference to my own project, Hero of Allacrost. This game is written completely from scratch in C++, so the only real limits to the battle system design are our imaginations. First, let me state the high-level goals that we have for our battle system (and the game in general).
Now lets get to the set of ideas. There are many of them, so I'm only going to open with a handful of ideas and introduce others later in the discussion.
-----
Idea #1: Allow the player to pre-select actions for their characters before those characters are ready to execute their next command.
While the characters are in their idle state, the player can select actions for their characters. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's not really reason to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
Idea #2: Allow the player to change pre-selected actions for their characters
This goes along with idea #1. If the player selects an action for a character during the idle state and something happens which makes the player wish to change the action for the character (such as an ally was badly hurt and needs healing immediately), then we would allow the player to do so (but only if the character is still in the idle state, the warm-up state is too late to cancel). This would also apply toward changing the target. With this idea, we have to consider whether there would be any penalty associated with changing an action/target. We could completely reset the stamina bar back to zero and force the character to go through the entire idle state again, or we could apply a less severe penalty such as a 20%-50% reduction of the current idle time that has been met, or there could be no penalty at all. I think I'd rather see a small penalty, because this will cause the player to consider whether or not they want to select an action for their characters as soon as they can (at the 0-time mark in the idle state). But I'm undecided here.
Idea #3: Populate a small action + target hot-key menu to allow the player to quickly execute actions
In our menus, we currently sort actions by category (Attack, Defend, Support, Item) and we have cursor memory implemented as well (the menu remembers the previously selected action and target). But I've been toying with the idea of having a small number (four) of "hotkey" actions and targets for characters. This idea came to me because I realized that you often only want to change between a small number of actions and targets in battle. For instance, one character might be a designated healer, and when there is no healing needed you would instead want that character to "meditate" to regain lost magic points (called skill points in the case of my game), or to attack an enemy if no healing and no SP regeneration is needed. Three actions, and three targets that the player cycles between for this character. Going through the entire action selection menu and target selection menus each time they want to switch between one of these settings is kind of a pain in the ass, so we would have this hot-key command card available for the player to quickly switch between these actions and targets. It could either be auto-generated by the game (ie saves last x number of action + target combinations) or we could allow the player to configure this, either in and out of battle.
I also had thought that maybe we could limit the character's actions to what they could fit in the command card to create an additional depth of strategy for the player, as they would need to select which skills they brought into battle (and couldn't use all the skills they learned). For our purposes though I think this would be a bad idea, because the strategic benefit is outweighed by the negative cost of additional micromanagement needed by the player, plus it could be seen as an annoying limitation for many people (not to mention it doesn't have much of a practical explanation for why skills are limited).
Idea #4: Allow multiple actors (characters or enemies) to execute actions simultaneously
This is another idea to reduce the amount of time that the player is forced to sit and watch. Right now only one actor can execute an action at any time (in this sense the game is turn-based). But what if this was not the case, and we could have multiple characters and enemies all engaging each other at once? Perhaps we can even add a strategic element to this, and say that if two opposing actors engage each other at the same time, the one who strikes first will cancel the other's action completely.
It sounds like a promising idea I think if its implemented well, but I have a couple major concerns with it. First, it could cause battles to become very chaotic with swords and spells flying everywhere (but shouldn't battles be chaotic anyway?). Second, it may be difficult to implement both from a programming and an artistic perspective. And there may be other issues that I haven't thought of yet.
-----
For the record, we've already implemented ideas #1 and #2 in our game, and they have been working pretty darn well. I'm still interested to hear people's thoughts about it though. Here's a concept piece that I drew up for how this implementation would work:
The key are those arrow icons surrounded by the circles. When the circle is white, you can select an action for that character and you only need to hit the corresponding directional key on your gamepad or keyboard. When it is grey, you can't select an action (because they are about to execute the one that was last selected). If a character gets to the green marker on the stamina bar (right side of screen) and they don't have an action selected, the battle action stops and the player is forced to enter a command for that character before the game continues.
You can see it in action during this video here. Notice that the actors on the stamina bar continue to get closer to being ready to execute an action while I'm selecting commands for all four characters. Once the first actor is ready to attack, they can do so immediately and there's no sitting around and waiting. But you can still play it out as the traditional "wait mode" as well, if you prefer. The nice thing about this is that you can get through simple battles more quickly, but still be more methodical and careful about your action choices when facing tougher opponents, such as a boss.
(Go to the 5:40 mark to see the battle that I'm talking about)
-----
So what do you think about these ideas? What alternatives or improvements would you do if you were designing your own game from scratch?
---
I'm going to start this discussion off by talking about it in direct reference to my own project, Hero of Allacrost. This game is written completely from scratch in C++, so the only real limits to the battle system design are our imaginations. First, let me state the high-level goals that we have for our battle system (and the game in general).
author=Allacrost Design Goals
Design the game such that the major focus is on gameplay and story, not advanced 3D graphics and physical simulations.
As much as possible, remove the tedious, meaningless, and micromanaging aspects of many historical and modern RPGs.
Require a high level of strategic thinking and planning from the player, and less mindless "button mashing" found in many RPGs.
Now lets get to the set of ideas. There are many of them, so I'm only going to open with a handful of ideas and introduce others later in the discussion.
-----
Idea #1: Allow the player to pre-select actions for their characters before those characters are ready to execute their next command.
While the characters are in their idle state, the player can select actions for their characters. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's not really reason to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
Idea #2: Allow the player to change pre-selected actions for their characters
This goes along with idea #1. If the player selects an action for a character during the idle state and something happens which makes the player wish to change the action for the character (such as an ally was badly hurt and needs healing immediately), then we would allow the player to do so (but only if the character is still in the idle state, the warm-up state is too late to cancel). This would also apply toward changing the target. With this idea, we have to consider whether there would be any penalty associated with changing an action/target. We could completely reset the stamina bar back to zero and force the character to go through the entire idle state again, or we could apply a less severe penalty such as a 20%-50% reduction of the current idle time that has been met, or there could be no penalty at all. I think I'd rather see a small penalty, because this will cause the player to consider whether or not they want to select an action for their characters as soon as they can (at the 0-time mark in the idle state). But I'm undecided here.
Idea #3: Populate a small action + target hot-key menu to allow the player to quickly execute actions
In our menus, we currently sort actions by category (Attack, Defend, Support, Item) and we have cursor memory implemented as well (the menu remembers the previously selected action and target). But I've been toying with the idea of having a small number (four) of "hotkey" actions and targets for characters. This idea came to me because I realized that you often only want to change between a small number of actions and targets in battle. For instance, one character might be a designated healer, and when there is no healing needed you would instead want that character to "meditate" to regain lost magic points (called skill points in the case of my game), or to attack an enemy if no healing and no SP regeneration is needed. Three actions, and three targets that the player cycles between for this character. Going through the entire action selection menu and target selection menus each time they want to switch between one of these settings is kind of a pain in the ass, so we would have this hot-key command card available for the player to quickly switch between these actions and targets. It could either be auto-generated by the game (ie saves last x number of action + target combinations) or we could allow the player to configure this, either in and out of battle.
I also had thought that maybe we could limit the character's actions to what they could fit in the command card to create an additional depth of strategy for the player, as they would need to select which skills they brought into battle (and couldn't use all the skills they learned). For our purposes though I think this would be a bad idea, because the strategic benefit is outweighed by the negative cost of additional micromanagement needed by the player, plus it could be seen as an annoying limitation for many people (not to mention it doesn't have much of a practical explanation for why skills are limited).
Idea #4: Allow multiple actors (characters or enemies) to execute actions simultaneously
This is another idea to reduce the amount of time that the player is forced to sit and watch. Right now only one actor can execute an action at any time (in this sense the game is turn-based). But what if this was not the case, and we could have multiple characters and enemies all engaging each other at once? Perhaps we can even add a strategic element to this, and say that if two opposing actors engage each other at the same time, the one who strikes first will cancel the other's action completely.
It sounds like a promising idea I think if its implemented well, but I have a couple major concerns with it. First, it could cause battles to become very chaotic with swords and spells flying everywhere (but shouldn't battles be chaotic anyway?). Second, it may be difficult to implement both from a programming and an artistic perspective. And there may be other issues that I haven't thought of yet.
-----
For the record, we've already implemented ideas #1 and #2 in our game, and they have been working pretty darn well. I'm still interested to hear people's thoughts about it though. Here's a concept piece that I drew up for how this implementation would work:
The key are those arrow icons surrounded by the circles. When the circle is white, you can select an action for that character and you only need to hit the corresponding directional key on your gamepad or keyboard. When it is grey, you can't select an action (because they are about to execute the one that was last selected). If a character gets to the green marker on the stamina bar (right side of screen) and they don't have an action selected, the battle action stops and the player is forced to enter a command for that character before the game continues.
You can see it in action during this video here. Notice that the actors on the stamina bar continue to get closer to being ready to execute an action while I'm selecting commands for all four characters. Once the first actor is ready to attack, they can do so immediately and there's no sitting around and waiting. But you can still play it out as the traditional "wait mode" as well, if you prefer. The nice thing about this is that you can get through simple battles more quickly, but still be more methodical and careful about your action choices when facing tougher opponents, such as a boss.
(Go to the 5:40 mark to see the battle that I'm talking about)
-----
So what do you think about these ideas? What alternatives or improvements would you do if you were designing your own game from scratch?
Games - Tester
Games - Other
