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.


Intro to Git and GitHub Part 1: Your first repository

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.

Create a new local repository

First, start up your GitHub client you downloaded in part 0.

To create a new local repository, click the “+” icon in the top left corner of the program.


Here you’ll be given the option to create or clone a new repo, set the name, path, and default git ignore.


It doesn’t matter what you name it, remember where you save it though! As for the Git ignore, the default “Windows” setting will be good enough for now. We’ll talk more about that later.

Hit the checkbox when you’re ready. Congrats, you just created your first repository!


Here is a basic overview/reference of the GitHub client.


  1. Create or clone a new repository
  2. Currently open repositories
  3. Current branch
  4. Publish/Sync repository to GitHub.
  5. Settings
  6. Commit message/submit for latest changes
  7. Past commits for current branch
  8. Latest changes

Your first commit

Go to the folder you just created your repository in. You can get there easily by clicking on the settings gear in the upper right corner and clicking “Open in Explorer”

You should now be in your new, empty repository. You’ll notice some files have been automatically created. Specifically, a .git folder and a .gitattributes file.

The .git folder has all the information and settings for your repository, you should never mess with this folder unless you know exactly what you’re doing

The .gitattributes file was automatically created for us by GitHub when we chose “Windows” as our settings. It tells Git how to handle certain files. For now, we can ignore it.

Let’s try adding something to your new repository. Right click and hit New->Text Document to create a .txt file.

Now rename this file to

Why .md is a “Markdown” type format. It’s a simple way of formatting text. A file called “” will later automatically be shown on your GitHub project page.

You can then open up in your text editor of choice. Notepad will work nicely for our purposes.

In classic programmer fashion, let’s write the famous first output:

Hello World!

Save the file, close your text editor, and open your GitHub client back up.

On the right, you should see our new file. If you like, you can hit the little arrow and see the contents of the file that have changed. So far it’s just our “Hello world!” line.

Now we’re going to commit our first changes. Be sure to write a descriptive commit message! You will thank yourself later as you’re trying to figure out what you did during each commit in the future, so it’s good to get in the habit now. I wrote:


First Commit


Added readme file and .gitattributes


NewRepo04Hit the checkmark to make your first commit. You should see the commit appear in your history. Your changes have been saved!

Change something!

Now let’s get to the part to show why Git is useful. Go back to your folder (Settings->Open in Explorer) and open back up your file.

Add a new line:

Hello World!

This is my first time using Git!

Save the file and close your text editor again. Now switch back to your GitHub Client. You’ll see that it noticed right away the file has been changed.

It doesn’t just track if the file has been modified, but also exactly how it’s been changed. If you click the arrow to expand, you’ll see it shows that line 1 did not change, but line 2 and 3 did.

NewRepo05Write a new commit message and submit. You now have a saved the changes to

Breaking up changes into multiple commits

What if you changed a lot of different things, but didn’t necessarily want to save all those changes at once?

Let’s create three new files. NewFile1.txt, NewFile2.txt, and NewFile3.txt. Doesn’t matter the contents, we’re just making up files for this example.

If you go back to your GitHub client, you’ll notice checkboxes next to each of the names of the new or changed files. To not include a change, simply uncheck the box.

NewRepo06Let’s say we still have more work to do on NewFile2.txt before we want to commit to the changes, but we want to save our work in NewFile1.txt and NewFile3.txt.

Make sure the checkboxes next to NewFile1.txt and NewFile3.txt and checked, and uncheck the one next to NewFile2.txt. Then commit!

NewRepo07Don’t worry, changes to NewFile2.txt aren’t lost. Your folder is still just how it was before, but the changes to NewFile1.txt and NewFile3.txt are now saved. You can then commit NewFile2.txt in a later update.

Discard changes

What if you are working on your program, and you mess something up. How do you undo your latest changes? Maybe you were working on that NewFile2.txt and decided that it wasn’t a great feature after all.

Simply right click the file, and hit “Discard Changes”


WARNING – There is no recovery for unsaved changes. Make sure you really want to discard all the changes since the last version!

Since NewFile2.txt was a new file, discarding the changes deletes it from your project folder.

Renaming and deleting files

Git automatically monitors all changes to files being tracked.

For example, let’s try renaming NewFile3.txt to NewFile2.txt, now that the original NewFile2.txt file was deleted in the last step.

After doing so, your GitHub client should look like this:

NewRepo09If you delete a file, a “delete” change will appear in the commit changes panel. However, if you rename, sometimes it thinks that one file has been deleted and a new one added.

If you want, you can rename files through the Git shell instead, but in many cases it’s probably just as easy to track the rename as two changes. One new file, and one deleted file.

Reverting changes

What if you wanted to undo a change after you’ve already committed?

Simple! In your GitHub client, go to the commit in question you would like to revert back. For example, let’s undo that first change we made to our file.

NewRepo10Clicking the “Revert” button will undo all the changes done in this commit.

In the GitHub client, this will create a new commit that undoes those changes.

NewRepo11GitHub’s client automatically fills out the message message for the reverse change. Now if you go back to your folder, you’ll see that only has one line!

NOTE: You may need to close and reopen the file in your text editor in order to see the changes.

Ignoring files

What if you had files that you didn’t want to track?

Let’s say our compiler generates a Build.log file. We don’t need to track the state of this, or any .log file within our project.

When you right click the file, you are given a couple options:

NewRepo12If you just want to ignore this specific file for whatever reason, you can click the “Ignore file” option and do so.

If you want to ignore ALL files with the extension .log (or whatever type the currently selected file happens to be), click the second option.

NOTE: Files already tracked/committed will still be tracked. But all future files with that extension will no longer appear in the GitHub client.

This will automatically generate a .gitignore file if you do not have one already. Remember when we automatically added the “Windows” one at the beginning? This is that file.

A .gitignore file lists all the files and extension types Git should ignore when looking for changes.

NewRepo13Remember to commit your new .gitignore file to make sure others who download your project will also have .log extensions ignored!

If you would like to add a premade .gitignore file designed for whatever kind of project you are working on, GitHub provides a repository of commonly used project types.

Visit to see the full list. Download or copy/paste the option you want into your own project file. Remember, you may need to change the file name needs to be “.gitignore” in order to work.

End of Part 1

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


Intro to Git and GitHub

This tutorial will teach you the basics of Git, using GitHub and the GitHub client.

Experience required:

None. This is written for people who have never used any kind of version control system before.

What will you learn:

Part 0: Introduction and Setup

  • What is Git
  • Why use version control?
  • What is GitHub?
  • Setting up the GitHub client

Part 1: Your first repository

  • Creating a new local repository
  • Committing changes
  • Discarding changes
  • Renaming an deleting files
  • Reverting changes
  • Ignoring files

Part 2: Publishing, cloning, and forking using the GitHub client.

  • Publish a new repository
  • Push changes
  • Clone an existing repository
  • Fork an existing repository
  • Pull requests

Part 3: Introduction to Branching.

  • What is branching?
  • Create a branch
  • Switch between branches
  • Deleting branch

Part 4: Merging and Rebasing overview.

  • Merging branches
  • Resolving conflicts
  • Undoing a merge
  • Rebasing
  • When should you merge and when should you rebase?

Each part will be a different post. For now, let’s dive into part 0.

Part 0: Introduction and Setup

What is Git?

Git is a distributed revision control system created by Linus Torvalds.

Since its creation in 2005, Git has quickly become one of the most widely used version control and source code management systems.

Why use version control?

Have you ever accidentally deleted an important file? Had a computer crash and lost work?

Do you manually zip and/or copy/paste your important files to keep backups?

Have you ever tried changing something in your code, only to accidentally mess everything up and not remember what you did to break it?

With version control, you can not only have a back up, but have a detailed history of all the important milestones of your project. You can also share your work with others, and have multiple coders work on the same project at the same time.

How much does it cost?

Git itself is free! There are various hosting services out there that have different pricing models. For this lesson, we’ll be using GitHub.

What is GitHub?

GitHub is a hosting service for Git repositories. Don’t be confused by the similar name, Git and GitHub are completely different things. You can use Git with a variety of software packages and services. GitHub is just one of the most popular sites for open source projects.

GitHub (the website) is free for an unlimited number of users, and an unlimited number of open sourced repositories. However, they charge a monthly fee for private (not viewable by the public) repositories.

What is open source?

Open source means everyone can see, and download the code for your projects. This allows others to check out, learn from or even contribute to your work. There are a lot of open source software projects that are created and maintained by various members of the community, including Git itself!

Where else can I host git repos?

There are a lot of different git hosts out there. I would recommend checking out the following:

Visual Studio Online

Cost: Unlimited projects and private repositories for up to 5 users. Charge for additional users.


Cost: Unlimited projects and private repositories for up to 5 users.

Do I have to use the GitHub client to use GitHub!

No you do not!

You can use any Git client to connect to GitHub. Many people control Git through text base commands, but I think it’s a lot easier to use a GUI tool.

There are other, more advanced clients you can use like Git Extensions or SourceTree. GitHub’s client very simple and bare bones, which I think is nice when you’re first learning, and why I chose it for this tutorial.

Setting up the GitHub Client:

Download GitHub Client

You can download the GitHub for Windows client by going to

Create Account

To create an account for GitHub, go to

Once you get your account set up, you can start the GitHub client on your computer and log in.

Configure settings

You will be given the option to set the name and email address you would like to have tied to your commits. Use an email address you don’t mind others seeing, as this information will be public!

If you are worried about spam, or simply don’t want your email address to be publicly listed, GitHub provides a private email address. Simply set your email address to “” where username is your GitHub username.

For more information, follow the instructions here:

To be continued

On Wednesday, look for Part 1: Your first repository!


Alpha Game Jam September 12th through 14th

Alpha Game JamTime for a new Game Jam! The Indie Game Developers of Silicon Valley group will host “Alpha Game Jam” at Microsoft’s SF Campus on September 12th-14th.

Instead of just the normal monthly meetup, we wanted to run an event that encourages developers of all skill levels to get together, learn from each other, try something they have never done before… or just simply have fun making a new prototype.

There will be no strict rules on what kind or game you should make, or how you should make it. Bring an idea, or create one on the spot. Meet new teammates, or have your team all ready to go. All experience levels welcome, from newbies to veteran devs.

To sign up, go to the Indie Game Developers of Silicon Valley page and RSVP. We will be using ChallengePost for the hackathon, and you can preregister there by going here.

One thing to note, this will NOT be an overnight event. We jamming until midnight each night, returning at 10am the next morning.

Spread the word, and I hope to see you there in San Francisco on September 12th!