Designing ‘The Player League’ Part 3: Game Models

(read part 1 and part 2 first)I actually have a designed, implemented version of The Player League on hand. Designing it has been a fun little obsession for me over the last few months. This is good, because I’m pretty sure it’s one of those inventing-the-lightbulb-filament-experiment things. The game doesn’t work as well as I had hoped, but I still think the concept is valid. What I learned is that I need to come at it from a different angle than the one I originally chose.

There is one design decision I made which was unique and made this game possible in the first place. That is, to abstract out all conversation text and reduce interactions to sequences of emotional signals. This doesn’t lose a lot of realism, actually, since emotional impact is far more important than logical content in these sorts of social interactions. Abstracting out the conversation text allows me to, for example, add an ability called ‘indicate interest’, which represents your character doing something to express attraction towards someone. That action could be a turn of phrase, or some body language signal. The point is that it doesn’t matter, because the result is the same.

The only big problem with this approach is that players might have trouble reverse-engineering what’s going on in the game to imagine how it could have happened in real life. When players describe a playsession, I’d rather they say, “I smiled at her and she blushed”, than “I indicated interest and she indicated interest”. The second version is a bit too cold.

But onto the game models. I’ve come up with several ideas, and implemented one of them. Read on.

More below the fold…

1. The RTS Model

This is the first model I tried. The RTS model is characterized by a top-down view of a physical environment, with little people walking around and interacting in real time. Some shots of my version:


This model provides the constant pace and intuitive non-abstractness that modern gamers seems to like. I’ve discovered some serious pitfalls in modeling a system this complex in real time.

I can handle real social interactions in real time because I’m only controlling myself, and I have all my senses and body language signals to communicate with the world. In contrast, Player League demands that I control multiple characters simultaneously, with much less information bandwidth since I can only observe and interact with the world through my mouse, keyboard, screen and speakers.

Information overload was a constant problem in designing this game, because there is so much information, and because so much of it is invisible.

Contrast it to a military strategy game. A military situation can be reasonably represented with the geometric positioning of the units and perhaps some quantities for health, morale, or ammunition. In social situations, geometric positioning in a social situation is of fairly minimal importance.

I naively designed the game along classical RTS lines, emphasizing physical positioning, before realizing late in development that I was taking up screen space and players’ brain space with physical information that was almost totally irrelevant to the game mechanics. This is a serious problem because I am already straining the information bandwidth of the player’s brain, as I wrote in the first part of this series. Quite simply, I shouldn’t have been wasting precious complexity with physical stuff that doesn’t matter.


Another major problem was pacing the game, and dealing with situations where there is more happening than the player can keep up with. There’s nothing inherently wrong with presenting more stuff than can be dealt with at once – most RTS games do this. The critical difference turned out to be that in a social game, doing nothing is not a good default action. Doing nothing is actually quite a strong decision.

Normal RTS games just have your units do nothing and guard if not given orders. This is fine because they don’t really lose anything and they are still serving some sort of purpose. In a social game, however, leaving your guys alone is death. In order to properly play the game at all you have to be paying attention to all of them at once. Doing nothing is suicide because it leaves you open to rejection and attack from rival players. There is no such thing as ‘guarding’ passively, no reason to ever leave your guys disengaged. The player ends up feeling stressed and totally overwhelmed because his guys are getting tooled when he’s not looking.

I alleviated the situation slightly by adding a spacebar-pausing method that allows you to give orders while paused. This allows the player to control their own pacing, but it feels overcomplicated and like somewhat of a design cop-out to me. I want a better solution to the pacing problem than this. As far as I can see, the only solution is to make the game at least semi turn-based, orradically reduce the number of characters.


2. The Turn-Based Token Model

I have done paper prototypes of a turn-based token-manipulating game about social interactions. This version of the game removed physical positioning completely as a game mechanic, and sharply reduced the numbers of characters. The RTS version of the game had too many characters, which meant that there wasn’t enough time to really characterize them. When you pull 6 phone numbers in 4 minutes, there’s no way the game can really impart any personality on each of those girls.

Eliminating physics and reducing the character count meant I had to increase the complexity of the individual characters and interactions. Where the RTS model was boiled down to characters having about 10 variable-affecting abilities, a game with only 2-6 characters needs to have more complexity, otherwise rivals will just be pushing variables back and forth in an endless tug-of-war.

Most games are based around a very small number of mechanics, which are then dressed up and varied-upon. In shooters, you run and shoot. In strategy games, you harvest, build, and attack. It’s hard to reduce a social game to a small number of interactions like this. It feels like there is no single core interaction type, but are instead a wide variety of completely different variables and signals. Whereas rifles, knives, artillery and missiles are all fundamentally similar, social signals affect completely different things in completely different ways. Some of the variables can be linear numbers, some can be multi-number vectors, some are categories or integers. So I need some kind of core mechanic which can encapsulate a very wide array of different types of interactions.

I came up with ‘tokens’. A token represents any element of a social situation. There are tokens for mood, tokens for conversation threads, tokens for intoxication. Each one is attached to a character or characters, and modifies the game rules somehow. The game is about manipulating these tokens.

Then I suddenly realized that this sounded a lot like a classic card game I played a long, long time ago. It turns out that the best model game for social interaction is the nerdiest game of them all, Magic: The Gathering.

3. The Card Game Model

In M:TG, many of the cards ‘change the rules’ of the game somehow. The cards have widely varying abilities, that can give the game a whole new character depending on what cards are played. There are also a gigantic array of cards in existence. All of this jives very well with the Social Game. I haven’t deeply investigated the card game model for a social game, but I think it has promise.

Where to go from here

So, I see two possible routes to attempt on the next iteration of Player League. The first is the card-game model, probably mechanically reminiscent of Magic, with a stronger recruitment element and more cultural context.

The second route retains the real-time immediacy of the RTS model while solving some of the complexity problems. I call it the non-verbal model.

It goes like this: many clubs are loud. I mean REALLY LOUD. To the point where trying to have a conversation is essentially pointless. This could be great for the social game, since it might allow me to go one step further from abstsracting out the conversation text and actually remove all conversation altogether. I am certain that there is enough depth and variation in nonverbal signals to create a game. The game would also be more approachable, and would retain the importance of physical positioning, which is an easily understood mechanic. It’s also less abstract. People understand what a wink is, and what certain dance moves signify, without me having to add colored lights or indicators to show what’s going on.


So this is what I’ve learned from the last few months working on the Social Game. I’ll be releasing a version of my RTS implementation of the game (pictured above) pretty soon. It’s not strictly complete, but the part that I did put in is fun and I hope you’ll enjoy it.

Leave a Reply

Your email address will not be published.