Friday, July 30, 2010

Minecraft: A Developer's Perspective

I've been playing a game called Minecraft for a while, and I decided I'd like to share a few thoughts about it.

What is Minecraft?
Minecraft is an amazing indie game, developed by Markus Persson, an amazing Swede who goes by the name “Notch” on the interwebs and communicates to the world through his blog, The Word of Notch. I'd say that pretty much anyone could have a good time in the game, even if you don't buy it (which gives you access to the most up to date version of the game). For free, you can play single and multi-player creative mode (build whatever you want), and a very outdated, but still fun version of single player survival. If you buy the game (right now it's just under 10 euro), you get access to the most up to date single player survival, which I'll explain a bit more about below, and very soon, access to multi-player survival (which is in development right now), as well as free access to every single future update to the game.

The up to date survival mode is really fantastic: you spawn in a blocky and practically infinite world (not actually infinite, but your computer would run out of memory before you could explore the entire map) with no resources, and you have to survive the hordes of evil monsters that prowl the world at night by building secure bases and crafting weapons. There are many items and tools you can craft, including swords, pickaxes, boats, armor, minecarts, and lots more. If you are so inclined, you could build yourself a fortress with traps to automatically kill any monsters unfortunate enough to wander into your territory. As an added bonus for those who are technically inclined, a recent update added the ability to create your own 'electric' circuits to perform tasks such as opening doors remotely, or triggering TNT explosions as monsters walk over them. I've spent a bit of time building a combination lock that traps anyone who enters the wrong combination, using some basic circuitry and a little bit of the almost non-existent in-game physics.

If you enjoy running around slaughtering helpless pigs and sheep, fighting through hordes of arrow-shooting skeletons as you search for resources late at night, riding minecarts down steep mountains, or if you just like to build vast epic structures, you should check out Minecraft.

Why the success?
Ok, enough of the free advertising! (But the game is just that good) Minecraft has been a huge success for Notch, with the game recently being bought 1000 times within 24 hours. It has been recognized as the amazing game that it is by people ranging from the TF2 dev team to random nobodies like me, and has been mentioned in publications like the PC Gamer. So, how did Minecraft attain this position? As an aspiring indie game dev, I have asked myself this question many times. Here is my attempt to answer that question.

1) Creativity. One of the primary premises of Minecraft is being able to build your own structures, to become a developer and exercise your imagination and creativity. When it was first released, the only game mode was single player creative, and it was a huge hit to those who knew of it. There are not many limits to what you can build, given enough time (except for things with perfect round edges). I have seen many amazing creations, from a model of the Earth to giant roller coasters. As an extra for those who have the know-how, you can create circuits (and if you have the time and patience, build a fully functioning computer).

2) Developer communication. Notch has done a fantastic job of keeping in touch with the Minecraft community. He has a regularly updated blog where he posts about how Minecraft development is coming along. He is open to suggestions from the community, and has in fact added features that were suggested by players. Unfortunately, Notch has such a huge fanbase that he can’t answer every single email or tweet addressed to him, but he does his best to be open and to keep updating the community on what’s new.

3) Frequent updates. Because Minecraft is still in Alpha, is has a long way to go before it is polished off and finished. Notch is taking an incremental development approach to this, and keeps steadily adding features and fixing bugs. He also has a recently begun the tradition of the “Seecret Friday Update”, where he updates the game with some feature(s) and leaves them for the community to discover. This practice shows the community that development on Minecraft is very much active and will continue to be such indefinitely.

4) Notch has fun. The reason Notch has brought Minecraft to where it is now is because he enjoys developing it. I can imagine that having to create software like Minecraft, but not having fun doing so, would be a dreary and painful chore for anyone, and most would probably quit before finishing. Notch has said plenty of times that he has fun writing code for Minecraft. Probably the best examples of this are the Friday updates, where Notch takes a break from whatever task he has been focusing on during the week, and takes a little time to have some fun with a new monster type or sweet little feature. He has made great progress recently on the multi-player survival mode, because, as he mentioned in a blog post, he is starting to have fun developing that massive feature.

Applying the facts
So, what lessons can an aspiring indie game dev learn from the example of Notch and Minecraft? In short: Keep in touch with the community, make sure your community can see the game in active development, and make sure that what you are doing is fun. Allowing player creativity is not always a feasible option in all game genres, but it definitely is one of the big perks of Minecraft. Looking at my own experience in game dev, all of these could and should be applied to that awesome and rather unsuccessful game which I help develop: HackWars. Frequent updates and keeping in touch with our community should definitely be worked on -- we are trying, but perhaps not hard enough. As to allowing for player creativity, HackWars definitely has this, but in a much more narrow fashion aimed towards players with technical knowledge, through the medium of player scripts and websites. One thing I’m sure of, and that is that I am having a lot of fun working on HackWars. Seeing player reactions to updates has always been very rewarding, and gives me incentive to keep on coding away at the mess of spaghetti code mixed with strange hacks and duplicate code and sprinkled with interesting comments that is HackWars. Oh, and it helps me to maintain the vision I have of HackWars becoming an amazing (more so than it already is) and popular game, which I will hopefully live to see become a reality.

Monday, February 22, 2010

More Communication and Tools

Well, it's been a while since I last posted; I have been rather busy with school and more recently, and I always found an excuse to postpone the writing of this post. However, a few key events recently paved the way to an end of said procrastination. Once again I will be drawing on my experience as a developer for HackWars, since that is an ongoing experience from a beginning developer's point of view (and it does make a great example).

Good Communication
As I discussed in my previous blog post, communication is key to a successful and smooth development process. This was made very apparent with the new direction HackWars development has turned towards. It all started with an email sent out to all of us developers, highlighting the need to examine our methods and to establish better communication between all of us. As a result of that email, the dev team held a meeting soon after. The meeting completely revolutionized the current state of our team, such is the power of good communication. For me personally, the meeting was more than just a laying out of plans for the future. It was a great morale booster. Having our entire team together, actively discussing our next steps in developing the game was something which hadn't happened in a long time; I felt a lot more motivated towards fulfilling my role. Since the meeting, we all have kept this communication level, and will doubtless continue to do so. With the much greater amount of information flow between us, developing has been a much easier process, and the future of HackWars looks much brighter.

To work effectively, you need ...
Tools! Yes, tools are getting another discussion as well as communication. As a result of the meeting, we decided on a new development process. In the past, development tools were batch/shell scripts, notepad or a similar editor, and a basic code repository. This led to some massive disorganization with respect to pretty much any changes to code. I had at least 4 different local copies of the repository all at different states. Although these were somewhat organized, it's still not an effective method of keeping track of code and progress (My only excuse for this is inexperience). As a result of this meeting, Ben, who has been learning a lot about professional development thanks to his awesome job at a startup, decided that we should have a professionally organized repository structure. This enables us to keep much better track of any major code updates, the current stable version, etc. Just recently, we decided to upgrade our development process even more by using the project management software, Trac. Most project management tools include features such as project timelines and task / ticket tracking. This addition to our toolkit has greatly bolstered our ability to effectively produce new, working, tested code, fix bugs, and to track down new bugs introduced by new code. Furthermore, we can keep track of what's been accomplished so far and where each task is relative to it's completion. After using Trac for only a few days, I can already see how absolutely necessary it is for any dev team working on a major project to have a good project management system to support them. Even though HackWars got a late start on this, "better late than never" holds true. I look forward to watching our development process grow and become refined as we learn through our experience.

In summary, the HackWars dev team is going in only one direction, up! Since I joined, I have seen constant improvement both in the game and in the way it is developed. I have learned a lot so far about developing on a large scale, and will no doubt continue to learn. Experience is another very valuable asset I have obtained from helping HackWars, and this one you can only gain by doing. Heck, in a couple years, I might even be a half-decent developer with the background to back up my ideas; who knows? Some of my other projects besides HackWars might be known by that time as well.

So long for now, I'm going back to my schoolwork and dev work!

Thursday, January 21, 2010

Large-Scale Developing: A First Look

A Small Introduction

During my relatively short experience as a programmer, I have developed a few applications, although none of them are anything big. A few months ago, I started helping with the development of the online game HackWars, for a few reasons, mainly because I think it's a great game, and would love to see it go places. HackWars is a project orders of magnitude greater than anything I had ever worked on before, but I was (and still am) willing to learn and help out as best I can.

I could spend a while talking on the state of HackWars when I joined, but that has already been discussed over at Hackstock Design and Dev. Examining the state of HackWars naturally leads to the question: how should one approach the process of developing a large application? I will be exploring possible answers to this question, as well as looking at it through different perspectives.

A Programmer's Perspective

I joined HackWars as a programmer. This means I would be given instructions of some sort (fix bug X, work on feature Y, etc.), and then do my best to complete what was asked. This seems straightforward, and it is in most circumstances. With HackWars, however, the situation was very different. The primary developers were busy with various activities like job hunting and finishing off a Master's degree, so after some initial discussion, I was more or less left on my own. I would talk with the primary developers for maybe a few minutes to an hour per week. As a result, I spent most of the time fixing bugs (something that always needs to be done). This changed when DraconisRavenix, another recent player-become-dev, began to take the design and development process into his own hands. We had been given a rough idea of where the game was supposed to go next: adding a massive amount of new content and quests. He was able to take the rough specification and convert it into a much more specific set of tasks, and I was able to start working on code needed for the new content. The key player in this change was communication. Draco and I talk on an almost daily basis, and this enabled us to keep information and feedback flowing between us about the update in progress.

It's Not All In The Code

Unfortunately, most of the work-load needed for the new content update fell in Draco's realm: game balance and in-game content. This could potentially create a choke point on the speed of development process. However, I had another realization here, which I will explain. I was talking to Draco one day, and he started to complain about how arduous the task of editing NPC save files was. Somewhere in my head a lightbulb went on, and I asked him if a custom tool to edit the files would make things easier. We both jumped on the idea, and he immediately provided me with several specifications that would make the editing process better. Within a few days, I had produced a tool which was usable, although it still lacked many of the requested features. After another week or two, I had polished off a full version. This tool sped up the development process considerably, as well as making it much easier. The conclusion: external tools can be invaluable aids in the development process.

New Beginnings

With the coming of the new year, I have been asked to help out in another major project, which will be starting from the ground up. I will be assisting in the entire development process from the beginning, and I will be able to apply lessons I have learned from developing HackWars to this new project, as well as learn much more about the development process for large projects. I will still be developing for HackWars, of course, and will hopefully see it growing and improving. All this is in addition to my schoolwork, so it looks to be an awesomely busy year ahead.