Solving casual PVP: Pokemon Go

So if you haven't been living under a rock, you've heard of Pokemon Go. It's the location based AR app that's taken the world by storm over the past couple of weeks. The game is as popular as it is buggy. Much of the design had been critiqued for employing Skinner box elements. But there are some gems of brilliance in the design. One of those in particular is the way PVP is handled.

Traditional casual PVP suffers from a couple of problems. The most obvious is Pay2Win. Some casual games bias the PVP heavily in favour the players that are paying. This alienates free players. And can make the game unpalatable in the long term.

A more subtle problem is game balance. How do you pit players against each other when they have different abilities and play time? How does the elderly grandma that plays once a week compete with the teen that plays every waking hour? Casual games that forgo Pay2Win often end up being Play2Win, and are heavily biased in favour of those with more play time.

So how did Pokemon Go solve this difficult problem? The trick is in asymmetric PVP. The game is heavily biased in favour of the player who is at the location at the time.

So let's look at how this works. First a quick look at Pokemon Go's PVP structure. Combat happens only at specific locations called gyms. Players attempt to gain control of gyms for their team. The attacker is player controlled. The defender is an AI controlled Pokemon left by another player. Combat is very heavily weighted in favour of the attacker, meaning gyms change hands at high frequency.

So the first layer of bias occurs at the team level. There are three factions a player can choose from, the factions are identical in all respects except for colour. This number three is important. It means that at any given time there are twice as many gyms to attack as there are to defend. Any given gym has twice as many attackers as defenders.

The second layer of bias occurs when a gym is attacked. The attacking player gets to choose six Pokemon to attack with. Most gyms are defended by two to four Pokemon, giving the attacker an instant advantage in numbers. On top of this multiple players can attack a gym at once, further driving the numbers advantage. Not enough for you? The attacker 'wins' and weakens the gym for beating just one Pokemon. There is no penalty for attackers Pokemon that are defeated.

I dunno about you, but six on one odds sound pretty good. No matter how big the other guy is. And that's exactly what Pokemon Go is aiming for.

So what about the team defending the gym? Players approaching a friendly gym can train it. This works by pitting one of the players Pokemon against the gyms Pokemon. For each Pokemon the player beats, the gym gets stronger. Let that sink in for a while, attackers get six Pokemon, trainers get one. 

So what does this mean taken altogether? It means players are incentivised to attack gyms. And with such bias towards the attacker, gyms are changing hands constantly. And that's a good thing. Even the newest player can successfully attack gyms. And the advanced players have an interesting challenge to try and defend the gyms they do capture.

What do you think of how Pokemon Go has handled casual PVP. Have you seen other games do it better? Let me know in the comments below.

Unity Developer Certification

So I got my Unity Developer Certification today. It was actually surprisingly easy. 

Key tips:

Do the practice questions on the certification training material. Many of the exam questions as are very similar.

Do a refresher on which components are in which menus. 'Just type it in the search box' isn't a valid answer for 'how do you add component xxx'.

Be broadly aware of the entire engine, the surrounding services, and the industry at large. You don't need to be an expert on any of these areas, but you do need to have the big picture. Examples include animation, coding, lighting, unity services, game genres, production pipeline and so on.

Relax. The exam is pretty easy. There are a few places where the wording is designed to trip you up. But ultimately if you know your stuff the exam will be a breeze.

And for reference, I'm Melbourne's first Unity certified developer. That's my claim to fame for this week.

Steam Greenlight - Lessons learned from Pond Wars

Two months ago I pulled a very cheeky move and put Pond Wars up on Steam Greenlight. As expected, the game didn't get anywhere. But it did give me some insight as to how the process works. So I thought I'd share that here.

Goals

Before talking about the process, its worth noting what I wanted to achieve. My goal with Pond Wars was to get a feel for how the Steam Greenlight system works. I also wanted to experiment with various methods of driving traffic to the steam page. And finally I wanted to see if just having a game up on steam could drive downloads of my game on other portals.

Beginnings - Organic traffic

I posted my game on April 26 (a Tuesday) at about 9 pm AEST. There was no special reason for this time, that was simply when I got all of my screen shots in. After one hour I had racked up a massive 25 views. 3 yes. 15 no. That proportion of yes to no stays pretty static throughout the initial portion of the campaign.

At twelve hours in my stats have climbed to 360 views, 44 yes, 193 no. The game is also 4% of the way to the top 100. There are a few positive comments, but they appear to be fairly generic. Seems that Steam Greenlight attracts a bunch of 'publishers' that are probably scams. Most of the genuine comments are negative, mostly saying the art needs improving. That doesn't come at a huge surprise, its pretty much in line with previous comments. Key take away - Steam gamers just don't appreciate Paint.

At twenty four hours I have 500 views, 50 yes, 255 no. The game is two thirds of the way down through the recent submissions page, meaning it will be in front of less gamers. Organic traffic from steam seems to be slowing at this point.

At thirty six hours the game is finally off the front page of recent submissions. So far its had 540 views. 53 yes, 292 no. Without the front page traffic has slowed dramatically. Interestingly enough there is no measurable flow through into my itch.io view count. Key take away - Steam Greenlight is not effective as advertising.

Traffic briefly picks up again going into the weekend. The peak is Sunday local time or Saturday in the US. On the face of it releasing a game on the weekend to maximise organic traffic while the game is on the front page sounds like a good idea. I'm not sure this would be totally effective, if there are a ton of other games also doing the same thing you might actually get less time on the front page. Key take away - You only get 36 hours on the front page, use it wisely.

By the May 9, only two weeks after launching the Steam Greenlight page, organic traffic from Steam has dropped down to nothing. In total I got 800 views from organic traffic, 67 yes, 434 no. Interestingly later viewers are more likely to vote no then yes, not sure if this is real or just an effect of my small sample size.

Social Media - Twitter and Facebook

For some context here my Twitter and Facebook following is pretty limited. I have 40 twitter followers, mostly other game developers. I have 250 friends on Facebook, mostly personal acquaintances. Sharing on both of these mediums netted me 40 new views, 3 new yes, and 6 new no. Its a small sample size, but it looks like my own friends and followers were more likely to vote yes.

YouTube

In the last phase of my experiment I made the Steam video public on YouTube. My channel there has about 1000 subscribers. Somewhat surprisingly I got no additional votes, and very few additional views.

If I was to do it again...

I would definitely spend more time on the art. The art work is the only thing that got looked at or commented on. Along those lines I would beef the video up to, possibly even paying someone else to make it.

I'd spend a little more effort promoting to my own social network. But ultimately my friends and game dev colleagues are not a huge market for actually playing the games.

I hope this helps someone else. And feel free to share your experience getting a game promoted on Greenlight in the comments.

Oh, and if anyone wants to see the Greenlight page, you can find that here. 

Global Game Jam - Demon Days

So, its over. We had the jam. Made some awesome games. Now its time to reflect. If you just want to play the game, check it out here.

The Team

From the left: Gaston Iglesias, Rhiannon Nee-Salvador, Emma Cameron and Richard Gubb 

Two weeks before the jam we went to a IGDAM meeting. The point of the meeting was to put together jam teams. There was a little confusion at first, several folk who weren't actually coming to the jam making teams. Rhiannon running around hoping desperately to meet at least one other Unreal developer. And in general a bunch of socially awkward game devs trying to figure out if they could stand sharing a room with other people for a weekend.

The end of the night came, and Gaston, Rhiannon and I were still unteamed. People were starting to pack up and head home. The venue was becoming dominated by unattached game dev students. Rhiannon quickly grabbed Gaston and me and press ganged us into her team. We had an artist and two programmers. We were live!

Over the next week we sent dozens of emails. We established art pipe lines. Source control (more on that later). We met up in person and discussed time lines, sleeping schedules, roles and more. We had never been part of a game jam before. But we were ready.

Artist Bait

Astute readers will notice there are four team members in the portrait. Between registration and the keynote we decided we needed to get another artist. So we set a clever trap to find one. You see game devs of all types have a weakness. We all love to play games. And board and card games are inherently social. I had Love Letter in my pocket (I seldom leave home without a game). We choose a corner near registration and began playing.

At first it didn't seem like we were going anywhere. We had a couple of coders join us. We had a 3D modeler. We had several people with there own teams. An audio guy. Even an old Advanced Fighting Fantasy buddy from high school. Finally Emma joined us. We had found the needle in the haystack, an unattached artist.

The Theme

Artist secured there was little more to do before the keynote. We grabbed a desk. Set up laptops. Gave source control another kick in the tires. Played some more Love Letter. And waited. They keynote itself was pretty good. But honestly I don't remember much of it. Something about roses in Iraq. Something about VR. A whole lot of sponsors. And the theme. One word 'Ritual' that was going to dominate our lives for the next 48 hours.

Initial whiteboard design

Ritual was a brilliant theme. There were two immediate directions we could go. Perhaps a game about occult or religious rituals. Or maybe we could go with the more mundane daily rituals. Turns out there was a third path some groups took that we hadn't even considered, animal mating rituals. We went back and forth several times, but finally settled on the base concept, a demon carrying out his mundane rituals, frequently interrupted by human summoning him to the surface world. 

The idea done, we ate our pizza, and set about meeting our first milestone. A playable prototype by the end of Friday night.

Original game design documents

Source Control

One of the things that went really well on our project was our use of source control. For the technically minded we used a git repo, hosted on BitBucket. We set the artists up with a basic GitHub desktop client. It automatically took care of pulling and pushing, in a single button press. I used SourceTree. And Gaston, the only one in our team who is a professional programmer, used command line access to fix all the tricky cases.

Things went pretty smoothly. We had a couple of hiccups were an asset was committed before Unity had created a .meta file. And we did have one inexplicable problem where Snuffles managed to loose his animation four times with less then an hour to go. But the benefits of keeping everyone on the same Unity project and code base were amazing. And actual handling of stuff on USBs was minimized to almost nothing.

Game Design

By mid day on Saturday all of the base elements for the game were in. The artists were well on the way to completing all of our art assets. Gaston had plugged in an xBox controller, bumping the experience up dramatically. We'd even goBut something was still missing. At this point the game was fun. But it was kind of pointless. There was no way to win or loose the game. No way to tell who played it better. To channel Chris Murphy, the game did not have flow.

We took a time out. We made charts. What should the player be doing with there time? What things should we penalize the player for? What were the player goals? How could we provide feed back? How should the game end?

The scoring / energy loop

The result was a three pronged system. We added a timer to set the game end. We added score to provide the player with a clear goal and feedback. We added energy to incentive the rituals. We all went back to our laptops to build the new systems and art to make it work.

 Balance

Gaston finished coding all of the requisite systems somewhere between 4 and 5 am on Sunday morning. The rest of the team awoke to a fully playable, fully integrated game. We had a whole day to balance and play test. What could go wrong? We snagged a few passing volunteers. Put up a rudimentary leader board on our trusty white board. And sat back to watch.

A screen shot of the final game

To our dismay perhaps one in five players actually got the game detailed tutorials. Everyone loved torturing Steve. The sound and the music were great. They laughed at being told to pet Mr. Snuffles while in the middle of killing civilians. Yet they didn't actually score points.

With very little time left we went back to try and fix this. We added key prompts over top of targets. We added floating scores when the player gets points or energy. We messed with the starting conditions and the timers. We definitely improved things. By the time 3pm came around about half of the players got what was happening without prompting. But the game desperately needed a tutorial. And we barely even scratched the surface on balance.

The future

A couple of weeks after the jam everyone got back together at another IGDAM meeting. This time to play the games other jammers had made. And to catch up with team mates. We showed off Demon Days. We played other games. We talked about what we want to do next.

Demon Days is finished for now. We aren't going to continue developing it. But we will be taking the lessons we learnt forward into our own work. And who knows. Maybe the experience convinced Rhiannon to try out Unity for her next project.

Play Demon Days

My proof arrived!

I have a real book in my hands and everything. Sure it's just a little one. And I self published it on create space. But I've legitimately got through (almost) the entire process of writing a book, from the first draft, through editing and publishing. 

I'm pretty close to being able to call myself a real writer. The last thing for me to do is read over the proof and hit the accept button. It's exciting times. 

I'll be taking some lessons from my experience with making games. I haven't perfected the craft of writing yet, so I'll be making the book available for free as an e-book. The print copy will be available at just the cost of printing and postage. 

And to finish it off here is a picture of the proof.