Jump to content
  • Advertisement

Digivance

Member
  • Content count

    247
  • Joined

  • Last visited

Community Reputation

1724 Excellent

About Digivance

  • Rank
    Member

Personal Information

  1. Digivance

    I have to agree a lot with this article.  Personally in my professional life I am constantly asked to perform tasks that I have no clue how to approach.  The reason I am in a supervisory position and on the board of directors in my company is because I live by the underlying message of this article.  I consider myself a loser and a failure if I do not accomplish something simply because I don't have the knowledge to do it.   It seems that many people are taking the most offense to this article from the seemingly insulting nature of the words and sentences that are used.  However I think it's an ideal lost in the politically correct world in which we live.  From experience, when I look to hire new employees or when I am present through interviews for other departments I am VERY quick to disqualify someone from the potential position at the first use of "I can't do ___" or "I don't do ___".  As harsh as it might sound those two statements alone will cost you a job at my company.   So from what I take away from this article is that a politically incorrect message is given to shed some light on the truths of the larger business "professional" world.  let's pretend a bit and put on our hiring hat, lets assume we are hiring a new "professional" for our company and monetary compensation is not an issue.  We are looking for someone to come in and fill a position that we are lacking.  Now some examples.   We are looking for an artist:   - Artist A:    I do logo and splash page / screen design with light concept artwork.  I can not (or do not) do character design and or animation.   - Artist B:    I do logo and splash page / screen design with light concept artwork.  I am not very experienced in character design and or animation but I am willing studying and learning how to do it.   (Who do you want to hire?)   We are looking for a programmer:   - Programmer A:     I do C++ programming, I can not (or do not) know how to use LUA or C# for scripting.   - Programmer B:     I do C++ Programming, I am not very experienced in LUA or C# but I am working through some resources and learning how to do it.   (Who do you want to hire?)   In both of these answers most (if not all) potential hiring executives will choose B, because they are versatile and seemingly have more potential to grow as needed.  They are not portraying a defeatist attitude they are admitting where they may be lacking and showing drive to improve themselves.  These are the types of people we want to hire.  Simply put the people that have the talents in these areas are quite expensive to employ in the first place.  Now when I have to hire 2 - 3 people for the same position because each of them is self defeating themselves and refusing to better themselves...  Well that's just an outrageous request is it not?  Expecting me to pay out 3 times as much of my companies hard earned money because potential employees refuse to take it upon themselves to get better?   So long story short, I am a hiring executive at my day job.  I own two small business on the side that I share with others.  I am looking to hire people at all three businesses, and who am I looking for?  Person B, the one that I hire for a particular field and can trust that they will know or will learn how to accomplish the tasks I present them with.  No excuses, minimal failures and lost time.  No I am not going to hold your hand and find you the resources and courses you need.  That is part of your job description.  No I will not tell you in your interview that I believe you to be worthless because you gave me the excuse that you just don't know how or can't do something.  But I will be thinking it, and that's what this article (at least in my opinion) is trying to present to the public.
  2. Digivance

  3. Digivance

    The Programming Primer

    Thanks to everyone for your comments and votes, I'm glad to see that this article seems to be a beneficial read for many people.  In the not so distant future I will write up some additional theoretical articles on some more advanced topics such as networking, threading and such.
  4. I would have to agree with rip-off, this article is confusing to follow even as an experienced programmer.  Also, you mention that you will not cover collision in this article yet collision is pretty much what pong is all about.  It seems like this article is intended for the new beginner to start their game coding experience but assumes that they are familiar with the complexities of incorporating and compiling third party code into their own project and skips over all of the fundamentals of the game loop itself.   Long story short it seems that a better way to write an article of this nature would be to actually start from scratch, explain how to implement a rendering framework (such as Direct X, OpenGL, SDL or XNA / Mono Game).  From there explain a bit about the actual game loop and how to create / implement it into your code.  After that a brief explanation of the basics of collision, some input and that would more adequately teach a newer coder how to actually get the game going from scratch.
  5. Digivance

    Oh, your code structure isn't pefect?

    I have found myself in this same boat all too many times.  What helped me to overcome it was money.  Customers don't tend to care if it's perfect they just want it done, and when you finish it they pay you.  From that I have learned to have an "acceptable" standard and a "personal" standard.  Where the acceptable is does it work?  Is the customer happy?  Are there bugs?  All in all there's few times that customers pay to maintain their works, more often they simply contract a fresh new build of the entire project ground up with new features and targets and what not.  As such, as long as the structure of the code remains viable throughout the coding process the first time you can be lax on return coding a bit.  That's not to promote poor coding practices but a way to let yourself actually be productive instead of a perfectionist.  When it all comes down to it my goal is to make stuff, I'm not big on the fight with the computer to get there so productivity over pretty in my book.
  6. Digivance

    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: 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... Numbers: 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). int 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. long 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. float 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. example: float x = 1.5f; double 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. Characters: 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: 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. Functions: 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". Methods: 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!
  7. Digivance

    What are you worth to a development team?

    @Servant of the Lord,   You raise some very valid points.  I understand your theory that this may not be the correct place to spur discussion as a forum post would have allowed for better quoting and piecing together.  I would have to strongly disagree with you that I am presenting anything as fact in this article as I feel I made it very clear that these are my experiences, views and opinions but I still appreciate your view and that I might consider some different approaches and or techniques in future writings.  I did feel that the journal was a good place for this as I thought it would hold a bit less weight than posting an "official" article somewhere.  This is a heavily biased article as it is just things I see and experience, I did not want to post it as an "Official" article anywhere and have anyone get confused and think this was some big fact of life.   About the "idea guy" topic, I didn't particularly mean to compare this "idea guy" to a game / level designer.  Small Team - Studio comparisons of worth be it intellectual or financial vary from team to team and maybe I should have focused some more on saying this is what I have seen and stressed that this doesn't mean it is what you will encounter.  For designers, I would respectfully disagree that studios in general hold them to such high regard and I didn't want to include that because designers are a project worth more so than a group worth and it varies.  If it's a major studio like Square that made a top down twin stick fighter plane game (I don't remember the name off hand) they had 0 designers on that project, as such even their best designers where "worthless" to that particular project.  As for Final Fantasy, designers here are everything (arguably still need assets and code to power it), in that aspect you are right.  A highly talented, trained and experienced designer can go places without knowing art, coding or composing.  It is my opinion that this is not the way to get into the field though.  I read a blizzard forum response explaining what they look for when they hire designers that might be interesting.   http://us.battle.net/wow/en/forum/topic/7592909216#17   What I gather from this is "Be something else, be a great designer, make games that prove your good than come see us".  Again this is my interpretation and this leads me to believe that the guy with the idea who learns to use UDK isn't necessarily important to large studios such as Blizzard or Square, both of them tend to be looking for something that has a relevant degree and lots of in field experience related to what aspect they are looking to have you design.   My apologies if any of this sounds argumentative I mean it in no such way.  You challenge what I say and that is great, as you should.  It will help people who may stumble across this to read it a bit more objectively or to challenge it themselves or to see that it's not fact it is opinion.  Let me end this comment saying you sir are 100% right but I stand by my opinions.  To me and those I have worked for and with this is the trend.  For you, the people that you have worked with it might be polar opposite.  I don't think that makes either one of us any "righter" than the other, it does show that the industry is big and just because these are the trends I have seen in my career doesn't mean it's the trends you or anyone else has seen.  Thank you for helping to enforce that point.
  8. 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!
  9. Semi active here again after a long period of not checking in
  10. Digivance

    The truth about MMO's

    [quote name='Over00' timestamp='1321498359'] I'm sorry... I really am. I thought this was a new post. I just realized it was posted before here: [url="http://www.gamedev.net/blog/355/entry-2250155-why-you-shouldnt-be-making-an-mmo/"]Why you shouldn't be making an MMO[/url] So here's my past answer to that: [url="http://www.over00.com/?p=1610"]Why you should be making an MMO[/url] [/quote] Just wanted to mention that was another article written on the same topic. It was a different author and it is just some more reading as to the cons of jumping into MMO design as an indie team. Please be sure to do your research before making such claims.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!