# What are the dangers of self-teaching game development? [closed]

I am about to embark upon a journey into game development. Following answers to my last question, I will be using C# and XNA.

However, I don't personally know any other game developers and I don't work in the industry so, as such, will be self-taught. The exception to this is obviously the asking of questions and reading of online/printed information but I would still class this as being self-taught.

With that, I want to be prepared for issues that I may encounter through not having someone to "keep me under their wing".

As an analogy, when self-teaching myself to play guitar, I played the A major chord in such a manner that it made moving to a chord I learned later more difficult.

If you could share your lessons learned and advice on what might go wrong in my learning of game development I'd be grateful.

I am well aware that making mistakes is the biggest part of learning but, if there're mistakes I can be prepared for then I'd be happier with that.

• Take a look, the share lessons thing may turn the question as open-ended and invalidate it, so it may get closed. May 3, 2012 at 13:24
• That's a good point. To any visitors, I do plan on accepting a comprehensive answer.
– Ste
May 3, 2012 at 13:28
• Ste, be aware that you can move a checkmark to another answer, if you think a new one is better. My apologies to Gustavo, not trying to cost him rep :) But the point of these sites, and the voting and checkmarking, is to highlight the best answer to a question. Also, although it's great that you did accept an answer, it's not necessary to accept one that fast - an hour after your posted question, is a bit soon. I usually wait at least a day, maybe more, before accepting an answer. See what shows up. May 4, 2012 at 10:32
• @Cyclops - yes, I wasn't expecting the question to prove so popular. I will review next week. Thanks to all for the great answers thus far.
– Ste
May 4, 2012 at 10:34
• Thank you for all of the great answers. I have moved the accepted answer to the one with the most upvotes. I have done this to reflect community opinion. Hope you understand @Gustavo
– Ste
May 8, 2012 at 12:07

### Game development is like structural engineering

There are minimum requirements for functionality. The minimum requirements are not exceptionally challenging and many people can learn how to fulfill them. That's the function part. It's the small part. This is where the decisions of what language to use, platform to develop on, or what libraries to utilize come in.

The next part is the big part. The form part. Form is what really distinguishes the good games from the great games. This is the part that's the art of game development. I'm not talking about just the sensory assets (graphics, sound, etc?). I'm talking about crafting an experience. This is the hard part.

The function part comes from tutorials, libraries and a bit of time. Anyone can do it.

The form part comes from you. It's the passion that got you to want to make games in the first place. It's like telling a story, a made up story (or a true story you embellish, a lot). The more you tell the story, the better it gets. In software development we call it iterating. Your story is your code. The first time you tell it, it won't be very good. Things will be out of place, you'll realize that this bit should go there and that one here. You'll find that things will probably flow better if you arranged things this way or expanded on this bit. So, just like a good story, you'll tell it, gauge how good it is, and then modify it. This takes dedication and this takes time. Don't fret if the first thing you produce isn't gold. I have worked long and hard on many parts of my game only to rip them out later because I thought of a much better way of doing it. Don't worry about this, it's all part of the learning process. You always learn from your mistakes, and often making those mistakes is what leads you to the better way of doing things.

So what you should take away from this is this:

• Play test often.
• Don't get caught up on the function right now. Don't worry to much about optimization, or which library will be the best in the long run. Just get the minimum functionality, then iterate.
• Once the function is done, congratulate yourself, you're a small fraction of the way done.
• Wear sun screen
• This is a skill that takes time to develop, you know that from learning a musical instrument, this is no different, you will get better.
• Remember what you're in this for, the joy of creating! If things get boring, then switch to something else (try out some game jams to break-up your development time). But don't quit just because it's hard.
• The game development community here on SE is great. You'll find everything you need here. You can post a question or hop into chat and discuss your ideas.

The internet is full of feathers of information in blog posts, tutorials and communities like this one. Collectively, I'd say that's a pretty good wing to be under. Basically the dangers are not severe. You might do things the "wrong" or hard way for a while, but you'll learn eventually. You appear to have plenty of programming experience, so I think you'll pick up on the function part quickly. The mistakes made in game development and "regular" development overlap a lot. Your experience will help you avoid many of the common issues the befall new game developers. I think you'll do just fine. Good luck.

• +1 for awesomeness, all that is missing on my post is found here :D May 3, 2012 at 15:36
• "Wear sun screen" What do you mean by that? a idiom "Wear Sunscreen" ? May 3, 2012 at 15:53
• That's a joke based on a article "Wear Sunscreen" by Mary Schmich. Basically, "The long-term benefits of sunscreen have been proved by scientists, whereas the rest of my advice has no basis more reliable than my own meandering experience." Perhaps more popularly known in the form of this song.
– House
May 3, 2012 at 16:05
• Well uh, sunscreen isn't all that good actually 2. Just stay indoors and keep programming. May 4, 2012 at 5:03

Yes, not having someone that have been there before to say to you what to do, how to fix, etc etc may be the worst thing you'll pass. But no fears! You still can read LOTS of blogs of people that have been there, they share their experiences in the industry, how they got into the success, how a previous game failed and why, etc etc.

Good examples are:

And lot's more!

My last sayings are: Don't fear. I'm self taught too, 4 years I've been introduced to game dev, lot's of barriers come, but nothing that you can't solve googling and reading some texts. Good luck on your journey :)

• To add to this, even professionals have this problem often. As long as you can learn, and Google, you can figure out pretty much anything. May 3, 2012 at 14:12
• Weird that you link 2Dboy. As far as I'm aware, they have done few things but ports of World of Goo to all platforms that ever existed for the past couple of years. It's been a long time since I read something gamedev related there. May 3, 2012 at 20:38
• @TravisG The process of release game isn't only related to developing it after all. It's good reading anyway. I posted the links more as reference, not to get following the blog. If you go back on archive, there are a few example of prototypes and all that helped them with world of goo and other "less little" prototypes :D May 3, 2012 at 20:45

This attitude. This "don't touch it, until you know how to do it perfectly" attitude. That'll really hold you back.

You see this attitude among beginning developers of all kinds though - not just games. Websites as well. Hey, a website is a database with an html front end with some javascript. You learn the technologies any way you can, you put your first site together. It isn't going to be fantastical, but after doing things in a sub-optimal way isn't a big freaking deal!! If you do it "the long way" the first time around, you can always do it better the second time around. My point is, there is no danger. Except this attitude, perhaps. This attitude is what will stop you from ever making anything, because you will always balk at the task and say "I don't know how to do that yet."

The attitude that there is a "right way" to do things. There isn't. Things are exactly as they seem. You have to put pixels on the screen, and make sounds when things happen.

• So true. This still holds me back a lot. Though I disagree somehow, in terms there are some more "right ways" to do, and a lot more "wrong ways", but perfectionism and analysis paralysis is certanly can be a problem. Great answer! May 4, 2012 at 5:17

Depending on whether or not you want to make this your profession later on (Im just going to assume you're thinking about it and this isnt just a hobby thing), here's what I found to be extremely effective:

1. Start small

It's been said before, but i'll say it again - start with small bits, familiarize yourself with an engine, a framework, a tool or program. Once you got the basics down -> go bigger.

1. Learn EVERYthing

This might seem a bit extreme, but what I mean is learn as much as you can about EVERY aspect of the game development - no matter whether or not you'Re a coder, artist or designer. Knowing the pipeline is key to building things in the most efficient way. If you're implementing a weapon -> design it, concept it, model it, implement it, code it! You obviously do not need to be a Grade A concept artist,designer and Pipeline nerd - but you should be familiar with all the tools of the process, and understand each step of the creation. Also, check out the game websites for news and updates in the business - gamasutra.com, kotaku etc all have great articles on both business and technique topics. Don't limit yourself to just one field of development - soak up ALL the knowledge you can get :)

1. Fail often, fail hard.

You'll suck at what you're doing. In the beginning. It's always like that (believe me, I know. :D), but it'll get only better if you keep on going and NEVER cease to look for ways to improve your work. The internet is a great source for tutorials,references and help. You'll never be truly stuck, so embarge on the craziest ideas, fail, learn from your mistakes and become more badass with that process.

1. Talk to people!

While the internet is a great source, getting face-to-face feedback is something you'll have to deal with on the job ALOT. So improving your soft skills is important as well. If you don't have a mentor yet, or in general dont know too many people working in the industry then you should look around your area for indie dev meet ups, go to conventions, and check for other events where you can start to build a personal network of knowledge and contacts. It also helps to build something with other people - self-taught is great, but game development is a team-based game, so check the forums for hobby project - for example the Epic Forum for UDK projects, Unity forums or even the CryEngine Forums -all three of those engines are widely spread, there's a truckload of talented people working on side-projects there, and they're mostly also keen on learning new stuff.

I think that's pretty much all the advice I can give. I hope this helped you in some way :)

• All your points are so important, they are #1 in this list! :) Sep 20, 2012 at 19:57

Somehow this is a great question! :-)

I've started my gamedev activity not so long ago, and it will be second time, so I can share my thoughts. You are actually right about that it's a good thing to have a mentor. This mentor will be the internet. So the more info is shared in internet, the easier it will be to learn for you. That's why XNA/C# is an excellent choice to start with. There is a lot of both amateur and professional indie gamedevs who is sharing articles and in the web. Other things to mention:

1. Go open source! Codeplex, GitHub, Google.Code, Bitbucket. There are a LOT of valuable things there.
2. Go to community! You are here, and it's a good thing. But also there is a large Microsoft XNA community with some good official stuff. Codeproject is also a good resource (however gamedev activity is rather low there).
3. You probably will need to read/watch a lot. Already mentioned before. Game development is not only coding. Game design is also important. Enthusiasm is important.
4. As usual don't try to bite to much at once, writing you own copy of tetris or breakout is actually a good idea.
5. It could be hard at start, game development is not only actually hard, it's also very different from say "enterprise" apps. There is a lot of new aspects, grapics, sound, etc. The more you go, the easier it gets (as usual).
7. Don't think your code is the worst thing you ever seen. Game code is harder to control, it's always somehow a little dirtier then whose pretty "enterprise" code. But I assure you, there I've seen some terrible creations (in terms of source code quality and game organisation) which were successful indie games. So, don't be to harsh on yourself, esp. at beginning.

I have no C# and XNA experience at all, but I think it won't make me wrong in the following statement:

It is perfectly fine to learn programming without a teacher. If your code works*, it doesn't really matter how it was coded. Well, it does for collaborative programming, but then you won't be coding alone anymore, will you? It also may make your code less readable for you in future, making it hard to use old components or debug new errors, but in the long run all your mistakes will be your strengths. Hardest thing in learning OOP and MVC design is understanding why I should do "this" in "that way". If you already have experience making bad programs you will know the strengths of patterns and use them to your advantage. If you always made good programs by following patterns someone taught you, then You will keep making good (in sense of valid code) programs, but instead of taking advantage of the patterns You will be limited by them, as You won't understand them enough to make useful modifications. In the end, it is most important that you practice, not how, so in both cases sooner or later You'll get quite similar experience.

*one thing is important though! In case of security You really should ask someone experienced if Your code is done well, as security holes don't popup error alerts.

This applies to about any discipline related to a creative industry:

The biggest danger is trying to build something 'too big' or 'epic' out of the gate.

For example, if you starting out at making some music you wouldn't start with trying to make a 50 piece 2 hour symphony.

In level design this manifests as trying to make the 'biggest map ever', or using the game system to build the largest most complex thing the game engine is capable of handling. In programming this can fall into 'making an entire game by yourself' starting with zero source code. You really need a lot of experience and discipline to start with zero source, and even then it is incredibly hard, and making design decisions over everything is hard the whole time you are working out the design of everything. Even a simplistic game requires a fairly large amount of programming in a modern OS and language these days. Also if you start with someone elses code you can learn what works and what doesn't work so well, so working with as many engines as possible is a huge plus as well.

So starting out I would recommend something like the following plans:

• Level Design: build a small room, build half a building, build a full building etc
• Art: make a hat for TF2 or something similary simple, or some texture replacements for Skyrim or some other bite size task to get started, before getting into skeletal or morph meshes and figuring out how to animate or paint them in zbrush them well.
• Programming: take an existing modable or opensource game engine, and modify some part of it (like a weapon), then make a new weapon. If you end up not liking the gameplay code, you could start hacking on the graphics engine.

The best thing to do would be to take an existing finished engine (either a modable one or some opensource one) and start hacking on it, and do that a few times to several different engines until you find one you like.