What Programming Language Should You Learn for Game Development?

After doing software development for more than 30 years, the one question I hear most frequently is “What programming language is best for X, Y, or Z?” This is especially true in indie game development due to the explosion of indiedevs and the ease with which anyone can build games.

So which language should you choose? Turns out, it matters far less than you think. Let me explain why.

Harry Potter

Think about Harry Potter for a moment. What makes Harry Potter great? In my opinion, it is the humor, the dramaturgy, the characters, the mystery, and the joy of expectation that builds up as the story go on. You may have other things that are important or perhaps you don’t think the books are great at all.

None of this, however, is related to in what language the books were originally written. I know it’s English but millions and millions of people around the world has never read Harry Potter in its original language and yet, you can sit down with any reader of the books, assuming you know a common language, and discuss the same story.

Why is this? The language used is simply a means to convey something else. All those elements that make Harry Potter great, whatever you may think they are, are simply conveyed with a language. The books are not the language used to write them.

I’ll tell you another secret. I’ve never read any of the books. I’ve only seen the movies and yet I can keep conversations with my wife about the story and the characters. She’s read the books only in our native language Norwegian.

The language matters far less than what the language conveys. You need the language but it’s not really what makes the books, or most books, good or bad.

The Right Tool

In my first article on “Four #GameDev Lessons from 20+ Years of Software Development”, I paraphrased a quote, possibly from Edgar Dijkstra, that programming language is to programming like telescopes are to astronomy. I further went on to explain why language is irrelevant, and although I still stand by those statements, it doesn’t really give you an answer as to what language you should learn.

The problem with answering this question is that to understand the answer, you must understand programming, and to understand programming, you must understand the answer.

For example, language X may be strong in algorithmic solving whereas language Y excels at handling recursive data structures. Language Z on the other hand supports platform ABC and language W does feature DEF really well.

Which of these features are important? It is really difficult to know until you actually know what these features are and to do that you need to already have decided which features are important.

Chickens and eggs. Impossible to solve, right?

However, what if we look at the problem from a different angle? Rather than trying to determine whether we get the chicken or egg first by studying chickens and eggs, why not look at a broader perspective?

If we learn more about biology, we find ourselves much more able to figure out mysteries like these. It took modern science to solve the question from a biological point of view and scientists came to this conclusion not by studying chickens but by studying biology.

In programming terms, this results in looking at programming concepts. Rather than learning a language, we focus on learning the ideas that we need to express through programming.

Programming Without Language

See if you can find a physical phone directory in a book form. It used to be that you could talk about the phone book and everyone knew what that meant, but those barely exist anymore. If you cannot find one, you may just have to imagine the following problem, which is this:

How many names must you see in that book to find any given name? Imagine that you can flip to a page and look solely at a specific name on that page. How many pages must you flip until you find the name you want?

As a programmer, I can tell you that the answer is below 33 off the top of my head, but before I reveal how, try it yourself. You’ll find the answer later in the article.

Here’s another one. Get a group of friends together in a room and ask them to move to any spot in the room. Then, move them one by one so that they stand in a line in alphabetical order. How many times must your friends move in order to get everyone organized as such? Building off the previous problem, how many times must you compare someone’s name to another friend to find the correct order?

Next, pick up a city map and a pencil and pick two random points that are connected by roads. How can you move from one place to the other if you were driving a car that couldn’t turn left? Count the number of intersections you need to cross or the turns you need to make and give the map to your friends to see if they can find a route with fewer intersections or turns. 

Problems like these are what software developers face every day. You don’t need programming tools or even electricity to solve them. You need a phone book, some friends, and a paper map.

Programming in English

What you are doing now is logical problem solving. That is essentially what programming is all about. You can solve most, if not all of these problems in any language so as you can see, the actual problems you will face are independent of language.

In fact, I’ve just used English to express these problems and let me use English to solve at least the first of these problems, the one with the phone book. The answer is less than 33 because of an algorithm called binary searching. Binary searching halves the possible solutions for every name you see, and if you do that 33 times, you’ve exhausted all the people on the planet (more than 8.8 billion people).

The way binary search works is that you take a list of ordered items, just like a phone book. You then pick the middle item of that list and check whether the item you want is before (earlier in the alphabet) or after (later in the alphabet). Throw away or ignore the part of the list that does not contain the item you want and then repeat the process. Do this 33 times and you are guaranteed to have found your name.

Cool, eh? Without teaching you the first thing about programming, I’ve presented to you and solved a well-known programming problem, just using the English language.

So… Which Language?

It doesn’t matter. Really. Pick any but pick one that has ample learning resources. Learn its syntax and then use the language solely to learn programming and the concepts of programming. After you’ve done that, you’ll find that learning a language is irrelevant.

Whatever you do, don’t fall in love with a language just because it is the only one you know. After you’ve learned the syntax of one language, pick another one and solve the same or similar problems with that language.

Think of it as writing a mystery novel. It isn’t because you write it in German than people will love or hate it but because of your command of the thrill. Stephen King is scary in any language.

As someone who has done software development for many years, I’ve built production software in a myriad of languages. I’ve even built several languages myself.

When people contact me now to ask whether I can help them with some programming task, I can usually forego the question of language or platform because my command of programming means I generally spend less time learning how to express the solutions in a new language than I do understanding how to solve the problem.

Unity? Fine, I’ve done .NET development more or less continually since 2001. Unreal? Awesome, I wore out my first pair of baby shoes in object orientation using C++. Python? JavaScript? Perl? Java? I hadn’t written a line of Java for almost 20 years when I picked it up to build libGDX games in February and I had my first game published two weeks later.

Once you understand how computers work, how programming languages allow you to communicate your ideas to that computer, and how to ignore or work around the peculiarities of individual languages, the language becomes just another line in the game design document, if it is mentioned at all.

So go ahead! Find a phone book, a few friends, and a map and start programming in whatever language you like. It’s a great hobby or job, whichever you prefer!

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Four #GameDev Lessons from 20+ Years of Software Development

I recently left a long career doing corporate and business software development. In fact, I’ve written software professionally for over 20 years now.

I actually wrote my first game around the age of 9 or 10 and I continued writing games until I joined the army at around age 20 and had to grow up, as society wants to call it. As such, I’ve actually got 10 or 12 years of game development prior to that so I’m on safe ground when I say that I’ve been making computers dance to my tune for over 30 years.

Throughout those years, I’ve learned some valuable lessons, many of which are surprisingly relevant to game development, as different as that is from the “serious” side of software. I’d like to share a few relevant lessons.

1. If it ain’t fun, you’re doing it wrong.

At various times in my career, I’ve moved into different areas of software. Without exceptions, whenever I’ve started developing software within an area, I’ve had incredible fun. Without exceptions, whenever I’ve stopped having fun developing software within an area, I’ve left that area shortly thereafter.

Take web hosting. I built a web hosting company in the 90s and had incredible fun building very complex and advanced publishing solutions. At some point, we stopped doing that because it got too serious and people wanted to buy the company and other grown-up things. We had to focus on what generated revenue rather than what was awesome. It stopped being about fun and started being about making money.

The company failed within a year after that.

There’s a time to be serious and always enough serious to go around. There’s never enough pure joy in simply creating, contributing, and having fun! It is also a lot easier to keep motivated if you enjoy what you are doing.

Lesson learned: Do stuff because it excites you and makes you happy or full of joy.

2. Learn all the time because knowledge and skills are easy to bear

One important thing I’ve learned is to bring as much knowledge as possible with you when you stop working on a project or task. By that I mean that you should always ensure that you learn something when you do something, even if it is how something completely fails if you don’t follow certain patterns.

This serves two purposes. First, it exercises your brain, and from what I’ve read (don’t take this as any scientifically founded claim) your head needs exercise as much as your body in order to stay healthy.

Second, however, is that knowledge is very easy to retain. It’s not something you need to lift when you move to a new city or on which you pay mortgage over the next 30 years. It’s yours, it’s free, and it’s very valuable.

When we built our first game, Maff’s Math Game, we focused more on learning how to build games than actually building the game. In other words, the entire team mostly learned for an entire game development life cycle with no plans or intentions of making a profit.

The result is that when we start new games now, we can skip past many of the learning bits and get results much faster. True, the investment in learning cost a lot of money but we know that long-term, we get that investment returned many-fold.

Lesson learned: Omnia mea mecum porto, my life motto. Google it.

3. Build reusable components always

My company Lobster Games is currently building a new game series called Final Arena. I’m not entirely certain we have the right formula for the gameplay. I haven’t tested it yet but we’re still moving forward with development to the stage where we now hire composers, modelers, animators, and so on.

“That’s madness,” any conventional wisdom will yell at you if you did something similar. “You need to test your idea early and fail fast”. And I agree, but I’ve learned a more important lesson.

You see, the way we build games, the codebase allows us to replace any part of the game fast. If the current gameplay doesn’t work, fine, we can switch it with something better, but that doesn’t change that we need a system for controlling characters, telling the stories, saving the state of the game, keep track of health and inventory, and so on.

By building the various parts of our game as individual components, we can replace parts that don’t work without affecting the rest of the game. Equally important, we can take parts we build for this game and reuse in other games because unless I’m mistaking, there will be a need to have music, a story, and characters in future games too.

Lesson learned: Reuse always. Even if you won’t, assume you will. It’s easier than you think.

4. Language is irrelevant but mandatory

Wiser men than me have spoken about computer languages, but I tend to favor the paraphrased quote that languages are to programming what telescopes are to astronomy. You need one, but it’s never the goal of the operation.

It stuns me how frequently I see debates about which language is best for game development. The truth is that there is no answer, and that’s likely the reason why the debate can go on for decades with no clear outcome.

So, whereas you do need a language to do game programming, it is far less relevant which one you pick.

This brings me to the second part of the heading; you always need a language. Despite how many toolsets now exist for building games with no programming, learning programming is vital to game development. You cannot do game development well without learning to program.

In SharePoint, where I’ve spent most of the previous decade or so, Microsoft has had to cancel the most important non-code development tool, the visual design interface in a tool called SharePoint Designer, formerly known as Frontpage for those that know their history. Microsoft said they did this because SharePoint was getting a MySpace problem with all the willy-nilly modifications people thought were so great.

That’s happening because it is far too easy to get to a certain point and thinking you’re delivering value when in fact more times than not you are just painting yourself and possibly your team into a corner.

A programmer’s mindset, however, and in particular an experienced programmer’s mindset, will understand problems to a much greater degree before they start building solutions. They will understand maintainability, extensibility, security, and many other aspects that the drag-and-drop-and-website generation never sees.

And it’s not about programmers having superior intellects or anything like that. It is rather that writing code teaches you how to approach problems in a very rational and methodical way. As much as I can, I urge people to get into coding even if they will never write a line of production code for the rest of their lives, simply because it makes them more rational problem solvers.

Lesson learned: Learn programming. No excuses.

So, there you have it. Four important, if not the only lessons I’ve learned over a lifetime of software development that I’m not actively applying to my game development career.

Which lessons have you learned in your life that you’re now applying to game development?

Pin It

Why Jeff Teper Needs to Get me Back to SharePoint

Don’t worry, @jeffteper, I won’t come back to SharePoint. Not because I don’t think you can do awesome things but because I’m doing game development now and I’m having more fun than a warehouse full of barrels full of monkeys. Oh, and I’m doing it in Costa Rica. This is, I’m not joking, our meeting room at the Lobster Cave.


SharePoint used to be fun, and may be again, but not this much fun.

But let me get right to the point for those who do not know: Jeff Teper has come back to head the SharePoint team at Microsoft after being promoted just a year ago, a sign, I said at the time, of the death of SharePoint.

Hang on… If he was promoted out of the SharePoint team back then… And he’s back now… Does that mean he got demoted again?

Jeff’s first and perhaps most challenging task will be to get me to do SharePoint again.

But You Just Said…

No, I’m not coming back. But Jeff needs to make me, or more correctly, people like me come back to SharePoint. Those that left in the past couple of years. Whether those are developers, architects, customers, or community supporters.

Because the SharePoint community has been bleeding badly. You may not notice it but people have been leaving en masse. Even those you think do SharePoint are sometimes doing so solely because having it as part of their title still pays a salary, but they secretly look for ways to do other work, or even actively do other work.

This is a huge, huge problem for Jeff and one he needs to solve because the community is one of the most important reasons SharePoint became such a success.

Read: Why I Love SharePoint Part 2 – The Community

The SharePoint community in the olden days built tools that were orders or magnitude better than what Microsoft did. Carsten Keutmann singlehandedly built WSPBuilder and SPManager, tools that completely changed building solutions for SharePoint and maintaining them afterwards. He did so for free. Awesome stuff like that doesn’t happen anymore.

The tech bloggers are diminishing, as does the collective intelligence of the community. The level of questions asked in open forums is going down, which means that on average, the SharePoint professional sucks more these days than they did just a few years ago.

Jeff needs to change this trend because SharePoint is massively complex and without a vibrant community that is passionate about the product, it will die.

Read: Four Reasons Why SharePoint is Dying

So How Can Jeff fix things? I have some suggestions.

Stop the NDA Madness

I’m a vocal opponent to non-disclosure agreements where the existence of such NDAs hurt the people they are originally intended to support. The Edward Snowden case is a typical example of this; the behavior of the US intelligence community was deemed to be detrimental to the US population.

The SharePoint MVP community is also under similar NDAs and it is hurting SharePoint. Up until the public release of information about the removal of design view in SharePoint Designer 2013, MVPs were actively recommending using SharePoint Designer for tasks they knew full well would not be possible in the next version.

Why? Well, they had to. They can’t leak that the next version of SPD completely takes away such an important part and they can’t stop recommending people use it because they’d ask why and the MVP would be forced to lie, avoid the question, or otherwise protect Microsoft rather than its users.

They should have been allowed to speak openly about this and if so, it would have saved the customers a lot of strife.

Note that I’m not saying the decision was wrong. I support the removal of the design view. I just think that the customers who spent time developing solutions that depends on SPD may have benefited from this information being public sooner.

Read: I Was Wrong, Kill the SharePoint Designer Design View

Release Faster and When Announced

I’ve also previously complained about whereas Microsoft in general has adopted an approach of making new version of software available for testing immediately, the SharePoint team refuses and still has often a year from the announcement of a new version and until anyone is allowed to see anything.

Read: SharePoint 2016 Like it Always Was

Jeff needs to drop the time from talking about a new feature or version and until people can start using it from years to minutes or hours at the most. This is the way Microsoft works now,  and it is the way it should work. It gives more feedback in the vital early stages, early insight for better customer decision making, and an overall better public image than the secrecy that dominates the SharePoint team.

And you know what? It seems it’s working. Originally, Microsoft had said there would be a beta version sometimes late this year (2015). Now, shortly before Jeff Teper came back, Microsoft announced a public beta mere months away and far sooner than people expected.

Of course, Jeff has known for a while that he’d be demoted coming back again, so I’m fairly certain he had some say in the early release.

Well done, Jeff! Another notch in your hero-belt.

Stop Feature Creeping and Fix Problems

SharePoint has major issues. Technical issues that have been around for years. Apparently, before SharePoint 2013, there wasn’t time to fix the design view in SharePoint Designer.

Well, why didn’t you cut some of the new features that nobody asked for, like the app model? Nobody wanted that. It didn’t work then and it doesn’t work now, as evident by Microsoft’s decision to kill the app model and rename it to the add-in model to get people to use it.

Read: SharePoint App Model Solves Non-Problems Only

Rather than getting new bloat to an already bloated product suite, fix what’s already broken. Stop adding new stuff until you’ve stabilized the current version. I mean, why is there no way to remove the Recent items in QuickLaunch? Nobody asked for it but you felt you had to add it and now there’s no way to get rid of it without mucking about with CSS.

Oh, but one thing remains. The most important thing.

Jeff, if you read only one thing, read this:

Don’t Kill SharePoint Foundation

Look, we know it’s not bringing cash. We know you want to kill it. You’ve said there won’t be a SharePoint Foundation 2016 (or rather, Bill Baer said so).

You know what? SharePoint Foundation needs to be there so that you attract people. It is an awesome place for people to learn about SharePoint so they get sucked into the money vacuum called SharePoint Server.

If that’s not your goal, then I think you’re really agreeing with me that SharePoint is dying. That’s why this is your most important decision, Jeff: Everyone is watching. Kill SharePoint Foundation and you effectively declare that you don’t want people to learn and adopt SharePoint.

Microsoft in general agrees with me, which is why they are releasing things like the free web based Office suites and Visual Studio Community edition; they suck in people to entice them to remain loyal.

Be like the rest of Microsoft, Jeff, because they have turned around and are awesome now and the SharePoint team hasn’t been up to snuff for a long time.


Pin It