Syrian Refugees Are NOT Potentially Poisonous Grapes

In the debate, I often saw an argument along the lines of, “If I gave you 10 grapes and told you two were poisonous, would you eat any?”

It sounds clever. There’s a risk. Most intelligent people would say no, and so the idea is that taking in Syrian refugees when potential terrorists could be hiding among them is akin to consuming grapes when you know they could be poisonous.

This argument is old, as this tweet shows:

Back when the Jews were fleeing the Nazis, nations all around the world denied them access because Nazis might be hiding among them. As a result, many more were killed in the Holocaust that could have been saved.

But what bothers me about the argument is how simplistic it is. It makes it sound like the probability is known, and that the only defense against risk is to avoid it entirely. It also makes the issue about the person being posed the hypothetical and not about who the grapes are.

Saving Syrian refugees isn’t the same as benignly eating a bowl of grapes or M&Ms and “knowing” some are poisonous.

It’s like knowing that there are people in a burning building and questioning whether or not to bother trying to get them out on the chance that some of them are arsonists.

“If there were 10 people in a building, and I told you two were arsonists, would you rescue any?” is about how the grape analogy sounds. Now suddenly we KNOW that there are arsonists among them. We even have a specific number, which makes this choice seem like a balance of odds.

And yet, despite knowing we could always find non-poisonous grapes or even some other food, allowing us to pass on this specific bunch of grapes, we still feel like the non-arsonists deserve to be saved from that building, right? I hope?

Syrian refugees are people fleeing a real danger. We have an opportunity to do the right thing and save them from the people we are supposedly afraid they are.

We lock our doors to protect the people inside, but I would question what kind of person you are to leave outside someone who is literally begging for his/her life.

Visualize Markov Chains in Action

Sometime back I took the Coursera online course “Model Thinking” offered by Professor Scott Page.

It covered modeling to help make sense of our complex world. Since models are often simplifications about what really happens, having multiple models that you can apply means you are better able to make sense of the world. I would highly recommend taking the class if you want to be a better citizen and a better thinker.

At one point the class covered very familiar ground. John Conway’s Game of Life and Stephen Wolfram’s cellular automota studies made an appearance, which got me much more enthusiastic about learning how to combine simple methods for complex procedural generation. Along the way came Markov Processes.

Wikipedia says, “A Markov process is a stochastic model that has the Markov property.” Let’s break that down into something resembling everyday language.

Stochastic essentially means random. We’re dealing with a probability. So a Markov process is a model that involves a random element.

And the Markov property? All this part says is that in order to determine what state you are going to be in, the only thing that matters is what state you are currently in. How you got to your current state, otherwise known as your history, is irrelevant. Your past does not determine your future except to the extent that it somehow got you to your present circumstances.

So the simpler definition of a Markov process is that it is a state machine in which how you get to the next state is randomly determined with probabilities based on your current state.

Why is this idea valuable to know?

Let’s say you have weather play a role in your strategy game. If it is raining, your players can’t launch aircraft.

The thing about real weather is that it’s hard to predict. Weather reports tell you that it will be partly cloudy with a 15% chance of rain instead of saying that it will definitely not rain. Because sometimes even if they think it isn’t likely, it happens. Sometimes when they think there will be 4 inches of snow, we find that it is more like half an inch and the predicted snowpocalypse will hit some other city instead. People can talk about the weather as if it is completely random and wonder why meteorologists can keep their jobs when they are wrong so often.

If you wanted to model weather in your game, you could probably use a random number generator. Let’s say that for each day represented in the game, you create a weather report by getting a random number to represent the chance of rain:

int chanceOfRain = rand() % 100;

So when it comes to determining if it actually should be raining or not, you can create a random number and see if it falls within the value:

bool didItRainToday()
    return (rand() % 100) < chanceOfRain;

It would work well enough. Players can make plans based on the forecast, but there are problems.

First, you can’t prevent streaks of certain values from appearing. If you have aircraft in the game, but the weather system prevents you from using them, they become less useful. One day of bad weather might be a minor setback for your war plans, but having weeks of bad weather could be seen by the player as ridiculous. With random number generators, it’s possible to get into this situation, and your players can get frustrated with the bad luck.

Second, you can’t prevent initial values from being “bad” either. The beginning of the game is when you are trying to pull new players into your game’s world. If the game immediately starts with bad luck, it might leave a bad taste in the player’s mouth.

Third, it’s not as realistic to have a day of sunny weather followed by a day of stormy weather followed by a day of sunny weather. As unpredictable as the weather can be, and as possible as the wild swings are, people expect good weather to follow good weather, and bad weather to follow bad weather, and that we’ll have good weather days more often than bad weather days.

You can mitigate the above issues by hardcoding non-rain values for the first few days and also keeping a count of bad weather and forcing good weather if that count goes above a certain threshold, but it’s a clunky solution that still leaves a lot out of your control as a game designer.

Enter Markov chains

Instead of treating each day as completely independent of the next, you can keep track of your current day’s weather state.

Let’s say that a non-rainy day today has a 90% chance of producing another non-rainy day tomorrow, and that a rainy day has a 60% chance of a sunny day following it.

Weather In Markov Chain Form

So almost all of the time a sunny day predicts a sunny day to follow, but every so often it will predict a rainy day. Rainy days might stay rainy for days at a time, but most of the time it will become sunny again the next day. So players can get a feel for how likely rain is to occur and make decisions based on their own mental model of the system, which makes rain an ever present threat without making it an overwhelming or unfair one.

And as a game designer, you can tweak the probabilities of each state until the weather acts how you want it to without having to hardcode everything, create a hacky bandage for it, or give up control to a random number generator completely. You could add more states, such as partly cloudy days and overcast days, which will have different probabilities for moving to other states. Overcast days can result in rainy days more often than sunny days, just like in real life.

You could also put Markov chains to work for you in other areas of games. What if the population of your city simulation has mood swings? That is, if people are content, they are likely to stay content, but sometimes a situation occurs in which enough people get upset that they influence other people to become upset as well. That is, you could have a Markov chain in which content people are likely to be content but sometimes become discontent, and if they are discontent, they are likely to stay discontent but sometimes become content again, mimicking what happens in real life when there is outrage that dies down after the news cycle stops covering the political scandal. In the city simulation, it might drive the player to take actions to address the population’s concerns before real damage occurs.

Or you could create random terrain with roads. Roads tend to want to go straight, but sometimes they turn 90 degrees. Your terrain generator can start creating a road with a particular direction, and each step it adds another tile of road next to the previous one. 90% of the time the next road tile will be placed by continuing in the current direction, 5% of the time it could turn left, and 5% of the time it could turn right.

If you want to play with Markov chains, learn more about them, and see them in action, then see Victor Powell’s visual explanation of Markov chains.

You Are Allowing Terrorists to Win by Giving in to Fear

I had two Muslim roommates when I was in college. They were the nicest guys.

One was in computer science and the other decided to go into religious studies. We played computer games together. They threw the best party I ever went to as part of the fraternity they were pledging for during my time living with them.

I remember conducting an experiment with one of them to see if one of us was more likely to get followed in a store after watching a documentary about discrimination for a class we took together. The results were inconclusive that day, which surprised us.

I also remember watching him eat Skittles as if it was the first time, and it turned out that it might as well have been. He had this look of pleasure as he ate each one, and he explained it was because they no longer used animal-based gelatin, which prevented him from eating them before.

Days after 9/11, I remember having a conversation with another Muslim friend about how no one would sit near her on the El that day. I didn’t understand right away what she was saying until I saw the anguish on her face. People were afraid of her because she had dark skin and wore a hijab.

She was great to hang out with, too. Last I heard, she became a paralegal.

I have non-Muslim Indian friends, some of them who are Christian. We’ve played ping-pong or foosball at the day job together, we’ve danced together, we’ve attended weddings together, and we’ve even done real work together.

I am aware that the untrained eye would lump all of these people together under the category “terrorist”.

Each time I see a terrorist attack has been successfully carried out in the world, there are two groups of people I feel for.

I worry about the victims and their families. My heart goes out to them. I can’t imagine the feeling of loss, sadness, and anger they must be feeling in the aftermath.

But I also spend time worrying about my friends getting hurt or killed by idiots who feel the need to “send them back to where they came from” or otherwise treat them as if they were the enemy.

These are real people. They’re Americans. “Where they came from” is just as likely to be a suburb of Chicago as it is the Middle East.

I see a lot of fear-based posts online by friends and family arguing that you can’t tell the difference between a radical Muslim and a peaceful one and so therefore all of them should be banished from the country, or rounded up and killed, or similar rhetoric that sounds like they have no problem with domestic terrorism when they are the ones conducting it. I see similar talk coming from some prominent politicians who seem to feel that the only part of America they need to worry about is the lighter-skinned part, and so they set an example for others to follow.

They worry about our way of life being under threat but have no problem throwing out life, liberty, and the pursuit of happiness when it comes to those who look different. We cherish our tradition of religious liberty, just so long as it’s Christian.

They worry about Da’esh/ISIS/ISIL/IS destroying this country, but then they turn around and ensure the principles that make this country great in the first place are destroyed first. Giving in to fear, they actively participate in handing Da’esh their victory.

And people like my friends are put at risk as a result.

So while I am processing what happened in Paris and Beirut and Baghdad, I am worrying about the safety of my friends.

Please don’t give in to fear. Real people with real families and real lives are put at risk when someone with enough fear, anger, ignorance, and hate gets the wrong message.

Unit Tests Save The Day Again

The other day I was working on creating widgets to make it easier for me to configure the elements of a screen in a game I’m working on.

At one point I realized that my interface class could hold the common data between the different derived classes, such as the widget’s position. There’s no reason that each derived class needs to have code copied to manage it, so I moved it into the base class:

// IWidget.cpp
IWidget::IWidget(const Point & position) : m_position(position)

// SpriteWidget.h
class SpriteWidget : public IWidget
        SpriteWidget(SpriteImage * sprite, const Point& position);

// SpriteWidget.cpp
SpriteWidget::SpriteWidget(SpriteImage * sprite, const Point & position) :

It should have been a very basic refactoring exercise, and yet I found a number of unit tests were failing that made no sense to me. It was as if the member variable m_position wasn’t getting correctly initialized when I created my SpriteWidget.

By default, a Point object initializes to (0, 0, 0), but as you can see above, my SpriteWidget passes along the Point position to the IWidget’s constructor, which initializes it’s member variable. And yet my unit tests indicated that SpriteWidget was not initializing IWidget’s Point correctly and was instead getting m_position initialized to the default values.

Reading the code, everything looked right, but clearly something was wrong. Otherwise, the tests would be passing.

So I started printing out logs to let me know the state of the variable. SpriteWidget’s constructor got position just fine as an argument. And it was correct in IWidget’s constructor. And yet when I tried to print out m_position from within SpriteWidget’s constructor, it returned values for a default Point.

And then I found it.

// SpriteWidget.h
   Point m_position;

I forgot to take the member variable out of SpriteWidget’s class definition, so it was shadowing IWidget’s otherwise inherited member variable, and I didn’t realize it.

But my unit tests were there to let me know that all was not well. Without those tests, I might have thought my code was fine. After all, the logic was correct, which I can verify after rereading it multiple times.

So I probably would have seen this unexpected behavior potentially weeks or months later, especially if my first production use of these widgets used the default position value of (0, 0, 0). It would have taken me forever to track it down, which would have been a disaster during a Ludum Dare timed compo.

Thanks for saving me time and preventing stress, unit tests!

Global Day of Coderetreat is This Saturday

A couple of years ago I attended my first Global Day of Coderetreat, a day to celebrate software craftsmanship and practice software development with like-minded developers outside of the context of a normal work environment.

I had a great time then, and so when I learned at the last minute that there was one coming up, I signed up for it right away. It’s a free local event, so there’s no excuse not to take advantage of it.

Last time we paired with different people in multiple iterations of developing John Conway’s Game of Life, with each iteration forcing us to throw away our old code and work under different constraints.

For example, one iteration asked us to avoid using primitives. At the time, I struggled to understand what it meant since you can’t create a custom class without using primitives at some point.

But the spirit of the exercise is that your solution shouldn’t expose implementation details. If you are using integer values to represent states, you could use a typedef:

typedef int State;

And then use State instead of int where appropriate. In this way, your code reads better because the way you model it is part of the language of the code.

Note how even with bad single-character variable names that

void update(GridPosition g, State s);

communicates intent a lot better than

void update(int x, int y, int s);

And ever since that coderetreat, I’ve been able to use that experience to write more readable code than I used to.

I’m looking forward to Saturday’s Coderetreat here in Des Moines, IA. It should be fun.

Are you attending a Coderetreat near you? Are you hosting?

Follow GBGames on Google Plus and Facebook!

Association of Software Professionals

Twitter: GBGames