LFG: Why Your #Gamedev Idea is Important But Not As Much As You Think

I have been hanging out in the indie game dev community for a few months now, observing, building games, and participating in discussions. After more than 30 years of software development experience, I think I have something to contribute despite my relative inexperience in game development as such.

One thing that somewhat surprises me is the degree to which people are looking for groups. What surprises me even more is how many people seem not to even do basic research before thinking they can get started.

Note: The term Looking for Group, or LFG, originated in MMO games where players were looking for a group with whom they can explore, fight monsters, and share loot that they would not be able to do alone. In game development, it seems to be a similar approach, mostly because building a game can be a daunting tasks requiring a wide range of skills.

It is rather amazing from several perspective. I cannot imagine any other business where people would join random strangers to build something that will hopefully feed their families. I know, many of these ad-hoc teams aren’t really bread winners, but it is still a large part of the indie game scene.

Quite often, however, I see someone posting a request for programmers, artists, writers, musicians, and so on, because they have an idea for the next big thing in games. They think that they can promise revenue sharing as a viable compensation to these people they want to hire because they do not really have any money.

Now, enough things have been said about revenue sharing and how it never works. And really, it never works in the same way I can say that nobody ever writes Facebook. Sure, one person did, but it is not really a viable business model to expect that to happen. However, even granted that, revenue sharing never works when the idea person initiates it.

The Problematic Ideas Person

Here is the problem with the idea person: your idea may be great but there is no way to know whether it has merit or is just another waste of bits and bytes. It takes a lot of work to prove that your idea is valuable and do not let this stop you, most ideas are not valuable.

As a programmer, I can know whether my code is any good because I feed it a bunch of data and get a result and if I am any good at what I do, I get the result I want repeatedly. It takes work but I have a very clear path from no code to code with specific rules or patterns I can follow to get the results I want.

The artist can know whether their art is good because they can show it to someone and have someone say “Wow, Picasso would be envious” or the complete opposite, “Wow, Picasso would be envious”. The music person can play his clip to friends and get immediate feedback in the form of “Wow, my ears just had an orgasm” or “Wow, my ears just got raped”.

If only Justin Bieber has solicited such feedback, he might have turned into a carpenter or something like that and the world would be a better place.

The idea person, however, has no such benefit until you have all the other elements. You cannot explain to someone what fun is in a repeatable way. You need to feel the game idea to understand whether it is interesting.

Explain Comedy

Let me give you an example: Explain to me, please, the premise of Faulty Towers in a way that makes me laugh every minute as I usually do when I see the show. Or pick any Monty Python movie any other show or move that makes you laugh. Pick Arrested Development if you cannot come up with anything else.

Explain that show or movie to someone in such a way that they truly get how brilliant those shows or movies are. My wife has tried, several times, to explain why Arrested Development or Bones are really cool series, and even knowing her and that our tastes are very similar, I can’t really say I want to watch either.

Just try it; it is exceptionally difficult to convey a final product in a short idea even when you know the product is brilliant. The term “I guess you had to be there” is a perfect example of how someone experienced something that they cannot really convey later.

That’s not to say your ideas are worthless, only that having an idea and getting to someone else being as enthusiastic about it as you are is really, really difficult. The engineers and artists who build code or pictures or sound have it easy. You have it hard and frankly, most of you are really bad at it.

To make matters worse, this is a very typical “well, how hard can it be?” situation for everyone who isn’t on the inside, where it is really easy to get started conjuring up ideas but where the work from there until you have one other person agree with you is exceptionally long and hard.

Dogfood, Eggs, and Baskets

I work for a game company called LOBster Games (this is my blatant self-promotion). We build a range of different games, from small quick projects like Letter City or Twisto to major undertakings like Final Arena that we don’t even know whether we’ll finish.

I’ve come to appreciate the ideas coming from the other members, or lobsters are we call ourselves, of the team. Whether those ideas are good or bad, we can’t know so we need a method for finding out.

At our company, we take ideas that come up and build them to a prototype stage very fast. In fact, Twisto went from “Hey, I have an idea” to first playable version in less than a week, to a fully feature complete version in two weeks, and to first public beta, mostly polished, in three weeks. If all goes according to plan, we’ve gone from idea to public launch in four weeks, which includes testing by external beta testers. There was a similar pace for Letter City.

That rapid pace means we can quickly test whether our ideas work for the audience. If not, the risk to us is low and we can move on to other projects without necessarily feeling too bad about the loss of time or money. It takes a bit longer and costs a bit more than an elevator pitch but has the same idea behind it.

There are other strategies that may work very well too to reduce the risk. The key question, however, is that as someone with mostly an idea, what exactly do you do to mitigate the risks of the team? Because that’s part of your job.

Have an Idea? Run With It!

So whereas everyone always needs to start with an idea, it is very hard work to get that idea from simply being that and to something that has real value. I am not discounting your ideas in any way. In fact, unlike many people in the community, I encourage you to come up with more ideas.

However, you must realize that it takes a lot of effort before anyone will buy your idea from you and that is why you struggle when you are looking for a group as an ideas person. You must understand that when you approach someone with an idea, you need to not just explain your idea to them but also how you plan to make that idea into reality. That takes skill from your side and if you don’t have that skill, you probably should hold off from trying to recruit others to your fledgling empire of awesome, as much as you are certain it will be just that.

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

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!

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