Hobby Game Developers: to use version control or not?

Version control, sometimes called source control, is the process of using a program to manage multiple versions of a software project, typically saving things in a remote database or similar structure. There are many version control packages available, including CVS, ClearCase, Perforce, and Git, the last of which has risen to great popularity in the last few years.

There are several advantages to using a version control package, with some of the major ones being:

• All changes are backed up, so if data is lost or accidentally erased on your machine you can recover it.
• By looking at the various revisions in the system, you can follow the flow of changes. This can really help out in triaging bugs for complex projects.
• You can work on several different versions in parallel and do an automated merge at some point to join the code from two or more versions. This comes in handy if you have a stable version that you are submitting to the app store, and a an experimental one with unfinished changes. In team projects where a single source file or module can be worked on by several people at once, this is even more important.

For any project that has more than two or three people, I’d say that source control is a necessity that can save hours if not days or work, especially for complex projects. Most of the projects I worked on in my day job used some form of version control.

However, for a hobby developer that is working on a game by him or herself, the advantages are much less. I’ve tried to use Git for one of my hobby projects, but ended up never needing it. This may be because of some habits I have developed over time. For instance, when I am going to make a major change to a function I often will copy that function, and keep the original one. This makes it easy to go back to the original if I end up breaking something, or decide the refactor I was attempting is not worth it after all. Also, I typically make sure my code is buildable every few minutes, as opposed to writing hundreds of lines of code for hours, and then trying to build. If you get a compile-time failure in that scenario, it can take quite a while to figure out where things are broken, and source control can potentially help there.

Instead what I do is simply zip my entire project directory and email myself once a day, so I have both a basic backup and ability to check previous versions. But I’ve almost never needed that, I do it primarily for peace of mind just in case my machine’s HD crashes – something that has happened more than once.

If you are on a Mac, you can use the Time Machine feature which will allow you to look at older versions to see what changed. However, unless you buy something like an AirPort Time Capsule or similar external storage solution, you are not protected against data lost. I just bought one of the capsules the other day, and it was pretty easy to setup.

If you are doing hobby game development by yourself, you’ll have to weight the pros and cons and decide what is best for you. If you don’t have experience with a software version control system, it’s probably a good idea especially if you consider making software development your career. I’d recommend Git since it’s popular, free, and you can set it up initially using just one machine (and expand to a remote machine later if needed).

Even if you are working on a hobby game with a handful of people, depending on how well segmented the work is you may not need a source control. For example, if one person is working on art, one on coding (implementation), and one on testing and story, then you may be able to craft a workflow which doesn’t require source control.

One more advantage of using source control even if you are working alone, you always have the option of easily sharing your code with people around the world, especially if you are using an internet-based system such as GitHub. This makes it easy to grow your team if things go well.

Are you hobby game developers out there using source control?

Hobby game developer vs career game developer

At the present time, I am doing game development purely as a hobby, meaning I work on it in my spare time and don’t earn any profit from it. And yet, some time in the future (could be several years from now, or longer), I think about what it would be like to be a career game developer, meaning that I make my living developing games.

While the fact of whether one gets his or her primary income from game development is black or white, I feel that it is possible to have a grey area where your are designing as a hobbist, but thinking like a career dev. To that end, I’ll try and illustrate the differences between these two mindsets in a little more detail.

Hobby game developer

Because there is little to no income involved, a hobby game developer has total freedom over what and how it is developed. This means that you can jump from project to project at any time. What tends to happen, at least in my own experience, is that most games that are produced are something similar to one played before and enjoyed.

For example, since I enjoy Starcraft I’ve made several games which bear at least a minor resemblance to it, and I’ve seen many other hobbists that have done the same.

Put another way, “I enjoy this type of game” plus “I enjoy programming” translates to “I enjoy programming this type of game”. Even if the game pales in comparison to the original, some of the happy memories from that will be revisited when playing the “homemade” version. This can be seen to be a bit like cover songs, since listening to them reminds one of the original version. If others feel the same nostalgia about the game, it can contribute to it’s success in the market.

A hobbyist developer doesn’t really have any deadlines or obligations, so generally there is less motivation to finish a project. As a result, many projects end  in a half-complete state when other more interesting things come up.

Depending on the person’s interests, he or she may learn new technologies just because they seem powerful or interesting, or for the purpose of buffing up their resume. There may be no connection to the quality of the resultant game produced using said technologies.

Career game developer

Because the career game developer makes a living from their job, possibly supporting a spouse and children, he or she generally has a much more serious attitude to things.

The attitude of the developer can change significantly depending whether the developer is self-employed or not. The focus of this article is mostly on the self-employed case, but I’ll talk about the company-employed one as well.

Company-employed (not self-employed)

A developer in this position typically has to follow the organizational structure and rules of the company who they are employed by.

For lower level positions, the employee’s main focus is just following orders from their direct boss. Quality may or may not be stressed, depending on the environment. Getting along with one’s boss, both socially and politically, can be important factors to promotions and other perks.

A key element here is that the developer’s salary, bonuses, and other benefits may not be tied to the game’s success in the market, apart from the fact that a failing game makes them a target for restructuring.

For higher level positions, there is typically more freedom as well as more responsibility to create a quality end product. The higher up, the more likely to profit from a successful game.

Self-employed

This category includes those developing and selling games by themselves, or part of a small team. The compensation of the developer in question is very strongly related to the game’s sales, so there is a very high level of importance put on making a “successful” game.

The key here is that as long as the game sells, the fact of whether it is “fun” to play by the developer(s) creating it isn’t relevant. In fact, you could end up working on a game that you would never play yourself, because market research has shown that it is likely to profit. Of course, it is ideal for developers to align the game they are producing with their own interests, but that isn’t always possible.

For the self-employed developer, abandoning a project midway through is a major sacrifice, because there was no direct profit achieved from those “wasted” hours. However, if there was some new market research indicating this game will no longer sell, it may make sense to cut losses. This is one reason the longer a game takes, the more risk there is to cancel it or redesign major parts of it. The upside is that the skills learnt, including knowledge of frameworks, programming languages, and OSes, may be a consolation since they can be leveraged for future projects.

Because of these things, there is more times that a career game developer has to put up with some tedious or unpleasant task – whether that is writing tricky code or trying to fix a tough bug. Even though it would be OK for the hobbyist to just give up at times like these, this is not acceptable for a career dev.

In exchange for these (hopefully) short-term struggles and compromises, the career developer has the chance of both increased rewards, as well as the satisfaction that their game did well in the market. Whether you coded a certain routine right or made a nice graphical asset is less important than the overall sales of the game.

===

Even if it’s only gradual baby steps, I’m going to try to gradually make this shift of mindset in the hopes of making the jump someday.

Let me know your thoughts on this stuff, especially if you are  acareer developer. Is there anything important I forgot?

Moving onto a new mobile game project and a new set of goals

My first mobile game on the iOS apple store, Play the Field, was a great learning experience in many ways, but to be honest the number of downloads was quite below my expectations, especially considering it was free. I knew the mobile game market was dog-eat-dog, but nevertheless I think I was still a bit too naive.

I still feel the game is a lot of fun, and at least one person who tested the game for me (who had experience with RTS games) said he felt it was enjoyable to play. But it’s pretty clear to me neither the gameplay nor the difficulty was the main factor in the small number of downloads. I’m pretty sure the game’s simple, unrefined visuals, was the real culprit. Although I tried to market those as “retro” or “minimalistic”, the actual number of games with visuals that simple that become popular seems pretty small. The game’s unfamiliar genre (“casual” RTS) may also have been a factor in the lack of popularity.

While I have recently done some experimental advertising for PTF, and may continue to do so in the future, I have decided on spending the biggest chunk of my time on a new mobile game. It’s something along the lines of a puzzle game influenced by classic games.

This time around I have a different set of priorities, the most important being to spend a greater amount of effort and time on polishing the visual and UI aspects of the game. In all my game projects up until now I’ve always went the path of least resistance (meaning I spent the most time of my time on other elements such as gameplay, AI, level design, difficulty, etc.), but this time I will shift that balance.

Since my lack of artistic ability isn’t likely to change anytime soon, I’m making the best of what I have – still trying to keep to simple visuals while adding things here and there to please the eye. In particular I’m trying to add more animations to the game, for the background as well as at the start of each level. In between each player’s turn there is also a special animation I’ve spent some time refining.

Besides this emphasis on visuals, I’m hoping my decision to make a more standard puzzle game will give it better chances at popularity, while acknowledging that genre is extremely competitive.

The final thing I’m planning on putting more effort into is making an enticing preview video, since I feel that’s one of the most important things determining whether a user makes the jump to actually download an app or not. Of course the screen shots are also important, and since animations won’t show up in these I’ll have to pick what to showcase wisely.

I’m aiming at the somewhat arbitrary figure of 2x over my previous game’s downloads, though part of me is hoping I can get at least 10x. Even 100x wouldn’t result in a famous game, but if I can see concrete progress in some form it will motivate me more to keep along this route. Otherwise, I may chose to devote my time elsewhere.

Programming is great fun, but there’s nothing quite like the thrill of real users around the world downloading your mobile game, with a great degree of unpredictability around what will be popular and what won’t.