Things my daughter learned from video games

My parents never liked the vidja gayms. They rot your brain, apparently. Mindless, useless, wastes of time staring at a flickering screen.

They didn’t like birthdays, or various bits of essential medical treatment either, so I’m glad I didn’t listen to them.

Over the past few months, Pam (6) has got into video games in a big way. She’d played Pokémon Go obsessively, and she still likes Magikarp Jump, but those were really fuelled by her love of Pokémon rather than a love of games.

She wasn’t really interested in anything if it wasn’t Pokémon.

Things changed when we got Sega Classics.

To start off, she played Toejam and Earl (because we could play it together and I could help her out), and the Sonic games, favouring Sonic 2 because of Tails. Cuteness rules her world, of course. That led her to Flicky, and that’s when things got interesting.

“Mama, it’s gone wrong. It keeps restarting.”

“Oh, ok, show me?”

“Look…”

If you’ve played Flicky, you’ll know it’s unforgiving. Games can last less than a minute when you start learning it.

Pam was learning. Specifically, she was learning that older games are tough. None of the constant progression if you wait long enough, that modern mobile games have. No, this was the original git gud.

The cat bumped into Flicky? GAME OVER.

You hit the spikes in Sonic? GAME OVER.

Fell off the edge in Golden Axe? GAME OVER.

Start again.

Learn.

Improve.

Die.

Do it all over again.

We’ve noticed a difference in her over the past month. Usually, she would be hesitant to try new things. She’d do them, but given the choice between playing something new, or watching a familiar episode of Pokémon, she’d choose Pokémon every time. But now, things are different. Given the large library of games in Sega Classics, she’s exploring them and picking ones at random. She’s found that she likes Ecco the Dolphin, too.

Her cries of “I can’t do it. It’s too tricky,” have almost gone. Now it’s a silent, resilient determination to win. Things aren’t “too tricky” any more, either. They’re “tricky like Flicky” now.

Her hand-eye coordination has improved. Her cooperation has improved. Her willingness to do work in order to get rewards has improved. Her concentration has improved.

She’s also learned about how skills transfer. To my surprise, she keeps returning to Golden Axe 2, which is the best in the series, but I didn’t think she’d like that style of game. She loves it though. So when she fired up Streets of Rage 2 (again, impeccable taste!) she said, “Mama, I thought older games were hard, but this one is easy!”

“Yes, that’s because you learned how to play this type of game when you played Golden Axe.”

“Oh, I didn’t know you could do that!”

“Yes babe, it’s called being able to transfer a skill, and it’s probably one of the most important things you can learn – that what you learn in one place can help you in other places too.”

So now she’s trying new things with glee, which has led her to Steven Universe.

I’m not complaining!

Nicola is doing a draw (with you!)

Over at Automattic, we have a fair few projects that use WebSockets. I knew what they were, but I’d never really used them for anything serious.

If you haven’t heard of WebSockets, they’re an easy way for a webpage and server to send messages to each other, without having to mess about with forms, or individual requests, or reloading pages.

My usual learning style is that I have to do something useful with a tech before I really get it. Sure, I can hold abstract concepts in my head, but it doesn’t really settle in until I do a project using them.

So I did this: http://draw.notnownikki.com/ – a 16×16 grid of pixels that anyone can draw on. You see everyone’s drawing happen in (pretty much) real time, and it works on most modern mobile devices too.

I learned a lot from doing this, both from a technical and personal perspective.

The technical stuff.

WebSockets are easy! Start a server, have the client open a connection, and send messages back and forth!

Managing events and making sure all your clients have the correct, up-to-date data, is hard.

When the user clicks on a pixel, a message gets sent to the server, saying, “Hi! We’re coloring in pixel X with color Y!”

Then, the server has to notify all the connected clients that the pixel has a new color, so a message gets sent out saying, “Someone just colored pixel X with color Y!” and everyone’s screen updates.

Simple, eh?

It would be if we only had one user. And if networks were all the same speed and everyone always got every message in the same order. But, we don’t, they’re not, and they don’t.

Let’s say that Emma and Nikki both go to color the same pixel at the same time. Emma used pink and Nikki used purple. The server gets these two messages, and sends the notification out to all the connected users. The server is going to do send out the “color it pink!” and “color it purple!” at pretty much the same time, and there’s no guarantee that connected users would get them in the order they happened. That means, some of the people might see pink as the last color applied to that pixel, and others might see purple.

That would be wrong and bad.

There were a few solutions I considered.

One was to put all incoming events (such as coloring a pixel) into a queue, and have them processed one by one and the results sent out to each connected user. That would work, but the nature of JavaScript made this the more difficult solution. If this was Java, I’d start a thread that dealt with the queue, and it would sit there happily processing. But with JavaScript, I can’t really do that. I can use signals to start the queue processing when a new event is added, but there’s the issue of what happens when two users add an event at the same time, and we’d have to have locking around that, and it just turned into a bit of a mess.

The next one I considered was to lock the entire image, update it, and send out the new data. This works, but means that every change is blocked when any change is getting processed.

What I finally settled for was locking individual pixels during a change. That meant that other bits of coloring could go on unblocked, but we’d be sure that the data we were changing wasn’t going to change underneath us when we were half-way done updating it.

Still, there was the issue of two changes going through, and not arriving in sequence to all the connected users.

See, while the state of the pixels was guaranteed to be consistent on the server side, the messages going out to connected users might not arrive in the order they were processed.

Let’s say we have 3 users. We get two changes to the same pixel, Emma sets it pink, and then Nikki sets it purple. Now those changes have to go out to the users. While both changes are getting sent out, the pink change might stall a little sending to the first user, because of some system conditions beyond our control. That means we could have finished sending out the purple change to all three users, when the pink change had not yet been sent. What happens then? The pink change carries on sending after the purple change had finished sending, and we have users seeing a pink pixel when they should be seeing purple!

We can’t have that, can we!

The solution here was a serial number for pixel changes.

When we set a pixel, we increment a serial number for it, so we can say “Change 5 to pixel X was to set it pink”, and, “Change 6 to pixel X was to set it purple.”

Now when clients get a message to set a pixel’s color, it can check if it has a more up to date change by comparing the serial number of the change. If change 6 (setting it purple) had been applied, and then we get a message saying to set it pink with a serial number of 5, we know that change is out of date and can be discarded.

And, it works!

Although there are scaling issues (it’s limited to a single nodejs process at the moment) these issues are solvable with a solution like Redis. But I doubt I’m going to need that with this application 🙂

The personal side.

I learned that, even though the canvas is a shared environment, I feel really strange going over stuff other people have drawn. It’s like I don’t want them to be offended if I add shading, or change it somehow!

I found I wasn’t alone in this either.

I also learned that the people on my twitter feed are lovely, and in a few hours of me tweeting out the address, we had collectively drawn this!

Screenshot from 2017-05-25 11-43-44.png

I plan to increase the resolution of the canvas and make the color palette nicer next, and hopefully get some of my pixel-arting friends to show what can really be done when people with talent collaborate!

What do you look like when you’re working?

I wonder if there’s a mental image people have of programmers that we’re always tapping away at keyboards, clicking, testing, and generally looking busy.

It’s been a long time since I worked in an office full of other programmers, so I’m not sure if that’s just the image I presume people have, or if it’s reality.

It’s certainly not my reality.

My daughter asks me many times a day if I’m working. I might be playing guitar, or staring into space, or spinning a pen, or making circles with my foot… and it’s generally in those moments that I’m working the hardest. Those distracting activities are allowing my mind to relax and visualise more complex scenarios and the bigger picture of how the thing I’m working on will fit together.

It’s in those moments that the solutions come to me.

I’ve worked like that for many years. Back when I was in a room full of programmers, one of them, Stephen, would see when I’d spaced out and he’d wait a few minutes and ask me what I was thinking about. Usually I’d reply, “I’m not sure yet. Something’s coming though.” And it usually did.

Writing this post is another distraction. Right now, my mind is full of dancing database tables, admin interfaces, workflow diagrams… stuff that would be overwhelming if I put it all on a whiteboard in front of me, but in my mind with a distracting conscious task going on, everything starts to fit together.

Perhaps I’m just weird though.

Do you want to watch a movie?

Hey, wanna watch a movie based on a William Gibson story?

Yeah!

Wanna watch a movie where Henry Rollins plays a doctor fighting for an underground resistance?

Yeah!

Wanna watch a movie where Ice T plays the leader of a group of freedom fighters in cyberspace?

Heck yeah!

Wanna watch a movie where Dolph Lundgren plays a manic street preacher?

YEAH!

Wanna watch Johnny Mnemonic?

Um, no thanks…

🙂

Two weeks in to the Automattic experience

I’m tired.

Usually I’d write some kind of glittering intro here. Y’know, to sound all witty and make you think the rest of this was worth reading.

It is, by the way. I just don’t have the energy to make it sound that way.

Here we go.

tradition
As is tradition.

Two weeks ago, I started working at Automattic, the company behind WordPress, who powers this very blog. As is tradition, new people do 3 weeks of support for WordPress itself, answering support tickets and doing live support chats with real users.

As many people in Automattic will tell you, it’s an invaluable experience. You find out more about the company, the product, and the users, than you would any other way.

It’s also a great way to get super tired and super stressed if, like me, you have a low opinion of yourself, anxiety, and more empathy than is healthy.

I just can’t help it. If someone is asking for help, I physically feel a need to help them. My point of view seems to switch to theirs, and their problem becomes mine. Add to that, the fact that I’m new to using WordPress itself, and you get a recipe for stress. A lot of the time, I just don’t know the answer, and I have someone asking me to help, needing me to solve their problem.

Thankfully, the problem of zealous empathy seems to pervade Automattic. Perhaps it’s down to their hiring process, or the type of people they attract – I don’t know – all I know is that everyone seems to want to help me solve problems just as much as I want to help our users. It’s good to know that I have a huge team of people backing me up, who can answer pretty much anything.

And sometimes, we get asked questions that have simply never been asked before. Then, we have to go experiment and figure it out. Try stuff. Take a risk or two. Because if we mess up, everyone knows we’re only human, and they’re only too happy to help fix things.

It’s a very nice way to work. And I’m finding (especially when it comes to domain and DNS issues) that I’m able to help others too.

Which is nice.