Archive for the ‘Game Design’ Category

As much as I love JRPGs, there is one problem that can somewhat drag the experience down, which is random encounters. Some people can tolerate more random encounters than me, most can tolerate less. I`m generally pretty forgiving when it comes to random encounters, but in really long dungeon with only a few different battles, even I will get tired of fighting the same battles over and over again. I will talk about some ideas I came up with for reducing random encounter fatigue for a game I am developing.

There is an alternative to random encounters that is sometimes explored but I`m not really sure if it has an official name. The earliest I can remember it being used is in the SNES game Earthbound, and more recently it was in Final Fantasy 13. The idea is that there are a bunch of enemies running around the dungeon and if you bump into one you will enter into a battle. Now this is a good system if, and this is a big if, you want to avoid battles. If you want to fight battles, or more likely if you find the boss too difficult you need to grind a level or two to beat him this is a bad system. Every single game I’ve seen that implements this system makes grinding very inefficient, because after bumping into all the enemies you have to leave and reload the area to get more enemies to fight.

Now you might say if the game is well balanced you won’t need to grin levels and a few battles will give you enough experience to beat any boss. Well the response to that some people are better than others at playing the game and no matter what somebody will need to grind levels to beat the boss. And this is okay. That’s the whole purpose of leveling up is to make it easier. You make the game exactly as hard or as easy as you need it to be. Fortunately I came up with a solution. I don’t want to steal anyone’s thunder if this is not an original idea but I cannot think of a single game that uses this, so I will cautiously claim credit for this idea unless someone else can show an earlier instance of its use.

The idea is to allow the player of adjust the rate of random encounters or even turn them off. I wouldn’t recommend turning it off unless you are really hardcore, because most people will probably need at least a little bit of experience and gold to beat the bosses. But for people who want a challenge at low levels you can turn off the battles to give yourself that challenge. If you are having a lot of trouble with a boss you can briefly crank up the random encounter rate to grind a level. If you really love the combat you can leave the random encounter rate cranked up all the time. If you are deep in a dungeon and you are almost out of Health and healing items you can turn off the random encounters and safely make your way out.

Now up till now the idea is for this to be a Final Fantasy-esque  jrpg, with a small twist that you have several rows and you and the enemies can advance left and right across the battlefield. Of course giving people the ability to reduce or even turn off random encounters changes things a bit. A key part of Final Fantasy is preparation, buying the right equipment and stocking up on items, and then being slowly worn down by random encounters as you fight through the dungeon. Now that you can reduce and even turn off the random encounters the dungeons lose their edge. Now random encounters are not there to wear you down, they are optional battles to prepare you for the bosses. Really this game stands or falls on how interesting the boss battles are because that’s the only part that isn’t optional. I do have some ideas for making that interesting which you will see over the next couple of months.

Another problem is that with random encounters greatly reduced the game is going to be pretty short. Even with random encounters padding it out, I’d be lucky to for the game to be half as long as a Final Fantasy. One idea I thought of is to add a few puzzles to the game, which isn’t really that uncommon for a jrpg to have puzzles in its dungeons, which will add maybe a couple more hours to the game.

Also this adjustable rate of random encounters is only part of my plan to reduce random encounter fatigue, the other is to add more variety to the battles. As I mentioned in a previous post each row can have values which give bonuses to defense and magic defense for the units standing there. One thing which was really easy to do is to randomize which rows gets bonuses and to set certain limits on what the bonuses would be. Another is to randomize the type, number and location of enemies for each battle. Its not completely random there are certain rules so that long range enemies tend toward the back and melee guys end up near the front, but even within certain rules there is room for variation. I need to adjust that algorithm a bit but so far randomizing the random encounters to produce a wide variety of battles is showing great promise.

I believe the two things I mentioned in this post should go a long way toward alleviating random encounter fatigue, and possibly eliminating it entirely. Only time will tell if I am correct. I was planning on releasing a rough demo to demonstrate the core battle mechanics some time this week, but then I realized, even though its technically got some playable functionality, its still in a really rough shape. I really don’t have anything to gain by releasing a demo this early. Maybe in a couple of weeks. Maybe if I’m feeling brave I’ll post some screenshots or videos showing off the graphics I made for this game.

 

Advertisements

As I mentioned in the last post I have been working on a game in game maker. The combat is similar to any turn based jrpg, with the main difference being that in this game you the characters can advance left and right across the battlefield and every character has a range they can attack. In general you have your tough melee characters go in front to take the brunt of the enemy attack, and the characters with magic or ranged weapons take potshots form the safety of the back rows.

Now the first problem I thought of with this battle system is that each side will advance toward each other and once they are within attacking range the battles will basically be the same as any other jrpg. Nobody will bother moving once they are able to attack the enemy. To deal with this problem I have come up with some ideas to encourage movement as much as possible.

First off, one of the player controlled characters has the ability to place mines. When a enemy enters that row at a later time, they will take massive damage. This is an ability that encourages the player to retreat rather than advance.

Another character has two related abilities, knockback and pull. Knockback, in addition to doing a little bit of damage, will move enemy unit back one row, if there is space for it to move there. If you are taking massive amounts of damage fighting several tough melee enemies at once, knocking one of them out of range while still doing some damage can make the situation more manageable. Pull does the opposite it takes an enemy from 2 rows away and pulls them closer, if the row is not full. This can be useful if there is some wizard dealing massive damage from out of range, and you can pull him close and deal with him on your terms.

Another thing I added to make battles more interesting is that certain rows will offer defense bonuses. This will work well with another ability one of the characters has, which is teleport. Using that the character can teleport to any row in the battle that is not full or occupied by an enemy. Since players and enemies cannot occupy the same row, if it looks like enemies will reach a row with a defense bonus before you, you can have the character teleport there and hold the row until everyone else arrives. Now this could be risky, because the character who can teleport is a spellcaster which mean he can’t take as many hits as some of the stronger characters. The magnitude of the defense bonus and the enemies being faced in this situation will determine whether this is a good strategy to use or not.

In addition to those there are the usual jrpg battle options, several types of healing spells, and attack magic. The more costly magic spells not only do more damage but will have greater range. There are also items to do things like restore HP and MP. And if none of those options are needed at the time, a character can always wait.

The combat system is basically done. I may need to add more abilities, or adjust the the ones I already have to cost a different amount or do different amount of damage, but most of the abilities I wanted are in the game and seem to be functional. I will need to do some serious testing to make sure all this works properly but so far the battle system works exactly as it is supposed to. A more serious problem is getting the user interface to not be absolutely horrible. And of course I’ll need all sorts of stuff that exists in the game outside of the battle, like shops and equipment and stuff like that. Basically I’ve worked on nothing in this game except for the battle system.

Actually this isn’t really an experiment, but if I could I would use the stuff I’m about to talk about to make an actual game, and see what results. I’m not sure it would actually be all that fun, but it would be interesting for me to see the results. I suppose if I was really desperate I’d just call it a thought experiment, but those aren’t nearly as cool as real experiments.

In many MMOs, several players will join together to go on raids to defeat strong enemies that they couldn’t defeat individually. The idea I have is to play a little game after the boss is defeated to determine how the loot is split up. Before I get to that, you may want to take a look at the Wikipedia page on Prisoner’s Dilemma.

If you can’t be bothered to click the link I’ll briefly explain. Its a situation where there are two prisoners, and they can either defect, to betray the other to the police, or cooperate. If they both cooperate they get 3 months in prison on a lesser offense. If one defects and the other cooperates the defector gets no prison time, and the cooperator gets a year in prison. Id both defect they get 6 months in prison. Can I get a table to show that?

Prisoner B cooperates                                 Prisoner B defects

______________________________________________________________________________________

Prisoner A cooperates |  Prisoner A 3 , Prisoner B 3             |       Prisoner A 12, Prisoner B 0

Prisoner A defects         | Prisoner A 0, Prisoner B 12             |       Prisoner A 6, Prisoner B 6

_______________________________________________________________________________________

What the hell was that? I asked for a table. Well hopefully its pretty clear. If they both cooperate they get a light sentence. Both defect he get a longer sentence, and if one defects he gets of free while the other gets a much longer sentence. Now lets change this so it can be useful in an MMO. I’m going to use gold as the payoff. Even though Bosses might have valuable items, they can be substituted for gold based on the value, the important thing is to have some sort of standard formula for payoffs. Players can either share the loot or steal, as shown in the following “table”.

Player B shares                               Player B steals

______________________________________________________________________________________

Player A shares |  Player A 50 gold , Player B 50 gold             |       Player A 20 gold, Player B 80 gold

Player A steals   | Player A 80 gold, Player B 20 gold               |       Player A 25 gold, Player B 25 gold

_______________________________________________________________________________________

For stronger bosses just multiply all the values. Now there’s usually more than to players in a raid, so how can we do this if there are only two players in prisoner’s dilemma? The easiest way to do it, is for every player involved to be paired up with every other player in a a separate prisoner’s dilemma, with the gold amounts divided evenly between all instances of prisoner’s dilemma.

Now what has research taught about “winning” prisoner’s dilemma. In a single case of prisoner’s dilemma, the optimal strategy is to defect, while in iterated prisoner’s dilemma, the optimal strategy is to cooperate. Its a bit more complicated than that, but if you read the Wikipedia article on prisoner’s dilemma it explains it in more detail.

Are MMO raids a single case of prisoner’s dilemma, or iterative. It depends on whether you play raid with the same people multiple times or not. In most MMOs players form guilds, and if aren’t cooperating with your guild, stealing all the gold, they can kick you out. Some player’s might not care, they can joing a guild, go on a raid, steal all the gold, and then join another guild. Eventually they might gain a bad reputation, and nobody will let them join, but all the other guilds already lost out on a bit of gold. They need some way to prevent that.

It occurs to me that in MMOs, there is no best equipment, you could have several sets of gear, for different circumstances. Before a raid, all guild members going on the raid, can surrender item that isn’t needed for that raid, as collateral. If they don’t cooperate, they get kicked out of the guild, and the item is sold, and money split between the offended guild members. But this brings up another problem, who do they surrender the item to? Another guild member? Someone could spend months or even years building up a reputation, eventually they get entrusted with several valuable items, then they ditch the guild with their ill gotten goods.

This game would play similar to WoW or any other MMO really, that combat is just filler, the real game is trying to figure out how to not get screwed by the people you raid with. I’d be very interested to see the solutions people come up with. I doubt the game would be very popular though.

You can find plenty of FPS, RTS, action-RPG, racing, and platforming games, but trying to find a good turn based strategy, or turn based RPG is like finding a needle in a hay stack. Most developers will not touch turn based combat with a ten foot pole. Many people have suggested that turn based combat is obsolete, and only ever existed because of hardware limitations. I don’t buy that excuse, but if its true, I should be very grateful to hardware limitations, for making some of my favorite games possible.

Turn based games and real time games both have a number of pros and cons, but there’s no reason to dismiss turn based games as obsolete when they offer something that real time games do very poorly, planning ahead. Putting aside RTS for a moment, its pretty clear to see that games like FPSs and fighting games for instance, may have some tactical considerations, but there’s no room for any long term strategy. If you tried to plan out a long term strategy in those games, you’d probably get killed, for not acting quick enough.

No RTSs have a bit more strategy to them, as the name would suggest, but where exactly does this come from. There’s a related genre of games called real time tactics, and what separates real time strategy from real time tactics. From wikipedia “Typical real-time strategy titles encourage the player to focus on logistics and production as much as or more than combat, whereas real-time tactics games commonly do not feature resource-gathering, production, base-building or economic management”

That’s it! What separates RTS from RTT? Gathering resources, constructing a base, building units. Gathering resources takes time, building a base takes time, building units takes time. Any thing that slows down the game, and delays a confrontation makes the game more strategic, gives you more time to plan. Its what separates RTS from RTT. Without those delaying mechanics, people playing RTT games don’t have the luxury of taking their time to plan out a long term strategy, and will mostly think in the short term.

Turn based games, are by their very nature the slowest games possible, and give you all the time you need to plan your next move, adding depth to the planning and strategy. RTS games, through various delaying mechanics give you a bit of strategy, but fall short of turn based games. There is another group of games that comes to mind, that uses delaying mechanics, to try and add a bit of strategy, and still have the urgency of real time games.

If you know me you can expect me to bring up Final Fantasy. Several games in the series used an Active Time Battle system, where you must wait for a gauge to fill up before you can attack, and the enemies also have these, and if you wait too long to attack, your enemies will keep attacking you. I can see the appeal of trying to capture the urgency of real time games, but putting in delaying mechanics to give you a chance to come up with a strategy, sounds good in theory, but in practice it failed. It was just too urgent to really think about your moves, and might of well have been real time.

So whats the point I’m trying to make. Games that mix strategy and urgency can be really fun, but no matter how many delaying mechanics you put in a game, it will never have the same long term strategy and planning as a real time game. That’s why turn based games will never be obsolete.

I’ve only played a couple RTS games on Console, and only a few more on PC, and generally speaking, the PC ones were a lot better. Although the console ones could provide a bit of entertainment, they tended to be too simple for any deep strategy to emerge. My experience with console RTSs was mostly with Halo Wars, and Brutal Legend, which have very different ways of compensating for being on consoles.  Well I also played a demo of Endwar, which I can only hope was a poor representation of the game, cause that demo sucked.

So first of all is Halo Wars. Unlike Brutal Legend, which has a very distinct play style, Halo Wars, is basically a very simplified version of Starcraft or other PC RTS. You gather resources, build a base, build units, and send them to kill the enemy base. Notable shortcomings include very few types of units, can’t build buildings anywhere, only at specific bases. These and other simplifications are basically necessary to make up for the lack of hotkeys. Having all the buildings in a few locations around the map makes it very easy to switch between. Overall it was a generally enjoyable game but far to shallow to be of lasting interest.

Brutal Legend was quite a bit different in its approach. It was hardly a strategy game, it was mostly an action game, hack n slash, whatever. There were only a few strategy parts to the game, and Tim Schafer himself tell people not to play those sections as an RTS. We already have action RPGs, so action RTS seems acceptable to me. The core idea of all the soldiers basically being there to support you, and focusing on your own character seems like a solid game concept.

Brutal Legend might be the prototype for future console RTSs which have small scale largely centered around your character, instead of larger multifronted battles. It certainly gets around the problem of not having enough hotkeys that traditional RTSs would have on a console. Of course as great as brutal legend is with its new gameplay style, Tim Schafer himself says its not a real RTS and I tend to agree. For a real RTS to work on consoles they still have to get over the hurdle of hotkeys, or have a very simplified strategy game.

Well their might be a way for consoles to have a replacement for hotkeys, through speech recognition. I understand Endwar did this, so its unfortunate I only played the demo and not the whole game, to judge how well it worked, but the concept is solid. Actually I don’t think I would use speech commands in the same way as Endwar. The controller would still be the primary way to control the game. Hotcommands would just be used to quickly select groups pf units, or buildings from around the map. As I understand it Endwar didn’t really have buildings, so its not exactly a good example of what I’m trying to say.

Microsoft Kinect might be good for this, and not cause of the motion tracking cameras or anything like that, but because of the speech recognition software. Before developers could make use of the microphone to make use of speech commands, but they would have to write their own speech recognition software. Now speech recognition is built into Kinect, developers can use it without a lot of hassle.

Since speech recognition allows hotcommands to be used in the place of hotkeys, and the lack of hotkeys are the only barrier to console RTS, their is no longer any reason to not make RTS on consoles, or at least Kinect, until the others get speech recognition as well.

The inspiration for this post comes from a comments over at JPH’s blog. So the he’s talking a lot about Dungeon Siege 3 demo, most of which is unrelated to the point I’m making. The main thing is that the game has a minimap but it doesn’t have a real map, but if you press R it will show a glowing path to your destination. Apparently this idea isn’t new, and can be traced back to Fable 2. Taking away the map was a design decision to make the game more intuitive.

I’ve got a great idea to make a really intuitive game. Make the game a single button press. The game goes something like this, 10 minute opening cutscene, a single button press to punch a guy in the face, and another 10 minute cutscene, followed by credits. That’s so intuitive anyone can play. No need for counter-intuitive things like maps, inventory, dialogue trees,  combat mechanics, or anything else that might make people’s heads hurt.

Sarcasm aside, are we really at the point where looking at a map  to figure out where to go next is too hard? I guess it takes the absolute genius of Visceral Games to have a button activated glowing path, and a map, in the same game. Last time I checked nobody is compelled to look at a map just cause it’s in the game, so including a map shouldn’t bother people just cause its not intuitive.

Basically your choices are to wander around with no direction if you want to explore, or go exactly where the next mission objective is. The cool thing about a map is that you can look at it and decide where to go, and figure out how to get there. Some games like Grand Theft Auto, let you choose a place on the map and it gives you a short path there on your minimap. Instead of a path that goes where the game designer wants you to go, you can have a path that goes where you want to go.

Obviously things like deciding where to go, and player choice, are far too complicated for players to handle, so its probably best to get rid of those things, in exchange for a more intuitive game.

In many of my software engineering courses in college there’s a lot of talk of writing  good software. You’re supposed to write up documents of how the software will work, and know how all the different parts interact. Before you even start writing the software you should have a design that makes sense.

There’s nothing like doing things the wrong way, to teach you the importance of doing things the right way. Although I’m not really writing any code exactly, the same rules about good design still apply. GameMaker does have a scripting language, but I’m not using it too much cause it has a number of powerful features that don’t require any scripting.

So for an example of some bad design decisions on my part I’ll give a quick example. In GameMaker there are a number of different objects(what GameMaker refers to as objects would be equivalent to classes in object oriented programming, and what GameMaker calls instances of objects are equivalent to objects in object oriented programming, and it is helpful to think of them as such). So we have 2 objects, a bullet and an enemy. When they collide we want 2 things to happen, the bullet gets destroyed and the enemy takes a certain amount of damage.

There are two ways to trigger this event, we can put a collision event with the enemy in the bullet object, or we can put a collision event with the bullet in enemy class. I’m sure there are pros and cons to both methods, but the worst thing to do, is what I did. I did both ways. The bullet contains collision events for some enemies, and some enemies contain collision events for bullets. This problem gets even worse as I added more types of bullets, and even more enemies.

As it turns out GameMaker has inheritance, which basically means I can make an object with certain events, like for example collision with bullet causes it to take damage, and I only have to make it once and other objects can inherit it. There were two tutorials that came with GameMaker neither of which explained how to use inheritance in GameMaker, but some online sources explained how to do it, and it will make things a lot easier in the future.

Another problem with my design, is coupling between two objects. Coupling is when two classes or, as GameMaker calls them, objects are closely tied together that one can’t function properly without the other. Depending on the situation you might merge them into on class, redesign the two classes to be less dependent, or it might be acceptable to leave it the way it is(or so I’m told). The two things I had closely coupled where the Player and the HUD that displays his stats and stuff on the screen.

First of all, health is a global variable in GameMaker. If I wanted I could make my own variable representing health and put it in the player class, but I didn’t, both the HUD and the player access the health variable. When the player gets hit he lowers the health, and the HUD displays health on the screen.What happens when the health reaches 0? The HUD has an event to kill the player and restart the game. Why is it in the HUD and not the player class, not sure, and I don’t think its a big deal either way, a much worse problem comes up later.

GameMaker has a little check box that lets you make an object persistent. What that means is that when you go to a new room, the player and HUD will still be there, even though everything else that was in the room will be gone. To proceed through the game the player needs to collect items and these items will be tracked with variables. Where are these variables stored? Well this is really the problem, I’ve got a whole mess of variables that should either be in the player class, or maybe in they’re own class, and they are split, some are in the player class and some are in the HUD.

It didn’t matter a lot to me since the player and HUD were both persistent, and that was what was most important. I needed the variables to be there all the time. Now it seems pretty foolish and there needs to be a redesign in order to keep this project manageable.

And that’s pretty much all I have to say about that. Go ahead and leave comments on how foolish I am.