Habit RPG - Gamifying My Life

Gamification is a subject I'm very interested in. The idea of using the engaging features of games to improve other areas of ones life, such as in education, is an awesome one. So, when I heard of HabitRPG, I was instantly interested. In this post, I'll talk a bit about what Habit RPG is, what parts of it's systems I especially like, and how well I think it accomplishes it's goals.

What Is Habit RPG?

HabitRPG is a todo system designed to bring the progression, rewards, and penalties of RPGs to bear against procrastination and laziness. You can defeat your tasks and habits to gain experience and money, and sometimes gear drops. The money can be used to buy gear, or to award yourself with things in real life. Failing to complete daily tasks or performing bad habits will cause you to lose life, possibly dying and losing money and equipment.

Task Types

HabitRPG has a bunch of different types of tasks:

• Habits can be good or bad, and which can be improved or reduced. For example, I have a habit "Eat Well" which I increase when I eat fruits and vegetables, and decrease when I eat junk food like crisps. Decreasing a habit damages your character.
• Dailies are tasks which must be done each day (or certain days of the week). If you don't finish a daily by the end of the day, your character is damaged.
• To-Dos are more general taks and don't have to have a due date. They won't damage you if you don't finish them, but still reward you if you complete them.

Difficulty and Task Value

One of the big strengths in Habit RPG is the ability to customize tasks with a difficulty, and the auto adjustment of rewards based on difficulty and other factors. Higher difficulty tasks are more rewarding to the player, but also deal more damage when left incomplete. Tasks also naturally change in value over time based on how successful the player has been in completing them in the past (dailies and habits) or based on how long they have been sitting undone for To-Do tasks. This system organically encourages players to work on Habits, Dailies, or To-Dos that are troubling them, to avoid massive damage and to get bigger rewards. It also means they are protected if they mess up a daily that have previously been very strong in.

Party It Up

Another huge strength is a party system. Playing together with others encourages accountability, and encourages you to log in often to buff your friends to help them out. You can choose different classes to provide different kinds of buffs, such as healing, damage buffs, and increased drops.

Custome Rewards

The ability to define custom real life rewards to buy with your Habit RPG coins has also been a pretty good motivator for me. However, this naturally only works well if you limit yourself to these rewards when you buy them, and I haven't always had enough will power to do this.

The Tavern

I've also found it very helpful that, if due to unusual circumstances (huge overtime at work, illness, travel) you cannot complete your dailies, you can check in to the tavern in order to avoid taking damage from them. There are some times when you really can't hold yourself to doing daily tasks, and the game offering a way to deal with this is essential.

Does It Work?

So far, my experience with HabitRPG has been pretty positive. I have found that negative reinforcement seems to motivate me more than rewards - for example, if I've been damaged and am about to die, I'll work super hard to get enough experience to level up and heal up. I've found the red tasks motivating as well, as I hate seeing them sit there and feel like I need to get rid of them. It's been nice having friends that are actively using it as well, which helps keep me motivated. Overall I really recommend if you need a little something to keep you on track with your goals, whatever those may be!

The State of Bounder Games

Wow, it's been a while since I've posted! Life has been busy. In the last four months I've been on trips to Spain and then to the United States to visit family; I've gone through hell and back to get my work visa sorted so I can stay living in Scotland; I've been working full time at Ninja Kiwi during the day; I've graduated from university (finally) with a Master's of Science (with distinction) in Computer Games Technology. Most importantly, though, I've continued to work with Bounder Games, my indie team, on what has now become two game projects: Armoured Engines and Combo Carts.

Anyone who follows this blog knows about Armoured Engines. However, that game has been set aside at the moment while the team works on a smaller game I came up with while looking at abstract diagrams of train tracks: Combo Carts. It plays somewhat like 2048 or Threes, except for one important fact: rather than tiles, you are pushing around carts on tracks. That means they can't always move in a particular direction, because the tracks prevent them.

The goal of the game is to combine carts as much as possible, making as many precious minerals as possible, before the board fills up. Only carts carrying the same type of cargo can combine. In free play mode, the map is randomly generated for each game, making each play through a new experience. We will also have pre-designed maps with particular goal cargo.

We chose to switch gears to work on this project instead of Armoured Engines for a very good reason - Armoured Engines was too big. We specifically chose it because it was a smaller game idea than most of our others, but it was still a full game with a story and lots of different mechanics. Combo Carts is much more bite-size in nature, concentrating on repeated play of one simple mechanic. It is a game I was able to code in a few hours, though polish and added features are taking significantly longer than that. It is a game we can use to get a feel for how releasing a game on the various mobile marketplaces actually works, since this will be our first. Essentially, it is practice. Serious practice and a real effort at making a high quality game, but practice none-the-less.

Combo Carts will be released later this month. After that, we plan to go back to work on Armoured Engines, but there is no way we will make our original September release date. Instead, we are aiming to release Armoured Engines in late November / early December, in time for Christmas.

In other news, we've gotten word that the Abertay Game Development Society, of which we are members, has secured a booth at Dare To Be Digital Protoplay here in Dundee. That means Bounder Games will be showing both Combo Carts and Armoured Engines there in August. If you live in the area, do yourself a favour and come play our games (and many others) for free!

Armoured Engines: A Game Takes Shape

Armoured Engines is now out of pre-production and in to full force development. The team has been cracking away for the last week and it's time for a development update!

Movement

Basic train movement was set up right away, followed by a scrolling background and foreground to give a feeling of constant speed. The train can be moved back and forth via dragging, with a nice acceleration/deceleration action that allows the player to "fling" the train back and forth along the track. Bounds were set up so the train couldn't be thrown off screen. While more fine tuning is needed, this mechanic is already feeling really nice and fun to control.

Cargo Flinging

The most basic method for dealing with enemies in the game is to fling the cargo you are carrying at them. This week we implemented cargo flinging, and our first cargo type: coal. We've got plans for lots of zany cargos in the future, some which weaponize better than others, but for now we'll be moving on to other features before adding more types.

Enemies

We wanted to get an enemy into the game right away to test against. We chose the Mortar as our first enemy as it's movements and AI are very simple - it simply scrolls across the screen in the background and fires mortars into the air, which must then be dodged or shot down as they fall onto the train. We also created a health system for the train, which sets each carriage up with a small pool of health. This means that each carriage can be lost individually - but if your engine is destroyed, the level is lost and your train limps back into town empty-handed.

Playtesting

We've been forcing the game on our friends and colleagues every chance we get, and have already gained many valuable insights about our control schemes. It's always surprising to see how someone else will attempt to control a game. One of our testers used much longer swipes when flinging coal, which we hadn't expected at all and had to re-program to account for. Others attempted to swipe higher or lower on the train than we were expecting. We learned a ton and will continue to test regularly with as many people as possible.

Overall the reaction to our game has been really positive, with many people asking when we'll be showing more of it. If you are one of those folks anxious for more Armoured Engines, you can follow us on Twitter, Facebook, Google+, or Tumblr.

Next Week

Next week, we'll be adding weapons to the train and improving the way we represent the train in data, so it can be loaded into different scenes and customized. We'll also be doing design work for many of the game's enemies.

Armoured Engines: A New Project Begins

I am very happy to announce that my small indie team, Bounder Games, are working on a new project. I have come to think of it as a "steam punk western epic", on mobile devices, called Armoured Engines. In the game, you take on the role of a train engine owner who travels between towns in the wild west, protecting the train and making important deliveries. Bandits, evil robots, hostile monsters, and more will attempt to cripple your steam-powered locomotive. Luckily you have at your disposal an arsenal of weaponry with which to fight back. The game will make use of intuitive touch control methods, different for each type of weapon. Some will be mostly autonomous while others will be more manually controlled. A big part of the game will be customising your engine, choosing what and how much cargo to take and where to travel. You can also hire helpers, which provide more functionality for your train (repairing damaged cars, boosting weapon performance, etc). Finally, there will be an overarching story linking all this together, of a grandiose style suitable for something dubbed a "steam punk western epic".

Meet The Team

Sarah Herzog

"Mama Bounder"

Speciality: Leadership, Programming

Other Talents: Art

Background: Sarah has been, at various points in her life, a writer, singer, artist, drama teacher, martial artist, chemical engineer, nanotechnology researcher, engineering education researcher, science teacher, tech support grunt, quality assurance monkey, and finally, most recently, a game programmer. So many hats leads to only one thing: indie game development.

Roy Stevens

"Bounder Bug"

Speciality: Writing

Other Talents: Art, Design

Background: Roy is a student at prestigious game development university Abertay. He has loved games for as long as he can remember, and has always wanted to have a hand in making them. Like the rest of the team, he has a wide range of talents and excels when allowed to have a hand in everything.

Kyle Drysdale

"Song Bounder"

Speciality: Audio

Other Talents: Art, Design, Writing

Background: Kyle is a recent graduate from a creative audio production degree at Abertay University. He shares a deep love of games with his team-mates, and specialises in making awesome music and SFX for games. However, he also is a talented graphic designer, artist, writer, and game designer.

The Plan

The Bounder Games team has big plans. Someday, we want to make amazing, long-term games that will take a year or two to develop and will have a crazy amount of depth and longevity to them. However, to get started, we focused on choosing a game idea that could be developed in only a few months - our target release date is September 1st. To that end, the team met and each of us pitched three ideas, all with the goal of promoting our style while meeting this time constraint. Armoured Engines was the unanimous choice.

Concept mock up of part of the world map

Now, we work. For the last week, and continuing into the next week, we have been in pre-production. This means, for us, creating concept pieces and mocks of how the various stages of the game make look, planning what features will be in the game, and working on story and characters. After that, we dive head first into production. It will be difficult, as I have a day job and Roy has university. We also have a couple planned trips out of the country later in the year that will disrupt our work flow. But despite all this, I am confident that we will be able to deliver a high quality game by September.

I will be posting regular development updates here and on the team's many pages. If you've got any social media accounts, it would be a big help to us to give us a follow/like, or, if you are feeling generous, a share. Our accounts are:

• Twitter: @BounderGames
• Facebook: www.facebook.com/BounderGames
• Google+: http://gplus.to/BounderGamesPlus
• Tumblr: http://boundergames.tumblr.com/
• YouTube: https://www.youtube.com/channel/UCUpnlSlDJRy4D6J3To4KgPg

Drop by and say "Hi!", and look forward to our future updates!

Unity Tutorial: Scrolling Ticker Text

As I work more and more with Unity, I've begun to learn tricks and tools that I'm guessing would probably be useful to others as well. In my most recent game, Bubble Market, I created a scrolling ticker text box at the bottom of the screen to display active events which were effecting the game at any given point in time. This kind of scrolling text is useful as a general UI element, so I made sure to keep the script generic enough to be re-used. It also occurred to me that these sort of tools may be useful to others as well, so I thought I'd write a quick post explaining what I did, how I did it, and providing the script as an example.

Step 1: Scissoring

The first thing you need to create a scrolling ticker text object is a graphical effect known as scissoring.

Scissoring: In computer graphics, the deleting of any parts of an image which fall outside of a window that has been sized and laid over the original image. Also called "clipping."

There are some more advanced ways to create this effect in Unity, but I went with the easiest route: using a separate camera to render the scissored object. If your scene has a lot of scissoring with different areas going on, I'd suggest looking into other methods, but for simple and limited applications, the camera method works just fine.

To apply this technique, first set up your object without scissoring enabled. Make sure it's large enough that it is easily evident whether your scissoring is working or not. For my example, I used a long test string in my ticker text mesh:

Before we set up the camera, you'll need to change the layer this object is set to. In the upper right of the object's inspector window, click the Layers drop-down and choose to create a new layer. Call it something like "ClippedObjects". Set your ticker object to the new layer.

Now, in your scene hierarchy, duplicate your main camera. Call the new camera something like "Clipping Camera". Make sure these two cameras are in exactly the same place in the game world. You'll need to make several important modifications to the cameras:

• Clear Flags: On the Clipping Camera, change clear flags to "Don't Clear".
• Culling Mask: On the Clipping Camera, change the Culling Mask to only have ClippedObjects (our new layer) selected. You'll also need to modify the Main Camera's Culling Mask, so that ClippedObjects is NOT selected. This will make our new camera only render this layer, and our old camera ignore it.
• Viewport Rect: This is the actual rectangle where the clipping will take place. On the Clipping Camera, define it to whatever you like. You should be able to see the camera's bounds in the scene, and the effect in the camera preview and Game panel.
• Depth: Make sure the depth of the Clipping Camera is higher (more positive) than the depth of the Main Camera. This will ensure the Clipping Camera is drawn AFTER the Main Camera, which is what we want.

If you run the game, your object should now be clipped based on the Viewport Rect you set on your new camera.

Step 2: Scrolling

This was the first part of the effect I was after, a ticker text where the text disappears as it scrolls to the side. Now for the scrolling itself.

The actual scrolling is just a simple change to the object's transform each frame, I won't bore you with that. The interesting bit was figuring out when the object was no longer visible, and figuring out exactly how far to the right to place it so it can start scrolling again.

While I could have simply used the renderer's isVisible property to tell if it was off screen, this wouldn't have been enough for the second part of the scrolling: moving it back to the other side of the screen. Instead, I decided to use the renderer's bound property, which measures the bounds of the object in world coordinates. I set up minimum and maximum x limits for the visible range of the object, which correspond to the viewport I set up in Step 1. I saved these limits as data members in the script.

With this set up, I can easily tell when the object has moved off screen to the left by comparing the renderer bounds of the object to my saved x limit:

ResetScroller() is a method which moves the scrolling text to the right, just off screen and ready to start scrolling again. We determine where to place this text in the same way that we determined when it was off screen: using our scissor limits and the object's renderer bounds:

This first calculates the width of the object in world space, then edits the object's x coordinate to be the maximum plus half it's width. This is because my text object is centre aligned - however, if your text is aligned left, you won't need this step.

If you create a simple script and apply the method described above, you should see something like this:

Further Modifications

What I described above will get a basic scrolling text functionality in place. However, what if you want to change the text? What if something tries to change the text mid-scroll? Currently, the text will change right there, somewhat ruining the effect. For my scroller, I designed a queue system which accepts new messages and switches to the next message while the text is off screen, or repeats the last message a specified number of times (or infinitely). I'm sure there's a lot more functionality you could add to the system even beyond that.

If you'd like to see the finished product, I've made the script available as a gist. Feel free to use it directly or as a model for your own creations.

What interest text systems have you added to your Unity programs? Please share if you implement the ticker text system in your game - I'd love to see this tutorial being put to good use.

Thanks for reading! 

Global Game Jam - MasqueRace

I love game jams. A game jam is a crazy creative mess, a high pressure font of ideas and collaboration. From constraints are the greatest concepts born, and fast prototyping allows outlandish, ridiculous things to be tried that you might never be willing to waste time with normally. Game jam games have even been released later as full games, such as Bossa Studios' Surgeon Simulator. And Double Fine have started opening their internal game jam, Amnesia Fortnight, to the public, selling the products and allowing the public to vote on games they like.

My Global Game Jam team Tiny Tales, plus some other shmucks

Recently, I participated in the Global Game Jam with a group of friends and fellow students of Abertay University. The jam theme was a sentence: "We do not see things as they are. We see things as we are." Our brainstorming session based on this topic resulted in tons of crazy ideas, such as "you are a fly", lots of ideas about perception, and even a murder mystery visual novel.

Team brainstorming session!

In the end we decided on a game about masks which change the character's perception of reality and alter the world around you. The game is a multi-player rhythm-based runner for the OUYA, dubbed MasqueRace, similar to Bit Trip Runner. The players changed masks to allow them to pass different obstacles. If an obstacle isn't correctly passed, the player slows down, meaning they cover less distance. The player who covers the most distance by the end of the song is the winner.

Level select screen, with three complete levels and
drop-in/drop-out for all four players.

This game was an absolute blast to make. I had never worked on a multi-player game before, nor one designed as a console experience. It was a challenge, but since it was local multi-player it wasn't technically too difficult. We did encounter a lot of unexpected problems - in particular, the scrolling background was a huge pain, being much more difficult to implement than we expected. However, we learned a lot, and we're all really proud of the result.

In-game, with four players, two with different masks active.

The best part about this game jam, for me, was the end. Seeing a large group of people gathered around our game, four players at a time, up on a huge TV, was an amazing experience. In the past all of my games have been single player only, and this one, while very simple, seems to be the most fun to play so far.

A crowd tries out the game.

We are currently polishing the game up in preparation for a game jam showcase on the 19th. If you happen to be in Dundee, stop by Abertay's Bar One and try out the game that evening! After that, we are considering releasing the game on the OUYA store on a donation payment plan.

J Quest

I'd like to start a new section at the end of my blogs - "J Quest", a challenge to my readers, and an invitation to conversation about the topic discussed in the blog.

This time, I'm inviting you to share your experiences with game jams in the past. Have you participated? If so, what lessons did you learn in doing so? If not, why not, and do you plan to in the future? What advice would those who have tried game jams have to give to those who haven't made the plunge yet?

My next post will introduce my next project, and my plans for my personal studio in the coming months. Look forward to it!

How To: Bitbucket meets Github GUI

If you've spent any time at all in software or game development, you have at least heard of "version control", probably accompanied by admonishments that you should be using it (you should). However, it's not always easy for new folks to decipher exactly WHY you need version control, what it is, and what the best way to go about using it might be. I've talked about this subject before, even going so far as to write a "newbies guide" to it. However, that was before it became possible to use Github's excellent Github GUI with the wondrous value of free private repositories on Bitbucket.

To save you from having to refer to two guides at once, I'm going to re-hash a lot of what I said in my original Newbies Guide to Version Control. The main difference here is that the old guide is written to work with the repositories at Github.com. The problem with that is that you can only use public repositories for free at Github, while at their competitor Bitbucket you can make private repositories for free. This is obviously a desirable feature for game development.

Enough talk, on to the guide!

What Is Version Control?

Version control is a way of tracking the changes you make to a project over time. Using a version control system such as Git, you can see a list of all previous versions of your project, and roll back to a previous version with ease. You can also "fork" your project to work on a separate instance of it, then merge it back together. Version control also works well in group projects because you can see exactly who made what changes, which can be very helpful when you need to ask someone about a piece of code. Additionally, version control systems usually support a remote repository - a place where the code is hosted online, which allows a group to share their work easily, and can also serve as an extra back up should local storage fail.

In this guide, the version control system we'll be looking at is called Git. The online repository hosting site we'll be using is called Bitbucket. Both are completely free to use, and with the desktop Github GUI, are quite easy.

Why Do I Need Version Control?

Version control is vital to developers, and anyone who likes to keep multiple versions of their work. Have you ever made a major change to something, only to find you really liked it better before? Did the most recent update from the programmers completely break the game, with no way restore it to how it was before? With version control, it's very simple to roll back changes or to integrate stuff you deleted in a previous version. Many people, before version control, did this by keeping multiple copies of their project locally on their computer - but this quickly becomes a disk space hog and also can be quite confusing. Version control systems like Git don't keep full copies of the project but instead keep track of differences, in a long line of differences going back to the original commit. This means that while the same information is saved, you don't have nearly as much space taken up by useless older versions of the project.

Version control with a remote repository has the added bonus of keeping you safe from hard drive failure, as it serves as a backup. Additionally, it is ideally suited to group work, giving a place to share work and a way to track who has done what. Bitbucket has many other features that help with group work, including issue tracking where tasks can be set and assigned, and a wiki where members can contribute and read documentation.

Installing the Github GUI

To get started, we'll need the Github GUI (the front end program we'll be using) and a Bitbucket account.

1. Download the Github GUI from...
   Windows: http://windows.github.com/
   Mac: http://mac.github.com/
2. Create a free Bitbucket account: https://bitbucket.org/account/signup/

You are now set up and ready to create your first repository! I'll guide you through this by making a sample repository with you.

Creating Your First Repository

Now that we have everything installed, it's time to create our first repository! We'll do this using the Bitbucket website. Once you log in, you'll be taken to your dashboard. In the upper right corner is a button "Create Repository". Click it.

Enter a name for your repository. I'll use "Tutorial" as the name for mine. When you name your projects in the future, make sure they are descriptive names so you and your colleagues can easily find the repository you're looking for.

Enter a description. This is also important as it's the first thing strangers or team mates might look at to learn more about your project. For my example I'll describe it as: "A simple repository for learning how to use github."

The rest of the options can be left at default, though you can check to add a wiki and issue tracker if you like (you can always add these later too!). When everything is filled out to your satisfaction, click "Create Repo".

You'll be greeted with a page full options for managing your repo. What we need to get started is the address for your git repo. On the overview, click "Getting Started" and "I'm starting from scratch".

This will take you to a page showing some terminal commands to use git to clone this repo and get started. Sounds complicated? That's okay, we're not gonna do that! Instead, open up the Github GUI you downloaded earlier. When you first open it, you'll be asked to do a one-time setup. You can skip entering a GitHub account (you don't need one to use this application with Bitbucket) but you do need to put in your name and email as these will be used to identify you in your commits. You can always change this stuff later in the application's settings.

When you're done, you'll see something like the picture below.

Now, in this screenshot I have three existing local repositories. Your right hand side of the window will be significantly more empty. You also probably don't have a GitHub account logged in like I do. That's fine - you won't need one.

The next step may seem a little odd, but it is the simplest way to get your bitbucket repo working with Github. First, move your Github window off to one side of the screen, then bring your bitbucket website window up on the other side of the screen. Still on that same page we got to above with the terminal commands? Good. The last command has an address in it. That's your repo's address. Highlight it, then drag it across to Github's window.

GitHub will create an empty repository for you, since the address points to an empty one. If you already had stuff up there when you dragged it across, it would download it and show you the repository history here.

You will also be asked for your Bitbucket username and password. Once you type them in, GitHub can remember them so you don't have to do it again.

Congratulations! You have created your repository on your local computer and on your remote repo on Bitbucket. Now you just need to fill it with stuff.

Making Commits and Syncing

You have a repository now, but it's empty. We'll create a simple text document to demonstrate making commits and syncing.

A commit is when you tell the program to take a snapshot of your project - somewhat like saving a new version. Generally you want to commit after each self-contained change is made. Fix a bug? Make a commit. Add a feature? Make a commit. Error on the side of smaller changes as opposed to massive amounts of differences between commits.

Syncing is when you upload your changes to the remote repository, or download changes from it - when you sync up your local and remote repositories. Always do this before and after you work on the project - before to make sure you have the most current code when you start, and after to make sure your work is uploaded and the remote repo is kept current. This is especially important when working in a group.

Now, on to how to do all that!

You can right-click the repository to get a context menu with several import options. 

• Open: This opens the repository in the GitHub GUI. We'll use this to make commits in a minute.
• Clone and Clone to...: Use this option to clone a repository from Bitbucket which you don't yet have a local copy for.
• View on github: This is only useful if your repo is on GitHub, which ours is not.
• Open in explorer: This opens a file browser to the repository's local location on your PC. We'll use this in a minute.
• Open a shell here: For advanced users only. This allows you to use powershell to muck about with the repo at this location.
• Stop tracking this repo: This will remove the repo from your list, useful for cleaning up if you no longer want to update a repo. You can always clone it again later.

Real quickly, lets add some useful default files to the repo. These are ".gitignore" and ".gitattributes". These files help keep your repo clean and ignore large, unnecessary binary files for common programs. Open your repository by clicking the right arrow on the far right side of it. Once the repository is open, click the cog icon in the upper right and select "Repository Settings...". Then just click the blue text to add the default .gitignore and .gitattributes files. Finally, check update at the bottom of the window. You'll see your repo with a few new entries - we'll cover what all this means in a minute.

Next up, we're going to add a readme.txt for the repo. Doing this allows people browsing your repo to easily see what your project is all about. So lets get to that! Right-click the repo and choose "open in explorer". You should get a window that looks something like this, depending on whether you can view hidden files:

What are those funny invisible files? Those are .gitattributes and .gitignore we added earlier.

Let's create a simple readme.txt to start us off. Create a new .txt document (you can right click the folder and select New -> Text Document). Name it readme.txt and put some text inside. Typically you want the readme to be a nice summary of your project, and you may want to include author names, copyright or license information, version details, and things like that.

Click the arrow next to the Tutorial repository listing (you can also right-click and select "open") to open the repository. You should see something like this:


This is the repository view. The files are listed on the right, with the history of the repository on the lower left, unsynced changed above that, and the current commit message at the top left. Right now we have only a few files, and no history or unsynced changes. You'll notice that there is a little "new" message next to our three files - the program is telling us that these files were not previously part of the repository. On the left of those files, you also see a check box. Generally you want to leave this checked - this tells the program that we want these changes to be part of our commit.

Lets go ahead and make our first commit. Type in a commit message. Often with the first commit you just want something like "Initial commit" - but always try to make the message as descriptive but succinct as possible (a few words only). You can put more details in the extended description as needed. When you're done, hit "Commit to master"!

You'll notice the window has changed, it will now look something like this:



On the left, we now have an entry in "unsynced commits" - the commit you just made. If you select it, the left side will now show the changes that were made during that commit. This is very handy since you can go back and look at when certain changes were made. You can roll back to a previous commit using this interface by clicking one of the two buttons at the top - either "revert commit" to reverse the changes made by the commit, or "roll back to this commit", which reverts back to a state just after this commit was made. Both would be silly at the moment, but can be very useful for long-term projects.

Let's go ahead and upload our change to the remote repository on Bitbucket. This is very easy to do! Just click "publish" at the top of the window - normally this will say "sync" but since this is our very first commit for this repo, it will read "publish". It will take a moment to upload, then the "publish" command will change to "in sync", meaning your local repository matches the remote one. Always check for this when preparing to work, especially when working on a group project. You'll also notice your commit has moved from "unsynced commits" down to "history" - meaning it is now part of the Bitbucket repository history.

We've made our first commit and published our first repo to the remote repository! Let's make a quick change so you can see how the differences look. Open up the file browser again and edit the readme.txt in some way - add a few more lines of text (maybe an author section) and modify some of the existing text. Save your changes, and head back to the GitHub GUI window. You should see your changes represented on the left (you may need to click "show" on uncommitted changes at the top right):



As you can see, the changes are represented as lines added or lines deleted. If you change a line, it counts as deleting the old line and adding a new one. Git conveniently tracks line numbers as well, something most programmers should be familiar with.

Go ahead and commit your change and sync it with the remote repo.

You now have created a repository, added files to it, published it, made changes, and submitted the changes! That in itself is pretty awesome, but that's not all git offers. Lets go to the website to see what other cool things we can do.

Further Features to Learn

This guide barely scratches the surface of what awesome and useful tools are available through version control, GitHub, and Bitbucket. First of all, you have your Bitbucket website, where you can browse and even edit your source right there in the web browser. There is a very useful wiki and issue tracker, great for documentation, task management, and bug reporting and management. You can create team pages to manage multiple people using the same repos. You can set up downloadable builds of your game to give to your testers.

In addition to the features on the Bitbucket website, git and GitHub's GUI have a ton of other, powerful features I haven't covered here, such as branching, forking, merging, reverts and roll-backs, and the ignore and attributes files. Git is a popular system so there is a lot of documentation out there, but hopefully what I've provided here is useful by itself and a good jumping-off point for future learning.

If you have any questions, feel free to leave a comment here and I'll do my best to answer!

Dissertation Complete - So Long, Uni!

At long last, after NINE YEARS of university (over half for a degree I'm not using), I am finally done! Friday, I submitted my dissertation. Assuming marking goes well, I am now a "Master" of Computer Game Technology. Now to move on to bigger and better things!

I may have been a little excited when it came back from the printer....

What does that mean for me, and for the blog? Well, firstly, I'll now be working full time at Ninja Kiwi Europe, maker of the mobile versions of the extremely popular Bloons games. I've been part time there since September, and it's an awesome place. I'm happy to be able to work there full time now.

However, that doesn't mean I'm abandoning my personal projects. In fact, I'm starting off my new professional life with a bang at the Global Game Jam, with an awesome team of Abertay students and recent grads. Most of us worked together at the TIGA Game Hack, and we're excited to work together again. It should be a ton of fun, and I'll definitely be updating here and on my Twitter (@Jiyambi) as we go.

After the game jam, I'll be focusing on making games with my partner Roy Stevens. Our first project is a mobile game called Bubble Market, made as part of the Abertay Game Development Society. Bubble Market will be programmed in February, with an alpha ready by the end of March and beta at the end of April. I'll be calling for testers during those times, so keep an eye out. Expect to see it on Google Play and possibly other Android app stores in May!

Also in February we will be pitching six game ideas internally. The chosen idea will be moved into pre-production, and work will begin on it as Bubble Market is completed. For this game, we are hoping to find an artist or two to help us out, but Roy is also taking some time to focus on his artwork so either way, we should have a nice set of skills for development.

As for the blog, I will continue using this as a space for development updates and reflections. I also plan to write a few how-to posts. The first of these will be posted shortly, and will cover using Github for Windows (the desktop program) with Bitbucket (the git repository). This has been requested by some of the Abertay Game Development Society folks and I think it could be a big help to student game development teams.

When I look back at when I started this blog, compared to where I am today, I see an amazing journey. It's invigorating to see the progress I've made, and so much more exciting to think about where I'll go from here. Look forward to it!