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.

Its Name Is Mud

Thus far, I’ve created a few models for a Flash game that I’m co-developing with another guy. I featured one of these models in my blog earlier, an elven archer of the Unseelie Court. The game we’re working on is in 2D, but I’m using my 3D models to make tile sheets. The 2D figures are so small that much of the detail that I put in them is lost, but I figure that it’s better to have too much detail than too little.

The next model I’m making for this game is a golem, a kind of tank unit that is able to withstand a lot of punishment before dying. As usual, I started by drawing a silhouette of the creature then filling in details over the black areas. I decided that the golem should be broader than a human being, the better to block its enemies. I made its arms long so that it can plant its fists on the ground like a gorilla to achieve better stability against attacks. Its forearms and fists are large and heavy enough to act as powerful blunt weapons. The golem is devoid of ornamentation as if the wizards who constructed it were more concerned about amassing an army than creating a work of art.

The model that I designed is so simple that it only took me two days to construct and texture its mesh. The weekend is just around the corner, so I doubt if I’ll be able to work on it then. Nevertheless, I hope to finish the golem’s tile sheet by early next week.

Tutorial: Rigging a Bow in 3DS Max

This tutorial shows how to rig a bow in 3DS Max. I wrote it after having figured out how to rig a longbow that I modeled. Bows are not as straightforward to rig as, say, a creature model because the rig has to cause the wooden parts of the bow to bend when the bowstring is pulled. The string may stretch for a tiny bit, but once it has reached its full stretch, it should maintain its length the whole time. When the string is released, the bow should snap back into place, and the string should slowly vibrate to a stop without causing the bow to bend.

I didn’t have any luck searching for tutorials on the Internet about rigging a longbow in 3DS Max. I did find a good video tutorial on rigging a bow, but it’s a Blender tutorial. Nevertheless, it gave me enough clues on how to do a similar rig in 3DS Max, but the workflow that I used is sufficiently different to warrant its own tutorial. Hence, I decided to write one.

This tutorial assumes that the reader already has a bow model in 3DS Max that needs to be rigged. The tutorial does not assume that the reader knows how to set up a skeleton and weight vertices to it, so I will try to explain these processes in detail. Some knowledge on the different coordinate systems that 3DS Max uses will help in understanding the later parts of the tutorial.

Ready to begin? If so, read on.

1. Activate the Left or Right viewport. For this tutorial, I chose to activate the Right viewport to match the view in the Blender tutorial I mentioned earlier. If the mesh is not displayed in wireframe view, press [F3] to switch to it.
   
   
   


2. On the rightmost side of the screen, make sure that the Create panel is selected then click the Systems button and the Bones button.
   
   
   


3. Click on the center of the bow’s handle to begin creating bones. Keep clicking along the upper half of the bow to create a chain of bones, making sure that the joints are more or less along an edge loop of the bow. Don’t worry about precise placement at this point because we can edit the bones later. When we finally click the point where the bowstring pulls the bow, end the chain by right-clicking anywhere on the screen. This will create an extra nub bone, which we will use eventually. Rotate the nub bone so that it is perpendicular to the bowstring with the bone’s tip facing away from the bow.
   
   
   


4. Activate the Select and Move tool, which is located on the top toolbar, then click the very first bone that we created, which should be the one closest to the handle of the bow. Zoom in on the bone with the mouse wheel to get a better view of it. Reposition the bone so that it is on the exact center of the handle. We may use the Absolute Mode Transform Type-In at the bottom of the screen to input precise X, Y, and Z coordinates.
   
   
   


5. If necessary, we can adjust the placement of individual bones with the Bone Tools. Click the Animation menu then select Bone Tools to bring up a dialog box of the same name. Click the Bone Edit Mode button to toggle on bone editing mode. We can then use the Select and Move tool to edit the placement of bone joints as necessary.
   
   
   


6. Press [H] to bring up the Select from Scene dialog box. Click the first bone in the list, then with the [Shift] key pressed, click the last bone to highlight all the bones. Click the OK button. Doing this will close the dialog box and select all the bones.
   
   
   


7. In the Bone Tools dialog box, click the Mirror button to bring up another dialog box called Bone Mirror. Under Mirror Axis, click the Z radio button then click the OK button. All the bones on the upper half of the bow should then be mirrored on the bottom half.
   
   
   


8. Having made the bones that control the wooden part of the bow, we will now create a bone to control the bowstring. Zoom in to get a good view of the center of the bowstring with the mouse wheel. In the Bone Tools dialog box, click the Create Bones button then click on the center of the bowstring to start creating a new bone. Click on a point away from the bow and its string to make a bone that is aligned like a nocked arrow. Right-click to end bone creation. An extra nub bone will be created as well, but we may delete it since it won’t be needed. Re-position and rotate the bone as necessary so that it is aligned perpendicularly to the bowstring and so that its joint is precisely at the center of the string.
   
   
   


9. We will now create what is supposed to be the root bone of the bow’s skeleton. Again, press the Create Bones button in the Bone Tools dialog box, but this time, click close to the center of the handle to begin creating a new bone at that point. Don’t click too close to the center to keep from attaching the new bone to any other bone nearby. As with the last bone that we created, make the new bone perpendicular to the handle of the bow then right-click to end bone creation. Delete the extra nub bone that is created, and use the Select and Move tool to position the joint of the new bone precisely in the center of the bow’s handle.
   
   
   


10. Optional but recommended step: Select each bone in turn and rename it to something meaningful. For example, I chose to rename the bones that control the upper half of the bow to “bone_bow_upper_xx,” where xx is a two-digit sequential number. In a similar fashion, the bones on the lower half of the bow are named “bone_bow_lower_xx.” The bone that controls the bowstring is named “bone_bow_string,” and the root bone is named “bone_bow_root.”


11. At this point, we actually have four separate skeletons for the bow. This is evident when we look at the schematic hierarchy of the objects we’ve made. Click the Schematic View button on the toolbar. This will open a new window named Schematic View 1.
    
    
    
    
    As we can see from the schematic view, we have four separate skeletons for the bow, but what we want to do is to integrate all the bones of the bow into one skeleton. This way, we will only need to move or rotate a single bone to move or rotate the entire skeleton. There are several ways to accomplish this in 3DS Max, but since we are already viewing the schematics of our objects, we might as link the bones within the schematic view itself.
    
    
    
    
    In the toolbar of the Schematic View window, click the Connect button.
    
    
    
    
    Now click the box representing the root of the upper half of the bow, and without releasing the left mouse button, drag the cursor to the box representing the root bone of the entire bow. Release the mouse button. This will cause the set of bones for the upper half of the bow to be linked as children of the bow’s root bone.
    
    
    
    
    Repeat this process to connect the bone of the bowstring and the skeleton of the lower half of the bow to the bow’s root bone. When done, there should only be one skeleton for the bow as shown below.
    
    
    
    
    We may now close the Schematic View window.


12. Use the Select Object tool to select the root bone of the bow.
    
    
    
    
    Scroll down the Bone Tools dialog box to see the Object Properties group box. Untick the Freeze Length checkbox and set Stretch to None. This will allow us to pull on the bowstring bone while keeping it parented to the root bone.
    
    
    
    
    We may now close the Bone tools dialog box.


13. Use the Select Object tool to select the mesh of the bow.
    
    
    
    
    Click the Modify panel on the right side of the screen and add a Skin modifier to the mesh. Under the Parameters rollout, click the Add button beside the “Bones” label. This will bring up a dialog box named “Select Bones.”
    
    
    
    
    Highlight all the bones of the bow then click the Select button. This will close the dialog box and add all the highlighted bones to the Skin modifier.
    
    
    


14. Using the Select and Rotate tool, click each bone in turn and rotate it to test the rig. Press [Ctrl]+Z to undo the rotation each time and restore the bones to their original state. If there are errors in how the mesh deforms when a bone is rotated, that means the vertex weights for the associated bones will have to be adjusted.
    
    In the skin modifier of the mesh, click the Edit Envelopes button, which will allow us to adjust the vertex weights of any bone as necessary. In the list of bones that also appear under the Skin modifier, select the bone whose associated vertex weights you want to adjust.
    
    There are a number of ways to adjust vertex weights for any given bone, but for this model, I will only use two methods. The first method is to use the Weight Tool. For this, we will need to be able to select vertices by ticking the checkbox labeled “Vertices” in the Select group box of the Skin modifier.
    
    
    
    
    For this task, it may help to switch from Wireframe view to Shaded + Edged Faces view. Pressing [F3] toggles between both views, and pressing [F4] toggles edged faces.  In the list of bones, select the bone that we want to adjust vertex weights for.  With the Select and Move tool, select the vertices whose weights we want to adjust. Now click the button for the Weight Tool, whose icon looks like a wrench. In the Weight Tool dialog box, make sure that the bone that we are adjusting vertex weights for is highlighted.  We can input any number between 0 and 1 in the box beside the Set Weight button. This number represents how much influence the highlighted bone will have over the selected vertices when we click the Set Weight button. For a given bone, vertices with a weight of 1 or close to 1 will appear red. Those with a weight of approximately 0.75 will appear orange. Vertices with a weight of 0.5 will be yellow, and this color will appear progressively paler as the vertex weight approaches 0.1. Vertices with a weight of less than 0.1 will be blue.
    
    
    
    
    There are other buttons in the Weight Tool dialog box that can affect vertex weights, but I will let you figure out what those do.


15. The second method that we will use to set vertex weights is to “paint” them. This is particularly useful for fine-tuning vertex weights that were set using the Weight Tool.
    
    Scroll down the Skin modifier until we see the Paint Weights button, which is inside a group box labeled “Weight Properties.” Beside it is a button marked “…” It is this button that we will press first to open the Painter Options dialog box to set up vertex weight painting.
    
    
    
    
    Different meshes may require different setups, but for this particular model, we set Max Size to 5 to give us a “paint brush” of just the right size. The checkbox labeled “Enable Pressure Sensitivity” may also be ticked if we are using a graphics tablet to paint vertex weights. We may then close the Painter Options dialog box.
    
    
    
    
    We now click the Paint Weights button and proceed to use the mouse (or the graphics stylus as the case may be) to paint vertex weights on the vertices that are supposed to be affected by the selected bone. Continue doing this with other bones until we are satisfied with the vertex weights. We may then press the Paint Weights button to toggle off vertex weight painting.
    
    
    


16. Go back to wireframe view by pressing [F3]. Zoom out the scene until we have a good view of the entire upper half of the bow then select the nub bone at the very top of the bow. Click the Animation menu then click IK Solvers > HI Solver.
    
    
    
    
    At this point, we will see a stretchy dotted line anchored to the nub bone that we selected. Bring the mouse cursor to the bone of the upper half of the bow’s handle and click it. This will create an IK (Inverse Kinematics) chain from the nub bone at the top to the bone that we clicked. If we were to change the position of the nub bone, the rest of the bones in the IK chain will rotate and shift position to maintain the connection between them.
    
    
    


17. Repeat the previous step to connect the bottom nub bone to the bone of the lower half of the bow’s handle. At the end of this step, we will have two IK chains named IK Chain001 and IK Chain002.
    
    
    


18. Activate the Select and Move tool then click the bone of the bowstring. Note down the X, Y, and Z position of this bone. Likewise, click IK Chain001 and IK Chain002 in turn and note down their X, Y, and Z positions.
    
    For my model, I had the following values for the aforementioned objects:
    
    

    World Coordinates

    	Bowstring Bone	IK Chain001	IK Chain002
    X	0.0	-0.009	-0.002
    Y	18.41	17.282	17.282
    Z	80.0	149.091	10.913



19. We will need to link the two IK chains that we created to the root bone of the bow’s skeleton so that they will move and rotate with the root bone. Click the Schematic View button on the toolbar again then link both IK chains to the root bone. The skeleton hierarchy should then appear as shown below.
    
    
    
    
    We now close the Schematic View window. Linking the IK chains to the root bone would have caused them to change position. With the Select and Move tool, click on each IK chain in turn and move them so that they are back to their original positions.


20. We’re going to use wire parameters so that whenever we pull the bone of the bowstring horizontally, the bow will bend. Wire parameters can be confusing to work with because all their positions are in reference to the parent coordinate system of the objects that are affecting each other, but the coordinates given in the table above are in reference to the world coordinate system. The bowstring bone and the two IK chains are directly parented to the bow’s root bone, so their parent coordinates are all in relation to the coordinates of the root bone. Below is a table showing the parent coordinates of these three objects.
    
    

    Parent Coordinates

    	Bowstring Bone	IK Chain001	IK Chain002
    X	-18.41	-17.282	-17.282
    Y	0.0	-69.091	69.087
    Z	0.0	-0.009	-0.002

    
    I don’t want to launch into an explanation on the different coordinate systems that 3DS Max uses. Suffice it to say that because of the way the bowstring bone and IK chains are oriented, making the bone and chains move horizontally means moving them along their parent X axis, and moving them vertically means moving them along their parent Y axis. In the case of my model, the parent X axis of these objects correspond to the world Y axis, and the parent Y axis to the world Z axis. Got that? No? Let’s forge ahead anyway.
    
    Select the bowstring bone and right-click it to bring up a context-sensitive menu. Click Wire Parameters > Transform > Position> X Position.
    
    
    
    
    Click the IK chain at the top of the bow then click Transform > IK Goal > Position > X Position. This will bring up a dialog box named “Parameter Wiring #1.”
    
    
    
    
    We want to make the bowstring bone control IK Chain001 by making the IK chain’s X-position change whenever the bowstring bone’s X-position changes. To indicate that it is the bowstring bone controlling the IK chain and not the other way around, we click the button with the right-facing arrow in the dialog box. Next, we enter a formula for the IK chain’s X-position. As shown in the picture below, the formula for my model is
    
    X_Position*0.4 - 9.918
    
    What the above formula means is that the IK chain moves horizontally at a fraction of the speed that the bowstring moves along its parent X axis. The fraction, 0.4, was chosen through trial and error to get the bow to bend realistically when its string is pulled. The closer the fraction is to 0, the more resistant the bow becomes to bending. The closer the fraction is to 1, the more pliable the bow is. The value 9.918 is there to ensure that when the bowstring bone’s world Y-position is at 18.41 (its original position as shown in the above table), the world Y-position of IK Chain001 will be at 17.282 (the original position of the IK chain). I derived the value 9.918 by first entering the following formula as the expression for IK Chain001’s parent X_Position:
    
    X_Position*0.4
    
    I then clicked the Connect button and took note of the new world Y-position of IK Chain001, which was 7.364 for my model. I subtracted this new value from 17.282, the original world Y-position of the IK chain, to derive 9.918. I then edited my formula to subtract 9.918 then clicked the Update button in the dialog box.
    
    
    


21. We also have to provide an expression for the parent Y-position of IK Chain001 to account for the lowering of the upper half of the bow when the bowstring is stretched. In the Parameter Wiring dialog box, in the box labeled IK Chain001, click the words “Y Position: Bezier Float.” As before, click the button with the right-pointing arrow to indicate that it is the bowstring bone controlling the IK chain then enter an appropriate expression for IK Chain001’s Y-position. For my model, I used the following formula:
    
    sqrt(4775.944 -(-0.6*X_Position - 9.918)^2) + 79.992
    
    This rather cumbersome formula is derived from the distance formula. Recall that in three-dimensional space, the square of the distance between any two points is as follows:
    
    distance² = (x₁ - x₂)² + (y₁ - y₂)² + (z₁ - z₂)²
    
    For my model, the square of the distance between the bowstring bone and IK Chain001 is
    
    (0 + 0.009)² + (18.41 - 17.282)² + (80 - 149.091)² = 4775.944
    
    Hence, the distance between these two objects is the square root of 4775.944, which is 69.108. However far we stretch the bowstring, we want the distance between the bowstring bone and IK Chain001 to be constant. We need to derive a formula for the parent Y-position of IK Chain001, given the parent X-position of the bowstring bone. If we let the coordinates (x₁, y₁, z₁) represent the position of the bowstring bone and the coordinates (x₂, y₂, z₂) the position of IK Chain001, we solve for y₂ using the following formula:
    
    y₂ = y₁ - sqrt(distance² - [z₁ - z₂]² - [x₁ - x₂]²)
    
    Substituting the known X, Y, and Z positions of the bowstring bone and IK Chain001 as well as the distance between them, we derive the following:
    
    y₂ = 80 - sqrt(4775.944 - [0 - -0.009]² - [x₁ - x₂]²)
= 80 - sqrt(4775.944 - [x₁ - x₂]²)

Note that the expression [0 - -0.009]² equates to 0.000081, a figure so small as to be practically zero for all intents and purposes.

The parent Y-position of IK Chain001, y₂, changes whenever the parent X-position of the bowstring bone changes as well. In fact, we’ve already established that x₂ is given by the following formula:

X_Position*0.4 - 9.918

As for x₁, it is simply the X_Position.

Therefore, the Y-position of IK Chain001 is given by the following expression:

80 - sqrt(4775.944 - [X_Position -{X_Position*0.4 - 9.918}]²)
= 80 - sqrt(4775.944 - [0.6 * X_Position + 9.918]²)

Written in a way that 3DS Max can interpret, this formula becomes

80 - sqrt(4775.944 - (0.6*X_Position + 9.918)^2)

Applying the above formula will cause the world Z-position of IK Chain001 to go down to 69.099 when the bowstring bone is at its original position, so we need to subtract 79.992 to the whole expression so that the world Z-position of the IK chain will be at 149.091. Hence the expression to use is

80 - sqrt(4775.944 - (0.6*X_Position + 9.918)^2) - 79.992

Simplifying, we get our final expression, which is

0.008 - sqrt(4775.944 -(0.6*X_Position + 9.918)^2)




Upon inputting the above formula as the expression for IK Chain001’s parent Y_Position, we click the Update button to apply it, after which we may close the Parameter Wiring dialog box.

At this point, I should mention that the exact formulas given here and in the previous step will not necessarily work with other bow models unless the X, Y, and Z positions of the bowstring bone and the two IK chains are the same as the ones shown in the table in step 19. I took pains to explain the derivation of these formulas so that readers will understand how to adapt them for their models.


22. Verify that the wire parameter works properly by using the Select and Move tool to move the bowstring bow horizontally like an arrow being strung. If the formulas we entered are correct, the upper half of the bow should bend the way a real bow should. Afterward, press [Ctrl]+Z to restore the bone to its original position.
    
    
    


23. Just as we did with the upper half of the bow, we will set up some wire parameters for the lower half. Repeat step 20 above, but instead of clicking on the IK chain on top, click on IK Chain002. Because both IK chains have the same parent X-position, w set up the parent X-position of IK Chain002 exactly as we did with the other IK chain, using the same formula as before.
    
    The IK chains do not have the same parent Y-position, however. Also, whereas the upper IK chain should go down whenever we stretch the bowstring bone horizontally, the lower chain should go up. Initially, we set the expression of IK Chain002’s parent Y-position as follows:
    
    sqrt(4775.944 - (0.6*X_Position + 9.918)^2) - 80
    
    We then take note of the new world Z-position of IK Chain002 and subtract it from the IK chain’s original world Z-position to derive a constant that should be subtracted from the earlier formula. In the case of my model, the new world Z-position was 90.901. Subtracting this value from the original world Z-position of 10.913 gives us -79.988, which we subtract from the above formula to derive the following:
    
    sqrt(4775.944 - (0.6*X_Position + 9.918)^2) - 80 + 79.988
    
    Simplifying the formula gives us its final form:
    
    sqrt(4775.944 - (0.6*X_Position + 9.918)^2) - 0.012
    
    
    
    
    After updating the formula, we may close the Parameter Wiring dialog box.


24. Repeat step 22 to verify that the wire parameters for both the upper and lower half of the bow have been set up correctly.
    
    
    


25. We’re not quite done with the bow yet. If we were to push the bowstring bone a little toward the bow, we will see that the bow also moves. Likewise, pulling the bow a tiny distance away will also cause the bow to move. We want the bowstring to vibrate when it is released, but we don’t want the wood of the bow to move with it. We will need to edit our wire parameters to accomplish this.
    
    First, we have to decide how far the bowstring should be allowed to stretch before it moves the wood with it. For my model, I decided to apply a tolerance of 4 centimeters.
    
    Next, we select the bowstring bone then right-click it to bring up the context-sensitive menu. We click Wire Parameters > Transform > Position> X Position, after which we click IK Chain001 at the top of the bow then click Transform > IK Goal > Position > X Position. This will bring up the Parameter Wiring dialog box.
    
    We will edit the expression for IK Chain001’s X-position so that the IK chain will move horizontally only if the bowstring bone’s position exceeds our chosen tolerance. Otherwise, it will stay at its original parent position of -17.282. The expression that we entered previously should thus be replaced with the following:
    
    if X_Position <= -(18.41 + 4) then
    X_Position*0.4 - 9.918
    else
    -17.282
    
    
    
    
    In my model, the parent X coordinates of the bowstring bone and the IK chains run opposite to the world Y coordinates, which explains my use of negation (-) in the first line of the above expression.


26. Next, click on the words “Y Position: Float Wire” in the box under IK Chain001. We will now edit the expression so that the bow will not bend up or down unless the bowstring bone goes beyond its tolerance limit. For my model, I edited the expression to read as follows:
    
    if X_Position <= -(18.41 + 4) then
    0.008 - sqrt(4775.944 - (0.6*X_Position + 9.918)^2)
    else
    -69.091
    
    
    


27. Click the Show All Tracks button beside the label “IK Chain001” in the Parameter Wiring dialog box. The label “IK Chain001” will change to “World,” and we should now be able to see within this box all the objects that we can wire the bowstring bone to.  Scroll around the box until we see “IK Chain002,” which should be labeled in red. Click the “+” sign beside it to expand its contents then click the “+” signs of “Transform : IKChainControl,” “IK Goal : Position/Rotation/Scale,” and “Position : Position XYZ.” Now click “X Position : Float Wire,” which is also written in red. Edit the text in the box labeled “Expression for X_Position” so that it will be the same as what we wrote in step 25.
    
    
    


28. Click the red label “Y Position : Float Wire” and edit the expression to read as follows:
    
    if X_Position <= -(18.41 + 4) then
    sqrt(4775.944 - (0.6*X_Position + 9.918)^2) - 0.012
    else
    69.087
    
    
    


29. Close the Parameter Wiring dialog box and try moving the bowstring bone horizontally. Tiny movements should not cause the bow to bend, but pulling the bone farther ought to.

This ends my tutorial on rigging a bow. It’s a long tutorial, but I hope it’s also clear and easy to understand. Anyone who wants to offer feedback or suggestions for improvement is welcome to write in the Comments section.