Should freemium games factor in Purchasing Power Parity?

One of the biggest strengths with the games industry today is how global it is. People download and play games from all over the work. Developers who realize this already make sure their games are localized for other languages. This leads to more players, more engagement/viral growth, and ultimately more revenue.

However, but I seldom hear about game developers customizing the price of their games on a per currency basis.

That’s where Purchasing Power Parity (PPP) comes in. Continue reading

Unity Microsoft Virtual Academy now Available!

Unity MVA Crew

From left to right: Jason, Carl, Matt, Tobiah, Adam, Dave V., David C.

The Microsoft Virtual Academy for Developing 2D & 3D Games with Unity is now online!

Fellow Microsoft Evangelists Adam Tuliper, David Crook, Dave Voyles, and Jason Fox, Indie Game Designer/Artist Matt Newman, Lead Unity Evangelist Carl Callewaert, and of course myself got together and recorded this live about two weeks ago.

If you weren’t able to catch it then, it’s now available for everybody to check out!

I appeared on modules 2 and 8. Module 2 is about 2D Game Development using Unity, and Module 8 is about Marketing and Monetizing your game.

If you would like the scripts/assets Carl and I used in module 2, as I posted earlier the files are up on my GitHub page.

When I wasn’t in a module, I was in the chat room answering questions. If you’re interested, you can download the public chat logs on the jump start page.

I would highly recommend anybody into Unity game development check this out. Especially some of the more advanced topics like Optimizing Your Games, Application Lifecycle Management (ALM), and Azure Mobile Services (using Prime[31]). Those subjects not often covered in other tutorials, and they contain a lot of useful information for Unity developers for all platforms.

I think we put together a great resource here for learning Unity. I hope you enjoy it!

If you do, please share it! Microsoft Virtual Academy (MVA) also has other great game development trainings, you may want to check them out as well.


Be Indie Now 35: Michael Todd

Be Indie Now 35

Be Indie Now 35:

Michael Todd

Have you ever questioned if you should pursue a career juggling, or indie game development? Michael Todd has.

He chose the latter, and I think he made the better choice.

He formed his own company, hired employees, went deep into debt, and eventually made it all back with his hit indie game Electronic Super Joy. He now works for the Yazar Media Group, and is busy designing a new procedurally generated game.

Hear his story on this can’t miss episode of Be Indie Now!

Continue reading

Sample Unity assets from Microsoft Virtual Academy

Guy Jump Sample Unity AssetsToday was the first day of the Microsoft Virtual Academy: Developing 2d and 3d games with Unity for Windows jump start.

Lead Unity Evangelist Carl Callewaert and myself gave a demo of Unity 2D during module 2. One of the most asked questions was, “where can I get those art assets and scripts?”

Well, I have your answer! I’ve uploaded them onto my GitHub page.

You can download them directly by clicking here, or go to my new Sample Unity Assets GitHub repo.

If you have any questions about these, feel free to send a tweet to myself or Carl.

We have another day of awesome modules tomorrow, so it’s not too late to join in if you’re interested! If you can’t make it, that’s ok, it will be available later on the MVA site.



Intro to Git and GitHub Part 4: Merging and Rebasing overview

This is a continuation of a tutorial blog series to learn the basics of Git, using GitHub and the GitHub client.

To start from the beginning, go here.

Now that you’ve made multiple branches, it’s time to learn how to put them back together!

Merging branches

To merge our “feature1″ branch from part 3 back into our master branch, go back to your branch manager. To get there, click the branches drop down and hit manage.

Merging01Drag the “feature1″ into the blank box on the left under “Merge”, and “master” onto the blank box on the right.

That will tell the GitHub client to merge the commits from “feature1″ into the branch of “master”. You can confirm that you’ve done this right (as opposed to the other way around) if the blue box on the far right also says “master”.

Click the merge button, and because there were no conflicts “master” now matches “feature1″.

Viewing branch graph

For this tutorial, I’ve been trying to stay away from doing shell commands. But, when it comes to merging, it eventually becomes unavoidable to use some text based commands.

To open the shell, click Settings->Open in Git Shell.

Merging02I won’t go over all the basic commands here, but in the shell you can do everything we’ve done so far in the GitHub client and more, with more options.

Specifically when dealing with multiple branches, viewing a graph may be useful. Try typing in this line:

git log --graph --oneline --all --decorate

As an example, I made another new branch called “feature2″. In both “feature1″ and “feature2″ branches I made new commits.

When I open the Shell and run the above command, I get this useful graph:

Merging03It may be ASCII art, but you can see the relationship between on the branches.

“HEAD” is the current branch. “origin/master” and “origin/HEAD” are the remote (aka “origin”) branches on GitHub. If we published the “feature1″ or “feature2″ branches, another “origin/feature1″ or “origin/feature2″ tag would also appear for the remote versions of those branches.

Resolving conflicts

As amazing and useful as Git is, sometimes things don’t always go as planned.

Let’s take our current project. We’ve been working on two different branches, one improving feature 1 and another creating a feature 2. However, they both have been working on Features.txt

First, let’s merge “feature1″ with “master”.

Merging04So far so good. But, what happens when we try to then merge “feature2″ with “master”?

Merging05Things don’t go quite as smoothly…

Merging06It’s time to break out the Git Shell again.

Our project now exists in a semi limbo state mid-merge.

If we wanted to give up and abort this merge, we can stop it by typing:

git merge --abort

We don’t need to abort it though, let’s try to fix it instead. Use the diff command to see where the conflict is.

git diff

Merging07Yep, we know the exact problem. You can see the “feature1″ and “feature2″ versions are at odds at each other.

It’s here you could use something like git mergetool to help resolve these conflicts and chose which lines from branch A and which from branch B to use. But since this is simple, we will go in manually and fix it.

Let’s open up Features.txt.

Merging08Git has added at each conflict, the <<<<<<<, =======, and >>>>>>>. The first part represents the “HEAD”/”master” branch, and the second part after the equals signs represents the “feature2″ branch.

We want to manually mix the two files together.

Merging09Now let’s go back to git. We now have to add all the conflicted files again to the project and commit. To see which files are or are not part of a current commit, we can use git status

Merging10We see that Features.txt is not resolved. We fixed it already, now we need to tell git. As the message says, we just need to type git add Features.txt and then git commit to finalize the merge.

Merging11Now if we look in the GitHub client, we see our merge has gone through.


Undoing an merge

If we aren’t happy with this merge, we can always revert as we learned in part 1. You can also revert by going back to the git shell and typing:

git reset --soft HEAD~1

The git reset reverts us back to an earlier commit. The “--soft” option means that instead of discarding the changes, it puts them back into our workspace for us to edit. HEAD~1 means we are reverting to the last commit (The current one being HEAD, so the one right before HEAD is HEAD~1)

That would undo the merge, or whatever the last commit just did. Since our “feature2″ branch hasn’t changed, we can always merge again if desired.


Instead of merging, git also has “rebasing”.

Rebasing takes a branch and integrates all its commits into another branch.

Functionally, it acts very similar to merging. You have to use it from the git shell. Instead of git merge <branch>, you do git rebase

When should you merge and when should you rebase?

At first merging and rebasing might seem to give you the same result. The code gets all mashed together! But, there is a key difference between the two.

Merging takes all the changes in one branch, then in one commit applies those differences into another branch.

Rebasing says I want to take all the commits in my current branch, and change the “base” at when the branch initially started at.

So when would you want to use one vs. the other?

You might want to merge when…

You made a branch for a new feature. After you’ve coded it and bug tested the feature and ready to bring it into your main code, you probably want to merge.

In this case, you don’t care about maintaining all the interim commits, but simply want the final product of that branch.

You might want to rebase when…

You were developing in branch A, and another developer working from branch B wants to integrate their work with yours.

In this case, you want to preserve all the interim commit steps and documentation they have been working on. By rebasing, you get not just the final code but all the steps that the developer took as if they had also been working on branch A the whole time.

End of Part 4

Click here to return to the main blog post.


You now know how to use Git and GitHub to create and maintain repositories!

You should try making Git repos for all your software projects. Remember to commit changes early and often, and write good descriptions! This small extra step will eventually save you hours of headache when something eventually goes wrong. In addition to allowing you to more collaborate and share your work with others.

For further learning, here is a fun interactive Git lesson that teaches you a lot of different more advanced git concepts:

I hope you enjoyed this intro to Git and GitHub blog series! If you have trouble understanding anything, or think I left something out, please let me know.

Thanks for reading!


Be Indie Now 34: Game Jams

Be Indie Now 34

Be Indie Now 34:

Game Jams

It’s the return of the panel style episode! We’ve been doing a lot of interviews lately, so I thought it would be nice to invite back Davain and Andrew to talk about Game Jams.

There was an article doing around a while ago asking, are game jams worth it? The panel thinks so, and shares their stories of jams gone right and jams gone wrong.

If you’re interest, I am also hosting my own game jam in San Francisco on September 12th, 13th and 14th.  It’s called Alpha Game Jam, you should join us!

Continue reading

Intro to Git and GitHub Part 3: Branching

This is a continuation of a tutorial blog series to learn the basics of Git, using GitHub and the GitHub client.

To start from the beginning, go here.

Now we start to touch on stuff that is a bit more complicated. There is a lot more you can do with branches, this tutorial will serve as an introduction to the concept.

What is branching?

When you make commits on git, you end up with a series of snapshots of the code in various states. What if you wanted keep the code in different states, without having to copy/paste into two different repositories?

For instance, you might have your 1.0 release version, and another 1.1 version for your in-progress new feature update.

What if while you are developing your 1.1 code, somebody finds a major bug that you need to fix from your 1.0 version right away? The new feature you are working on isn’t finished yet, but you don’t need to discard and revert all your hard work to get access to the 1.0 code. Instead, set up a new branch for your release and in-progress code.

What if you have a master version of your code, and you just want to mess around and change things just for testing? You want to be able to commit your work and save what you’ve been doing, but don’t want to mess up your master. You should not afraid to commit test changes because you would then have to revert them back later. Just make a new test branch instead that will not effect your master branch.

Branching allows you to organize your commits and keep track of multiple versions of your code.

This may sound weird at first, but it gets simpler once you see it in action.

Create a branch

By default, all git projects have a “master” branch. There is a drop down box that says “master” on top of your commit log. Click it to expand the drop down menu to view all your current branches.

Branching01To see more options, click the manage button on the right of the branches drop down.

Branching02Since we only have one branch, not much is going on in this screen right now.

To make a new branch, go back to your main project screen. The text box should say “Filter or create new”. Type the name of the new branch you want.

Branching03Now you have two branches. “master”, and “feature1″!

Switch between branches

To switch between, click on the drop down menu again.

Branching04Try selecting “feature1″ and make a new commit.

Branching05Now switch back to “master” branch. You’ll see that your new commit disappears. If you check your folder, the files are automatically changed. When you’re ready to work on your new feature again, select the branch again and you can continue working.

Deleting branch

To delete a branch, you’ll need to go to your branch manager again. To get there, click the branches drop down menu again and hit the manage button on the top right.

Branching06You can’t delete the current branch you have “checked out” (the one you have open). Other branches appear below, simply click the trash can to delete them.

End of Part 3

Click here to return to the main blog post. Part 4 will be posted on Friday.


Intro to Git and GitHub Part 2: Publishing, cloning, and forking.

This is a continuation of a tutorial blog series to learn the basics of Git, using GitHub and the GitHub client.

To start from the beginning, go here.

Publish a new repository

Time to put your project online!

GitHub makes it easy to share your code with others online!

To publish your local repository, click the “Publish Repository” button in the upper right hand corner.

Publish01GitHub will give you some choices. If you want to release your source code for everyone to see, it’s free.

Publish02Click publish and in a moment your code will be online!

Once your project is linked to an online repository, the publish button will change to a “Sync” button.

Publish03If you want to make sure you have the latest code from the web, click the button to see if you need to download any changes.

Push changes

After you’ve made a new commit, the Sync button will show that your local repository is ahead of the current online one.

Publish04To “Push” these changes to the server, just click the sync button!

Now you can reach the latest code for your projects from any computer with an internet connection.

Clone an existing repository

To download an existing repository to your computer, you have to “Clone” it.

GitHub’s client makes it easy to clone any repository tied to your GitHub account. Click the new repository button, and hit the “Clone” tab.

Publish05Here you’ll see a list of all the repositories tied to my GitHub account. Highlighted is the MyFirstRepo repository I just uploaded.

You can get to other repositories by going to On the side of every public project page on GitHub, you’ll see these two buttons:

Publish06If you just want to download the files, you can go for the zip. But if you would like to be able to look at past commits, and commit your own changes, click the “Clone in Desktop” button and GitHub will automatically request to open your GitHub client.

Choice a place to save the files in, and now you have your own copy of that repository on your local machine!

Fork an existing repository

“Forking” is similar to cloning, but GitHub automatically links your new cloned repository to the original repository from which it came from.

Using your web browser on GitHub‘s website, there is a “Fork” button on the top right of project pages.

Publish07Forking a project adds a new repo to your account, which you can then clone to your local machine in GitHub’s client. You can make whatever changes you would like to your version of the repository, and it won’t affect the original.

Why would you want to do this? Because now you work on your own code and modifications without worrying about messing up someone else’s code (or their code messing with yours). Then when you’re ready, you can make a pull request to merge those changes back in.

Pull requests

Let’s say you want to work on an open source project. You decide to add a new feature to make the project even better.

You could clone it and work on your own new repo, which you may or may not share with others. Instead, you should work on a fork of the original project.

Then when you’ve finished making your changes and want to push them back into the original project for others to use, you can make a new “Pull” request. GitHub has a system for this built right into the website.

You can add documentation of exactly what you added and why, and the repository owner can check all the changes before making them officially part of the original repository.

That’s how you can contribute to the projects of others, and that is one of the basis of how open sourced software is built! Now you too can be an open source developer.

End of Part 2

Click here to return to the main blog post. Part 3 will be posted on Monday.