Hello folks.

I'm slowly working my way through learning a few skills and familiarizing myself with a number of software applications that, from what I can find, are necessary for a career in level design. My issue is that looking simply at the big picture, it is difficult to tell what is the most efficient order to learn each skill or application in. My hopes are that someone who is already in the field, or that knows there way around the applications might be able to share some wisdom or advice on what order to tackle these in and maybe add something I missing to my list.

My list is as follows;
1. Unity 3D - to build levels and games for use in a portfolio.
2. C# - for scripting within Unity and to work with XNA if I have the time.
3. Maya or 3DS Max - for creating assets to use within Unity. I have not decided on one as I haven't worked with either enough to understand the differences.
4. Photoshop or free alternative - for creating simple textures, you guessed it, to use in Unity
5. Figure and perspective drawing - To hopefully improve my skills with asset creation and level design.
6. Game play, fun, and all the stuff that really matters - Pretty much something I'm constantly working on amongst everything else.

Thanks for taking the time to look at my question, and I look forward to reading your answers.

All sounds reasonable, and I'm a big Unity fan but the best advice anyone could give you is this:

1) Make a game

And to be more specific, with your current level of skills (even if non existent), pick the absolute simplest possible game you can conceivably make, be ruthless about not adding any extra ideas and features, and do the whole thing from start to finish. It doesn't matter if it looks crap, plays badly, or even if it has bugs. The trick is to complete it.

From that experience will quickly emerge the areas you may want to work on. If you have any existing skills, use them, but don't let them become the focus. Identify the most basic things you need to do to get the game to "work" and do those (worry about looks, polish, etc etc later).

IMHO, level designers have to understand the game as though they had made the whole thing themselves, and by making your own game, even if incredibly simple, you start to hone the craft of identifying the simplest way of doing something, and the "art of the possible", e.g. using the bits at your disposal, however modest, to make a great playing game.

BTW, I currently divide the areas in a game into "Core, Decorative and Peripheral". I know when I'm working on something Core. Every area (including art) could be considered Core, but equally every area has a kind of built in iteration trap, where you endlessly fiddle with that bit, while never completing the game. Everything *should* be iterated, but it takes taking on a full project and committing yourself to completing it in a given timeframe to identify what is a useful iteration, and what is just wasting time.

Anyway, just some random thoughts- best of luck, and cool question- I'm also interested to hear other's answers.

@RunontheSpot

Thanks for the response. I've built one game I call 2X2, which is a simple text based puzzler where you solve puzzles within a room grid that is, yup, 2X2. It was a great learning experience, especially as it was the first thing I've ever programmed, ala C#. The issue is that to move into making games in a 2D or 3D space I'm going to need allot more skills and a higher level of fluency in 3D and 2D applications than I currently have. Taking what you said however, I guess I could focus on using Unity and working with the available Assets so I'm more focused on building games than learning software.

@Predator_UK Thank you as well. SO, I came up with my list using 2 methods. First, I read Tom Slopper's FAQs and looked at what goes into making a portfolio, which for level designers is basically games and mods. Second, I browsed mid and high level wanted adds on Gamasutra and looked at what skills various level design jobs required, unsurprisingly it was experience with Unreal or a similar engine and Maya or 3DS Max. With these two sources in mind I decided I have essentially three major goals; finish school, build a game or two for my portfolio, become fluent in UDK and Maya or 3DS Max. I did give UDK a shot, but found it really difficult in comparison to Unity, so decided to make my first stabs at game design in Unity. Coming from the audio world, I've developed a strong commitment to workflow and ease of use over how many features and bells and whistles a tool might have. I do plan to move back to UDK eventually, but only after I've gotten a little more comfortable with working in 3D and creating a game.

Now as to why my list is so exhaustive, I really don't know where I would like to work, as I don't have any experience within the game industry. My guess, from my previous work experience, is that I would prefer to work at a small company where I may need a wider variety of skills than I would in a specialized role at a big company. None the less, the idea is to be as attractive a candidate as possible to a big, small, or in between sized company when the time comes to find a job.

My issue is, that while I have 4-5 years before I finish school, I only have a small block of time, maybe an hour or two a day where I can actually work on learning software and making games, and I'd like to use this time as efficiently as possible. My goal is to try and focus my learning in such a way that I can remove any potential roadblocks and redundancies in my learning as I go. As an example I've been focusing on learning Unity, but I've recently found that without some scripting skills, what I can actually do is some what limited. Now that I know this I've decided to focus on learning C#, but I worry that by the time I get back around to working with Unity I'll have forgotten much of what I've all ready learned. I'd like to prevent these hold up as much as I can in the future.

EDIT: I apologize for the ridiculously long post.

I think you should stop worrying about what technologies you should learn, and start worrying about what skills an employer would look for in a candidate.

An employer probably isn't going to care whether you've written your own game from scratch, used Unity, UDK, XNA, etc. They are going to care about whether you have the core competencies for the job.

So you want to be a level designer. A level designer does not make art. A level designer doesn't write a game from scratch. A level designer uses a level editor to design a level, that's it.

You may have to do some scripting, but when you are scripting in Unity3D you are writing the game. You are creating a game from scratch. This is not what you'll do as a level designer.

I suggest you focus on modding existing games. Use the art that already exists, instead of learning Maya to make your own (or get an artist to help you make the mod). Use the game mechanics that already exist in the game, or script new ones, but don't write an entire game using a scripting interface as you'd do in Unity.

Most of the level designers I've known in the industry have come from other disciplines, but the one level designer I knew who was hired into the industry as such gained the company's attention by making a kick-ass mod of our game.

It seems as if you're trying to learn a broad set of skills. That is nice and all, but I would strongly suggest focusing in one area (art, programming, design, etc.).

The jack of all trades is the master of none.

You may have to do some scripting, but when you are scripting in Unity3D you are writing the game. You are creating a game from scratch. This is not what you'll do as a level designer.

Nor is it what I'm really interested in! I have no interest in creating new games or assets, but from the reading I did on Gamasutra, World of Level Design, and the Breaking In FAQs it seemed I really didn't have a choice.

Unfortunately, since I've just recently come into the world of PC games, I have no clue about modding. I'll take the advice I've gotten here and try to learn more about it, and focus my efforts on that area.

Also, you mention core competencies of the job, in your opinion what would those be?

I apologize for my confusion, as its been pretty difficult on finding information on just being a level designer. It seems most people are interested in using level design as a first step into game design and most the information I've found seems to be tailored to that perspective.



@Hardcharger I definitely want to focus on level design, but in most fields I've worked in it helps to have a fairly broad skill set relating to your specialization. For example, as a audio engineer I was more valuable to my clients because I could also troubleshoot electronics and computers.

The job I have now is definitely a jack of all trades job, because on any given day I can be setting up a phone system, running wire for a T1 extension, troubleshooting a Cisco router or, as i have to do in a few hours, train some one on their ATM system.

Some jobs require a broad knowledge of skills, while some require a more narrow specialization. My research led me to believe that level design was more the former than the latter, but apparently thats not the case.


Thanks again to everyone for all the useful information, I really appreciate it.

In my experience (which isn't super broad), a "level designer" is usually a lower-level designer. A higher-level designer is one who has the luxury of dealing mostly in high-level conceptual design. A lower-level designer is more "in the trenches", actually piecing together the game.

So I think you might want to focus on what the core competencies for a designer are. I may not be the best person to give advice on this, since I've never designed a game and honestly I can't even come up with decently original game ideas, but in my experience working with designers, here's what defines a good one:

• Is a good communicator. That includes both concrete skills like grammar as well as the (possibly unteachable) ability to communicate know how to communicate the right information given one's audience. When a designer describes his concept to an artist, he or she will use different terminology than when describing his concept to a programmer, or to publisher, the public, etc. This means knowing about the various disciplines, what constraints they deal with, what they're capable of, etc. It doesn't mean knowing how to use Maya or how to program.
• Is creative. Can generate new ideas and examine them for feasibility and fun-factor. Can think outside the box. Can take existing ideas and incorporate them with one's own ideas. Has the restraint to limit one's creativity and knowing when to use "tried and true" ideas.
• Has a broad knowledge-base from which to draw ideas from. Many of the designers I've known have been huge history buffs. Many have in-depth knowledge of the history of games. They know which ones they think are good or bad and why. They know about the games that are coming out, what makes them unique, etc.
• Has a good sense of balance. Don't buy a balance beam, I mean gameplay balance. Balance is more important in some game types than others, but many designers spend a lot of their time balancing gameplay. Are some unit types too powerful, is some boss too hard, is some level too long, etc.
• Can put himself in the player's shoes. It's hard to know how a game is going to feel or appear to a player when you've been staring at it for months. It's very important to be able to figure out where players will get frustrated, what parts will be most fun to what types of players, etc.

That's all I can think of right now. You're probably thinking it all sounds pretty wishy-washy, you'd probably like a more concrete answer to exactly what you should learn. It's the nature of the beast though. It's hard to describe what makes a good designer just like it's hard to describe what makes a good writer. It varies and depends on who you ask, it's all gray-area. This is one big reason that it's still not super common for someone to be hired as a designer without some other kind of game industry experience. As you'll hear elsewhere, lots of people get started in QA or other disciplines. I've witnessed this pattern myself.

I think your best bet is to make some really awesome and innovative game or level using modding tools. If you can convince some artists and programmers to write a game that you design, then that's all fine and dandy, but most indie projects fail and end up as 300 lines of sloppy code that do nothing, two half-rigged crappy models, and a load of (amazing and game-changing, if you ask the "designer") ideas that never see fruition.

You might want to look into Little Big Planet 2, people are designing some really amazing games using that toolset.

If you had created Narbacular Drop (the innovative game which Portal was based on), you could show that and potentially get hired as a game designer. So create something great.

You can't just jump straight into game programming, and generally you don't need to know a thing about game programming to be a level designer.

However, if you were to still want to learn game programming, the first thing you need to learn is programming.

I believe that the best way to learn programming is to start with something simple. Do some web development in PHP or ASP or something. Heck, you could do this to make a website for your portfolio in the future!
Web development teaches you the fundamentals while making it very easy to do things that can otherwise be complex -- for example, making a GUI (graphical user interface, if you're that new to this stuff) for whatever you're building. It also lets you brush up on web/UI design while you're at it, which is a plus.

The next logical step is to learn more serious programming. I recommend starting with a high level C-syntax language for this, C# is a good choice here. C# will bring you up to speed with many of the more complex issues of programming, without forcing you to stress things like memory management that lower level languages would. I don't recommend Java or Flash here, unless you intend to target web browser apps. C# should be a good starting point, though.

The third step is to make an actual game. This should be a simple 2D game like clones of Tetris, Snake, or Pac-Man. 3D games are very complex, and so are most "modern" game types. These simple puzzle-oriented games are the best for learning the basics. Since you're already familiar with C#, you could probably just use XNA. Or you could switch to C++ and use a library like SDL or SFML that provide easy-to-use 2D graphics APIs, but then you're in the realm of few exceptions and many errors.

At that point, for your purposes, you should be pretty much good to go. Browsing the source code of the game you're developing for should fill you in on anything you're missing. However, if you decide you'd rather take the programming route at this point, the only thing you have to do is keep programming.