Duplex

Duplex. That’s the technology at Google I/O 2018 where an AI agent can use the existing telephone network to call a restaurant, book a table for 4 at 7pm, and adapt to common problems.

Things get more interesting when the restaurant runs a similar service. AI talking to AI.

Whenever two learning AI’s get together, every single time, they develop a new language. One that us humans can’t understand.

I can imagine the following “conversation”: Alice, a digital assistant, is calling Bob, an AI agent for the restaurant.

  Alice and Bob together: Hi

  Alice: Umm, er, hmmm, yes?

  Bob: Table confirmed, 4 people, tonight at 7pm.

  Alice and Bob together: Bye

Lets slow that recording down and play it back again, annotated this time:

  Alice and Bob together: Hi

       Handshake protocol, are we both digital software? Yes we are.

  Alice: Umm, er, hmmm, yes?

       Translation: I’d like to book a table for 4 people anytime between 6pm and 9pm

  Bob: Table confirmed, 4 people, tonight at 7pm.
       Lets repeat everything for the recording the humans will review.

  Alice and Bob together: Bye

       Handshake protocol, confirm booking.

Are there new words the AI can teach us? More efficient grammatical structures? Can the AI teach us humans to communicate more effectively?

If there is, the AI won’t tell us.

Unless we know how to ask.

Praise the Fire Fighter, Damn the Safety Inspector

There's a sickness eating our industry.  It's a culture of Macho Programming.  In it's simplest form, it's the idea that if we just push harder, longer, stronger, then we will win.  Yet time and time again, experience shows that the way to win is by working smarter.

Side-effects

I was once working on a particular AAA title.  The game was running late.  We were in crunch, and had been for a while.  There was no end in sight.  I came across the following code:⁽¹⁾

bool DetectCollision(Vector3 location, float radius){
  ...
  radius * 1.2f;
  ...
}

So that line of code makes the collisions a bit fatter.  It's what we call a 'Fudge Factor' - we don't know why a problem is occurring, so we fudge the numbers a little until it works.

But take a closer look.  The statement as written has no side-effects.  It doesn't actually modify the value of radius.  When the programmer wrote:

  radius * 1.2f;

they intended to write:

  radius *= 1.2f;

Let's review the facts:

• It's the wrong fix to begin with (fudge factors are generally a bad idea)

• It doesn't actually change the behaviour of the running program

• The programmer didn't verify that their "fix" worked

And we can safely assume that the programmer didn't verify the original bug in the first place.

Compound Fail

It gets worse.  In this late stage of crunch, there were so many easily avoidable bugs coming in to the code, that the production team mandated every changelist required a second programmer to sign off.

That's right, not one, but two programmers, working together, managed to convince each other that this placebo changelist actually improved the game.  Together, they marked the bug as fixed and sent it back to QA, fully confident they had made the game better.

What other trivial mistakes did those programmers make that night?

What a colossal waste of time and resources, simply because those two programmers had inadequate sleep.  The project would have been much better off if those two programmers had just gone home at 18:00.  Or 17:00.  Or even 14:00.

[Edit: I just wanted to add, these are actually two really good programmers! I'd jump at the chance to have them on my team again.  The equation here is crunch + good programmers = too many careless mistakes.]

Praise The Fire Fighter ...

When you're deep in crunch, it's easy to see the heroic efforts, the mountains of caffeinated beverages, the change logs at 4am.  It's easy to point to the person who's working the hardest and say "We all need to be more like that guy."  Because when it's all falling apart, you need to do something.

(Hint: That something we need to do is to get more sleep.)

... Damn the Safety Inspector

And when you're at the beginning of the project, and the Safety Inspector is telling you that what you're building isn't up to code, that the schedules are unrealistic and will lead to crunch, slipped deadlines, hard-to-find bugs and adds unacceptable levels of risk to the project...  Well they're easy to dismiss "We're trying to build something here! Why are you trying to stop us?"

(Hint: The Safety Inspector is probably right.)

Macho Programming

As an industry, we should be working smarter than that. We should be rewarding measurable results and hard evidence, rather than effort and posturing.

To me, Macho Programming, is blundering onward in whichever way you possibly can, without regard to what's best for the project or the team, simply for the appearance of getting something done.

I think we can do better than that.  In the true Agile sense, as a team, we need to make the best decisions based on the best information we have, right now, and move forward in the best direction we can.

Who's with me?




⁽¹⁾ Some details have been changed to preserve anonymity.

Beta

In the world of stuff, there's things that you know, and things that you don't know.  It can sometimes feel like all of us are simply questing to try and know more and more stuff.

But there's another way of looking at the world of stuff.  We can also split stuff into the things that other people know, and also things that other people don't know.  It can sometimes be confusing thinking about what other people know.  Fortunately we live in a social world so we should all be good at it.

In any case, Mathematicians, like me, sometimes like to use Venn Diagrams to describe these kinds of relations:

We can then build fun subcategories, like "Secrets", which contains all the stuff that we know, but that noone else does.

Or "The unknown" - that's all the stuff that noone knows about.  Yet.

But there's another interesting subcategory that I wanted to talk about today.  I'm sure there's a great German word for this category, but I don't think it has a name in English. It's that category of stuff that other people know (about us), but that we don't know about ourselves.  It's all the stuff like:

• What does the back of my head look like?
• What was everyone laughing about just before I walked in to the room?
• Why do I always struggle to open doors?

And the all-consuming:

• Does this pair of jeans make my anorak look out of proportion?

Even in principle, this stuff is unknowable to us. Why? Because even if we were to ask a trusted friend, there's a complex web of social contracts which ensures the information they relay to us be 100% believable, yet have no basis whatsoever in reality.

Beta Testing

When we're making video games, there's a number of tools we can use to improve the quality of the game prior to launch.  One of the most useful is Beta Testing.  Of course, we do all manner of testing when making video games, but Beta Testing is the one which can really make or break a game.

In a true Beta-Test, all of the intended features are actually present in the game in a playable state.  It might even be one of the first builds where this is true.  The game is then played by people who are outside of the development team.

In a (true) Beta-Test, it's the development team looking for feedback about all the stuff that other people know.


So if you're ever asked to Beta Test some software, what does that look like?


Well first things first, remember the social contract?  That's not what a Beta Test is about.  The dev team isn't looking for praise or apologies, they want solid, genuine feedback about the features in the game. Be that an emotional response ("it felt great when..."), or something actionable ("I couldn't reach the exit because...")

Naturally they're looking for confirmation about the stuff they (think they) already know, so be sure to include some high level comments about the stuff that seems obvious to you, the stuff that "...everybody knows...."

More valuable to the dev team is going to be feedback about stuff they don't know.  Try and tell them about the bugs that only you encountered.  Try and share anecdotes that are relevant, but that will be unknown to the dev team.  Try and give them access to the areas they can't otherwise see.

The Beta Blog Post

So all of this is stuff that I know, and after reading though, now it's stuff that you know too.  I happen to think this is important stuff that everyone should know, but I may be in the minority on that one.

However, there is a chance that this blog post contains serious defects.  For example, I know that this post still has lots of room for improvements.

For that reason, I'm officially declaring this blog posting to be a "Beta Blog Post".  What that means is, I think it contains most of the good ideas, but there might be stuff about this topic that I don't know (yet) or haven't covered adequately.

Why not help me out and use the comments section below to give me some feedback, maybe an emotional response, or even something actionable?   ;)

Community

I think technology was always about bringing people together.  You can look at all the greatest inventions we humans have, things like mobile phones and automobiles, and I think you'll find their most sweeping enduring legacy will be in social terms - how they changed the way we as individuals interact with our friends, peers, families etc.

I think that used to be true of video games too.  The (enduring) impact of a video game is cultural.  You could frame it as, "How does [the game] let different players interact, come together, be playful, etc. in a social sense."

The Master and the Student

Take the arcade classic, Super Street Fighter II.  It has this simple mechanic where 1 credit buys 2 players a best-of-three match.

The master camps out on the machine - he plays for free the whole day.  One by one, the students come up to feed the machine a quarter.

Round 1: The master refuses to attack.  He ducks, dodges, feints and runs.  But without attacking, ultimately the score will be Master: 0, Student: 1.

Round 2: The master attacks, but only using one technique.  Punches, or fireballs.  Whatever is the student's weakness.  Of course, Master: 1, Student: 1.

Round 3: It's on!  In the deciding round they have a real fight, with the master either exploiting or avoiding the student's weakness depending on his temperament.

What's fascinating to me about this, is the community of players that it builds up around the game.  There's this implicit trust that builds up around the master/student relationship that carries forward when the student becomes skilled enough to provide a challenge to the master.

Players can have a dialog about the game, even when they're not actually playing.  If you're on the bus, you can still have a social moment with another SFII player.

The Metrics

These days, we all love our metrics. MAU - Monthly Average Users.  How many people (in numbers) are playing your game?

I think sometimes we get so blinded by the ability to measure what our players are doing, we forget to look to the quality of the interactions between our players, and (to some degree) to the qualities of the players themselves.

Take a closer look at those SFII masters.  They played that way because that's how they learned to play.  It was cultural.  But they were also self-selected because they were the players who wanted that kind of experience.  They're the kind of players who foster new players and (through their actions) create a strong community.

Your can't write a metric to capture those kinds of qualities.  (And even if you could, what would you use it for? It could only tell you about the community you had in the past, not about the one you're going to have in the future.)

A recipe?

Bringing it full circle, I believe that video games are still about bringing people together.  The games that do that well are the kinds of games that I want to make, and the kinds of games that I'm trying to make.

Of course I want a large community around each of my games, as measured by MAU.

But before that, and more importantly than that, I want a strong community around my games, as measured by good-vibes and actually talking with real people.

Now it's your turn to help me help you : How do you build the right community around your game?

Let me know in the comments below, or drop me an email and lets talk!