Pay-to-Win Games, Part 2: Money-Making Secrets

This is Part 2 of my series on designing pay-to-win games. Those who haven’t read Part 1 may read it here.

The design of a pay-to-win game should encourage players to spend their real-life cash instead of camping. In the parlance of so-called “social games” (i.e., pay-to-win games that you usually find on Facebook and mobile devices), camping means spending days or even weeks at a time accumulating resources to purchase items that can improve the player’s stats without leveling up. As I explained in my previous blog post, leveling up too fast is bad for players. Those who realize this may camp over long periods of time to try to maximize their stats before doing anything that will earn them experience points. From a developer’s standpoint, camping is undesirable because not only does it make for a dull game, but it also allows players to get away with mooching off your hard work. While you can’t expect the majority of players to part with their money, you should aim to get a significant minority to pay you on a fairly regular basis. This blog post reveals the various game designs I’ve seen that encourage players to be repeat paying customers.

Be warned that what I’ve written here sounds downright manipulative in some parts. If you believe that game designers should be as guileless as Santa Claus, stop reading now. If you don’t want your faith in humanity shaken to its core, go to some other website that will fill you with childlike wonder. I’ll level with you. I don’t like the pay-to-win mentality, but I’m amazed that a significant number of players support it. Even if you choose not to make a pay-to-win game, knowing what works in these kinds of games may help you understand what makes players tick. On the other hand, if you prefer to cash in on the pay-to-win scene, you may learn a few tricks from this blog post. Either way, you’ve come to the right place.

Bulk Discounts on Premium Currency

Pay-to-win games usually feature two kinds of currency. The standard currency is earned by purchasing certain items that provide regular income. Premium currency is gained by purchasing them with real money. This kind of currency is then used to buy premium items. Designers will generally want to provide bulk discounts on premium currency to encourage players to spend more of their real money.

Pricing Premium Items

We can categorize premium items into three types. The first type provides a direct and permanent increase in players’ stats. This type of premium item is what pay-to-win games are known for. Depending on the game, these items may come in the form of weapons, armor, units, military buildings, and whatnot. Regular premium items of this sort are available on the market all the time, but others are “limited edition” items that are sold for only a few days before disappearing from the market entirely. Afterward, a different set of limited edition items will be sold. Limited edition items usually provide much better stat boosts than regular items of a similar price.

The second type of premium item does not provide permanent stat boosts but helps in the completion of certain activities. Some premium items refill players’ energy so they can continue to do quests. Others accelerate the time it takes for players to complete a task, such as constructing an income-generating building or traveling from place to place. Others, such as spells in some games, offer stat boosts for a limited duration.

The third type of premium item comes in the form of packages that contain other items that may or may not provide a permanent stat improvement. These packages are rather like booster packs in collectible card games. Some of them are purchased with premium currency. Others are acquired by completing quests but may require the use of premium currency to open. The random content of these packages makes acquiring or opening them a form of gambling, one where the odds may not always be disclosed. This may be legally problematic in some countries, so I won’t discuss them further in this blog post.

Regular premium items (as opposed to limited edition items) that provide a direct and permanent stat boost should be very expensive relative to the benefits they provide. In fact, they should be overpriced. The higher the stat improvement they give, the more exorbitant they should be. If players are desperate enough to purchase these items, they should pay through the nose for them. Other types of premium items that provide an indirect benefit, such as energy refills and temporary spell boosts, should be relatively cheap.

It may seem odd that I would recommend setting too high a price on the very items that pay-to-win games are known for. If developers do that, aren’t they effectively discouraging players from buying them? Yes, they are, and that’s a good thing. Among premium items of the first type, developers expect players to buy the limited edition items rather than the regular ones. They also expect to sell more of the second type of premium item, especially when they are used with quest ladders, which I explain below. The expensive items are actually decoys. They serve as a reference point for making the cheaper items seem well worth their cost. The use of expensive decoys is called price relativity, a topic that has been studied extensively in behavioral economics. It is known to work effectively, which is why developers of pay-to-win games use it.

Loss of Resources to Attacks

In pay-to-win games, nothing irks players more than losing resources to rival players’ attacks. These resources may be units or buildings that are destroyed during an attack, but what’s more common in most games I’ve seen is for players to steal standard currency from each other. Since premium currency is bought with real money, it should be never be subject to theft.

It may seem irrational for players to get outraged over the theft of virtual money, but that’s human nature for you. What’s astonishing is that some players are willing to spend real money on premium items to protect their virtual money. Again, that’s part of human nature. Behavioral economists have known for some time that people fear loss much more than they desire gain. It seems that many people fear virtual loss as much as they fear actual loss. Developers can take advantage of this by providing rewards for getting players to attack one another. This will encourage more players to protect their virtual assets by purchasing premium items.

Rewards versus Experience Points

When deciding whether to complete a quest, players will balance the items and currency to be gained versus the experience points offered. Remember that in pay-to-win games, items that boost players’ stats are good but leveling up is usually bad. Hence, items equate to rewards, but experience points equate to risk. Currency by itself isn’t much of a reward unless it is high enough to purchase sufficiently powerful items. If the rewards cause players to be more powerful than if they were to camp, players will ditch camping in favor of fulfilling quests. Campers will then find themselves helpless against more active players. For this to work, however, players will have to know what they stand to gain by fulfilling the quest. If they don’t know what the risk and rewards are, they may choose to camp instead. As long as the rewards are high enough vis-à-vis the risks, players will be eager to complete them.

Developers should not make all quests particularly rewarding to fulfill, however. Only those quests that may require the use of premium items to complete should have good rewards. These types of quests are generally Limited Time Quests, which I discuss next.

Regular Quests versus Limited Time Quests

Most pay-to-win games have quests that may be completed at any time. Since there is no urgency to complete them, players may camp all they want without missing out on anything. These quests typically reward players only with in-game currency and experience points, so campers tend to undertake them only when they are ready to level up. Limited Time Quests, however, start at a particular date and time and have to be completed before the given deadline. Because some Limited Time Quests are so difficult and time consuming that they require the use of certain premium items such as energy refills or spell boosts to complete them, they tend to offer much better rewards than regular quests. These are the types of quests that should encourage players to be active instead of camping.

By hosting Limited Time Quests at least once every two weeks, developers are more likely to get a steady income stream than if they were to offer only regular quests.

Quest Ladders

Some quests are actually composed of a series of progressively more difficult quests. I call them quest ladders for lack of a better term. Completing one quest in a ladder leads to the next quest in the series. The first quest is easy, but the succeeding quests are more difficult than the last. Likewise, the rewards are initially small, but they get exponentially more desirable as players rise up the ladder.

The best quest ladders I’ve seen are also Limited Time Quests. In these quests, the rewards should be much, much better than whatever premium items may be bought directly. By the time players reach the higher rungs, fulfilling the quests on time may be so difficult as to require the use of energy refills, which can only be bought with premium currency. With the ultimate reward in sight, a number of players will deem the cost worth it.

If players can acquire superior premium items that can only be gained through a combination of effort, energy refills, and temporary spell boosts, they will feel that their expenditure is well worth the cost. In fact, the inferior premium items that can be bought at an exorbitant price are there to make the energy refills and spell boosts look cheap by comparison. Besides, players tend to feel much better about themselves if they get ahead in the game by “playing smart.” Just as predators prefer to hunt living prey than eat something that is already dead, players prefer to win a prize through effort than simply paying for it outright. The best pay-to-win games require their players to earn superior items by being active while paying to complete the more difficult quests on time.

Team Quests

Some games allow players to band together in teams that can pool resources and gain common rewards. Developers can design quests that only teams can complete. Some of these may be regular quests that the team may finish at its leisure, but the quests that are more likely to spur the team to activity are Limited Time Quests. If the rewards for fulfilling team quests are better than those of individual quests, players will generally prefer to band together. The same reward may be granted to all members of a team, or the rewards may be prorated according to how much each team member contributed toward completing each quest. If experience points are given to everyone regardless of their participation in team quests, then even campers in the team may find themselves leveling up faster than they want to. Campers who are not in any team may soon find themselves being trounced by team players.

Evolving the Game

Even after releasing their game, developers should continually mine their data on player behavior to adjust the game as needed. If more and more players resort to camping or simply drop out of the game, developers should try to find out why. If player participation is high but sales of premium currency drops, developers should determine what needs to be fixed. The game should evolve as the need arises, changing the benefits of some items if necessary and introducing new types of quests. If the game never changes in any significant manner after its release, players may get bored and seek other games to play instead.

Pay-to-Win Games, Part 1: Why, Oh Why?

When I first got an iPhone, I immediately downloaded several free-to-play games to check them out. It didn’t take me long to realize that for a number of these games, leveling up too fast is an insidious trap. Leveling up only gives you a token number of points to improve your avatar, but the bulk of your avatar’s strength actually hinges on getting other players to ally with you and equipping each of them with certain items that you acquire in the game. These items usually come in the form of weapons or armor, although in some games, they appear as superpowers of some sort or creatures that can fight under your allies’ command. The net effect of having these allies and items is to raise your avatar’s attack and defense stats. There are other items that can be purchased that provide income for your avatar over a period of time. You’ll need this income to purchase better but more expensive items. It takes a long time to generate enough in-game money to acquire the best items that can be purchased at any given level, so leveling up too fast will pit you against players who’ve taken the time to make themselves powerful.

The reality behind many free-to-play games is that they are actually pay-to-win. Most items can be purchased using in-game money, but there are also premium items that can only be acquired by spending a second type of currency that is bought with real money. Players who spend lots of real money on premium items are more likely to trounce players who don’t. This is why games that feature these types of microtransactions are called pay-to-win games.

I find the idea of bringing in real money to acquire significant advantages over other players both disturbing and fascinating. Games are supposed to be tests of skill, so it seems patently unfair to allow players to buy their way to victory. One might argue that professional athletes make use of expensive gear and training to give them an edge in their sport, but the fact remains that no matter how much money they spend, it is still their skill that wins them the day. With pay-to-win games, on the other hand, enough real-life mullah can easily substitute for whatever skill their simple game mechanics involve.

Nevertheless, the pay-to-win business model actually works. I assume that most players don’t spend real money on these games, but the ones who do spend enough to keep the developers afloat. While developers of paid games lose some potential income to piracy, developers of pay-to-win games don’t have to worry about piracy at all. This puts pressure on some developers to abandon their traditional business models in favor of pay-to-win models.

Pay-to-win isn’t a fad. Like it or not, it’s here to stay. From a developer’s standpoint, the question is how to design pay-to-win games that are commercially successful. In my next blog post, I will expose a few tricks that I’ve observed.

Before You Make an MMORPG

If you’ve never made a videogame before and want to jump right into making a Massively Multiplayer Online Role-Playing Game, stop right there. An MMORPG is one of the most difficult and resource-intensive types of games that anyone could ever attempt to develop. Rather than setting yourself up for an epic failure, do what the pros do and get your feet wet on something much, much simpler to develop.

Once upon a time, there was a guy who had acquired some game development experience by working for a number of professional studios. He didn’t start out making an MMORPG though. As part of a development team, he worked on a mediocre sidescroller about a mutated monkey and on a decent game about a bat who was a circus acro-bat. (Get it?)

It was only after he worked on those and other games that he figured he could start a game studio of his own. He got a couple more buddies to found a company called Condor. They actually had enough clout to make a fighting game featuring several well known superheroes and super villains.

Armed with a lot of experience making videogames, it was only then that they started working on an RPG. It wasn’t a multiplayer RPG, mind you. It was just single player. Even then, their game didn’t have a multitude of character classes. It only had three: a melee-type character, a ranged character, and a wizard. These three character classes didn’t go adventuring together. Players could only control one character.

Because of the developers’ prior experience in making videogames (and perhaps because of the marketing clout of a much larger company that decided to acquire their studio), the RPG they made was a big hit. Only then did the developers feel confident enough to make a sequel that featured more character classes as well as a multiplayer mode.

The name of that game was Diablo. Condor was acquired by Blizzard before the release of their RPG and was renamed to Blizzard North.

Don’t start by making your first game an MMORPG. Make some casual single-player games first. You may be surprised to find out just how challenging it is to make a decent casual game. Only when you have considerable experience under your belt should you venture into single-player RPGs. If you can make a successful RPG, you’ll have what it takes to develop MMORPGs.

Afterword

This post first appeared in its earliest form in a forum thread started by a guy who wanted to make his first game an MMORPG. He had come up with a plethora of character classes and tried to solicit more class ideas in his thread. Most of the classes he came up with were of wizard types: druid, sorcerer, pyromancer, aeromancer, geomancer, cryomancer, and necromancer. By the time he had made eleven character classes, I decided to post my advice shown above.

To my surprise, I found that my post was well received by a number of people apart from the original creator of the thread. One person likened my post to an entertaining game in itself, and another person suggested that a “sticky” thread for posts such as mine be created in the forum. I figured that if people liked my post that much, I might as well write a version of it on my blog.

Well, here it is. Hope you liked it too.

Post Mortem: The Proper Care and Feeding of Your Demons

A new Game in Ten Days (GitD) jam was started in Kongregate last week, this time with Collection as the theme. Every time I hear of a new GitD contest, my eyes mist over, and visions of a game start playing before my eyes. If I didn’t have other projects ongoing, I’d probably join every GitD contest as they come just so I could materialize the visions I see before me.

For this month’s theme, I chose to make a game called “The Proper Care and Feeding of Your Demons.” It’s basically a match-3 game where the objective is to defeat your rivals in astral combat by summoning demons to fight for you. Each time you defeat an opponent, you learn how to summon one of his demons. In my game, you can collect up to six demons to summon, but you can only pit up to four at a time in combat. The concept for this game is partly inspired by Pokemon of all things.

Pokemon wasn’t the only inspiration I drew upon. Prior to the contest, I had recently bought a game that was on sale in Steam called “Puzzle Kingdoms.” Like the Puzzle Quest series before it, Puzzle Kingdoms is a match-3 game. Unlike Puzzle Quest, where matching tiles gives you the mana to cast spells, matching tiles in Puzzle Kingdoms allows you to ready the troops at your command for an attack. I liked the tactical aspect of this game, so the mechanics that I came up with isn’t too far off from that of Puzzle Kingdoms.

In my game, players are presented with a 9×9 grid filled with sigils, each of which represents an emotion. Demons feed on the emotions that they are associated with, so players need to make enough matches of their particular sigil to summon them. Once a demon is summoned, players will need to match the minimum number of sigils that the demon needs to get it to attack.

By the time I was deep into the development of this game, I started to worry that deeply religious people might take offense to it. Fortunately, religious beliefs were never an issue among the players who commented on my game.

My game didn’t win the contest, but it didn’t do too shabbily in terms of number of votes garnered. Early during the voting period, feedback was few and far between, so I had to encourage voters to post their comments on the games. It looks like my encouragement bore fruit, because our entries soon had plenty of good feedback from the voters.

Raw Feedback

Here are the comments that I got on my game:

1. Love the graphics, the humor, the theme. Not such a fan of the gameplay (too much randomness, not enough diverse effects, not clear who attacks what when), and the music after the first two loops. Proper theme fit.


2. Proper Care and Feeding of your Demons gets my (hypothetical) third vote. I love the professionalism in this game. The reason I didn’t give it my second vote is because I personally have a moderate distaste for these kinds of games. I must still admit that it is very well done.


3. Feeding Your Demons: You were my third place choice. Love the menu, love the concept, though you didn’t really hit the theme too well. It’s very hard to plan in these games, but maybe it’s because I’m bad at them. random moves would give me 12 combos that I never could have foreseen, and I never got any benefit from. overall, too luck based, and very easy to win.


4. First thing instantly apparent. Great art! Got confused abit about how to actually play until I read the description. I think I managed to break the game though. It seems to be stalled without me being able to click anything. (I think I was randomly clicking around the board and that it read me trying to swap 2 gems on the board?)
   
   Alright a smoother run 2nd time around. Interesting concept for me, but as others have stated it was very reliant on luck. Would be interesting to see more varied styles of attack, as well as more strategy in choosing which sigils to take. (Such as activating certain special abilities of demons that have different effects, both on the enemy and on the board itself.)


5. Nice implementation, though as others have said, it is far too luck-based (which is a common problem for those types of games). Maybe have the sigils that drop in be inactive for two turns (thus not being auto-collectable for the current player or their opponent, but also allowing the opponent an opportunity to disrupt any auto-matches that would occur for the current player)? Or having the dropped sigils be “blanks” that would determine their type based on its adjacent sigils’ type (thus making any auto-matches rare; it would probably be best to have a weighted random selection, where the most common adjacents get the least weight)? Or perhaps the dropped-in sigils could be inactive until an adjacent match is made (though this would potentially still allow auto-match chains)?


6. Fun game mechanic. Not sure about the demon stuff, seeing a ton of combos is cool, because usually that is good… then you realize they’re all useless and it’s like :/ Also matches were too esay, didn’t lose when I didn’t know the rules, then once I did I was winning before they could even summon them


7. I’m not concerned with the amount of luck involved. The battles are long enough that one or two big combos won’t ruin your chances. I spent enough time labouring over many decisions to feel as though I had sufficient control over my fate.
   
   You probably shouldn’t be able to use more demons than your opponent. Not only does it make for some easy fights, but it meant there was little need to consider the differences between the demons and make strategic selections. You just play them all until the final round.
   
   As for the theme, I’d have been more impressed if I didn’t have the full set until after the last fight.
   
   Kudos for start muted.


8. Interesting start to the game. The graphics are very cleanly done and most of the UI looks professional. Navigating your way to look at your Demons and back to a fight is pretty confusing, though. Once the match starts things go a bit down hill. The matches seem to mostly be about placing your pieces and hoping you get a seriously long chain. The game also seems to bug out sometimes and cause your creatures to attack on the other players turn. For that matter telling the difference between your turn and the other players turn can be quite the hassle unless you are watching the boxes around the player icons. Having some sort of pop up over the center of the playing board for a second that shows the current players name might go far to fix that.
   
   The primary issue I have with this game is that while it covers the theme as you have to collect the Demons to fight with it is secondary to the gameplay of the game.


9. I liked the idea behind this, but it was a little tricky to get into, not enough was explained or simplified. I found I could use my opponents sigils, I don’t know if that was inentino or not. Gameplay was too slow and froze when a board icon went missing entirely. I didn’t really know how to play effectively, eg whether certain icons were better to clear than others and so on. Polish it it a ton more!


10. I loved the idea but the actual combat has too much luck involved in it for my taste also not a fan bejeweled


11. Simple match3, I know, but I liked it. There was a bug when I played it: I fought the opponents, from left to right, and accidentally clicked the second-to-last guy twice. Beating him a second time completed the game, before I even fought “Wicked Wendy.” Also, it’d be cool if I could choose my character name/avatar…unless you planned on building an actual story around ol’ Sam. Anyhow, when a game holds my interest all the way to the end, it’s done something right. Nice job. Maybe for polish, give the demons different-looking attacks (Ifrit should be throwing fireballs, not lightning bolts!) By the way, I quite enjoyed the music. Where’s it from?

Common Points Raised

I got some really good feedback on my game, so much so that I’d like to list the different points raised and reflect on how I might address them.

Randomness of the Gameplay

Early during the development of this game, I was startled with how often a cascade of successive matches was made whenever a player made a match. In the Puzzle Quest series as well as Puzzle Kingdoms, a quick succession of matches in a single move would happen on occasion, but in my game, it was happening almost every turn. I didn’t have enough time to address this particular problem, but now that the contest is over, I’ve had time to figure out what was going on.

Apparently, there are a number of features in my game that contribute toward the frequent random matches that are made.

• What qualifies as a match. In many match-3 games, an adjacent set of matching tiles have to be in a single horizontal or vertical line to count as a match. In my game, however, as long as the matching tiles are adjacent to each other, the game considers them to constitute a match. Hence, L-shapes, T-shapes, or any other shape involving horizontally and/or vertically adjacent tiles of the same type are all considered matches. This is also how Puzzle Kingdoms counts matches, but it should be noted that for some reason, Puzzle Kingdoms doesn’t have frequent random matches the way my game does. What I like about this mechanic is that it is easier to match more tiles when they don’t have to be in a single row or column. It is easier to make matches in this manner, but it is also easier for random matches to appear. I’ve verified that if I were to consider only adjacent matching tiles in a row or column as match, I would significantly reduce the number of successive random matches that take place. With the combat mechanics as they currently stand, however, battles would also take much longer.
• The size of the grid. I’ve found that if I were to reduce the size of the grid, I would effectively reduce the chances of making any match, deliberate or random. The size of my game’s grid is currently 9×9. By comparison, the grid in Puzzle Quest is 8×8, while that of Puzzle Kingdoms is 7×6. Even with a to 5 ×6 grid in my game, however, the number of randomly occurring matches is still disconcertingly high.
• The number of different tile types. My game has only six different tiles, each of which represents a particular emotion, whereas Puzzle Quest has eight different tiles. Puzzle Kingdoms also has eight different tiles, but one of them (the wall) cannot be used to make a match. It stands to reason that the more tiles there are in a match-3 game, the less likely it is for a random match to appear.  Nevertheless, I’ve found that increasing the number of tiles in my game will only result in a slight reduction of random matches and makes it more difficult for players to produce matches.

The fifth comment that I received on my game presented a number of suggestions for reducing the occurrence of random matches, but they all look unnecessarily complicated. It seems that my best options are to either consider only adjacent sigils within a row or column as a match or to reduce the size of my grid to 7×7 and increase the number of sigils to eight. I’ve tried both, so I know that either of these options will significantly reduce the number of randomly occurring matches.

Needs Different Attacks, Special Abilities, and Combos

Now this is a very interesting set of comments. Although the demons differ in terms of stats, these differences may not be obvious to some players. From my playtests, I’d say that the differences are significant enough to affect the gameplay, but I could have done more to distinguish the demons further if only I had the time to do so. Now that the contest is over, I guess I have as much time as I need.

All the demons in my game have only one kind of attack. It would be interesting if they could launch different attacks depending perhaps on how the sigils are matched. Even more interesting would be to find ways to combine the demons’ attacks to launch special combos. Finally, the suggestion that certain effects may be able to affect the board is seriously worth looking into.

Confusing to Play

During a battle, the only way to tell whose turn it is is to check which player’s portrait has an orange frame around it. In the meantime, a lot of sigil matches and demon attacks may be occurring in rapid succession, making it confusing to tell who is attacking whom. It doesn’t help that attacks are indicated by having a bolt of lightning instantaneously arcing from the attacker to its target. To make matters worse, none of the figures in my game are animated, which makes it even more difficult to distinguish the aggressor from the victim.

The way to solve this issue is to have more graphical indicators of whose turn it is. The orange frame around the active player’s portrait is not enough. I can dim the portrait of the inactive player perhaps. I can also animate all the figures to make it obvious which ones are attacking and which ones are taking damage. In addition, I can have the player avatars do appropriate gestures for swapping sigils, summoning demons, and commanding them to attack.

To top it all, my game lacks a tutorial, which would have alleviated some of the confusion that arose. Unlike most match-3 games, swapping tiles in my game involves choosing a tile from the player’s set of tiles and exchanging it with one of the tiles on the board. Also, depending on the player’s roster of demons, some tiles are important to match, and clearing others has no effect at all. If I had enough time, I would have included an in-game tutorial that explains how to play and win.

Too Easy

During my playtest, the sheer randomness of outcomes meant that there were often times when I would lose despite my best efforts. Consequently, I decided to err on the side of making the game too easy because I didn’t want to risk frustrating my players to the point that they wouldn’t want to play my game anymore. Neither extreme is ultimately acceptable, however, so the only solution is to put in lots of playtesting and to tweak the game’s difficulty in the process.

Great Aesthetics

In truth, I didn’t make most of the art myself. I downloaded them from the Internet and gave credit to those whom I could identify as the artist. I’m actually a capable artist myself, but I’ve learned that trying to make a lot of good art during a game jam gives me precious little time to program and test the game. Nevertheless, I was responsible for putting everything together in an aesthetically harmonious way, which makes me glad that I do have some talent in the arts.

That said, I’m not entirely satisfied with the Facebook-style interface that I designed. I would have preferred to show a section of the city where the player character lives. The city scene would have buildings that players can click on to bring their avatars inside, where they could then meet other characters for them to interact with. All this would have needed far more time to implement however, so I had to cut corners by making an interface that looks a bit like an office application. For an expanded version of this game, however, I would prefer to go with my original idea of having an interactive city map.

Good Concept

I’m not sure if what was meant here is that demon summoning made for a good game concept in itself or if the match-3 mechanic for demon summoning was good. Personally, I think that sigils as tiles, a grid that is reminiscent of magic squares, and the subject of demon summoning all combine in a cohesive way in my match-3 game, but of course I’m biased. On the other hand, if I were to expand this game further, I would probably have to consider how to make it palatable to players who uphold strict religious beliefs. To me, the demons in my game are a kind of metaphor for strong emotional forces and how they can drive people to do either wonderful or terrible things. I don’t want to lose that metaphor as I believe it has some potential for a good story. Nevertheless, it is not my intention to espouse real-life attempts to summon demons, just as game developers who let players take on the role of gangsters do not espouse a life of crime. This is an area where I will have to tread carefully.

Doesn’t Fit the GitD Theme Well

This is the least of my worries. I have my sights set on a much bigger prize than winning the contest itself. I want to be able to make games that are popular and highly rated on a consistent basis. As far as I’m concerned, the GitD serves as both a source of inspiration and as a trial balloon of sorts. I find that it is a good opportunity to rapidly prototype a concept and see how well it is received. From the looks of it, I’d say that this particular game may be worth developing further.

Voting Results

It seems that my game development skills are improving because I got a good number of votes this time around. Among the twelve entries in this month’s GitD, my game got sixth place, a decent showing if not a particularly good one. I interpret this to mean that there is some potential in my game that may be realized if I address the issues raised.

It should be noted, however, that I only got about a third of the votes of the first place winner. Apparently, the frequency with which random matches would come up was the most critical issue among voters. Also, some voters prefer action platformers to match-3 games. I, on the other hand, dislike action platformers and prefer more cerebral entertainment. There is probably a much bigger market for action games than match-3 games, but I prefer to develop for a niche I enjoy than one that I don’t.

Another issue that voters took very seriously was whether my game fit the Collection theme. Some voters believed that it did. Others didn’t think so. This issue isn’t really important to me as far as learning how to develop enjoyable games is concerned, but I can’t help but wonder if my game would have gotten more votes if everyone allowed for a liberal interpretation of the theme. If it did, that would have confirmed all the more that I have a potentially good game in my hands.

Component-Oriented Programming

Over at the Kongregate forums, a guy named Drakim wrote a series of posts on a relatively new programming paradigm that has come to be called Component-Based Development or Component-Oriented Programming. Basically, this new paradigm does away with inheritance to create classes and builds software entities by assembling components instead. Using this paradigm doesn’t require new languages for component-based development. You can still use your favorite Object-Oriented Programming language as long as you avoid the temptation to use inheritance to build classes. In truth, there’s nothing to stop you from mixing and matching the two paradigms if you wish, but inheritance forces child classes to inherit all the properties and methods of its parent, whereas classes assembled with components will have only the functionalities that their components provide, no more and no less.

What I like about this new paradigm is that it solves an issue that I’ve been wondering about for some time – multiple inheritance. Most OOP languages don’t implement multiple inheritance and with good reason. Things can get messy pretty fast if the multiple parents of a class have their own way of implementing common properties or methods. With a component-based architecture, however, all you need to do is to build and slap on the components that each class needs, and you’re good to go.

All this is fairly new to me, so I’m in no position to talk about it at length. Instead, I’m posting the links to Drakim’s series of articles for future reference.

Part 1 – A criticism of OOP in game development

Part 2 – Composition over inheritance

Part 3 – Events to the rescue!
Part 4 – Examples and advanced techniques

Sculptris is Great

I’ve been playing around with a program called Sculptris, which I downloaded a while back. Sculptris sounds like it might be a videogame about falling blocks, but it’s actually a 3D sculpting application that was developed by the makers of ZBrush, Pixologic. When it comes to sculpting a new model from scratch, Sculptris is actually superior to its older sibling. Each model generally starts life in Sculptris as a simple sphere, which the user can shape into a detailed organic model with the tools at his disposal. As the user sculpts his model, Sculptris automatically subdivides the area under the brush to accommodate more detail. As of this writing, I know of no other 3D modeling application that does that.

That said, there are still a few kinks in this application that Pixologic needs to iron out. As the poly count of a model  increases, so does the chance of Sculptris suddenly crashing. Fortunately, Sculptris saves the current work in progress periodically and seamlessly. Running it after a crash will automatically load its last save file.

While Sculptris is great for sculpting organic models, it doesn’t come with a lot of bells and whistles. If you want to retopologize a model or change its pose, you’ll need to use other 3D applications for that. Nevertheless, using Sculptris is probably the closest one can get to molding clay in digital form. What’s more, it’s free. That, along with its ease of use, makes Sculptris a winner.

Post Mortem: Dungeoneers

Last week, I participated in another Game in Ten Days (GitD) contest, this time with “Dungeons” as its theme. I’d have preferred to finish my works in progress before joining another game jam, but the theme was just too good for me to pass up. I eventually made a Flash game whose working title was “Dungeon Dweller Exterminators,” but I changed it to “Dungeoneers” upon release.

I wish I had blogged each day about what I had done if only to keep an accurate record of my working process. I was pressed for time, however, so I chose not to write about it. Next time I join a game jam, I really should keep a journal of what I do.

Currently, my game lets players hire adventurers and form a party of up to four of them to explore the four levels of a dungeon. All the action takes place in a top-down view of the dungeon, although I would have preferred using an isometric view if only I had enough time to implement it. Players can move the entire party by clicking on any part of the dungeon level with the mouse. Once the adventurers encounter enemies, however, they will automatically decide which of them to target. I wanted players to be able to also choose targets for each adventurer to add more tactical depth, but I didn’t have time to implement that. Neither was I able to provide an in-game tutorial or instructions on how to play the game, although despite that, I found that players were able to figure out what to do. The worst part was that I didn’t have time to design the levels to make them tactically interesting or to test my combat system thoroughly. That failure was what voters zeroed-in on.

As of this writing, it appears that most if not all of the votes have been sent, and it is obvious that my entry won’t win. Unlike the last GitD that I joined, though, I did get a few votes this time around. Not everyone who voted gave feedback, but I am grateful to the ones who did. Because of them, I know that my game may be an ugly duckling now, but it has the potential to become a beautiful swan. Below is the feedback that I received on my game:

• Not really good at its current state, but gives a hint of what can become of it after some polishing, and that looks really promising. Most of the things I could suggest have to do with polishing x or y aspect, so I’ll just skip those. Gameplay wise, the combat system seemed rather strange; units seemed to have a really shitty accuracy. Even the rangers would miss half of the time while the enemies were next to them, which reminds me that Diablo/that-demon-thingy seemed to be the only enemy able to hit (and kill) my units. Some work and you may have a solid game there.
• Neat start, but like…I have to ask—what’s with the combat in this game? I started writing this post while my two knights were wailing away, and they’re STILL at it. The chance to hit seems absolutely abysmal (players don’t typically like games where their characters miss all the time) and, on top of that, the time between swings is really slow. Makes the combat VERY uninteresting. Speed up the attack speeds, and mitigate damage through armor/absorption/reduction rather than evasion. I finally gave up on the…thing (skeleton?) I was fighting and ran down to fight some red thing. If I’m still fighting it when I finish this post, I’m just going to give up. Still, with some work, this could be pretty cool.
  
  PS: My knights are STILL fighting the red thing in Dungeoneers and everyone is still at full health. WTF?
• Seems like it could be very fun. It is disorientating at first though.
• I don’t know what it was but the fighting between people and creatures was extremely slow and tedious, and since that was pretty much all there was to the game, I’m afraid I didn’t stay for long.
• I made a team of exterminators and started working on the rat infestation problem at the church, but then I ran into a skeleton that neither of my guys could hit and it couldn’t do anything to them either, so that was that. Bug report though: clicking on the skeleton generated a null object reference error. Thought you might want to know.
• Receives my second vote for being a good quick mouse navigable game.
• An interesting game but sadly not a very good game. The best thing the game has is the pathfinding system. It freaked out a bit when both you and the enemy were trying to get to each other but otherwise it was very strongly done.
  
  The combat was really shallow. Apparently the Knight has so much armor nothing can hit him, even at level 1. Sadly, he also hadn’t really hit anything that is not a rat. The monk dies far too easily to tell if he can hit the skeleton/humanoid enemies on the 3rd floor. Ranger can actually shoot from a distance but it’s far too hard to see if he’s even attacking. Barbarian does good damage but also takes damage and dies a bit too easily. Considering that you gain so little money running the dungeon killing rats you can’t level up or gain new people to your party without serious rat grinding. I’m not even sure you can damage the skeleton guys or the final boss.
  
  Controls were ok but also left a lot to be desired. All you can basically do is tell your people where to go and let them to the rest. This leaves us with very little strategy. If you click a living thing on the map you get a little rotating triangle selection over it but it doesn’t seem to do anything at all. The opening screen was also very confusing as clicking the church without any people at all doesn’t explain anything.
  
  All in all the game has good promise but feels highly unfinished.
• Has potential, but as others have found, the combat just doesn’t seem to work, and that’s a pretty fundamental part of a dungeon crawler. All the effort on this one seems to have gone into the menu screen.
• my trusty Knight 2 thought he’d found a solution to the horrendously slow combat speed – making use of the excellent pathfinding to sprint for the stairs right away every time.Then he met an epileptic dragon, and since it seemed unlikely to hurt him, he couldn’t bright himself to attack it. This wasn’t the epic adventure that was expected of him.
• Decent concept, but needs a bit of work.
  
  I tried grinding far enough to get one of every fighter but the ranger (I thought maybe the monk would be good against the skeleton, but started with the knight and barbarian), but the third floor was still impossible (as far as actually harming the enemies). I also tried a single knight at level 3 — but the only noticeable difference between a level 3 knight and a level 1 knight is that he’s four times as expensive. “There’s no turning back” is kind of weird when you discover that there is turning back (as in exiting via the stairs you came in from).
• A proper dungeon crawler, with pathfinding and adventurers! I don’t really know what is good about different classes, and my pair of knights have spent the last 5 minutes fighting a skeleton(?) with neither side doing any damage. Looks promising, but unfinished, way too ambitious for 10 days

Based on the above comments, there seem to be two consistent patterns that come up again and again.

1. Combat, which happens to be the central part of the game, is the one that is most poorly implemented. Attacks take too long to execute, and often, little to no damage is dealt.
2. The game has potential, but it would take more work to get it to an enjoyable state.

When scheduling an I.T. project, there is a quick rule of thumb that says that about 30% of the entire time should be spent on designing the application, 40% on programming, and 30% on testing. If memory serves me right, what really happened was that I spent maybe 40% of my time designing the game, 50% programming it, and only 10% or less testing it. I used up much of my programming time creating a pathfinding and targeting system that would enable opposing teams to move across walled rooms and fight each other. Hardly enough time went into combat resolution.

As always, my efforts are not wasted. I now have some good code that I can always re-use in other projects. More importantly, I have the seed of a game that may wind up being engaging if I polish it just right.