Adventures Of An Accidental Games Developer – 2 – Source Management

My next blog post will be about the SDL library, But I don’t want to talk about that yet. I want to talk about something really, really important. Something that a lot of programmers don’t do, but really ought to. Source control. Particularly, source control with Git.

If you’re about to start a major development project, such as the creation of a video game, you’d do well to start good proper source control management processes.

Now, there are other source management systems. SVN, Mercurial and Microsoft SourceSafe are two examples I can think of from the top of my head. But I know Git best, so that’s what I’m going to be banging on about. 

So, what’s this Git then? 

Git was invented by Finnish-American programmer, Linus Torvalds. You may know that Linus is also famous for developing the Linux kernel which runs on billions of servers, cell phones and computers worldwide. It was initially created to manage the development of the Linux kernel, which is one of largest open source projects in existence with hundreds of thousands of contributors.

In a nutshell, Git allows for rapid, seamless developer collaboration without the risk of malicious corruption. And it just works.

Why Should You Care?

Are you worried about having your source code corrupted? Are you worried about making a change and it breaking your application? Would you like to be able to roll back your application to a specific period before you made a change? Would you like to be able to work with your code on your local file system, and have your main source code trunk being on a separate device? Or even better, on the cloud?

If you answered ‘yes’ to any of those questions, you probably want to start using source control. And Git is hands down, the best one on the market right now.

Who Uses Git?

Lots of people use Git. Popular open source projects like Gnome, Ruby on Rails, Node.JS and Flask use it to allow for coders around the world to work on one project with absolute ease.

There are some unorthodox use cases for Git too. There’s a guy in the UK called Francis Irving who uses it to track issues with his house, as shown in a recent Wired article .

Thousands of companies use Git internally, and it is rapidly replacing Sourcesafe, CVS and SVN as the source control manager of choice. Git is huge. And it’s not going away.

What is Github?

Github is a site that allows you to freely store open source projects on the cloud. They also allow you to have private projects stored on their servers, provided you are a paid subscriber to their service.

How do I get Git? 

Git is open source and available on most platforms. If you’re using Linux, you can grab it from your  repositories. There are binaries available for OS X and Windows. Incidentally, there’s an incredible metro app for Windows.

Many IDE’s have plugins that allow you to work with Git and Github. My favorite Java IDE, IntelliJ comes with a Github plugin built in. Eclipse has an optional third party plugin that provides Git support.

Whatever your platform or development environment, there’s nothing stopping you using Git.

Learning Git

Git may seem a bit daunting at first. Learning it isn’t hard though, and can be done in 15 minutes. Check out the Try Git course from CodeSchool.

Fin

I hope I’ve convinced you of how awesome Git and proper source control is. If you use a different source control method to Git, I’d love to hear about it! Just drop me a comment below.

Enjoy This Blog Post?

You should subscribe. Pop your email in the box in the sidebar and you’ll get an email whenever I write a new post.

Adventures Of An Accidental Indie Games Developer – 1 – The Minimum Viable Product

Minimum Viable Product is a term that gets banded around a lot, especially in ‘Lean Startup’ circles. It’s not a difficult concept to grasp, and being able to understand, plan and work towards an MVP can make planning and coding your product a much less stressful endeavor.

In this article, I’m going to talk about using MVPs to plan development, and why they rock.

product_donuts-copy

Borrowed from Pando Daily. http://pandodaily.com/2013/02/04/three-reasons-not-to-build-a-minimum-viable-product/

Minimally Viable

So, let’s imagine a hypothetical scenario. Let’s imagine that it’s the early 20th century and there’s been a fire in the offices of Henry Ford in Dearborn, Michigan. It couldn’t have come at a worse time. Henry was about to demonstrate his Model T car to the world, which would revolutionize motoring. Sadly, the fire consumed his only prototype and all his blueprints. He’ll have to start from scratch.

What Makes A Car?

So, let’s pretend you’re in Henry Ford’s shoes. You need to reinvent the car that would ultimately shake up manufacturing and transport and you decide to create a minimum viable product. This contains all the features you need to sell, market and demonstrate your product, and no more. So, what do you need?

  • The ability to increase and decrease speed as required, and to traverse obstacles and roads. 
  • A chassis, to keep out rain and to protect the internal components.
  • Somewhere for the driver and any passengers to sit.

This is the minimum viable product of an automobile. All the other cool stuff like heated seats, bluetooth and iPod docking can come later. For now, this is all he needs for him to call his product a car. 

How Does This Relate To Games Development? 

As someone getting into games development for the first time, I’m constantly aware of the need to have an MVP, and to work towards it.

Having a pre-defined minimum viable product is actually the cornerstone of all my planning, as it keeps me conscious of essential features, and allows me to ignore that pesky little voice in my head that asks ‘what if?’. The pesky little voice that, when obeyed, results in distraction from your main objectives, and adding lots of non-core features before you’ve completed the essential facets of the game. 

In retrospect, someone ought to have told the developers of Duke Nukem Forever about this fabulous concept.

What I’m Working Towards

So, I’m working on a game right now. Here’s what my MVP is.

  • My application will be able to parse a JSON file. 
  • That JSON file will then be rendered in the game as a room.
  • The JSON file will contain information relating to a character, and that character will be able to traverse the room.
  • The JSON file will contain information about events, which will be interpreted by the program. These events will be predefined.

And you know what? That’s all I’m going to do. At least initially. I can add the sparkles later. I can make it look prettier once I’ve got core functionality down.

You can’t build a house without foundations.

Fin

If I’ve piqued your curiosity and you want to read more about lean concepts, I can’t recommend The Lean Startup enough. It’s a fabulous read.

Enjoy This Blog Post?

You should subscribe. Pop your email in the box in the sidebar and you’ll get an email whenever I write a new post.

My Code Is Bad And I Should Feel Bad : What I Learned From A Code Review

So, I’m fairly young. I’m 21 years old. There are a lot of people out there who are significantly smarter than I, and have a hell of a lot more life experience than I.

Nothing is more true when it come to programming. There are some people out there who are just mindblowingly amazing coders. You see them, and you just want to channel Wayne Campbell and go all:

And I think that the best way to improve as a programmer (or as anything really) is if you speak to these people and ask them to look at your code and to give you advice and direction.

So, I asked my close friends Roland Hesz, Dewi Morgan and Frans De Jonge to look at some Java code I produced and asked them to give me a code review and to be honest and brutal and to give me constructive feedback. I wasn’t disappointed.

This article will look at some things I picked up from my code review, and how I plan to improve.

My Project – Java!Java!JSON!

It’d likely be worthwhile to explain what I’m trying to actually accomplish first. So, I’m a student of Computing at Liverpool Hope University. In our first year, we learn C and Java, and we we have to make a product in each of these languages. In C, we make a video game or a physics simulation. In Java, we can make whatever we want.

I decided to make a toy compiler and VM. The project is called Java!Java!JSON!, and is named so because it interprets a specially structured JSON document which is then passed into a toy VM written in Java, which runs on the Java VM.

It’s nothing awe inspiring. It’s a fairly basic project that I’m working on because I enjoy finding unique ways to abuse JSON and because I thought it’d be fun.

Getting Feedback

I sent off my code (handily stored on my Github profile) and waited. Each of my friends then promptly responded with some amazing, clear, actionable feedback. Here’s what I learned.

Parlez-vous Java?

So, I’m no Java developer, and I don’t have the deepest knowledge of the Java API. Most of my experience is in other languages, like PHP and Ruby. As a result, I had code that was a bit like this:

System.out.println(“File located at: ” + Directory + “/” + OutputName + “.JJJ”);
// Obviously the above is only true on a *Nix system. I should eventually work out how to determine the user’s OS.

Can you see the problem there? If I ran my code on a Windows system, it wouldn’t run because Windows uses backslashes in its path declarations.

Fortunately, Java has a nice little built in method called File.separator which actually determines what OS is running and what file separator type is appropriate. This does pretty much all the leg-work required. I didn’t  know about this until Frans told me about it.

From this, I realized that I should sit down and get a better, more in-depth understanding of how Java works and learn the useful little facets of the Java programming language.

Source Code Only A Mother Could Love

There were parts of my code that were actually not really hideous. Functions were terse and clearly named. I made sure they did one thing, and one thing only. They obeyed Curly’s Law. Capitalization was really consistent. On the whole, I was generally quite consistent.

But, there were bits of the source code that could be more aesthetically pleasing. Firstly, I could have changed my capitalization to reflect scope and to reflect the contemporary coding styles in Javaesque languages.

Whilst my functions were quite clear in what they did, I didn’t really comment all that much. Yeah, I know it’s really damn important. In particular, there was no commenting in my Main method. This really, really needs to be fixed as you can’t really gleam what the program does just by looking at the Main Method.

Cancelling The Housekeeping

So, in my code, I had a few methods that would call System.exit(1) whenever they’d hit a critical problem. This works like the little red ‘Emergency Stop’ buttons on trains, and just ends the program without doing anything else.

Whilst this is fine for a tiny little toy program like mine, it’s generally bad practice. What if your program opens a DB connection? Are you just going to leave a bunch of connections open? This is a major design and implementation issue.

In my case, what if my program fails whilst interpreting the JSON file and has already started to write to the pseudo-bytecode file? It’ll just quit without tidying things up, or without giving any meaningful information as to why things went wrong.

The solution? I’m going to write a class that handles what to do when things go all Pete Tong. Some logging will be involved. I’ll try to close things more gracefully. I’ll try to tell the user where things went wrong

Fin

Zed Shaw in his infamous ‘Rails Is A Ghetto’ rant said something that really resonated with me:

“Great programmers don’t defend stupid, they stamp it out and own up to their mistakes.”

I’m not a great programmer. Nowhere near. I’d like to be one. The only way to be a great programmer is to identify where you’re screwing up and where you’re going right, and to make concerted efforts to get better. And I’m really grateful that I have such brilliant friends who are prepared to talk to me in depth about the code I produce. To Frans, Roland and Dewi: Thanks ever so much!

Help Me Out

My project isn’t even slightly finished, but I welcome feedback and advice. The source to the VM is here and the source to the compiler is here. I’d be honored if you had a look, and told me what you thought.

Like this article?

You should subscribe. Pop your email in the box in the sidebar and you’ll get an email whenever I write a new post.

Adventures Of An Accidental Indie Games Developer – 0 – Bearcat

I’ve never really been into video games.

Sure, I had an Amiga, PC and XBox throughout my childhood. Sure, I occasionally liked to play a bit of Doom (1, 2 and Final. None of that Doom 3 nonsense) and some Morrowind.

But it was never really my main passion.

I was much interested in other stuff. I wanted to be a writer, or a coder. Video games didn’t really interest me all that much. When I eventually sold my Xbox, I thought that was it. That my time gaming was well and truly over.

So, naturally when I went to University to get a degree in Computing, it just so happens the final assignment of the first year is to create a video game. This should be fun.

Requisites, and stuff. 

So, let’s first talk about what I have to do in order to get a passing grade. The video game must be developed in the C programming language, and use the SDL (or some derivative of) graphics libraries. OpenGL is acceptable. 

We also absolutely must include and make use of a particular library called Chipmunk.  We are assessed on two things. How much effort we put into the project and how creatively we used Chipmunk.

So, what’s this Chipmunk then?

Depends on who you ask really. It could be a fairly terrible rapper from East London. It could also be three furry forest creatures suffering from severe helium toxicity. In this instance though, we’re talking about Chipmunk, the physics engine.

Without going into too much depth (Don’t worry, I’m going to do that later), Chipmunk is a beautiful, cross platform library which allows you to simulate gravity, friction and particle physics. It has some wonderful, cross platform bindings and just generally rocks.

With it, you can make fun puzzle games like World Of Goo, or just create fun little physics simulations. It’s really something else.

Finding Some Inspiration

So, growing up the only two games I really played religiously were Pokemon on the Gameboy and Doom on the PC.

Doom was cool because it was immensely customizable. You had these files called WAD files, and they contained all the textures, logic and metadata required to create a level in the Doom universe. And it wasn’t just ID Software who could create these WAD files. Anyone could make them.

Of the millions of people who played Doom, thousands were inspired to create their own levels. In many respects, Doom was host to the first real modding community of any video game.

And Pokemon? Well… I just really enjoyed it. It was a charming, top-down RPG game with a great storyline. You could easily pick up and play, and it was (in my humble opinion) perhaps one of the best games ever to be released for the Game Boy console.

So, what does Pokemon and Doom (two wildly disparate games) have to do with my computer science project?

Well, to explain that, I’m going to have to explain a thought process I had the other day.

Now, suppose you want to be a film maker? Well, that’s one thing that is decidedly easier today than in was in the past. You just get a camera, shoot some footage, edit it and then upload it on to Vimeo. And you can do that on a standard home computer.

What if you want to make music? Well, most laptop computers have a microphone and a webcam. You can sing a song in your bedroom and be seen by millions, as people like Kina Grannis have done.

If you want to be a writer, you can just open yourself an account at WordPress.com and start writing. Trivial stuff. There are even specific communities on the internet that cater entirely for fiction writers.

All these creative pursuits are vastly simpler as a result of the Internet and computer. But it’s not gotten any easier to create a video game. Not really.

What if you wanted to create a piece of interactive fiction?

What if you just had to edit a single JSON file to create a room in a video game?

What if you could learn how to create an engaging, entertaining, top-down RPG video game in just 30 minutes?

My Plan Of Action

As part of my undergraduate degree, I plan to write a program that interprets a specifically structured JSON file which describes a room. That JSON file will contain information pertaining to what the room looks like, what it contains and events that occur when prompted or interacted with by the user.

The aim is to simplify the process of creating interactive fiction drastically and to profoundly lower the bar to entry when it comes to video game development.

In the process, I aim to become a more competent C developer and to gain a deep understanding of the SDL and C libraries. And hopefully create an end product that just plain rocks.

And I’ve decided to call it BearCat because I’m really terrible when it comes to naming things. And because bears are powerful, and cats are elegant and I want my end solution to be really powerful, but also really elegant.

And, naturally, I plan to blog about it every step of the way, along with other topics that I think are relevant to the field of games development.

Because, y’know… It’s me.

Interested? Want to be the first to know when a new blog comes out? Just put your email address in little box located in the side bar, and you’ll be the first to know whenever I write something new!

The HTML5 Diaries – 6 – The Tough Bits

This is the last part of the HTML5 Diaries, covering the Microsoft 70-480 exam. So far, we’ve looked at the basics of HTML5, including semantic markup, Canvas and the new form API. We’ve also looked at CSS3, and how we can use CSS to change how our markup is presented. We’ve also looked at Javascript, in all its weird and wonderful glory.

In this blog post, we’re going back to Javascript and we’re going to look at some really, really advanced topics; Web sockets, web workers, exception handling and promises. The contents of this tutorial corresponds with the final video on the Microsoft Virtual Academy.

The way this lesson is going to be structured is going to be a little bit different from previous lessons. I’m going to explain the theory behind each of these topics, but there isn’t going to be a great deal of code behind them. Rather, I’m going to point you in the direction of some other blog posts and tutorials.

Make no mistake, these are huge, huge topics. I couldn’t give them justice in just one blog post. That said, I’m going to try and introduce them in a really gentle manner. Now, if you’re just coming here, you probably want to start from the beginning of the series. If you legitimately have no idea what the hell I’m on about, you might want to read up about the Microsoft HTML5 exam. Click here for more information.

So, let’s begin.

Exception handling: What is it, and why should you care?

So, suppose you’re designing a highway. You expect your highway to link two major cities and to carry lots of traffic. What happens if a truck overturns on your highway, causing a major pile-up and severing all lanes?

Well, the first thing you’ll want to do is to let people know that there’s been a pile up. You’ll also want to funnel traffic through alternative routes so that you don’t end up with a massive backlog of cars. Exception handling is basically the procedure that you do when a lorry overturns on your highway. The highway in this analogy being your application.  Douglas Crockford defines exceptions as this:

“Exceptions are unusual (but not completely unexpected) mishaps that interfere with the normal flow of your program.”

When you set up exception handling, you’re basically defining a set of behaviors that the program will enact whenever things go south. So, let’s look at the example the good Mr Crockford gives in Javascript: The Good Parts.

var add = function (a, b) {
if (typeof a !== ‘number’ || typeof b !== ‘number){
throw { name: ‘TypeError’, message: ‘add needs numbers’ };
} return a + b;
}

So, what are we doing here? We’re defining a function called ‘add’ which takes in two inputs. Inside the function, there’s an if statement which checks if ‘a’ and ‘b’ are both numbers. If they aren’t, the Throw statement is called and that interrupts the execution of the function. According to Javascript: The Good Parts, a throw statement should be given an exception object which contains a name property and a descriptive message property. Name property just identifies what’s gone wrong. The message adds an element of description.

When you use that function, you’re going to want to catch the exception that is thrown. So, let’s use the ‘add’ function we defined earlier incorrectly and see how we meaningfully use exception handling.

try {
add(“cactus”);
} catch (e) {
document.writeln(e.name + ” : ” + e.message); }
}
So, what have we done here? We’ve called the ‘add’ function from within a Try block. Now, if we successfully use the add function, happy days. The program will continue its normal flow and continue to the next bit of the program. If you recall, the ‘add’ function is expecting two numbers. We’ve given it a string of characters. That’s unexpected behavior, and will cause the function to throw an error.

That’s where Catch comes in. Catch basically catches the exception that is thrown and assigns it to a variable called ‘e’. Within the Catch blocks, it will then print out the name of the exception along with the descriptive message. And that’s basically that. From here, I suggest you check out chapter five of Eloquent Javascript. Now, let’s look at some harder stuff.

Promises: I promise the next few paragraphs will not use long winded analogies.

I lied.

Imagine you’re working as a software developer for a big company. You’re a busy guy, and lunch comes and you’re really, really hungry. So, you go down to your favorite Mexican place to get some tacos with your laptop so that you can do some work.

You go into the restaurant, find a space, put your coat and bag on a chair and stand in line to order your food. When it’s your turn, you order the beef tacos with some nachos and you return to your table, as you await your food.

Now, you’ve paid for your lunch, and the people in the kitchen start cooking it. You know the food is going to come. You’ve given the teller money for it, after all. Do you take your laptop out and start working?

If this is the real world, the answer is yes. But with Javascript, it’s a bit more complicated.

Suppose you have a function that does a lot of stuff, and therefore takes a while to execute. About 100ms. Now, Javascript normally would wait and block until that function is fulfilled. Now, suppose that you’ve got other stuff in your application that uses Javascript? UI elements, and all that jazz.

Well, they’re not going to do anything until that function you called finishes what it’s doing.

Promises work by returning a dummy value, allowing your application to do other stuff. Once the function has finished its task, it’ll return its true value.

Promises are really complex, and other people have explained them better than I could have in just these few paragraphs. Have a butchers at this blog post from Bryan Klimt (of Parse.com) and this one from the MSDN.

Web Workers: (Web) Workers Of The World, Unite.

So, what are Web Workers? Consider this (admittedly terrible) analogy.

Professor Gerhard has a brilliant mind. He’s at the forefront of evil science. His advancements in apocalypse summoning technologies are world renowned. His advancements in the fields of mind control and hypnosis have won him many Evil Nobel Prizes. Unfortunately, Professor Gerhard has limitations.

Despite being an evil super-genius with an army of minions and a death ray, he still only has two hands and one brain. He can only do one thing at a time. He’s just a person, after all (albeit, an evil one). So, naturally in a quest to augment his productivity and to speed up his quest for world domination, he decides to clone himself.

He attaches a phone booth to the top of his towering fortress of solitude and waits for a lightening storm, like an evil Marty McFly. Eventually, a bolt of pure energy strikes the red phone booth in which he concealed himself, and blue bolts of energy surges through his veins, knocking him over. He hits his head of the floor, speedily rendering him unconscious.

Eventually, he comes to. His blurry eyes focus. And who does he see? Himself, standing over him. It’s his clone, spawned from the high voltage that was pushed through the red iron chassis. Now, with his clone, he is unstoppable. The 80’s rock band Power Tool once said that two heads are better than one. They were right.

So, where does this terrible, terrible analogy fit to Javascript? So, Javascript is like Professor Gerhard. Despite being this powerful, object oriented, Turing complete language, it can only do one thing at one time. It’s not concurrent.

These things called Web Workers are the only way to do concurrency in Javascript. The Javascript language itself is single threaded. The way it works might be seen a bit hack-y, but it works nonetheless. You’ll define the behavior that you want to execute in a bunch of external scripts. You then call them when you need to by spawning a new worker.

Communicating with these scripts, or web workers, is done by using something called Messaging. It’s also worth noting that web workers can’t mess with the DOM, so if you want to use them for cool hacks with your markup, think again. HTML5 Rocks has a great article about Web Workers. I’m just going to leave it with you, and let you carry on from here. It’s a big topic, after all.

Web Sockets – More Fun Than Deleting System 32

Web Sockets are interesting. Think of them like R2D2 in Star Wars: A New Hope. There he was, just a normal R2 droid, loitering about on Tattoine, spending his dusty days getting shot at by Jawas and sold to the ill-fated Lars family. And then Bam. He’s shoved into an X-Wing with Luke Skywalker and the rest of Red Squadron, shoving a torpedo down the cakehole of the Death Star. In short, they add this extra abstraction of awesomeness to Javascript and to your HTML5 web application. They add lasers to your application.

So, enough with the astonishingly tenuous metaphors. What do Web Sockets actually do? They basically allow your web application to have its own network connectivity. Pretty cool, right? With them, you can create a continuous, persistent connection to a remote server, and send and receive data to and from said remote server.

Where would we use Web Sockets? Think things where high latency is bad. So, you’re talking about your browser based multiplayer video games (especially first-person shooters) or web applications where data needs to be readily and frequently updated and is time sensitive, like stock tickers. A cool thing about Web Sockets is that you can send data either in the clear, or encrypted. Web Socket functionality is also present on most web browsers. Even Internet Explorer has Web Socket functionality!

Web sockets are kinda hard to comprehend at first. As I said at the start of this blog post, I’m not going to scare you off with heaps of code. I’m going to point you in the direction of some amazing resources. And most fortuitously, HTML5 Rocks has a great lesson on them. Check it out. If you’re feeling brave, have a look at the RFC for the Web Sockets protocol.

RFC stands for “Request For Comments”, and they’re used by computer scientists to debate and design standards for protocols. By reading the RFC for web sockets, you’ll find yourself getting a really deep level of understanding for what Web Sockets actually do.

Fin

This concludes my six part tutorial on the Microsoft HTML5 70-480 exam. I wish you all the best success with your exams. If you have any comments or questions, please leave a comment below, or ping me an email here.