The Passion of the Developers

A thousand little decisions go into the creation of a great product. Most are not in the specs or master plans. Instead, they are implemented by testers and programmers. Yet, these are the same people that are traditionally lampooned as geeky and out of touch with the target customers.

What would happen if the developers possessed a deep understanding of their customers needs and desires? Suddenly, those thousand little decisions aren’t introducing random noise into the product. Instead, they are pushing the product forward. A single decision might not make much of a difference, but taken en mass, the momentum generated by enlightened developers can result in a massive reduction in design risk. You’ll develop the right product sooner and with fewer errors.

You can’t unfortunately just say “Dude, I looove my customers” and expect to get results. To harness the power of the passionate developer, you need the following pieces in place:

• Empowered developers
• Meaningful customer feedback

Empowered Developers
One philosophy is that we need better specs and those damned monkeys need to implement the specs exactly as designed. Better command and control system and more rigorous process is obviously the trick to success. This tends to generate poor results.

Imagine that you are a highly creative individual whose life is reduced to a series of highly detailed checkboxes that you are told to fill out one after another, day after day. If you deviate, you are punished and ridiculed. The results are gun-shy, non-communicative production workers that rely on obfuscation and deliberate bending of rules in order to express their innate creativity. Many wonder why they got into this dreary business in the first place. Others just give up.

When indentured coders and testers make design decisions, they lack both the experience and the desire to do the right thing for the user. They’ve been trained to take orders from management instead of building up an intimate empathy with their user. In the best of worlds, they implement uninspired versions of the features described in the specs.

In the worst of situation, they labor in secrecy, adding a little bit of their own uninformed creativity back into the product. When confronted with the havoc wreaked by Byzantine architectures and convoluted, unnecessary features, the humanoid production resources are surprisingly defensive. How can you be angry? They were just trying to salvage a small bit of their creative souls.

Such feature creep is not the fault of the individual testers or programmers. It is the fault of the team and management for turning a creative and invigorating process into menial labor where talented creators have no other option but to rebel.

We need a different philosophy based on passionate, educated team members that put the user at the center of their world. Developers gain the power to make their own decisions through their deep understanding of their customers.

Simple beliefs
Empowerment is a word that has been stripped of much of its initial meaning by the hippy liberals of the world, but the concept is rather simple. An empowered person is someone who has the ability to make their own decisions.

Let’s look at some building blocks that need to be in place before you can have empowered developers. You need to believe these are true and the people on the team need to believe that they are true. If these foundational beliefs are weak, it is very likely that you’ll end up falling back on command and control decision making structures in the face of emergencies or pressure.

• Developers are passionate people: Even technical people burn inside with an inner flame of intense creativity. It can be hidden. It can be misdirected. But you must believe that it exists. The other insight here is that developers are motivated by very human issues. Dream, fears, respect and social hierarchy have a greater impact on productivity than economic incentives or logical rules.
• Most decision should occur at the edges: Management serves a useful role in maintaining group cohesion. They rarely however, have intimate knowledge of the production issues experienced by individual workers. When developers at the edge with customer empathy are encouraged to solve problems that they happen across, a hundred issues that are invisible to managers start going away. A well functioning team is bursting with these small acts of ‘goodness’. Over the course of a project, the momentum results in an order of magnitude improvement in product quality. The most important outcome of this philosophy is that the people who build a piece of customer work flow hold absolute responsibility for it’s usefulness to the customer. “I’m just doing what I was told to do” is the vilest of attitudes.
• Encourage learning through failure and feedback: The urge to control production often stems from fear of others making mistakes. “The morons are going to just screw things up!” is a common refrain. If you remove the opportunity for people to make bad decisions, you slide rapidly down the slippery path of command and control. An empowered developer has permission to fail. In fact, rapid, low cost failure is actively encouraged since it is the single best way to learn about how to make the product better.

Customer feedback
Now we have a team of passionate people. They are solving problems at the edges and they have permission to fail. Wonderful! We still, however, are missing the most critical element. We need to build a strong customer feedback mechanisms that encourages the team to create a product that matters.

• Identify the customer
• Believe in the customer
• Get close to the customer

Identify the customer
Identifying your customer is where an amazing number of teams fail. They become focused on a bit of technology and imagine that users will just appear out of the woodwork. The whole process of iterative product design requires an identified customer so that you can know when you are on the right track and when you need to change direction.

The first step is to write down your customer definition. You’ll take into account market data, economics, opportunities that you’ve noticed and a billion practical details. It will feel like a very intellectual pursuit. The next step is to go out and find an actual, breathing human being who represents your customer. Customers are not data points. They are people that you can question, observe and befriend. The customer definition is just a tool that helps you narrow down your search. The real win is when you can get your customer in the room with your developers and they can drink a beer together. PBR FTW.

This isn’t easy. You may not be able to find a single person who represents your typical customer. You may end up with multiple customers that represent different needs. You may find that people on the team had very different ideas of who the customer might be. You’ll likely redefine your customer multiple times once you start talking with your initial customer prospects.

It is okay if it is hard. Don’t give up. Choosing your customer is the single biggest product design decision that you will make over the course of your entire product’s development. My belief is that no project should be green lighted for even minor development unless the team has had extensive conversations with an identified target customer.

Belief in the customer
The user of your product must be worthy of great passion. Remember, we are dealing with passionate developers thrive on living meaningful, creative lives. When the target customer is considered unworthy or boring, the development team will feel little urge to empathize or go the extra mile.

Product development is a service to others. The products we produce make someone’s world a better place. The team must be able to explicitly articulate why it is worth spending years of their precious lives providing the target audience with a new bauble. If you can get everyone on the team to passionately proclaim that they wish to serve the customer, you have built a powerful unifying vision that will carry the team through hard times.

It is worth noting that practically any customer can be worthy of great passion. All customers are people with dreams and passions of their own. They have tricky problems that result in very emotional human costs. An important aspect of connecting the passion of the developers with the passion of the customer is to identify the human, emotional aspects of the customer problem and bring those to the attention of the team.

Get close to the customer
Once you’ve identified your customer, you need to figure out ways of gathering information about them. One of the great Zen mysteries of product design is that in order to successfully serve your customer is that you should never give them what they request. So you can’t just grab a customer of the street and ask him to design your product. An average customer is good at identifying problems, but they are poor at prioritizing, understanding larger patterns and generating elegant solutions. That is your job. Your customer is there to let you know when you get things right and when you get things wrong.

The feedback cycle is pretty straight forward

• Identify a problem or opportunity
• Build a valuable solution that fits the available resources constraints.
• Present the solution to the customer and record their response. Do they realize the value of your solution?
• Use the data to identify new problems and opportunities. Look at the big picture and start the cycle all over again.

There are a plethora of good techniques available for getting closer to the customer. IDEO has their 51 ideation cards, college design courses teach books worth. They operate at different timescales and give you different types of information. Implement multiple ones and see which ones work the best for your particular customers. Here are some of my favorites:

• Use your own product: Try to replicate what you see your users doing. Mimic the masters so that you understand their thought process by doing. This builds developer empathy with your customers and is one of quickest feedback cycles around. It also however, can be highly biased.
• Onsite customers: Make a customer or two part of the development team. You get very rapid feedback and lots of cultural transfer into the team. The downside is that customer objectivity can be polluted by constant contact with the team.
• Observe customers using your product: Set up usability studies and gather both quantitative and qualitative data. Every team should do this, but it can be expensive and feedback only happens in spurts.
• Hire psychologists and ethnologists to study your customers: You’ll often gather key insights that would otherwise slip by someone not trained in methodical observation. Making these results actionable often takes additional work.
• Listen to lead users: Some users are actively solving the same big problems that you are attempting to solve, often years ahead of the market. Find them and learn from their successes and failures.
  

You are always balancing three different aspects of the customer feedback.

• Reduce feedback cycle time: The more quickly you can fail, the less effort you can put into each failure and the sooner your can correct your course
• Improve objectivity of results: It is easy to get biased results. Many of the issues dealing with customer psychology are fuzzy in the best of situations and the developer’s own interpretations often dramatically skew the data.
• Improve clarity of results: With more data comes more noise. Boiling down the flood of information into actionable, meaningful results that the team can understand is an ongoing activity. Many teams collect customer information, put it in a binder and then never look at it again. If you don’t act upon the customer feedback, it isn’t useful.

There is a substantial cost to all of these activities. You’ll need to change your development practices. Daily builds and regular check-ins help ensure that you always have a product that your can put in front of users. You’ll need to spend money. Bringing in users, ethnologists and usability experts adds to your headcount. This is the cost of doing business.

Barriers
I’ve laid out two pieces of a successful product design team. The first is empowered passionate developers and the second great user feedback. Without the first, user feedback is either ignored or fails to permeate the multitude of small decisions that go into building the product. Without the second, the team spirals off into wasteful directionless exploration.

The single biggest barrier to creating a team of developers that are passionate about their customers is the core cultural beliefs of the people already on your team. Chances are good that they rose to where they are today by mastering a traditional command and control style system. They’ve been personally rewarded throughout the years by checking off the check list or writing checklist for others. They got a big fat raise for staying late and adding those 12 new features from the spec. When the product fails, they are told, “We should have added those 6 more features that got cut because developers were so slow.” The weak ones leave and the ones that are great at silently adding questionable features are promoted and promoted again. They are trained, their egos are invested. After five to 10 years of this, an experienced developer builds up an unshakable, unquestioned belief in command and control style development that only falters when they finally die off.

A thousand little successes do not start with a mandated policy. They begin to gain momentum when the role models within the company start acting upon the beliefs in concrete ways. This is where most process change breaks down. People say one thing, but revert back to habitual behavior when the going gets tough. They still believe, deep down, that the old method of command and control is less risky than trusting a team driven by passion and customer feedback.

Only when people on the team have personally experienced success using the new techniques and they’ve adopted new beliefs as a core of their personal philosophy will momentum sweep through the entire team. Several items need to be in place:

• The right people: You need a core group of people willing to believe in both developers and customers. These folks are rare since the current system isn’t focused on producing them. If you find one, hire him or her immediately. The culture they bring to the team is worth as much as their skills alone.
• The right situation: Often people need to be in the middle of a failing project before they will consider that there might be alternatives.
• Time: Smart, strong people do not give up their culture overnight. After years of steady and obvious success, they’ll start to shift. Start with a like-minded core and grow it slowly.

Very few companies have all these items align. I was chatting with one insanely successful game company that follows many of these methods. They’ve given talks on their process. They’ve partnered with other companies and attempted to teach their process. Each time it fails. Imagine a company that consistently releases highly profitable AAA titles merrily giving you their secret formula. Would you take it?

Yet no one does. It would require companies giving up their most fundamental beliefs about how software is designed and built. They would need to give control to the lowest people in the organization, embrace a constant stream of failure and put customers, not their creative urges, at the center of the design process. That, my friend, is scary. Product success is cool, but a shot a being Top Monkey in the current ineffective system is much more attractive.

Why are we in this business again? Where is our urge to build great and wonderful things that serve the world? It seems a shame to let tradition, habit and hierarchy get in the way.

Conclusion
Lately I’ve been contemplating a nuclear bomb of a statistic. 80% of software features are either never used or used very rarely by customers. Anyone who does software development should be staring at that number in shock. 80% of your sweat and tears has little to no customer value. In most cases, customers would be just as happy if you were to give them 1/5^th of the existing product and make that little sliver work better. How much time and resources could you save if you only delivered the right features?

This in turn has gotten me thinking about the common software development practices, the ones that fixate on execution risk instead of design risk. What we build is just as important as the fact that we can crap out a product by Christmas.

Passionate developers that empathize and listen to feedback from customers form the foundation of an efficient team for one central reason: They are very good at reducing the risk of building the wrong product.

• Team members more readily identify areas of design risk that require iteration with customers.
• Any big design mistakes are caught early through customer feedback.
• Small decisions are made more rapidly with fewer errors.
  

You aren’t going to save 80% of your development time since all this iterating does chew up a serious effort. But you may save 50% or 60% of the budget. More importantly, you may end up releasing a product that is of value to someone that you care deeply about.

Passionately yours,
Danc.

Killing the elder game

I had a chance to sit down with Andrew Tepper, the designer for A Tale in the Desert. His game is a good example of a village game, one of those small MMO that flourish in the dark corners of the internet. They’ve got a small group of dedicated developers making a wonderful, profitable game that is invisible to much of the world. They bootstrapped themselves into existence without selling their souls and are planning for an optimistic future. I believe the market could eventually sustain a couple hundred more such carefully targeted titles without undue competition. Just don’t make a traditional fantasy MMOG

One of the fascinating things about A Tale in the Desert is that it ends. Every 18 or so months, the game starts over again with a new ‘Telling’. This is highly uncommon. Most online games are actually two very distinct game designs mashed uncomfortably together.

• The advancement game: The newbie grind
  
• The elder game: The eternal end game

The two games
In the advancement game, the player gain levels, learn skills and build in-game friendships. The grind up to level 60 in World of Warcraft is a good example of the advancement game.

Once you've completed the advancement portion of an MMOG, you begin the elder game. Now that you’ve got hundreds of hardcore max-level players, you need to keep them entertained in order to keep the subscriptions flowing. Typical mechanics that you find here include PvP, Quests for items that give social standing but not practical benefit and lots of guild politics.

The elder game is all about maintaining a steady state. Brian Green describes it as an episode of Star Trek. No matter what crazy things happen in an episode, everything is back to the same situation by the end. Sure, you spent two months planning a raid to capture that enemy castle. The balance is carefully tweaked however so that eventually, you will lose the castle. Use of heavy negative feedback means that all the PVP, legendary questing and more is ultimately and intentionally for naught.

Tension
There is obvious tension here.

• Game balancing. Building and balancing two distinct play systems cost a lot of money, time and effort. The shear scope of the game systems is often a problem.
  
• Audience Expectations: During the advancement game, you’ve attracted and trained a population of players that loves advancement. Then you plunk them into a steady state system. The whole process provides a schizophrenic value proposition to the customer
  
• Cultural shifts over time: Steady state systems are even more difficult to balance in the face of shifting cultural dynamics. When the game launches, you want a lot of investment in the advancement game. As the game evolves, you need to start improving the elder game to keep the players who have maxed their character. Finally, you need to start streamlining the advancement game since the newbie zones are often desolate after the initial rush of players. So over the life cycle of the game, you end up with radically different design requirements that are constantly shifting.

Cyclic games
A Tale in the Desert is a great example of how you can run the game in 'cycles' or 'Tellings' in Andrew's terminology. Instead of heading directly into the elder game once the advancement game is played out, you end the game and start it over again. This gives you the ability to start out all the players from scratch and let them replay the game that they originally fell in love with. Think of it as the repetitive play of Tetris, but on the scale of 3 to 18 months instead of 15 minutes.

You end up with some great benefits:

• More focused design: Instead of multiple game designs, you have only one, the advancement game. This can reduce costs and improve balancing.
  
• Built in opportunity to refresh the game play. Suppose you want to add a completely new system into the game to address some flaw that was uncovered in a previous Telling. In a traditional MMO, you’ll often run into massive resistance from the player base if you try to alter an existing system. They seek to protect their investment. When a new Telling begins, you have license to add new mechanics. Players may even expect it; there is a thrill in discovering new systems.
  
• Clearer player expectations: It is easier to align player expectations with the design. You aren’t forced to constantly shift the design as the player demographics age.
  
• Marketing relaunch opportunity: You get the opportunity to relaunch the game in the market. Every Telling is in effect a new version of the game that can be promoted and sold as a bright and shiny new thing.

Not all is rosy
You introduce some interesting new problems, but these are not insurmountable.

• How do you get players to go happily into the light? Andrew’s answer is group goals. The group chooses to complete goals that win the game and start the next cycle. By empowering the player to make the choice, there are far fewer complaints. The designer engineers the Seldon-esque dynamics of the system to encourage player choice to flow, on average, in a particular direction, but the players still make the final choice.
• How do you prevent increased player churn at the end of the telling? Currently, the churn doesn’t seem so bad from the numbers that were bandied about. A small meta-game involving tokens that indicate social hierarchy might be enough to stem end of Telling churn even further.
  
• Wither the player content? When you reset the world, you wipe clean vast quantities of player content. I don’t honestly know how bad of a problem this ends up being. This social force could easily contribute to the dramatic momentum of the game. Imagine one group trying to prevent the end of the world and their clashes against those who want to advance to the next round. Setting player expectations regarding the purpose and life span of their creations is likely the biggest challenge.
  
• Gaps in the advancement game turn away new players: In a typical advancement game with lots of grinding and leveling, there quickly emerges a gap between players that join only weeks apart. In a traditional MMOG, you know that if you grind long enough, you can ultimately join your friends at the elder level. Cyclic games that only have the advancement game always have to deal with players that exist in classes based off when they joined. One such cyclic title: Earth 2025, mitigates this somewhat with the use of allegiance systems, where new players can join existing groups. In other games, setting up a healthy flow of economic value between newbies and elders can also increase the collisions between players of different levels.

All in all, these cyclic online games are a fascinating variation on the typical MMOG. It only goes to show that the dominant game design model is not the only model and that there is still an enormous space to explore in online games before we've completely tapped out their possibilities. Thanks to Andrew and Brian for the great conversations.

take care
Danc.

References
A Tale in the Desert
Andrew Tepper's game.
http://www.atitd.com/

Psychochild
Brian’s web site. He mentioned the elder game concept to me.
http://www.psychochild.org/

Earth 2025
One of my favorite examples of a cyclic game.
http://games.swirve.com/earth/
http://en.wikipedia.org/wiki/Earth:_2025

Village Games
My article on village games from 2005
http://lostgarden.com/2005/10/game-business-model-learning-from.html

Millions of Peaches: The value of games

Raph gave a fun, mildly inflammatory talk called ‘Influences’ questioning if games are fundamentally limited in their capability to explore the human experience. Such angst makes my geeky heart beat faster. What follows are the random late night thoughts jotted on the airplane ride back.

My heavily editorialized version of the talk: What if games are only spreadsheets? You can reduce a game into mechanics, stimulus, inputs and lots and lots of numbers. As the game is played, the player immediately strip away the initial sensations of wonder and end up with mechanical tools, a debug console of symbols that represent the ticking, clockwork heart of the game. But, but but…how can we expand our influences beyond the math? How could you evoke the taste of a peach? You can do it easily with a poem, a novel or a movie. But no one is doing it with games.


Games are limited as a medium. So is everything else.
Suggesting that each medium lends itself to certain human experiences better than others should not be shocking. For example, you can create a deep understanding of an individual relationship with a novel. A painting on the other hand may only be able to capture a single emotion associated with a particular moment in that same relationship. Both are powerful experiences, but each medium still has obvious strengths and weaknesses. There are lots of mediums that have difficulty dealing with ‘peachness’. You could certainly shave a cat to look like a peach, but it is quite the tricky exercise.

From this perspective, of course certain peachy topics stump all but the most skilled game designer. At the very least we can say that games are poor at exploring experiences that require input and output mechanisms that are undeveloped either technically on the game’s execution platform or culturally in the game’s audience. For example, games right now lack a taste output apparatus. They also lack widely accepted stimuli that the audience will recognize as a metaphor for taste. So part of it is an interface problem and part of it is a cultural problem.

Limits to the medium exist. We should recognize them. We should also attempt to be insanely clever in getting around them.

The strength of games as a medium
The mildly inflammatory bit is the suggestion that games have no superpowers. What if no matter how many steps forward designers make, we will still end up with shallow clockwork toys? Perhaps, if someone wants to create a meaningful experience, they should skip games all together.

There are at least two obvious counter arguments to this fear.

• The process of creation is not the player experience.
  
• Games do in fact have super powers, particularly in the area of letting player experience a situation directly instead of through an intermediary.

The process of creation should not be confused with the player experience
Raph makes the point that games are just math. Math is one of game design’s most powerful tools, but it is not the final player experience. Often when we are in the muck of creating a project, we despair that our creation is nothing but numbers and fields because we’ve lost sight of how the virgin player will experience the product. Since we spend so much time playtesting and reacting to the feel of our prototypes, there is a strong inclination to blur the line between player and creator and treat the two roles as one in the same. At this point, if creator only sees numbers then surely it is a bad game.

I think of it as the difference between chemistry and perfume. A good bit of chemistry, equations, experiments and theory go into the creation of a new perfume. But that detailed process of enumerating chemical bonds doesn’t need to show up in the end experience. When she dabs a drop on the graceful arch of her neck, Marla won’t be thinking “Mmm…ketones!”

It is the role of the designer to take the clockwork spreadsheets and construct a mix of stimulus that the player can synthesize into a coherent, evocative experience. We are a expert judge of the experience, but we always need to recall that our deep understanding of the game’s theory and mechanics also builds within us an unavoidable bias.

The trick here is to always go back to your players. If your game starts feeling like a spreadsheet to the team, start running some play tests and see how players react. Tune your game based on player feedback to turn your spreadsheet into an amazing and visceral experience.

When the mechanics connect, the impact on the player is magical. When they don’t connect, remember, it isn’t the fault of the spreadsheet.

Game do, in fact, have super powers.
Perhaps it is best to start with an example. One night, a few of us stayed up past the pumpkin-hour playing a game delicately titled “Asshole”. All the fratboys and sorority sisters know it: card, alcohol, and people you thought were friends. The trivial rule set can be described easily with a spreadsheet. However, a description of the mechanical clock does not tell the full story.

When played properly with a copious supply of tequila, Asshole is a game about social hierarchy. As soon as the first President and Asshole assume their positions, the players learn about the use and abuse of power. They learn about counteracting and influencing official authority. More importantly, they learn how the other players, people who are typically friends outside of the game, react in social situations that many would never deliberately put themselves into. Trust is built, friendships formed and treachery revealed. We learned to worship El Jefe.

I challenge any medium, be it movies, books, poems, music or theater to provide the same intimate experiential insight into the workings of the audience’s immediate social group that you find in a simple game of Asshole. This is magical, life changing shit. It is unique to games (and perhaps jam sessions)

Most static media is about the author processing the world and spitting out a result for an audience to consume and savor. Games are about the author building an interactive model that actively encourages the player to uncover their own truths. Both approaches exhibit expressive super powers. Both reveal something unique about the human condition.

If you prefer to create a canned, processed insight into an imaginary character, might I recommend building a novel or perhaps a movie. If you want to help the audience gain practical insight about their immediate friends and family through a safe and pleasurable interactive experience, try making a game. What you want to say has a large impact on how you choose to say it.

Self imposed viewpoints
So enough with the angst! Games are obviously more than clockwork silliness. Certainly, they have weaknesses like all existing mediums. They also have impressive strengths that we should explore and extend.

Maybe games aren’t very good about describing the sensation of eating a peach. I can live with that. Our role as designers is not to build passively consumed descriptions of the world. Our role is to build direct experiences that provide players the opportunity to form their own insights.

Does this involve math and modeling? Absolutely. Are the insights that players take away only about math and modeling? For most players, I would say no. When someone takes on the role of President in a game of Asshole, I learn about them as a leader. I find out who is the joker in the crew and who is the follower. I see who complains when their status drops and who does not. Numbers are a foundation of the game, but they do not necessarily define the complete player experience.

Game designers and some hardcore players are perhaps the major exception. They tend to see the world through clockwork tinted glasses. In their quest to reduce, codify and model the world, it is far too easy to become blind to the wonder and beauty that the simplest games promote. If you see only clocks, seek additional perspectives that help you see what your players see.

Now, who wants my top two cards?

Take care
Danc.

References
Raph Koster’s talk at Project Horseshoe
http://www.raphkoster.com/2006/11/10/project-horseshoe-influences/

Rules of Asshole
http://www.pagat.com/climbing/asshole.html

Project Horseshoe

I attended a unicorn convention in Texas this past weekend.

I always tell people that the role of 'game designer' is really a mirage left over from the days when there were one person teams and we needed a term to described the person who mashed together the messy creative gunk inside a game. Nowadays, we have specialists: Level designers, producers, creative directors, AI programmers, UI coders, writers, artists and more. Few companies seem to really hire the old definition of 'game designer'. Instead you are posthumously awarded the title when no one knows exactly what the heck you do any longer.

The Fatman and his wonderful wife managed to round up a herd of actual sparkling game designers, the impossible sort that think deeply about the big picture of how game systems work. The assembled brain trust was easily responsible for hundreds of games, many of which are legendary or at least ballsy beyond compare. For three days, they gathered at a remote Austin ranch and talked intensely about game design.

The goal: To solve the biggest problems facing game design over the next five years. I’ve cobbled together a few essays from the event that will eventually get posted on this website. More importantly, there will be no doubt stunning papers from the working groups posted later on down the road. Sparks were flying. And hay. Don’t forget the hay.

More than anything, it gave me faith that if you just get the brightest people of our industry off their isolated islands and give them a chance to talk, amazing ideas are inevitable. Experience shared is multiplied, not diminished.

Take care
Danc.

PS: Despite all the magnificent displays of mental virility (complete with glowing horns and stamping hooves) there was a surprising lack of supple young virgins (male or female). I can only imagine that this will change once word gets out about the event.

Project Horseshoe website
http://www.projecthorseshoe.com/