Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

About this blog

Helpful tips and notes

Entries in this blog


The Programming Primer

Hello again everyone:
I have been seeing a lot of confusion with some of our beginning level programmers on the forums lately, namely in what programming language(s) they should be learning, what languages are used for what and how much they should learn. One thing I remember from my days of asking these same questions (many many moons ago) is that there aren't very many if any sources that "humanize" programming from a primer aspect, meaning most learning resources dive right in and kind of expect you to just accept and know some things with very little to no explanation or definition. As such I think a primer like this is long overdue, I'm sure there are others but my hope is to write one here and make it a little more available to a community who seems to be in need of this kind of material. For once this is one of my journal entries that is based more in fact than opinion, if you are really new to programming I would suggest reading over the following sections multiple times and ensure that you REALLY understand it before moving on with your learning. I feel it will really help you in the long run.

Programming Basics:
The major portion of this entire document relates to the art of programming itself and won't be particular to any one specific language. You should learn as we go that the language becomes more of a specialized tool to achieve the goal of creating software (that is programming) then being as much of a critical choice. You will start to notice that many times the choice of language really doesn't matter. It is true that some languages perform faster than others at a core level, some languages are easier to use and provide framework built in to them that others do not, some languages you turn into software on your computer and distribute (compiled languages) and others you send out the code and your user's computer will interpret or build it into software (scripting langues). As such we will come back to the discussion on how to choose the best language for your needs at the end of this article, for now try not to focus on a language but learn from the knowledge being provided as programming theory and techniques.

So what is programming? Most everyone knows that programming is making software, games, apps, web sites and so on (which technically can all be generalized as software). This is true, but a programmer is actually much more than just the guy that types out commands for a computer to do things, he (or she) becomes a master problem solver. This is the big part that you need to get used to before you can start efficiently programming anything. Know that not a single one of us (Including some friends of mine that code for nasa's rovers) DO NOT KNOW IT ALL! Not knowing everything is fine, it's common. Knowing the fundamentals of what programming is, knowing that your job is to apply that knowledge to solve a problem and having the ability to research, learn and figure out how to do it in the best performing way for the project at hand is what makes you successful. The point of this section is basically to get you to understand that you will always hit something that you don't know how to do (off the top of your head) and that is normal, what makes you a programmer is the ability to take the challenge in front of you, break it down to the fundamental components and figure out a way to arrange those fundamental components in such a way that it efficiently solves the challenge. Never get discouraged when you don't know how to do something, it's just part of our field. Never get upset when something you do doesn't work, learn why it didn't work and find a better way to do it. THAT is programming.

Fundamental Components:
So now we're starting to get into things. At this point I have mentioned that programming is the art of understanding fundamental components of programming and arranging them in such a way that they efficiently solve the challenge at hand. What is important to know is that these fundamental components exist in all programming languages and that all programming revolves around invoking these things in one way or another. As a programmer in any language you will simply be using that language to use these fundamentals to get the results you are looking for. You will start to notice that when you start learning a language it will dive right into tutorials that teach you how to use these things but most of them just assume you already understand what they are and why you want them. This is the knowledge I feel is not readily available to new programmers, and although the rest of your programming life will be figuring things out mainly on your own I still think that this is one area that we experienced programmers need to explain better. So as we move on here it is important to realize that all of these things I am about to define and explain exist in every language and are used in every program, game, app or website you will ever create. There fore the better you understand what these are and what they are for the easier it will be for you to actually make software.

Variables are something that I consider to be the most important part of programming. A variable is little more than a region of memory (ram memory in most cases). It's just somewhere that you can store data while your program is running. We use variables every day and in every project that we work on. A variable is "declared" in code, this means that we use a command (slightly based on what language you choose) to tell the compiler "this word" is "this data type". After declaring the variable you can assign values to it, meaning that you can basically say "this word" = "Here's my cool value". Variables take up various sizes of memory based on what "data type" they are, we will get to this next but for now you want to really understand that a variable is a term used to define a word in your code that is used to refer to a piece of memory that stores a value. Just like in algebra how letters are used as variables in an equation, in fact almost every time you need to calculate anything in your code you will use a programming variable in an algebraic equation almost exactly like you did back in school!

Example: (This is C++ just to illustrate real usage)int x;x = 10 + 2;

In the example above we see how to declare a variable (int x;) which is telling our C++ compiler (the program that turns our code into software) that we want "x" to mean an integer value (we will discuss that a bit more in just a bit) then we are telling it to assign the value of 10 + 2 to that variable. Now we have 12 stored in memory and we can call on that later! Simple concept but is one of if not the most important thing you will do every day.

Data Types:
Data types is a term used to define what type of variable memory we are using. Some languages will mask this from you and give you a more global "var" type that means (any kind of memory) while others are what we call "strongly typed languages" that require you be specific about what type of variable memory you want to use. In either case it is VERY important to understand what data types are, even when using a "soft typed language" that doesn't require you to specifically declare what type of variable memory you want. Understanding data types, what they mean and how they work under the hood makes your life easier in the long run and leads to less unknown behavior. There are 3 logical classifications of variable data types that is to say in your brain there are 3 different types of variables you will use. Numbers, letters and boolean's (true / false). From here there are actually numerous different sub classifications and even some extended types that won't really make sense until later on, but for now I recommend getting familiar with the basic 3 and their sub classifications. Lets look into these a bit more...

You will use numbers all the time when you are programming. There are many different types of number variable data types that you can use and which one will depend on what you need at the time. Sometimes you may want to consider ram space requirements for these different types but honestly this rarely matters. Modern computers have tons of ram, unless you are working on something that is very performance oriented and requires tons and tons of variable data space you really won't need to pay to much attention to this. However it is always better to use the least amount of ram that can hold the values you need. Information on data types and memory size usages is abundant and I won't reiterate this same information here, you should look this information up and learn it on your own after this (consider it your first learning on your own assignment, you'll be doing that a lot anyway).

An "int" is an integer value. It holds a whole number, can be "signed" or "unsigned" (meaning can support negative "signed" or positive only "unsigned"). Use this when you need to work with small to medium whole numbers.

A "long" is a "long integer". Depending on the computer it may support up to twice the size of the number as an integer (some computers make integers and long's the same size). Just like an integer this can be "signed" or "unsigned". It is a whole number, you use this when you need to ensure you have space for very very large numbers. In most cases integer values will suffice.

A "float" is a "floating point integer" which means it's a decimal point value. Just like integers and long's this can be a "signed" or "unsigned" value. Use these when you need to store a numeric value with a decimal point. Note that most languages require that you place the letter f at the end of a float's VALUE.

float x = 1.5f;

A "double" is a "double precision floating point integer". Much like you probably can guess this is a decimal pointed value that can store twice as large of a number as a floating point integer. You use this value when you need to ensure that you have space for an extremely large decimal pointed value. Double's do NOT require the trailing letter like a float does.

Character's are letters, many languages have moved beyond this particular variable data type in favor of more useful "string" styles of data types which are a bit more complicated to understand but knowing the character data type is still fairly important latent knowledge in my opinion. A character is one (or two bytes) of ram that can store a letter. I say two bytes because some non american English languages use what we call a "wide character" Wide characters require more data to define the character than a normal american English character does. Wide characters can also be used for american English characters as well under different encodings. The more you program and the more you learn the more this stuff will make sense. For a primer the important part to know is that a "character" is normally one byte in memory that stores a letter. A string is multiple characters that can comprise a word, a sentence or even an entire article. Little more homework from here, research characters, encoding and strings.

Boolean (or more commonly bool) is a very small (1 bit) memory allocation that is used to store the very simple true or false value. If you remember your binary mathematics course (assuming your schools made you learn it like our's did) binary is little more than 0 (false) or 1 (true). This is really at the heart of everything that any computing device does, little more than high speed timed transmissions of 0's and 1's that flip transistor values and when rigged together and activated within the proper sequence can cause various outcomes. (Ok, too much there, but point is yes and no, true and false, 0 and 1 are VERY important). However at the level of programming that you are most likely to do, assuming that your not building device drivers in assembly your use of bool data types will simple be a means of storing a yes or no that you can later check and act upon. Examples being something like isAlive, or hasWeapon or what have you.

Stop and make sure you understand!
At this point we have covered the basic variables and data types, as we continue basic understanding of variables and data types is expected. Be sure that you truly understand everything above before you read on, if you have questions or find that I did not adequately explain something then by all means start flexing your programming muscle and hit the web in search of more information on whatever you may not be absolutely clear on. This will become a golden ability the more you get into programming, not just understanding what I just explained but the ability to go that extra step and make sure you understand it by finding more documentation and resources that further your understanding of both what I have introduced and what I have left out. Keep in mind I DID leave a lot out, what I left out is no less important but it is normally more complicated. I am leaving it up to you to expand your knowledge and find what I left out on your own because this is training for your later programming. You now have a basic knowledge and some key phrases that will set in you down the right path, simple searches using these terms will unlock a wealth of information and your willingness to read until you can't read any more is what will make you a better programmer down the road. (To other experienced coders, feel free to point out what I have left out but also understand I'm doing it on purpose to teach some beginners that ever so important art of studying & learning on their own).

Functions & Methods:
Functions and Methods are two terms that are interchangeably used to refer to a written portion of code that performs a task and optionally returns a value. In my opinion it is NOT correct to interchange these words as they where initially described to me to mean two similar but different things that we will address as we go on here. It is important to note that I am in the minority that believes there is a strict difference in these terms, as such you can and should assume that whenever you see either of these words they COULD mean either of the two definitions. This is a debatable theory of sorts where there is no official answer that dictates who is right and who is wrong, you can agree with the way I think of it or not and it will not directly effect your knowledge or abilities.

A function as mentioned is a bit of written code that performs an operation and optionally returns a value. When I say function I specifically am speaking of what we call procedural coding. That means that a function is just a function, it can be used by itself and it is not part of a class or data object (that we will cover soon). The way you write a function can vary from language to language but the core fundamental that you are doing is always the same. You are assigning a word that you can use in your code that can perform an operation and optionally return a value (yes I'm a broken record). Functions can take what we call "arguments", an argument is a variable that you give to the function, this is something the function can use in it's operation that helps to determine the value that it might be returning. In strongly typed languages the return data type and argument data types are very important, in some other softly typed languages they may the return types and data types may not matter as much or may not even be required at all but it does always help when you know in your mind what type of data you are feeding in and what type of data you are expecting to come out. This might be best shown with another small example, again I will be using C++ here, remember that how you write this in a different language might look slightly different but the technique is the same and what it does is the same.
int startNumber = 5;int otherNumber = 3;int addNumbers(int firstNumber, int secondNumber){ int resultNumber = firstNumber + secondNumber; return resultNumber;}int myNumber = addNumbers(startNumber, otherNumber);

What we see here is that we start off declaring (and defining) two integer variables that we will be using. startNumber and otherNumber, we set the values 5 and 3 to these variables. Then we define a function, we say it will return an integer, and that it takes two integers as arguments, (firstNumber and secondNumber). It is important to note here that "firstNumber" and "secondNumber" ONLY exist within that function and no where else. That means that outside of the function's { } braces firstNumber and secondNumber may cause an error (in a strongly typed language) or will always be 0 (in a softly typed language). Likewise startNumber and otherNumber normally DO NOT exist within the function itself (this is scoping which is a bit more advanced theory you will learn on your own later). Inside the function we declare a new variable (that only exists within the function) and assign it the value of "firstNumber" + "secondNumber". This makes "resultNumber" 8 (duh). We then "return" this resultNumber.

After this we actually use the function to make something happen. We create another new integer variable called myNumber and we assign it the value returned from the addNumbers function, we give the addNumbers function the arguments of startNumber and otherNumber (which inside our function turn into firstNumber and secondNumber respectively). What happens here is that at the end of this example myNumber is 8. Although this example is very pointless it simply demonstrates how you could create a function to do some work and return a value. Now in your code instead of writing that work out every time you can just use that function to get the result you want. You use functions often to keep yourself from typing out the same "work" over and over again. It is always good practice to put "work" into functions whenever possible, in the long run it will limit the time you spending typing code and make it easier to make changes to everything that uses that function all from one spot instead of searching over your entire code and changing it everywhere you wrote that same "work".

Again, please note that many other programmers will say that a method is exactly the same thing as the "function" we just defined and technically they are right (as there is no answer to which term specifically means what). Unfortunately I kind of have to jump ahead of the next section and mention this now, I'm sure it's a bit confusing but it has to be said here to limit the confusion if you are reading somewhere else and you see people talking about "methods" meaning the same thing as I just defined for functions. Just always remember that depending on who says either of these words will make the difference on what that word means to them. When I say "Method" I am referring to a function that is a part of a class or object as we will cover next. Many other people say "method" and what they mean is exactly what I just defined as a function. Vice verse some people may use the term "class function" or "class method" to mean exactly what I mean when I use the word "method". To a beginner this is a bit confusing, the easiest way to deal with this is just to remember that both words can be used interchangeably no matter how you look at it they both refer to a portion of code that performs and operation and optionally returns a value. Sometimes they might be "procedural" like we just say in the function example. Sometimes they might be part of a "class object", but either way what they do is exactly the same, they do work, might let you provide arguments and might return a value. If and when you start working with another coder it is good practice to discuss this and agree upon what you will mean when you use these words to help prevent confusion as you go on.

Classes and Objects:
Classes and Objects are also a bit confusing as they are two terms that are supposed to mean slightly different things. Some will argue the terms are interchangeable while others (like myself) insist that they mean specific things. I believe I am in the majority in my beliefs in this one being that they mean different things, however always be aware that something your reading might use one or the other of these terms to mean the same thing (just like some say method when I would say function, some may say object when I would say class). Again conforming or not conforming to the more popular belief of what each of these words won't directly effect your skills or abilities as a programmer.

With that said, a class is a very special data type of sorts. It is a region of memory that can hold a collection of variables AND functions within it. The variables and functions within a class are normally if not always related in some way, for example a "WeaponClass" might have variables that tell the weapons size, it's strength, durability and might have functions that you would use to get these values such as maybe an "attack" function that would return the amount of damage the weapon deals based on it's current durability and then reduce the durability slightly to simulate the weapon degrading over time. Hopefully why a class would be useful just lit up in in your mind (OH That's why I want to use them!). A class is a means of declaring a "thing" that has multiple parts, being variables an functions that can do work on the variables of that class (and or on arguments or other variables that the class can see, again this gets into scoping that you will be on your own to go learn about).

So now I will put my foot down so to speak and explain why I consider functions, methods, variables, members and objects all different words that mean different things. Keep in mind this is MY way of thinking, some will agree some won't and at the end of the day it's a fruitless argument, they are just words. When I say that a function is not a method that's because to me the word function means a procedural portion of work. Something that exists by itself and is not inside a class, to me this makes it easier to immediately know what my team is talking about when we say "This function is doing this". A method is a function that exists within a class, although it does the same thing, that is it optionally take arguments, it does some work and optionally returns a value the difference to me is that a "method" resides within a class no matter what. This can and will be argued by others, make your own decision on what you think each should be called just know that there are two slightly different things at play here, one that exists by itself and one that exists within a class.

What I just started mentioning in this section is "members". This was something that seems to be pretty much agreed upon as a term that means a variable that exists only within a class. That is exactly how I mean this term and most of the time when you see someone say "member" in programming this is what they mean too. In some rare occasions you will see some people say "member" when they just mean a variable that exists by itself but these are rare instances. Be aware that member MIGHT be used to refer to a variable, also know that there are times when people will refer to a member by calling it a "class variable" or a "class property". Again it's pretty much all potato pototo and they are just words that are referring to sections of memory that you can assign and get values from.

Now, classes themselves are a bit tricky to learn at first as they are more strict about deceleration, definition and use. Some languages (mainly C++) require there be a very distinct separation between the declaration (where you say this is my class, these are it's members and methods) and the definition (where you actually write the methods). Most other higher level languages don't enforce (or even support in some cases) this distinction. In these other languages you write your class once all together, this means that you write it just like you are declaring it but when you hit a method you go ahead and define your method (write the work) right there inside the declaration. This is something you will need to learn to do based on the language that you are coding on, it's mainly important to understand that a class is just a collection of members and methods that are somehow logically related to you as the programmer. They are used to make your life easier.

To use a class you have to create an instance of that class. This means that you instantiate a name to be an area of memory that contains the members and methods of a class, much like you would create a variable. So this means that your class that you write is more like a blueprint, it is nothing but a definition until you create an instance of it (or as most of us would say an object). There are some more advanced topics about classes that include singleton and static classes that don't require this instantiation but that is another one of those things you will need to go learn on your own. (Yes I'm making you work for it a bit, you will need to work for your answers ever day as a programmer and you might as well get started now).

Now we come to where I make a bid difference about what "class" means and what "object" means. To me (and I do think this is the more popular understanding) when I say "class" I mean the declaration and the definition of a class. The code that makes the blueprint so to speak. When I say object I am referring to an instance of that class (the actual usable name that represents the memory that contains members and methods as defined by the class). Some people will still use the word object to mean what I explain as being a class, some people don't use the term object at all, me aware that either word CAN mean what I have referred to as "class" depending on who is saying it. In some cases where people don't make this distinction in their own terminology they will normally say "class instance" or "object instance" to refer to what I call an object. When using the words "class instance" or "object instance" it's pretty cut and dry and not open for much debate, this will always mean what I mean when I say object. Adding the word instance makes the term no longer interchangeable with the word "class" as it is referring specifically to a word you use in code that means the area of memory that holds an instance of the members and methods that you have defined in your class.

Wait I'm confused as hell!
Good, and as well you should be. Programming is not easy, it's not simple, and it can not be completely explained or understood from a single article that spans a few pages. What I have set out to do in this entry is to arm you with some theory and terms that will lead you down the path of glory. I have purposely left some of the more complex things out, I have purposely wrote this article in a way that should have you asking questions and at this point I want to set you free. Not to throw you out to the wolves but to get you started with the researching and studying that will become an invaluable skill to you as you continue through your programming career. I don't mean that you should walk away from this article baffled, perplexed and feeling like it was a worthless read. I want you to walk away from this article understanding everything I have presented in it, and to do that I want you to head out and do some research to answer the questions I have given rise to in your head. I don't mean to leave you stranded and you can of course contact me if you'd like, my response will be that I will go to a search engine to find resources that further explain what you are having problems with and I will tell you what search phrase I used and give you links to the resources to go read. This is not me avoiding answering you but again I can't stress this enough YOU NEED TO FIGURE IT OUT. This is what will make you or break you as a programmer. Yes there is always someone out there with the answer, and yes you can take their answer, apply it and make it work but not understanding why their answer works will just lead to more problems down the road. This little idea of researching, reading and learning WHY things work the way they do will empower you to no end and it's something that you will see all experienced coders trying to force you in to. As a beginner myself it always aggravated me that I asked a simple question that needed a little 10 words or less answer and people always referred me to huge articles that didn't seem to answer the questions (but when I read it I came to the answer myself). This is why we all send you to read way more than you wanted to know, it teaches you to answer it yourself and arms you with behind the scenes information that will answer more questions later on down the road.

Where to go from here?
At this point I assume you have headed the warning that I issued many times in this article and you have gone out and researched, answered your questions and that you completely understand everything I have presented to you in this article. This will have undoubtedly lead you to even more knowledge than what I have presented here (such as static and singleton classes, data structures, pointers, arrays and so on). Some of you will have read over this and will understand everything I have said without having to do external research, that is good but is not particularly better than someone who got all confused and had to go look up more information on what I said. Actually they might even be in a better position than you are right now because they actually got equipped with all that which I left out when they went looking for more information. In either case, don't worry, this is a primer it's meant to give you a knowledge of what programming is all about behind the scenes and to give you theoretical advice of sorts on what to go learn about and what it's used for in the long run.

So from here, go be free, be a programmer! I know it sounds generic but that's the best I can offer to you as a beginner at square one. Learn that which I have presented and learn it well, recite it in your sleep! Don't worry so much about how you will implement these fundamentals in any one particular language but understand what they are. Once you understand all of this you are equipped to understand what tutorials are saying and you are now able to go learn whatever language you want! How to pick which language you want is a completely different discussion that warrants it's own entire article that I will try to provide in the near future. Till then, I'm sorry to leave you hanging but the short idea of what this article will talk about is "what does the language do?" "how common is the language?" "how many resources are out there that I can understand to learn from?" and "how efficiently can I write code in this language?".

I hope at this point that I have rambled on enough and instilled the importance of learning to learn being THE MOST important fundamental of programming. I'm hoping that I have exposed and made a little sense of the core tools, theories and features that are used to make things happen and given you an idea of how you might think of these things working together to make something happen. Even though you still may not actually know HOW to do it you should be able to think of things like....

"I can use some variables to hold statistics for a character. I can arrange these variables as class members and create a class that represents a character in a game. I can then write methods inside this class that will calculate leveling up and other complex equations that would pertain to a character in a game."

So forth and so on. That is what programming is all about ladies and gentlemen. Taking an idea and breaking it down to fundamental component's or theories then researching a language that gives you the means of making that happen and studying the techniques of that language that allow you to do what you want. When you don't fully understand something don't get discouraged, get educated! Remember it's all pretty simple when it all comes down to it, what you are learning is just the subtle nuance's of how to make these things happen in an order that works for what you are trying to do using the language as your tools. And finally, with all of that I hope I have clarified what programming is and what you want to do to learn how to do it. I hope I have given you terms that you can research and study to learn more and given you the general idea of how you make solutions to problems using the fundamentals that these terms refer to. As always, comments and questions are welcome, see my profile for contact information if you would like to contact me directly for anything else, I look forward to hearing the community response!




What are you worth to a development team?

I'm baaack!
Fellow game designers and developers, I have returned (as if anyone really cares lol). I have been quite busy with my work over the past year and have just recently been able to spare up some time to get active here on Game Dev again. Wanted to take a moment to address a topic that I feel is well over due and that is what are you worth to a development team. Before unleashing the rant machine which is my writing I'd like to acknowledge the fact that the views and statements I will make throughout this article are my personal opinion which may or may not reflect all studios the same. Also, I'm a programmer, fiction and non fiction writer and overall designer thus making this opinion what may be biased on the side of others like me. With that said, please read on and understand this is how I and people like me might see the world. The idea is that by the end of this you might have some ideas on how to appease the more technical members of your team and as such find it easier to get to common ground and work better with each other which in turn will lead to better collaboration for you and a potential team.

Who the heck am I?
I'm a long time programmer, concept designer and content writer (over 15 years of experience and growing). I have done a little bit of everything in my day, coding, artwork, modeling, animation, quest writing, game mechanic design, dialog writing and even took a stab at composing. I have no false dellusions of being some all mighty game development god and I know that I simply do not have the adequate talent to be a quality graphical artist or musical composer. It is however important to note that as some of my words may seem to belittle what you do or contribute to a team it's not a personal attack, more so it's just what I have noticed as I have worked with teams, studios and clients throughout the course of my career. So with that, hide the women and children, brace yourself lets get to it!

What is worth?
"Worth" in the broadest scope means value, so what we are discussing here is what is your "value" to the team. However it's not quite that simple, worth in the gaming industry is further broken down into sub sets that vary quite a bit (almost polar opposites as we will come to find out). There is what we will refer to as intellectual worth (or your level of contribution / importance to the game being what it is) and the other we will refer to as financial worth being how much money the team may consider you to worth. Lets go ahead and dive into these a bit more in depth just to understand what I am talking about with these two sub sets of "worth".

Intellectual Worth:
As I touched on above what I consider to be "intellectual worth" is your level of contribution to the project, quality of work and effect on the game as a whole. This is something we will expand on as we go here, it's just important to realize that what I am trying to say by this is how important are you to the game getting completed. A higher intellectual worth to me means that the game is much less likely to be completed without you! Basically the more intellectual worth you have the more critical you (or your role) is to the team, they probably don't want to lose you (until we contradict this statement later on).

Financial Worth:
This is not to be confused with the idea of how much money do you have, that is not the financial worth that I am speaking of here (and actually we will briefly discuss monetary contributions as intellectual worth later on). You'r financial worth is how much the team thinks you should be paid for your services, be it a percentage of profit sharing, a one time project contract or an hourly rate through the course of the project itself. Unfortunately I won't be giving any concrete numbers, but I will try to give percentage based ideas of how teams may think and or approach this topic.

Studios and Teams:
These are two more terms you will find me using quite a bit as we go and I think it might be wise to define what I mean by these terms. In short, when I say "studio" in this article I am referring to an established group of developers with financial backing (funding). This would be a group of developers that may work on projects and sell them (I mean actually complete, publish and sell their games) and may or may not hire outside help as they go.

When I say "Teams" in this article I am speaking of groups of developers (normally smaller groups) that either have not yet completed and published a game title or if they have completed it they have not actually sold it or monetized it in anyway. As such we are going to assume that a "team" is a group of developers that do not have money now, they will not pay you right now. They may however have plans to get funding, donations, promissory purchase funds (kick starter) or the intention to sell the game and split the profits.

An important thing I must stress here is that I am talking about people who are trying to not only build and complete a game but people that are looking to monetize said game by some means in the near future. This monetizing means that they will sell the game to players, sell it to another studio, charge micro transactions, subscriptions, DLC whatever, by some means they are trying to make money. This article does not reflect the importance or worth of individuals in hobbyist projects, eg projects that are "just for fun" or "portfolio value" or by whatever means not intended to make money. Groups and developers that create not for profit games gauge worth an value totally different and there's really no way to make an assumption as to a basic guideline for them, each group will be different in this aspect. If you are part of a group working on a not for profit game I'm sorry to have wasted your time but this article is not for you.

Give me some information already!
I'm sure many people have thought this by now (maybe even literally said it to the monitor), and yes now that I have clarified what I am trying to talk about and what the various terms that I will use mean we can actually start talking about something! As this topic is a bit broad and very dependent on grouping and project's we are a bit forced to divide the conversation into multiple parts here. First off I'd like to start with teams (remember, no money right now probably no previous works). So here's the way that I see it and what I have experienced quite a few times throughout my career...

Teams - Intellectual Worth:
Teams normally tend to measure your intellectual worth based on content contribution and quality alone. This simply means that the more you provide and the better quality you provide the more your worth. It's normally pretty cut and dry and everyone is pretty much on the same page for this one.

Programmers, it doesn't matter how technically advanced or difficult what you are doing is your team doesn't realize that. They care about the performance of your code and how fast you got it done.

Artists, it doesn't matter if your doing pixel art, vector art or modelling it's the end result your team will judge you on. Your team doesn't realize how difficult it is to actually draw or model quality pieces they simply judge you based on how good it looks when your done and how fast you got it to them.

Idea guys, in a small team your intellectual worth is held in pretty high regard. That is to say that the rest of the team realizes that you are the focal point of the project, without you they wouldn't be making a game they would just be making things. Your intellectual worth is normally judged on how well planned is your design document and how fast can you produce it.

Content Writers, you are the people who write the story, history, dialog, descriptions and anything else textual or spoken within the game. Your pretty darn important to a team as you add the content that drives their graphics, mechanics and code. They make the flash to bring the player in to the game YOU write the content to keep them in the game and maybe even push them to buy it. You are important and your team will most likely judge your worth based on are you using the correct spelling and grammar for the language you are writing, is what you write compelling and interesting and again how fast can you get it to them?

Composers, unfortunately your worth is judged a little more harshly than the others on the team. In many small teams music and audio effects are little more than background noise or so they will think. Some teams will understand that you are just as important as content writers or artists in that your music is an added effect that immerses the player deeper in to the game play and helps to hook them to the game (possibly driving sales). Your worth may get judged a little more harshly here but it will still be based on how compelling are your scores, would someone actually listen to it outside of the game and yet again, how fast you get it to them.

Marketing / Advertising, this portion of game development unfortunately is completely off the radar of most small teams. As far as they are concerned you most likely aren't worth anything to them (until they realize they're not actually getting sales). If and when a team realizes that they need to advertise and market their game you become worthy and your worth is rated in a very black and white judgement. How many copies have you helped us to sell? The team is not likely to understand impressions, traffic flow, turn over rates, so forth and so on. You should really make a big attempt to educate your team to your importance and do this using facts. Spill the beans a little bit and tell them what the tricks are, although they may start to have an idea that targeted marketing is a means of getting impressions from potential buyers and even that doing this means to find communities and sites that would potentially buy their game to post advertisements to it doesn't mean they can do it as good as you can. Don't be so secretive and your likely to be deemed a little more worthy / valuable from an intellectual stand point.

Anyone I'm forgetting, although I may not have mentioned you directly by some means you should fit into one or more of the categories above. Please try to relate yourself as closely as you can to what I have listed and chances are your worth will be judged accordingly. Example, voice actors you are basically composers in the eyes of a team in that you are creating audio that they will use. You may or may not also be considered something of a content writer depending on your ad libbing the more you take a simple sentence and turn it into something more interesting the more you fall into both categories. Animators, the team considers you an artist perhaps something of an idea guy if you also extend upon the requested animations and or present your own concepts of movement. Like voice actors the more you do outside of what you are asked to the more you fit into multiple categories.

Recap, everyone in a team intellectually starts pretty equal and your intellectual worth is almost entirely judged on doing your job. You want your team to consider you as a major part of the game? You want to be listed as a chief or a lead member? You want the game to be "You and so and so's game". Do more and do it right. Sometimes you will make sacrifices in the interest of completing contributions and that is to be expected but if the only way you can get something done is to do it with poor quality you may very well be in the wrong field. On the same note you may make the highest quality assets ever made by someone in your position but if it takes you forever to get it done, you might be in the wrong field. Teams don't have massive amounts of money to support long term projects, know this, own this, love this, and most importantly understand that your team needs you to git' r done so to speak. Coders, are you only getting 80fps but your expecting over 100? Get over it, 80 is acceptable move on and get the game moving (never ever hide your recent updates from the team because your a perfectionist... Leave the team your not helping). Artists, does your character look good but not perfect? Ask the team if they like it (never ever hide your work till your complete because your a perfectionist... Leave the team your not helping). Idea guys are you hitting a brick wall and you cant decide between A and B? Flip a coin and move on, the entire team is waiting on you to know what to do next. (Never ever get stuck not being able to make a concrete decision.... Leave the team your not helping). Composers, does your audio track sound good but one of the instrumentals is one key out of tune? Ask the team, never ever hold back your tracks because you don't think their perfect you guessed it leave the team your not helping. So forth and so on...

Studios - Intellectual Worth:
This one is probably going to get discouraging for lots of people because experienced development studios tend to judge intellectual worth more so on availability, quality, quantity and speed. It will sound a bit like I'm saying that a studio expects you to be a master of your art and honestly, yes they do. Experienced studios have released projects before, they have gone through the entire process and they understand who contributing what created how much of a difference to the end result. They are comparing your worth to experiences of past projects and what they feel helped or hurt said projects.

Programmers, you are held to a much higher regard by many studios (this isn't just me saying it because this is my core profession this is true in many cases). As we will see this same trend coming out through this section to put it simply an experienced team understand how important it is to have good high quality code, written fast and completed. While teams may think coders are a dime a dozen, studios tend to understand that a true programmer is hard to find. Someone that actually gets it done quickly and efficiently is worth quite a bit to a studio and you are very important to the project getting completed in their eyes.

Artists, just like programmers studios hold help you up onto your pedestal. You are VERY important, just as much as the programmer maybe but not necessarily more so. Reason being? Tons of "artists" can draw a great picture, very few can do it again and do it on command. Studios tend to understand the importance of having an artist that not only can create quality work but can do it when they are told and don't take forever to complete it. To a team you might be considered one of these dime a dozen members because there are so many self proclaimed artists out there, to a studio they have seen that a "drawer" and an "artist" are different things. A true artist is hard to find and is worth a lot to the game getting complete.

Idea guys, this one is going to sting really bad and probably cause some angry responses later on but the studio doesn't consider you worth very much if at all. I'm sorry to say it but EVERYONE in the world is an idea guy, I have an idea for a game, you have an idea, the janitor has an idea, your girlfriend has an idea. While teams will consider you much more valuable because you truly are the keystone of the project studios realize that any and everyone is ready to take up this role. As such you are actually in 0 demand which to the experienced studio means your not important to the game (because it's very easy to replace you). Again I apologize that this sounds harsh but it's a reality you would do well to accept and use this discouragement as a stepping stone to learn another talent and increase your worth to the team. If you have ideas and a high school level education you should find it pretty easy to also be a content writer, maybe you can sketch out some concept designs for levels and characters and what not. All be it without the latent artistic talents (that few of us have) you probably won't make anything the team can use graphically but being that you can at least present something graphical to further the teams understandings of your ideas and concepts (no matter how poor) you are worth a little more than the average idea guy. Further reading on why I and so many others come to this conclusion please see Game Idea Value.

Content Writers, get ready I'm going to anger you too. Unfortunately this is another field that experienced studios hold in a low regard as to intellectual worth. Simply put they know that good old fashioned fun game play can trump a story line if need be. The idea guy can provide enough of a story outline to muscle through and they can get artists / coders to do a little more to pull the gamer's attention away from the story line of the game. Also, there are many good writers out there, there are a lot that will do it just for recognition of to get their stories heard. Unfortunately in the eyes of an experienced studio this makes you expendable as you can be replaced or even cut from the project and there are alternatives that the team can look in to. Just like the idea guy you can learn some basic design practices, maybe provide some sketches or possibly even learn to do market and advertising research.

Composers, finally you start to get some more recognition here. Experienced studios tend to realize that the audio of the game is actually much more than simply background noise. They have most likely come to realize that audio assets can be used in conjunction with mechanics and graphics to immerse the player deeper into the game and provide an overall better experience to their player. Unlike a less experienced team the studio will more likely understand your contribution is a silent killer of sorts (ha funny I call it silent when it's music huh?). The clank of a sword, the swoosh of the bat, en subliminal feeling you get from hearing creepy music when zombies are around. These things greatly increase game play and the studio is likely to know this.

Marketing and Advertising, your intellectual worth still isn't very high to a studio as you don't actually make a big difference to the game getting created BUT you will at least have some value if you provide incite and suggestions through the entire project. If you are performing research and finding what players want, relaying that to the team and helping the design target potential customers better you do have some intellectual worth to the studio.

Anyone I'm forgetting, just like with teams, apply your skill sets to the above categories as best you can. We can always debate what "category" of contribution your specific role in the team is but most if not all times they still all break down from one of these broad overall categories. No matter what you do somehow you should fit within one or more of the above listings.

Recap, we see a bit of a shift in intellectual worth here. Studios as mentioned have experience creating games and they see people's contributions in a totally different light. As incorrect or blind as it may sound many studios tend to think this way. Being that they may have failed quite a few times before they actually succeeded they tend to be more interested in getting this project done and bad experiences / wasted time, funds or assets from previous projects effect how they will look at you. Never ever argue with the team management about how important you are to them, find out what they want you to do for them to consider you more important. Studios are paying you to get it done, don't tell them how they should do it, do what they ask of you and more whenever possible. This is what makes them consider you more valuable.

Teams - Financial Worth:
I have covered quite a bit in the previous intellectual worth so here in this section I'm just going to simplify things a bit and focus mainly on how teams may consider / judge how much money they are willing to pay you based on what you do. I would like to stress once again that these are my personal experiences while working with various teams on numerous projects, this is not what I think things should be like, I'm not trying to justify or argue it, this is just the trends I have seen throughout my career. It is my opinion that this is what you will encounter when you first start working with small teams however it can and will vary from team to team.

Programmers, here it comes guys this is the one that is a stinger to us. We're not worth much at all to teams. We all know that there are dozens of self proclaimed "programmers" out there no more than a few minutes away (to get in touch with). We're all vocal quite a bit and teams have seen so many of us around forums and job sourcing sites that simply put we're a dime a dozen. They don't want to pay you at all, they think anyone can do what you do, when they do offer profit sharing or hourly pay it tends to be insulting at best. I suggest however that if you are not getting offers from studios you suck it up and do it anyway. Studios will become more likely to consider you later on when you have worked with a few teams plus hey you'll get real experience and become a better programmer for it. If you don't always want to be a better programmer or don't see the value in getting ripped off on your first few projects you'r in the wrong field, go make websites or something. (Look I'm nearly insulting my own kind!)

Artists, this one stings a bit as well your just like a coder. Any of us can go to deviant art and see hundreds if not thousands of good to high quality works and quite simply the team figures there are so many good starving artists out there they must be cheap. When you request something that seems reasonable to you they are likely to show you the door. Why would they pay you so much money when the guy on deviant art does the same quality for $5? Granted you and I know it's never that simple. You may actually get the work done to a good quality and in a quick manner but still, teams aren't experienced they don't realize that makes a difference. It's just art and kinder gardeners can draw with crayons just because your a bit better doesn't mean they think your worth more money. Just like above with the programmers though, I would suggest that you also suck it up and get ripped off a few times. Studios are more likely to hire you for what your worth if and only if they see that you have done as you where asked in a timely manner and lead to a released project. Also, some money is better than no money isn't it? Is art not your passion? If you don't like to create art and get better / faster at it all the time perhaps you are in the wrong field and should just stick to your doodle pad. (Sorry, I insulted the programmers to. It's harsh but meant in good faith).

Idea guys, you are probably the leader of the team. Your the guy that sketched out a design document, recruited help and are driving the project. I say this because no project starts without an idea. If the Programmer starts up the idea and goes looking for help your not likely who he will be looking for, likewise an artist with an idea is the idea guy himself and most likely doesn't need you or at least doesn't want to pay you for what he is doing and or started. With that said you normally set your own financial worth in these situations but you should be aware of the impact this will have on your team. Keep in mind everyone else on your team has an idea as well, what you are doing is nothing special to them. They may have joined you because you had the artist already and the coder is looking to make some money, or the artist might join you because you have a programmer already working on something and the artist wants to make some money. Content writers might just join you because they like the idea, they may or may not want money that's between you. For Programmers, Artists, Composers, Marketers and Advertisers however they have spend money and time in their life to learn what they are providing you. They deserve fair compensation and will quickly lose interest if you value yourself much higher than a small fraction. Again they can come up with an idea too, why are they doing all the high end work while you collect massive amounts and they get next to nothing? (Yeah I'm trending again, insulting everyone a little bit to be fair to all).

Content Writers, your financial worth is entirely judged by the scope and depth of the project. Basically your going to be worth what the project sets you up to be worth. That is to say that a larger RPG with heavy story line as the main selling factor is going to be a project that will pay you a little more than something that is like a platformer with a story. Just like with Programmers and Artists I suggest that you go ahead and let your self get ripped off a couple times as well. If nothing else you are perfecting your writing skills while actually publishing some work. Making a little money rather than nothing and building portfolio to move into more literary fields in the future. If you don't like to write stories and such or you think writing is only worth doing when your making good money... Yeah your in the wrong field. Go look around and see what short stories are worth to magazines, news papers and web sites. Go see if you can get your book published, but get out of game development. (I feel like such a bad guy talking so much smack)

Composers, unfortunately your in that boat with Programmers and Artists, maybe even more so. Musical composers are everywhere in this world and there are quite a few that just want to be heard. Going hand in hand with the intellectual worth misunderstanding teams pretty much figure they can get stock sound effects for free off the internet, make them work and that your music is little more than background noise, as such it's not really important. As long as it's not horrible and it's there it's good enough. I still suggest you go ahead and get ripped off a few times though. Portfolio, experience and proof that you can compose on command is worth quite a bit to a studio who may pay you fairly or even well. However since I'm bashing everyone down a notch in this section here's your's too. If you don't like to make music just to hear it and or be heard your in the wrong field. Your music is an artistic representation of your spirit and soul, it's something you want to share with the world. If it is unacceptable that you create works for anything less than a small fortune then by all means go record an album and see if you can sell it, but game development is not for you.

Marketing and Advertising, you guys are really getting the short end of the stick through all of this. Inexperienced teams normally don't realize that just because you make the best game in the world doesn't mean you sell it and you'r worth is severely underrated. They figure "I'll just post on steam it'll sell!" or "I have a website it'll sell". More often than not the team does not realize that they have to actually get quality traffic to the sales page to make a sale. They figure I'll just post on some random forums or blast out some emails and boom I'll get like 100,000 hits over night! Partially true but how many of those 100,000 are actually looking to buy a game in your genre at your quality level for the same platform? Anyway, you guys know what I mean here that was just a bit for the non marketing savy people to understand what I'm talking to you about. With that said I have by some means knock you guys down a peg as well, it's only fair everyone else is taking it and hopefully in stride. Although what your doing actually translates the product into money you'r actually doing the least quantity of work on the team. Yes you are highly specialized and you get results just like the professional coder or the amazing artist or the concert quality composer BUT... They all spent hundreds if not thousands of hours creating their contributions. You will be providing at best a few dozen hours. For amount of time invested to what you should receive you have to take a step back and understand they are not willing to give up what they have worked so hard for in order for you to chime in 6 hours of advertising. My suggestion to you is that you try to work out a per piece commission, if your as good as you say you are this allows you to make money at your pace. If it's a low percent of each sale the team is likely to play along and if you move thousands of units you can make quite a bit of money without forcing the other members to feel like you don't deserve it.

Studios - Financial Worth:
I skipped the who I forgot and recap on that last section because I went much longer than I expected per role. Hopefully this final section will run pretty quick as we have pretty much everything covered already. I'm going to try to get straight to the point here and not offer as much of the "blab" that has increased the previous sections, I assume by now your seeing the trends of thinking and I don't have to explain why the studio will feel the way the might as much.

Programmers, Aha finally we're worth some money! This will be argues by non programmers or programmers who have never worked with or been contracted by a studio but it's fact. When a studio hires or contracts you it's because you have earned that position. They expect nothing but the best from you but they're going to pay you VERY well to do it. Seriously, there is a TON of money to be made when you get good enough to work for a studio.

Artists, Come on guys, your with us programmers! Many of my programming colleagues may argue this fact as you would argue the financial worth of the programmer but the fact is studios know that a talented and highly productive artist is worth gold. Just like with us coders the studio expects the world from you but they will give you the world in return for your services. Just one project done with a studio will make up for at least 2 or 3 projects you got ripped off on working with teams. Seriously, your going to be rich.

Idea guys, I'm sorry your not going to make a penny. Ok that might be a little rough, they might buy you a cheese burger. I'm sorry to be so blatantly rude about this but you have to understand they are spending tons of money on Programmers, Artists and other members, these other members are SO excited to not only be doing what they love but to be getting rich in the process that their brains are overloading with ideas. They are all happy to propose 10 new ideas right now for free because they are making their money doing other things. No matter how golden your idea is they're not likely to steal it nor are they likely to pay for it. At best you may get a "That's a great idea when we catch up the 40 game ideas we have we'll get back to you". If you want to work for a studio you HAVE to learn a talent they need, not try to push something on them that they have an abundance of. (Never sell salt water on the ocean so to speak).

Content Writers, you vary quite a bit and you will be looking for a large studio in order to make some money. Much like the idea guys the existing members are willing to step up and adopt your talent to get the project rolling and keep their studio running so they keep making their massive pay checks. You would be amazed how motivated these other studio employees are being that they are bringing home thousands per week or more. You will need to have quite a bit of portfolio value to get on the radar of huge story oriented development studios that actually need dedicated writers. I'm sorry if it sounds rude but your going to have to suffer through a lot more of the team rip offs to get noticed.

Composers, come jump around in the happy house with us programmers and artists. Finally your talents are highly revered and you will be making very good money to be doing what you love. The studio knows your contributions add to the profit they will make and as such they are willing to pay you very well to do what you do. Just like us however you are expected and demanded to make top notch audio on command. You will be working hard but you will also be retiring early in life.

Marketers and Advertisers, yeah you know your making money too. The studio has sold games before they know that you have to get quality faces looking at the product to sell it and they know a large investment to you will return higher profits for them. Many times you are not hired by the studio itself as much as you are contracted or outside advertising agency are hired. However mid sized to large studios would rather just pay roll you and have you on hand to keep it up all year round. Get good at it, and be able to prove that you will make them money and you'll be rolling in your cut as well. Just like the rest of us you will be busting your hump but the pay off will be worth it. You may however also get stuck in the rut where you will need to get ripped off quite a bit to demonstrate your ability to a level where the studio will want you but in the long run it will be worth it I promise.

In closing,
I have rambled quite a bit on this topic as I see it and as I have lived it over the years and I'm sure many of you want to chime in your opinions. As always with my posts I welcome debate and input from everyone. I'm sure many of you will have different experiences you'd like to share, many of you want to prove me wrong and maybe a few people will agree with me. I would prefer that if you are going to challenge me on these topics that you do it with real world experience under your belt. Of course everyone is entitled to their opinion but I would like the idea of this article to remain as opinion's from people who have lived it more so than opinions of how people think it should be but have not ever been a part of a team or studio.

By all means if you have something to comment please do but do not mislead as to where you are coming from with the opinion or comment. If you have not worked in the field but would like to say something I would love to hear it but please admit as such. Do not lead anyone astray, someone might be reading this as a real discussion between people who have actually worked in this field. I have worked in this field for years and these are my OPINIONS. I don't mean what you have to say is any less important but I feel it is vital for readers to understand where the opinion is coming from. What you have to say may be more important than what I said but the reader needs to know honestly if you have or do work in the field, if you are just saying it like you think it is or if you have done some research somewhere that backs your statement.

So all in all I hope this does spur up a huge conversation where we can all share experiences and opinions about this topic. My hope is that it helps to enlighten those who wish to pursue a career in game development and that the following discussions arm them with some incite and information that helps them better themselves and in turn better the game industry as a whole. Let's please not argue if I'm right or wrong but discuss the topic of "What are you worth to a development team" as the title suggests. Also any studio managers, team leaders or anyone else who is in a position to hire workers. Please chime in, the community wants to know how they can be that guy you are looking for and this is a fairly good conversation for you to tell us what you are looking for when you hire someone.

~ Let the comments begin!




The truth about MMO's

Hello again everyone!
Hello everyone, this time around I didn't wait as long to post my next article. Now this one is going to hurt considering the high amount of MMO projects that are currently looking for members here on the forums but it's just something I have to talk about. In short an MMO is not an obtainable goal for a first time team, and in this article I am hoping to point out some of the reasons I say just that. As with all of my articles the contents here in are my personal opinions formed from my experiences, observations and research, and with that said lets get to it.

My MMO is different, it will be a hit!
That's great, the market needs some fresh new ideas. We are currently stuck in a bit of a rut with the same old thing over and over again in the MMO world. I personally have not seen much of anything different come out since the inception of World Of Warcraft. This statement may not be entirely true, but I have yet to be lead into anything different. It seems as if every other MMO that currently is on the market is nothing more then a clone of WOW. With this in mind I understand the urge that so many people have to create their ideas and publish their MMO but wait, there's a little research that everyone should do before jumping in.

Graphics are one of the largest things to note about an MMO. Quite simply you need thousands if not tens or even hundreds of thousands of graphical assets to build any kind of decent world for your players to interact with. This is because of the audience you are targeting, simply put casual gamer's don't play MMO's. It's worth taking that into consideration at the very onset of your idea. With that statement alone you have to immediately think about how you can cater to and spark the interest of the hardcore gamer. Graphics are one of the top most important things that a hardcore gamer is looking for. Yes game play is very important and all but you need to keep their eyes happy to get them to play long enough to even see what your game is about.

Continuing on this idea I've seen many teams that fall under the impression that you actually need less characters to make a successful MMO then you would to make a regular stand alone game. It's believed that simply skinning the characters, changing the color schemes and slapping some different clothes on them will go a long long way. In some cases this is true, and we have seen that done successfully in many of the traditional MMO's that are out there, however, there's only so far one goblin can go.

This concept by itself is already diminishing your uniqueness to the MMO community. They have seen clothable and skinnable models done over and over again, they are used to it. This is not making your MMO stand out and at this point you have an MMO, you have standard character practices, your targeting the hardcore gaming community and your competition is way better then you are. Your facing WOW, Rift and other games that where developed and backed by huge companies with seemingly endless wallets!

That's ok, I have a better story:
This point I won't argue much about. With the exception of WOW having a story that is 17+ years in the making (yes Warcraft one came out in 1994) we don't see very compelling or unique story ideas within the MMO market. So yes this may be an area where your game can dominate and where your idea holds great potential. The story line and plot progression you design may be gold, maybe even platinum BUT you must also have the goods to support it. The only real arguing point about the story being what is going to make your MMO the best ever is that you have to get the hardcore gamer to actually pay attention to it. (Hope you got some good graphics...)

Well my game play is better:
This will vary based on what your particular game play design is. But in many cases you are competing against possibly dozens of complex battle, professions and statistical systems that are modeled after WOW. We come back to the audience and what they are going to be expecting from you here, only the best! It's not quite as easy as you think it's going to be to provider better game play then these big boys that are already on the market. The best way to see what your up against here is to play as many MMO's as you can find, and play them in their entirety.

Well my PVP idea is totally different!
This is another one of those things that I see many people taking a bit to lightly. PVP is a great selling point and can attract millions of players to your game, but it comes at the cost of thousands of hours worth of statistical and skill balancing. Having even one over powered race or class of character can lead to disaster for you. PVP in most cases is pretty cut and dry to it's players. Either it's a fair competition or it's not, and when it's not (due to lack of balancing) they don't care to try. When they don't care to try they are going to look for what else there is to do, and if your game is built with it's entire focus on unbalanced PVP... Well you see where that's going.

So I've heard the argument "That's not going to matter I only have one race and theirs no classes, players can build their stats however they want!". This doesn't mean you don't have to balance those potential skill buildings, and also make reasons for players to spec themselves differently. If it's fairly easy to just max everything out you will have all of your players rushing to said max, playing a few battles, getting bored and going back to WOW where they can choose more options and build up their specs differently along side millions of other players.

Well my MMO has a much better PVE system!
This one I just have to be rude about, no you don't. You may have an idea or two that are not yet implemented by the big names just yet, but they have WAY more then you do. They have epic stories and long well written quest lines leading to instanced dungeons and raids that challenge the players and test their strategies and teamwork. All of this has been designed by teams of dozens if not hundreds of designers, developers and writers, something a small team of only a couple designers does not have the time and or money to mimic and or surpass.

Hosting the games servers:
Here's the real kick in the teeth. Say you do get enough graphics to get your game started, maybe you do have a well balanced and interesting PVP system, maybe you have a great story line and amazing PVE, now where are you going to host this game? The most common answers I get are "We'll just lease a small server to start and when the money starts coming in we'll upgrade as needed" and "We'll get investors!" Lets go ahead and break down the plausibility of both of those answers.

Small Server Now, upgrade as needed:
Many people are unaware of how expensive it truly is to power something with the magnitude of an MMO. Through my calculations that I wont go into here as they would take many pages to define out basically a package that provides you 10TB per month of transfer is breaking down to 92 hours of play per month per player (assuming 100 players). I say 100 players because the speed of the gigabit Ethernet your server is plugged into the network with is limited and the amount of traffic generated per connection is a lot higher then you would imagine. This may sound like it's a fairly high amount but we come back to the fact that your audience is hardcore, a lot of them will be playing say 4 hours a day, 7 days a week, (28 hours a week) and they will get cut off before the end of the month, or your going to be paying out the wazoo.

Next the processing and memory power, granted your not rendering graphics on the server and it won't require as much per connection but you need to be aware your still doing all your collision testing, positioning, rotations and many other calculations there. The cheap servers will not be able to keep up, you will need top of the line to support your 100 players. At this point I urge you to look into it your looking at around $375 per month to get a server that can handle some players. Keep in mind your going to have to offer your players free time to get hooked and it is going to take a LONG time before you actually get even 10 registered players. Now what are you charging them to play? Is it going to cover the $375 a month your paying and reimburse you for the past 12 months it took to get 10 people to register?

I'll get funding:
This is yet another common answer that is not well researched. Have you contacted any advertising, marketing, or other funding prospects yet? I have, and let me give you a taste of what your in for when you call these people and try to pitch your idea. "We're not interested in MMO's but we wish you the best of luck". This is what 9/10 of them will say to you the second you mention it's an MMO. This is if you even get that far, many people prior to even talking to you want your demo. Which means you have to have the game in a stable running alpha test and it needs to be live so they can log in and try it out. Granted you won't need the super machine to power just 5 - 10 connections to allow your team to test and leave room for the investor testing, but you will still be spending at least $100 - $150 per month for a cheap host.

Now you got your demo up, your lucky it only took 3 months worth of live testing to get it to a playable demo stage and you found a cheap server so your only out $300. Now you start contacting investors and looking for funding to proceed, your on a good track. Here comes the heart break, the response you get from the investors that you got to this point "You have potential but I don't see anything that can rival WOW or Rift or any of the other large scale games. How is this going to promise me a return on my investment?" No problem, you don't fall into any of the categories I have spoken about in this article, you have 20+ modelers, you have 3 dozen writers, you have 5 or 6 professional composers and a swarm of programmers. You can actually write better stories, you can provide more and better graphics, your PVP system is so well balanced that it's always a 50/50 chance for one on one, your PVE is epic! "Ok, well contact us again when you have all of that stuff built in". Hope your pockets are deep enough to keep paying for your server for the next 2 years while you get it all done.

Ok, I get it the world is against me!
Unfortunately this is the cold hard truth about MMO's, the entire world is against you and it's not only an uphill battle but you are working against the wind while standing on ice trying to climb straight up a 90 degree incline. So what do you do? Do you give up on it all, just scrap your idea and cry in the corner because your bound to fail? No not at all. I realize that this entire article speaks against you making an MMO and that is the intent of it, you should not jump into game development under the impression that you will grab up a couple volunteers and make an MMO, it's not going to happen and none of your arguments really hold any weight in the grand scheme of things. However that doesn't mean that you will never make it happen, it simply means you need to approach the entire concept logically and work your way up to it. WOW didn't start up over night and wasn't created in a month. It started with a VERY VERY popular series of games that built up the story, built a fan base and most importantly generated the income needed to pay people to build it, make commercials and other assorted advertisement and also gave them a cushion of money that could be used to launch the game and support the massive server costs required to get it all started.

At this point I'm sure many people want to argue and show me all of those free MMO's that are out there. Before doing such please research who made them, find out how much money went into making it and how much it costs to support that game. Find out how much money they are producing from in game ad space or premium purchased products and such. Research the actual team members, find out what other games they had worked on prior to building that MMO. Find out how many years of game development experience the team had as a whole before they even tried it. This is the point when I feel you will start to see things from my perspective. There is not a single MMO on the market today that was built as a first project by a group of volunteer developers with no experience. Also you will start to find some MMO's that where created by a small army of talented and experienced developers, you'll start to play it and you'll hate it. Poor graphics, horrible response, lag spikes from hell, not enough players and so on. So your going to build a rag tag team with no experience and do what these professionals couldn't even do?

Final Thoughts:
I'm sure this one is going to spark a lot of controversy and many people will try to point out contradictions to what I'm saying. I hope everyone does, I welcome it and I hope that someone does completely belittle this article. If nothing else simply reading through this article, doing some research and attempting to prove me wrong will get you to ask the questions you should ask before trying such a project. I'm sure this will not stop the countless projects that are going right now, nor will they pay any heed to what is being said here and that's not what I want to do. I don't want to crush your dreams I don't want to make you feel stupid or any of that. As with all of the articles I post I simply wish for everyone to do their research and make educated decisions that can lead to the betterment of themselves, their teams and their projects. What I truly want is I want you to succeed, I want you to finish your project and make a billion dollars. I want you to come show me that shiny new Ferrari or Rolls Royce some day and tell me I was wrong. However for that to truly happen you have to know what your doing, it all starts with asking questions of yourself and looking beyond the glitz and glamour. You need to know what really goes into making an MMO, the costs, the armies of developers, the hundreds of thousands of hours it takes just to get a simple beta test started. If and when you see the ugly truth that lies in the answers to these hurdles consider cutting back and starting a bit simpler, maybe even contact me and we can do something together, but when all is said and done make yourself and your game successful by doing it right.




Who needs a design document anyways?

Hello fellow designers,
It's been a couple months and as such I felt it time to post another journal entry. This time around I wanted to take a moment and discuss some concepts and ideas behind game design documents, who needs them and how important they may be. As with all of my entries this posting is meant to be informative and get you to ask the questions that will lead you to better results in your ventures. All of the ideas and concepts I mention in here are personal observations and experiences I have encountered over the years of design and development work I have done.

So to the point, who needs a design document?
A simple question with an even simpler answer in my opinion. YOU! Yes I'll say it and believe me it matters, all potential works be it video games, board games, computer software and or web sites all start from one vital asset known as the design document. We've all seen the abundance of people who like to come up with ideas on how they can make a better game or a better service then the last guy, we've all seen the next guy step up with his additions and modifications so forth and so on. But what really gets these projects going? What is it that actually draws interest to you and your project? In today's world where many designers are looking for partners and profit sharing members how do we even get started? The answer to these and many more critical start up questions is the design document my friends.

But my idea is simple, I think people get it...
False! This is a common misconception for many people that try to get their game project started. A lot of times people feel that their game is small and simple and they don't need a design document for other people to know exactly what the project is supposed to be. Although this may be true for you and your friend it's not always that simple. Most of the time the idea seems brutally simple to you because it's your idea, and the friends that you talked to for the past 3 months about this idea seem to completely understand you because you unknowingly have pitched the idea to them so many times. I'll try not to go into one of my long winded rants here, just basically trying to make the point yes you need a design document no matter how simple your project seems.

Ok, I get it I'll make a design document
Well it's a good start to understand you need the document and to begin working on it, but some more consideration is needed. Do not start writing the design document as a chore that needs to be done in order to post a request for partners and or help. Write your game on paper (or in office for today's age), the entire thing, front to back. A design document should never be less then 3 pages and should never generalize ideas and concepts. The design document is what your potential help will read to get the complete feel for your game, make it interesting, explain things, make it call out to other designers and most importantly make it scream "You MUST be a part of this".

An old saying goes "You get what you pay for", and this really does hold true. However it's not always "money" that you need to pay in order to get quality and results. In this world there are many game designers, and even quite a few that are of top notch professional quality that are either out of work or looking to pursue hobbyist projects. Your design document is the first and most important thing that these people will see when they consider you and your project. Not having a design document immediately kills any chances you have for getting a professional grade developer to join you. Having a weak or incomplete design document shows that you yourself don't really have the dedication to continue working on your own project. Keep this in mind when you are writing, try if you can to read back what you write and think "How would someone else feel about this? Does this document show that I am dedicated to the project? Do I show that I have a clear cut idea of what I am looking for in both a team and in a game?". Whenever possible have an impartial person real through the document and have them give you feedback. A lot of times this impartial person will give you new ideas and help you to complete concepts that you are struggling on. In the long run this not only helps your chances of finding quality help but also gives your project that little extra boost in the direction of success.

So how do I do it?
Design documents, like the games themselves come in many different shapes, sizes and templates. It's normally best to simply start writing, tell your reader who the characters of your game are, what the characters are doing and why someone may want to play your game. Extend on this, add some brief dialog ideas you have, explain what you have in mind for some cinematic's, give ideas of how many levels their may be and how the player progresses through them. As with any writing you will always have a rough first draft but that's ok! You don't need perfection in your first go, your basically trying to get that massive jumble of ideas our of your head and into writing. You will notice as you go that it seems like a never ending task as the more you write the more you need to write. This in itself is the main reason why you NEED that document in the first place.

So trying not to get to far off subject I will go back to some of the key components I mentioned in the paragraph above. I do not intend this list to be the definitive answer as to what all design documents MUST have or how they should be layed out but I will give you a quick example of some of the things I myself do when writing up design documents for my clients. It is my recommendation that you always try to address each of these points in every design document you create but by all means please go with the flow and write your document as best fit to your project.

Believe it or not Characters of a game are one of the most important aspects. The characters are who your player will fall in love with, learn to hate, connect with and so on. As such I believe it's a major part of the design to develop a core set of "Lead Characters". I always strive to give a little background story for each character, a bio, a description of what I think they should look like and so on. Most importantly connecting the characters to the story is a must in my design process. I highly recommend giving a reason why this particular character is involved in this story, why they are doing what they are doing and so on. Cinematic's:
I can almost feel the proverbial heat coming already for saying that cinematic's should be defined inside of the basic design document but I do feel it adds ambiance and makes the design more appealing. I will admit this is not a very crucial part of early design it does show that you have a complete idea going and that your not in the early rough draft pitching stages of a project. I normally try to give a generic yet fairly good definition of what I am thinking of when it comes to some of the games cut scenes, intros and other cinematic (movie) scenes. These also help to show intended plot progression and get the reader to truly understand the mechanics of the story. Whenever possible I would try to include descriptions of the cinematic's of a game, however try to avoid step by step scripting as it will inevitably change throughout development. Story Line:
Story line is paramount to a design document. I know there are probably people already that are reading this and want to point out "I'm just making a puzzle game there is no story". However if this is the case you normally don't need to recruit help, puzzle games are normally designed in their entirety by one or two people. If this is the type of game you are going for I must admit I have wasted your time with this entire article. However, for everyone else your story is VERY important. This should really be the bulk of your design document, you should explain why the game is taking place, why characters are drawn into the game, what the goals are, how the plot progresses and so on. Be very very wordy with this portion, if you don't know the answers or can not fully define / describe this portion get back to the drawing board. Simply put writers who have these great ideas and can write the entire story and plot for you are probably selling their stories to publishers and other development studios. As the proposer of a project this portion of design falls to you... period. This does not mean that you need it to be perfect, you can leave a lot open for other people to chime in on in order to create the perfect work, but the fundamental ideas of who's in it, what are they doing, how do they win and so on MUST be answered before you move into further stages of design and development. Levels:
Location, ambiance, surroundings, where, these are also very important. Star Wars didn't take place on middle earth, nor did Lord of the rings take place in space. Your reader wants to know, where is this game taking place? What time frame, what are the surroundings like, what kind of technologies exist, what are the people like and so on. Level's may not be the best heading for this particular part of the design but the message stays the same. You should know where your game takes place before you try to tell other people about it. Although references are a good starting point no one wants to copy pixel for pixel another games style. You should explain in as much detail as possible what the your games world looks like, what the levels or areas are, how the player will interact with those levels and how to progress onto the next ones. In many cases you will not have all of these levels designed but you should at least have a starting and ending point clearly defined before you start developing and adding in filler. Items:
Ok, not as important but does add to the readers understanding of your game and it's mechanics. You could probably get away with ignoring this section but I promise you that adding in these details will greatly increase your chances of landing the help your looking for. Be simple but concise here, give ideas of the important types of items and how they would work. This matters mainly to writers and programmers but everyone likes to have a good read of the equipment and supporting items that they can gain throughout the game. Skills:
Skills, abilities, attributes... They all seem to fall somewhere in the middle ground of importance for a design document. Not having them may not ruin your project but having them is definitely a major plus. Programmers and graphics people especially both like to know and need to know before they get started what kind of special's they will be responsible for creating. Whenever possible try to explain what these are, how they work, what they do and maybe even pitch some ideas as to what the animations and particle effects that might go into them. Exact statistical numbers are not the most important part of this so don't waste your time trying to get everything balanced and perfected just yet, that can come much later in the development stages of your project.

When all else fails
When all else fails and you simply can not seem to get a good design document going, seek help... Professional help if needed. However there are many writers out there that can offer tips, pointers and maybe even help with a little proof reading. Many times this comes free of charge as there is an abundance of talent out there and we live in a world where people just want to be heard. Throw away your NDA, get over your insecurities and ask other people to criticize your work. Once the heart heals from the brutal lashing you will inevitably get from opening yourself to it you will have a lot of good advise to work with. As people ask questions about your design or criticize and even insult it, use that! Take the words they give you and apply them to your work, make it better, improve it so they can not pass along that insult any more, and in the process of appeasing the haters our there you will find yourself gaining ground.

Research, study, read.... Very important to game designers. Many times people play a game see it and want to do something better. But before you jump in and write out your ideas do some research. Study why it is that the game that spawned your creativity did so well (or so poorly in some cases). Find out what other people thought of the game, join the forums and collect more ideas. Not only will this give you more to work with but you will find yourself getting more and more creative with every additional article or forum posting you read. This will reflect into your design document and help your project get going.

Final Thoughts (Yes, just like Springer)
I would imagine after reading this article people will have strong feelings both ways. As you see personally I believe that no project will succeed without a good, strong and well thought out design document. Even with the masses that may disagree with me on this it is my experience and observations that have lead me to these conclusions. I personally have seen and even been a part of many failed projects, I've seen what happens when there is little guidance and poor design details. As such if you believe me or not I implore of you to at least do your homework on this matter before you move another step with your project. Ask successful teams and teams who have failed alike, ask if they had a design document, ask to see it. Compare the responses you get from both and make your own decisions as to how important a good design document truly is.

I'll end on that note and I welcome other peoples responses to this, yes even from those of you who think I'm full of it. If you have any more questions or would like to run some ideas by me I'm always willing to help as my schedule permits. My contact information is in my profile I do not get back to this site much in order to monitor my messages here but I do read my emails every chance I get. The most immediate way to get to me is through my instant messengers that you find on my profile or you can try to email me. I'm Dan and I'm AT my website, I'm sure you can put those together and get the address from it ;).




Professionalism and it's impact on your team.

Hello Everyone,
It has been quite a while since I have written anything in the journals here but stumbling across something today spurred up the great ranting machine inside my head. Professionalism and the lack of it in today's gaming world. I was browsing through a few of the career opportunities here on Game Dev today and stumbled across this listing that I just had to comment on. Lets go ahead and jump right into it here with a few little excerpts that I gathered from said posting. In the interests of not being that guy that openly and publicly bashes someone else's short comings I will mask the companies name. The purpose of this entry is not to insult the intelligence of this company but to use their lack of it to educate everyone a bit on professionalism.

[quote][color=#1C2837][font=arial, sans-serif][size=2]COMPANY is looking for a few brave individuals to help us change the world. The person should dream in game mechanics, shout stories from the rooftops, eat ideas, and poop prototypes[/font][/color][/quote]

At a glance of this above statement we see the reference to "poop prototypes". Now I have a sense of humor and what not, actually I don't even particularly look down on them for this attempt of an interesting yet meaningful joke. However this is their opening tag line, this is the sentence they are using to try to get people to apply for a career with their company. I would invite all professionals to comment here on my journal about this. Personally what I see is immaturity what would attract only immature bidders and applicants if you will.

[quote][color=#1C2837][font=arial, sans-serif][size=2]If you can't not make things, don't not consider not passing up this call to arms! If you can't not draw (even crappy little doodles), don't not call. If you take serious gaming seriously enough to want to actually go farther than cutting ropes and tending crops, if you can take classic game design skills beyond the traditional gaming medium, if you want to work over there on the next mountain, the one that is trillions of devices high and billions of parsecs wide (rather than the sad little mountain of mobile apps and cloud bursts, and trivial little doomed sunsets of web crap everyone is trapped on today) than maybe you should talk to us.[/font][/color][/quote]

This was the next portion of their posting. First and foremost, deplorable English! This is a company based in Pittsburgh PA. Now I am no English major nor will I attempt to correct every one of the numerous problems with this above statement but I would like to just have you all take a little look at this. I must also note at this point, this is really a serious job posting! This company truly believes that these two statements which in my book can barely be considered English (American, British or otherwise) will actually attract someone to apply for a position!

[quote][color=#1C2837][font=arial, sans-serif][size=2]Questions? No we don't want you to even apply if you don't have a relevant degree (BFA, BS, MFA, MS) or experience or if you aren't fun to play with. No we don't care if you can use all the fancy new tools and platforms and software but we do care if you can learn any tool you need to make your idea.[/font][/color][color=#1C2837][font=arial, sans-serif][size=2][/quote][/font][/color]
[font="arial, sans-serif"][size="2"][color="#1c2837"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]Are you serious? This company that doesn't even have an elementary school level of communicative skills will refuse me the time of day because I myself do not have a college degree? This was what really sent me into an uproar and the reason I came to journal land to vent a bit on this subject. Although this is by far the most unprofessional and outrageous job posting I have ever seen in my life it is not uncommon. Far to many times we see teams and companies that come here to GameDev to solicit help for their projects. I believe it's high time someone breaks the silence and gives some cold facts about this lack of professionalism and how it does and will continue to effect the teams and companies that post utter crap like what we see above.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]I want to urge everyone to start looking into successful game projects, teams and companies. Contact them, read their web sites, flip through game manuals and read reviews about them. You will notice that every single one of them speak, write and otherwise communicate professionally. Complete sentences, good proper grammar and punctuation politeness and so on. This is no coincidence people, basic communicative, speaking and writing skills are one of the single most important concepts required by any team that wishes to ever make it out of even the earliest design phases.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]"I have a dream!", ok not exactly but you know what I mean here. This is the basic phrase (not in so many words) we see in every single posting of the Help Wanted boards here on GameDev. Approximately 90% of the time this is followed with some basic comparisons to existing games and more comments along the lines of "We want to change the world" "We have no experience" "We are going to make the next best selling game in video game history!". Quite frankly no, your not. I will try my best to not refer to myself as a professional as I don't wish to start that argument here but I do hold 14 certifications in programming and other various computer technology fields. Someone with the skill, experience and certifications that I have are the type of people that actually get work done and drive games to market.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]So why do these teams never get people like me (or even someone more talented then I) to join? We know better then to waste our time with unprofessional proposals and ill conceived designs. Which is finally bringing us to the point of this complaint ridden entry, professionalism and it's impact on your team. We've all heard of that one in a million team that strikes it rich on their first game release and strive to be just like them. However it's important to do a little research and understand what the difference was, why did that particular team make it where hundreds perhaps even thousands of others have failed? We can all speculate many different reasons, talent, dedication, technology, communication breakdowns and what not. However at the core of all these comes your professionalism. The self proclaimed project managers and team leaders, these are the people responsible for driving their team into greatness.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]So how and or why am I trying to make this connection between professionalism and all other aspects related to the success or failure of a team? Basically it's like that old phrase "You get what you pay for", although we're going to look at it in a more broad sense. More so you get what you put in. When at the very beginning of a project the so called leader starts off with immature, unprofessional or incomplete designs and ideas you are already destined to fail. As I mentioned a bit earlier and I would imagine that I speak for the majority of the professional grade developers and designers out there, we wont give YOU the time of day.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]Well finally, to recap I really just want everyone to take a look at these quotes. Examine and maybe even get a good laugh out of them, but ask yourself truthfully... "Would I apply to this company?" I would venture to answer this question for everyone in advance with a firm "Nope". Although this entry has highlighted an extreme case, possibly even the worst possible job posting I've ever seen in my life we can all learn a little something here. I'm sure to the submitter of this particular post this was gold. This adequately depicted their teams goals and personalities while attempting to find candidates that where for lack of a better term on the same page as them. This is what we all do when posting any requests here on GameDev. We think and speak from the heart in hopes of finding like individuals to join us in our quest for greatness. Unfortunately this in a lot of cases is the recipe for disaster. I do not wish that you take my message as "Don't be yourself, be a politician" but think about what you say and or post before releasing it to the masses. There are many ways to get the same message across without it looking as if it was written by a 5 year old with down syndrome. Taking the time to formulate complete ideas and concepts, clearly listing what you are looking for and what you can offer are paramount to a successful venture in this industry.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]I'll leave you all with just a few more words of incite. Think about the ramifications of what you are saying in a post, a thread or a request. Although you have written what seems to be great to you take a moment and think "Does this adequately attract who I am looking for"? Do some research on the technologies you want to use, the types of concepts and features you are looking to implement. The main flaw I am pointing out in this example is as such. This company we are speaking about here is looking for someone with a college degree, a professional. What college graduate have you ever heard that speaks or writes in such a poor manner? Also you will notice that they make mention of "We don't care if you know how to use fancy technology.", a complete contradiction in my eyes. If you are looking for a professional, a college graduate or what have you would it not also make sense they would have experience with fancy technologies? Ok, I'm rambling again so my final thoughts. Always think before you speak especially in a public forum. Do some research, have your cards aligned and your ducks in a row, be ready to speak professionally and answer all the questions a potential team mate may have. If you don't you will never succeed you will simply attract failure after failure.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]
[font="arial, sans-serif"][color="#1c2837"][size="2"]Comments are welcome, I would like to see what other people have to say about this matter.[/color][/font]
[font="arial, sans-serif"][color="#1c2837"][size="2"]




UDK For Indies?

Hello everyone:
Wanted to take a moment to talk a bit about the Unreal Development Kit and it's potential as being independent technology. I have noticed that the many independent teams here on Game Dev are starting out with UDK as their core technology. As such I just wanted to share some things that I have learned about UDK and it's plausibility as an engine and development environment for independent video game projects.

The most credible UDK advantage over any other engine / tool kit is the power that you gain simple access too. The core Unreal engine has been used in many large scale commercial games and does provide the utmost speed and performance. I would almost even venture as far as to say that the Unreal engine is THE most powerful engine in existence.

UDK Comes with a very powerful and easy to use tool set as well. The Unreal Game editor (or the level editor) is basically a powerful modeling tool with a very easy to use video game elements wrapper. In other words it is quite literally point and click to design your levels and worlds. The Unreal Kismet editor again shines with power and simplicity, it's a simple point and click flow chart editor used to write simple logic into your levels. Things such as switches, dynamic lighting, traps, enemy spawning and more. Next we have the built in "Matinee" editor, this allows you easily add animated cut scenes into you game. Again we must thank Epic for the ease and power of this editor.

Next I'd like to talk a bit about Unreal's portability to various platforms. UDK currently ports to Windows PC and iOS platforms only. This means that your end product would only be playable on Windows PC and iOS devices such as IPhone4, IPad or iPod Touch. In order to port your title over to console systems such as XBox360 or Playstation3 you will need to upgrade to the FULL Unreal engine 3.

Next we get into the cost and licensing restrictions, here is where it all starts breaking down for me. UDK is free to use which is great, allows you and your team to start working immediately with no additional cost. When your project is complete you can release it free of charge and not have to pay Epic anything (again great for hobby / freeware games!). If you decide you want to sell the game you made, go ahead. You only need a $99 license to start selling your game. This will allow you to collect all of the profits from your game up to the first $50,000. Everything you make after the first $50,000 you must start paying 25% royalties on... (ouch!)

This will allow you to release your completed game and sell it over any marketing means you choose. However you are staying limited to Apple mobile devices and windows PC. Please consider these markets carefully, and also research them thoroughly before you commit. Windows PC game sales are dropping, have been for many years. If you google search for "PC vs Console Game Sales" you will see many examples and sales figures that show the drastic difference between games that are actually selling and making money on PC versus new age consoles. Following the law of averages I would say this shows that we as developers are at least 10 times more likely to sell our games if we can get them on console.

Apple mobile devices however are a HUGE and growing market. Making games directed for the app store have found their holy grail. If your main marketing goal is the app store and you are not interested in venturing into PC or Console markets then you can really stop reading here. To put it simply, there may be cheaper options but if you design small (maybe $1) games, the single $99 license would suffice and you would not likely surpass the $50,000 cap. Therefore you gain the most powerful game engine and tool set for a mere $99!

The great divide:
Here is what further pushed me as an independent developer away from the UDK. There is a HUGE divide between creating a Windows PC / Apple Mobile project and porting that project to console. As of right now there are two main ways that I know of for small independent teams to make it on to consoles, the first is through Microsoft's creators club (leading to the live indie marketplace). Or to receive funding / publication from an accredited marketer and or developer. In order to go the first route Microsoft will limit you to C# and XNA (which are a very powerful Microsoft created managed api). However UDK is powered by a C++ powered core engine that is not supported in the indie market.

This leaves us with our only option to be to come up with $10,000 for each console license, pass Microsoft and Sony's regulations and testing THEN come up with an additional $450,000 for a FULL Unreal Engine 3 License (also passing Epic's regulations and testing). WOW, that means it's going to cost me $470,000 just to port the game to console?!? What the hell there has NEVER been an indie project that profited $630,000 (the amount you would need to make after UDK royalties to have $470k in your hand).

Ok, lets not panic here... Maybe we can simply get some major studio to co-release the console port for us... Although this IS a possibility, with most teams and projects this is not a practical option. You have to think of things this way, you are basically asking another developer to publish your game under their license. They are staking their studios name, credibility and over $470,000 worth of licensing on your project. Now your adding in another source of regulations you must meet, even more testing criteria, and will more then likely be asked to change things so as that your publishing source feels comfortable that your project is worth marketing.

Regulations and Testing?!
You will notice I make mention of various regulations and testing. Let me clarify this a bit and I will start with Microsoft. For Microsoft to even consider your team for a full license and XBox360 dev kit you must have prior game releases under your belt. You must be an officially licensed company with a business mailing address. Your project must be 100% operational and bug free in the eyes of Microsoft beta testers. So assume you as a team have already released a project or two, maybe you do have a registered company and a PO box for your mailing address. Of course your game is flawless and ready to go, it's built with UDK! You will still need to wait for months while the Microsoft Team tests your project.

Epic's regulations are basically the same, and from the last I have heard they do not do the testing of your project. Sony has similar regulations and will need to do their own testing like Microsoft does. Sony may also take months to do this testing, if you are lucky you can schedule both of these testing simultaneously so as to not lose to much time.

Ok, I think I have rambled enough about the basic concept of UDK as an indie technology. Let me recap with a little example break down of what a team is really looking at when using the UDK to produce their titles.

[Windows PC / Apple Devices (App Store)]
Complete your design document Install UDK and begin development Pay Epic $99 to start selling your game If your game makes more then $50,000 you will need to also start paying an additional 25% royalty to epic
[Console Devices (The big bucks)]
Complete your design document Register your team as a real company Register with Microsoft / Sony (assuming you meet the qualifications) Pay MS or Sony $10,000 for a license Register with Epic (assuming you meet qualifications AND are registered with MS or Sony) Pay Epic $450,000 for a FULL Unreal Engine 3 License Install the Unreal3 tool set and begin development Obtain MS or Sony testing approval Obtain marketing (Disc distribution / live marketplace / psn) Do I finally make money?!? Yeah, if people buy it
Final Words:
I apologize if some of this entry comes across as cynical, I was actually quite devastated to learn how much money it would cost to actually port a UDK project onto to console systems. I was also shocked to find out that the PC gaming sales are dropping so exponentially. However personally I have decided to do my best to keep up with the devices that are most popular (and yet still easily accessible by me). UDK simply put up way to many borders between me and the illusive console market. As my goals are to A: Make money doing what I love and B: to make popular games, I simply can not afford to ignore consoles any more.

By no means to I wish to break anyone spirits or crush any teams here but I did feel that this concept and realization of what it's actually going to take to get a UDK project on the big screen so to say is need to know information for serious teams. It is important to know of major hurdles such as these prior to designing, planning and marketing a new project. So long story short, if your goals are to ever get a given project to the console and you are starting out or just a small indie team. UDK will kill you with a BFG470! However if your aim is the app store or a PC only release then UDK may still be within your means.

Thanks for reading!



Sign in to follow this  
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!