# Question
Title: Game Development Degree vs Computer Science Degree
I'm at the point in my life where I'm starting to look at schools, and was hearing a lot of mixed things about schools such as Digipen or Fullsail that target game development specifically. As someone who is planning on becoming a programmer and getting into the games industry, would getting a game development degree be better than a traditional computer science degree?

# Answer
> 92 votes
Schooling isn't going to get you a job.

If you're good at what you do, and you care about it, you don't need a degree.

A game-focused degree is good at helping you getting your foot in the door since a lot of those schools have teachers or advisors who are actually in the industry. It'll also help you by providing you useful team experience.

Also, and this is very important, a Computer Science degree *is not* about programming. You might have a class here and there that might be useful, but the degree as a whole is not about good programming practices or really anything pragmatic that you would need on a day to day basis. (Note: this may vary based on your school.)

That being said, getting a CS degree usually implies going to a non-game-focused school, which also implies getting a more well rounded education, which might pay off int the end. Also a lot of regular schools have game development programs these days which could get you some connections to the local industry.

At least in my experience, getting a certificate from one of these game development colleges is almost worthless on its own. Unless you have side projects or have some kind of way of proving that you care about whatever field you're interested in other than just going to school, you'll be going in the "maybe someday I'll get around to these people" pile of resumes (hint: I won't).

*Edit*: since I really didn't answer the question, basically my opinion is this:

If you have the motivation to work on games in your spare time, do that and get a traditional education. It'll pay off in more ways than if you just went to more of a niche school.

If you're the kind of person that works better when somebody is telling them to do something, or if you need to feel like your money is on the line, try to go for a game dev school instead.

If your sole focus in life is to get into the game industry (it shouldn't be), and you're smart and motivated enough, try taking a year and working on things in your spare time (mods, solo projects, demos, whatever) and bypassing both options.

# Answer
> 48 votes
I see there's already an accepted answer, but I thought I'd throw in my two cents, because I disagree with the top-rated answers and I actually do evaluate and hire applicants for programming positions. (Not to imply that others don't! Just that it's something I spend a fair amount of time thinking about..)

First, I agree with Tetrad that if you're passionate and good at what you do, you don't *need* a degree. I left school shortly before finishing, myself. But having a Computer Science degree definitely is a big plus for any candidate. Tetrad mentions that computer science programs are not about programming. That's true to a point, but that's like saying that going to school for carpentry isn't just about swinging hammers. Looking at it that way, I'm not just looking to hire *programmers*, I'm looking to hire *engineers*. I want you to be able to not just write code, but to create well-built systems. A comp sci degree will help you out a lot in that way.

To address the question of whether a game development degree or a comp sci degree is better, I generally prefer to see comp sci degrees, myself. It depends on the program, however - I've heard good things about RPI's program, as coderanger mentioned. But several designers I've worked with have gone for the general "game development" degrees that teach a hybrid of design and programming, and after talking to them, I'm wary of how in-depth the programming portions of those programs are. Then again, applicants coming from those schools tend to have demos or other examples of their work, whereas people coming from comp sci degrees often don't - being able to look at someone's code is a big bonus.

I realize I haven't directly answered your question, but I hope that helps you with your decision.

# Answer
> 13 votes
My only concern with getting a gaming-specific degree is that it might hinder you from getting out of the industry and into another programming field if you ever had the need to (bad gaming economy, given the choice to re-locate or lose your job/get another programming job in the area, etc.). A computer science degree is more generic and well rounded and should let you be able to get into about any field of programming. You're most likely going to have job training no matter where you end up anyways.

# Answer
> 10 votes
Having a good general software engineering background is always the best way to go. I was one of the first students through RPI's game studies program (as a minor, major was still CS) and I would say I have gotten about 10x the practical value out of the non-game-related classes. As Tetrad says, the bigger issue is if you are a good programmer regardless of degrees or titles. I think at one point about 1/3 of our software team here didn't have a university degree. At least with RPI's game development classes it was mostly an excuse to get more experience building games which I probably would have done in my spare time anyway. A good, formal game design class is definitely worth looking in to though, mostly so you know more of the terminology used in the industry ("MDA", "system dynamics", "prisoner's dilemma", etc). Few schools offer a good software engineering program, so CS/Games might be the best you can do, but be sure to pay attention to things like OS and network programming too or it will most surely come back to bite you.

# Answer
> 6 votes
Both have tradeoffs. Short answer: the trade school can make you marginally more relevant to the game industry, but marginally less relevant to the rest of the world. Since the average career length of a game developer is 5.5 years (we looooves our burnout), going trade school only is essentially a life commitment to the game industry (unless you're prepared to go back for a more conventional undergrad later).

There have been a lot of writings on this subject. My favorite:

http://www.sloperama.com/advice/lesson44.htm \- and really, everything else on Tom Sloper's site. He writes in a no-nonsense style and is not afraid to be very clear about the up and down sides of the industry.

http://www.gamecareerguide.com/features/298/choosing\_a\_.php \- and really, everything else on GameCareerGuide. This is the whole POINT of the site, as a resource guide for people looking to enter the industry.

And really, type "choosing a game school" into Google and you'll find more advice than you can possibly read before matriculation :)

# Answer
> 6 votes
Although there is already an accepted answer, I chose to write this answer to expound upon some of the previously discussed points, as well as address a few errors I noticed in other answers.

## Accreditation

First and foremost, there are two kinds of accreditation in the United States:

* **Regional** \- This is the process traditional colleges and universities go through
* **National** \- This is the process specialty and vocational school go through

There's a lot of information out there that goes into detail about the different processes, but here is what you need to know:

* If you get a degree at a nationally accredited school, you can pursue a degree at regionally accredited institution (and vice versa).
* If, for whatever reason, you decide to transfer from a nationally accredited school to any other school (nationally or regionally accredited), **before you have your degree**, the new school **does not** have to accept **any** of your credits.

## What to look for in an institution/degree

There are a ton of schools out there that offer game development education (traditional and specialty), and a lot of them aren't worth 2 cents. Be sure to do your research and learn as much as you can about a school before committing to it.

* **Degree or Certificate?** \- When you graduate, will you get a degree or certificate?
* **Professors** \- What are their backgrounds? Do they seem qualified to teach the subjects in their curriculum?
* **Curriculum** \- Are the majority of the courses based on theory or application? Specifically look for courses that teach software architecture, rendering (Direct X or OpenGL), artificial intelligence, calculus, and trigonometry
* **Students** \- How many students find jobs? What companies? Ask to see sample projects completed by students, and examples of what those students contributed to the finished product.
* **Industry** \- Does the school seem connected to the industry? Are there game/software/simulation companies in the area? Do guest speakers visit the school? Is there a local IGDA chapter?

## General tips

* **Experience is more important than formal education** \- In this industry, talent is everything, that is why it is important to...
* **Work on games outside of school** \- It doesn't matter if you're going to a traditional or specialty school (or what kind of degree you're pursuing), you should make a **serious** effort to work on game projects in your spare time.
* **Network, network, network!**

If you have an questions, or would like me to clarify any of the points made, feel free to leave a comment. :)

# Answer
> 5 votes
There is a difference between game design and game programming. Now, a lot of game companies use different API's, so having the skills to adjust to a new coding environment is a great skill to have, or you'll be very sorry.

I have seen programs that also teach you a specific set of tools and resources. This specification is great for a while.

As a *programmer* for the industry its better to just get a CS degree. And, you'll learn design by simply being in the industry and perhaps work up to the position of being designer if you are also *creative*. However, A lot of leading game designers have degrees from finance to mechanical engineering. So, it doesn't really matter too much what degree you really get, but by the end of the day buddy its really rare to be a lead designer without working up, and landing a programming job with a solid CS background is definitely the best way to go.

The bottom line: A CS degree will help in the game field. Most of the time you are working with middle wear or editing components. By the end of the day you probably never realized you worked on a game!

# Answer
> 5 votes
Something nobody has mentioned yet, which I'd like to add, is ***networking***. No, not the thing you do with Cat-5 cable, the whole "interacting with people" thing.

The traditional degree is arguably "better" than the game development school degree.

But you will miss out on a *huge* opportunity to network with other people who are in, have been in, or want to get into the industry. People who would otherwise become friends, mentors, co-workers, co-founders, employers, employees, etc.

So if you do go for a traditional degree, you have to be prepared to miss out on that, and try to compensate for it as best you can.

# Answer
> 5 votes
Here's the pros for each side as far as I know:

**CS Degree:**

* You'll get a broader education and meet a wider variety of people. This is probably more important than you realize.
* You'll have the opportunity to change majors more drastically if you discover a new passion.
* It's likely much cheaper.
* Your degree will be useful outside of games. The odds of you spending your entire career in the game industry are *very* slim.

**Game school degree:**

* You'll get more hands-on experience with game tech.
* You'll be around other people that want to do exactly what you want.
* You'll (hopefully) get some industry connections.
* You'll learn more practical game-oriented stuff. (But keep in mind that what you're learning here has a painfully short expiration date.)

I would *strongly* discourage you from going to Full Sail. I worked in the game industry in Orlando for eight years and I can count the number of Full Sail grads we hired on one hand. It's fantastically expensive and is very unlikely to be worth your money.

# Answer
> 3 votes
If you go for a Game Development Degree just know they don't hold much steam in normal programming positions. Having said that, Digipen is probably the best program you could do. They have very good relations with Valve and their student projects have won multiple IGF awards yearly.

From Digipen students I have talked to they are very hard core game programming from the very beginning with industry focused skills like C++, OpenGL, and DirectX.

If on the other hand you decide you want a more general Computer Science degree it will prepare you for general programming which is definitely not enough to land a good job as a games programmer. Even worse a lot of schools are trending toward teaching Java as their language of choice.

Joel on Software - The Perils of JavaSchools

If you ever want to blow an interview or any chance at a game programming job, just say your primarily a Java programmer.

I'm not trying to say it's impossible to land a good job as a game programmer with a CS degree but sadly a CS degree will be the least impressive thing on your resume.

Having said all of that, a CS degree definitely won't hurt. Just expect to be spending every spare moment working on side projects and creating an awesome portfolio. Those two things will land you your job. The CS degree is more of a safety net in case you end up not liking 100+ hr crunch times which last for 6 month periods =) *(that's a bit extreme but not that uncommon)*

# Answer
> 3 votes
Everyone you will be competing against for jobs knows something about making games. You need to think about what kind of value you bring to the table that is not about making games. Whether that's a strong knowledge of computer science or software engineering, Expressionism, classical antiquity, French cooking, or cognitive psychology is up to you. Game companies have more than enough people that know games - know games, but know something else too, because that's how you're going to surprise people and make something that stands out.

# Answer
> 3 votes
Working for one of the major console companies I can attest to the fact that HR will most of the time automatically filter people without degree's before sending the CVs to the managers. Something to keep in mind.

In terms of degree choice, currently people doing Game Courses are generally looked "down upon" compared to CS courses. This isn't fair, and certainly isn't a reflection of what the Game Courses teach. But as they are relatively new and most people hiring wouldn't have had the choice, so still believe in a strong CS background. Of course, ymmv.

If you are sure you want to get into the games industry as a programmer, than the best advice I can give to you is to do a joint CS + Math degree (if you have the ability). It will facilitate (in my experience) a job as a graduate much quicker.

# Answer
> 2 votes
From my personal experience in a game design education, what really matters isn't the specific degree, but your dedication to learning and improving your programming skills and demonstrating your talents. I've met a lot of people with degrees not specifically game deign oriented like fine arts, networking, and computer science, who apply them in the industry. I say find a school that teaches you what you'd like to learn, then apply those skills to making a game by yourself or with friends. It will demonstrate your technical skills along with passion for video games.

# Answer
> 2 votes
Major in Computer Science, with a specialization in Game Development... UC Irvine has such a program, if you have the grades and SAT scores for UCI, go for it. Also UCI is located in southern california, where so many top game dev companies are... which helps a lot in landing a great job in the field.

# Answer
> 2 votes
**Do a computer science degree.** If the course is worth its salt you'll be well-qualified for a job in the games industry and if the worst comes to the worst and you don't manage to get a job in the games industry (or decide it's not for you - I know plenty of people who've changed their minds about their career between starting and finishing their degree) you'll *also* be well-qualified for a multitude of other jobs. The same cannot be said about a specific games programming degree.

There are a lot of things you can do that will increase your job prospects a lot more than doing a specific degree. One of the biggest things I look for when I'm recruiting programmers (admittedly not for the computer games industry) is evidence of a passion for the subject. Students who turn up to most lectures, do the coursework and get reasonable marks in the exam are ten a penny. The really good candidates are those who've done something extra, like working on a personal project in their spare time, going out and getting work experience in the holidays and just generally putting in more than minimal effort.

Do a computer science degree, but keep working on game-related stuff in your spare time. Pester local (and remote!) game companies for work experience in the university holidays (the worst they can say is no). Work on a small game that you enhance over the years - you may even be able to get some university use out of it for your dissertation. If you then go to a games company looking for a job, and can show them the game that you built up on your own, the technologies you taught yourself to make it, the fact that you spent three months doing unit tests for game company X instead of having a summer holiday *as well as* knowing all the fundamentals from a computer science degree, they'll be a lot more interested in hiring you than if you just freewheeled through a games development degree. (Who knows - game company X might have really liked you from your unit testing, and feel you're ready to do some full-time programming for them.)

# Answer
> 2 votes
It all depends on what you want to do in the long run. Do you want to be a programmer or a designer? Do you actually want to start a company yourself? Is there a type of company you want to work for?

I'll guess that you want to be a programmer, that way this post won't be 10 pages long.

If your focus is game programming, go for the CS degree. Then on your own, apply it to game programming (side projects for example). A "Game Design" or "Game Design and Development" program will not be focused enough on actual programming.

Also know that there is a difference between learning "programming" and learning "computer science". CS is more about computational thinking, problem solving, logic, and even a bit of philosophy. And keep this in mind:

*Computer science is no more about computers than astronomy is about telescopes.* --Edsger Dijkstra

If you plan to start your own company, and focus on programming, i'd still suggest CS, but with either a minor in business, or business as a second degree altogether.

Now, if you are already a strong programmer(and/or computer scientest) and have some money to blow (or plan on starting a successful company, \[and have already researched enough on how to do that\]), then you can look into a school like Full-Sail to acquire more focused skills.

# Answer
> 1 votes
If you can find a degree like the one at Digipen where you learn to build games from the bottom-up in C++, I would recommend taking it. To have a shot in the traditional gamedev world you need to know C++ really well, but if games are your passion and your life, you may get bored on a non-gaming degree and potentially drop-out - I know I would! Especially CS, where you barely learn to program. Any employer that would hire a CS graduate over a more highly skilled programmer from a gaming degree isn't worth working for.

Of course, if want to sidestep the traditional games career path entirely you could just get a copy of Unity or Flash and start making games. In the indie world qualifications are worth nothing and talent is everything!

# Answer
> 1 votes
I think it massively depends on the quality of the course - in either case. A 'generic' CS degree that covers a wide range of topics and disciplines is infinitely more valuable than a 'games programming' course that teaches you about XNA. Whereas a games development course that focuses on computer science with additional modules in games programming (fundamentals of graphics, writing high performance code etc) would be an excellent choice.

To be honest you are more likely to get hired by what you taught yourself outside of the course than what you learned on it. Most companies require some kind of demo, if it isn't flashy enough you won't be noticed. I haven't yet found a company that hires people without experience and without a degree - it is pretty much required for someone to even look at your CV.

Getting into the games industry is brutally hard when you have no experience. You either have to be miles ahead of the pack, have the contacts or just darn lucky (or in most cases all three). Because of this, many people just don't make it in. For this reason, I would suggest making sure your degree is equally value to those outside the industry.

While you are at university though, learn how to code in your spare time. Write some simple games in XNA, learn about shaders and **LEARN C++**.

You will not get a job in professional games development without C++ unless you are very lucky. Where I work the single most important skill a programmer needs after good communication skills and general aptitude is C++. We don't use XNA, DirectX or OpenGL - most places have their own APIs, libraries or use toolchains like UE3 so these are irrelevant in anything but learning the concepts.

Also network like crazy with people in the industry - see if there are any studios near you, speak to friends of friends, try and get an internship, strike up a rapport with someone important there - anything to get someone on the inside to know your name.

# Answer
> 0 votes
**Get the CS Degree** is what my reaction tells me.

If you really want to game develop, you'll be doing your small projects during your education. When you're finished you've got an extremely robust education that will function as a CV booster and competence base you can build on. And one day if you don't want to game develop anymore you've probably got a wider spectrum of possible careers with the CS degree.

But in the end, it depends more on you as a person than on your degree. If you can convince your employer that you're good enough it won't matter much what degree you have. Unless the company needs to brag to their clients about how many degrees their employees have (which is actually the case with some consultant companies at least).

Don't forget about the possibility to make it as an entrepreneur. It is hard but it can pay itself.

# Answer
> 0 votes
If anything I would go for a computer science degree; I'm doing it myself. But I am also pursuing a **game development concentration**. Whatever school you are planning to attend, you may want to investigate if they have this option; I highly recommend it! I will graduate with a computer science degree and all the same courses as any other CS major, so if I choose not to enter the game industry I still have all the education of anyone else with a CS degree. But I am also taking some game-related courses, which give me focused knowledge in game development.

For example I am currently enrolled in a general game development course which is taught by the president and CTO of a local game company, so I'm gaining a lot of practical and real-world knowledge from him (as opposed to some other CS courses which can go deep into theory at times). But I'm also taking a course in software engineering, in which I am practicing Java and proper software engineering methods which apply to all areas of computer science.

At the very least, **do your research** about the school you're planning on attending. Find out who the professors are and look them up; do they know their stuff? Are they in the industry or have connections? Are they IGDA members? Look at the list of courses and see if it appeals to you. Check out the area around the school and see if there are any game companies. All of these factors play a big part in figuring out whether the school has a genuinely great game development degree/concentration, or if it's just a gimmick because game development is the latest "cool" thing.

# Answer
> 0 votes
I would recommend going through a CS, Software Engineering or similar program. Back in university, we had game companies like EA who came about twice per year to recruit coops and new grads. The school didn't provide any game degrees at that time and they were targeting CS and Soft Eng students.

There are some courses in university like Computer Graphics which you can take to create basic games, ray tracers and other graphical projects from scratch. Do extremely well in those projects and you can use them as a portfolio to sell yourself to game companies.

If you manage to get in the game industry and not enjoy it, you can always count on your CS or Soft Eng degree to find other development jobs in different fields.

# Answer
> 0 votes
The problem with computer sciences, and especially with learning how to program, is that it is an applied science: the theory doesn't lead to a lot of applications...

You can learn theory about maths without doing a lot of exercises, but there are no way you can be good at programming without coding: all the problem is about getting something to program so you can train, and that, the gamedev school will give you.

Programming will earn you money because you solve problem and create applications: the theory is easy, but the technique and practice to achieve work is harder to obtain...

CS is good to learn the basics, but NOTHING replaces DOING something.

Either go to the gamedev school or find a good project to do, but the latter choice is risky...

# Answer
> 0 votes
My take is to look for a traditional 4-year college that has a game development division of it computer science or computer engineering division. Maybe it just has a professor that's in the industry. Maybe you could do a thesis or independent study in game design. Your best bet will be to do a lot of research like this into some 4year schools that you have the grades to get into - you want to see if they have a backdoor/side door into game development.

# Answer
> 0 votes
I faced the same question a few years ago and chose to do games development. I think there is a lot of confusion here on what a games development degree involves. For my course and most games courses the title is similar to "Computing with games development" which as the name suggests means you major in computer science and minor in games development. In my course this meant 1 to two(max) modules a semester for games development. I did exactly the same degree as my friends in the "Computing with software development" and "Computer Science" courses with the exception of those one or two modules (usually is was only one games module).

When we did our FYP's or other major projects I *had* to do a project relating to games development but the software development class could do anything software related including a games project and the computer science class could do ANYTHING computer related. So even if you choose to do CS it doesn't mean you can't continue to learn games development using what you know from CS.

The reason the courses are designed like this is to give everyone regardless of course a good general degree in computing. I have met people in courses absolutely specific to games design and their employment opportunities are significantly reduced because of this.

From my experience, because I didn't do a games intensive degree I wasn't ready to go straight from graduation to a games development job but I have been able to get a job as a software engineer, if I want to get into the games development industry I just need to get working on some side projects to build up a portfolio (honestly though, I would wager that with a bit of luck I could bag an entry level job at a games company). The experience of working at a software development company will help me get that first games job and in the mean time I'm learning a lot about general software development.

My advice, if you choose to do a games course, make sure it isn't absolutely specific to games development, courses that will enable you to work in an industry other than just games will be much more beneficial.

# Answer
> -1 votes
Full Sail is accredited by a different accreditation board than traditional universities. This means that credits earned at Full Sail will not transfer to traditional universities. So, if you want to get a MS or PhD, you'll have to start from scratch.

# Answer
> -1 votes
If anything I would go for a computer science degree; I'm doing it myself. But I am also pursuing a **game development concentration**. Whatever school you are planning to attend, you may want to investigate if they have this option; I highly recommend it! I will graduate with a computer science degree and all the same courses as any other CS major, so if I choose not to enter the game industry I still have all the education of anyone else with a CS degree. But I am also taking some game-related courses, which give me focused knowledge in game development.

For example I am currently enrolled in a general game development course which is taught by the president and CTO of a local game company, so I'm gaining a lot of practical and real-world knowledge from him (as opposed to some other CS courses which can go deep into theory at times). But I'm also taking a course in software engineering, in which I am practicing Java and proper software engineering methods which apply to all areas of computer science.

At the very least, **do your research** about the school you're planning on attending. Find out who the professors are and look them up; do they know their stuff? Are they in the industry or have connections? Are they IGDA members? Look at the list of courses and see if it appeals to you. Check out the area around the school and see if there are any game companies. All of these factors play a big part in figuring out whether the school has a genuinely great game development degree/concentration, or if it's just a gimmick because game development is the latest "cool" thing.

---
Tags: education
---


title: Alternative to pyGame?

text:
# Question
Title: Alternative to pyGame?
i'm learning something about game programming from a book about "pyGame". pyGame is simple, but... python is a little complex and different from my previous knoweledge about programming.

I know "classical" language: C# (also C/C++), Java ... I know a lot of people love Python but for me is a little harder to learn!

So I'm looking something like "pyGame" but for java or for c# ... A library with which I can do almost the same thing i can do with pygame (so .. do more with less code ... and headache).

# Answer
> 7 votes
Love offers a similar level of complexity as PyGame, though I'm not sure you will find Lua much easier than Python. If you want to just go with something more direct, look for bindings for SDL (SDL.NET for example) for your favorite language, or even just use it directly in C. Many PyGame APIs are just thin wrappers for SDL functionality.

# Answer
> 4 votes
I'm not familiar with pyGame but if you're looking for a nice easy framework to use for game development why not use XNA 4.0? It's free and lets you create games that can be played on the XBox 360, Zune HD or Windows Phone 7.

The benefit of using this is you can very easily leverage your C# knowledge and start working right away with learning the framework instead of wrestling with the language.

I **highly** suggest you start learning XNA by following this great series of tutorials made by Riemers.

# Answer
> 3 votes
http://wiki.python.org/moin/PythonGames has the list of python game engines/libraries. Some of the game engines in the list are not Python only. Ogre and Panda are well known ones in both you can use c++.

# Answer
> 2 votes
Ctrl+C Ctrl+V from another question I posted on

> **Slick** is a nice 2D Java library based off of LWJGL. It handles the game loop, rendering, and contains useful functionality to implement sprites.
>
> It comes bundled with many different demos and examples.

Things like tilemaps, sprite sheets, etc are all built in. Basically lets you focus on the game, not how to write an engine.

# Answer
> 1 votes
If you know C, I'd recommend Allegro, game programming library. That's what I used when I was getting into game dev, and it served me well back then. It has similar capabilities to SDL, but for me it was always simpler, and more straightforward. They even say on the website that there are bindings for C#, but I have no idea how those work.

http://www.talula.demon.co.uk/allegro/

Also, I find it very weird, that you say you know C++ but can't learn Python. Python is way simpler and easier to use than C++.

# Answer
> 1 votes
Honestly I don't think anything can do better than pygame: SDL is simple enough, so it's a good choice. Python, when thinking about programmer-friendliness, is like the best language ever. I don't think you can do much better than pygame.

# Answer
> 0 votes
SDL is made with c and is perhaps the most popular game programming library. Also I think I did read somewhere that pyGame is based on it.

http://www.libsdl.org/

# Answer
> 0 votes
* angel-engine is for simple prototyping but is pretty complete.
* panda 3d is a full fledged 3d engine with commercial games using it, but has a relatively simple python interface if you don't want to get fancy (just look at the simplest examples).

Both are well documented.

---
Tags: python, pygame
---


# Question
Title: In general, are programmers or artists paid better?
I'm in a private game programming school where there also are 3D art classes; sadly, there seems to be a lot more students in those latter classes, something like 50% or 100% more.

So I was wondering: in the real video game industry, which of the artist/modeler or the programmer is more likely to be wanted in a company, so who will be paid more ?

I'm sure there are artists which are obviously paid better than other programmers and I'm sure there are other sorts of jobs in the game industry (sound, management, testers), but I wanted to know if there is a general tendency for one or the other. And sometime I wonder even if an artist can happen to write scripts...

# Answer
Every year, Game Developer Magazine puts together a report of average salaries and other metrics concerning game development budgets, remuneration, and hiring.

You can buy the full 2005-2010 report, although it is quite expensive, since it's targeted at research institutions. A cheaper option would be to buy the summary in the April 2010 magazine for $4, or the summarized summary on Gamasutra's website, for $0. (However, to compare entry-level versus mean, you'll need to get at least the $4 version.)

> * Programming: Programmers are among the highest paid talent in the mainstream game industry, with an average annual salary of $80,320. Experience pays in this technical role, particularly when jobs are more rare--programmers with more than six years of experience earned an incredible 36% more than the average annual salary in 2009.
> * Art & Animation: Unlike those in most disciplines, artists saw a slight average salary increase this year to $71,071, up a modest 2% as more artists reported pay increases than those in any other creative field.
> 14 votes

# Answer
It's true, programmers tend to be better paid. (I'm a game artist that worked for 4 game companies) .But I highly disagree with above poster. We're talking about a professional programmer and so, also about a professional artist. Ok, then just drawing well requires a ton of years. I mean, just draw correctly with good anatomy and proportions, solid perspective, good control of lighting, composition, etc. This requires a career, usually(and many extra years on your own, and even so, many don't reach the level). Be it Fine Arts, or what is being done in USA and Canada, special institutes to prepare ppl to do concept art and have the needed base for modeling characters of the high realism you see in any high end game. (millions of polygons for detail is not all, there's needed a lot of knowledge and techniques behind, that all is hyper realistic, does not come free, and only a few artists get it right)

Let alone the fact that the "modelling software" training is huge in years. Master Uv Mapping, high end modeling, texturing, shaders, GUI work, pixel art, etc,etc. (I'm proficient in all this) Animation in its own is a very hard career, and I can tell how few *good* animators are out there, that can animate really well, at the needed quality.

But it always keeps floating this wrong concept saying that salaries are ok so because programing (extremely hard, too) is harder. I have known of the years and preparation needed of way too many staff mates, and man, compared with my close to 30 years of real preparation, is at least, on pair...

IMHO is just a market reason, a matter of how many are out there, and certain historical reasons.

Edit: And btw, you mention musicians, they are even paid worse than artists. And again, is not a matter of they had *less* preparation. Again, is market reasons, number of ppl into it, etc. And to your question: "And sometime I wonder even if an artist can happen to write scripts..." I am a game artist, today a corporate designer, and yep, I have coded scripts, VB, html/css, some action script, some python... A practical advice would be: become a programmer, as the market needs more them, as there might be fewer programmers into games (and yes, an incredible amount of knowledge is required).
> 3 votes

# Answer
Game career guide has a free publication stating average salaries in different divisions of game dev companies. It confirms what's been said: programmers are paid more in general.
> 3 votes

# Answer
I agree with most of the above posters, that programmers are paid higher(generally, the quality of work would make a huge difference) But I also find artist have an easier time picking up small jobs outside of work.
> 3 votes

# Answer
Generally a lot more people wants to be graphics artists, so there's a whole lot more competition and the wages (around here) are way below programmer wages, likely for that reason.

Not that any of the two would be more demanding or would take longer to master than the other though, it's just a matter of high/low demand and many graphics artists are so dedicated to their calling that they will enter the industry at very low wages. Programmers (again here) get to cherry pick employers because there aren't enough (regardless of their skill level).

If you're a content creator or animator, scripting will be a natural part of your toolset. Just about any work done with computers require scripting at some level, salary men use VBA in Excel and so on ;)
> 1 votes

# Answer
In general, programming is the higher paid of the two disciplines - starting wages for artists are almost always below those of coders.
> 0 votes

---
Tags: game-industry, hiring, human-resources
---


title: Should I formally study to make games?

text:
# Question
Title: Should I formally study to make games?
I don't have formal studies in programming nor in graphic design, I'm self-taught, you know I have learned some things here and there. So far have been doing amateur stuff, sort of hobbyist. I would like at some point of my life be doing professional games, don't know if that would mean acquiring formal knowledge at some gaming college. It is something even desirable or advisable?

# Answer
If you think you'd enjoy making games then go for it! It's always best to do what makes you happy. But really, there are two routes you could take. You could take a generalised course that included computer programming for example a computer science course. Then maybe learn game programming afterwards. That way, if the game programming career falls through, you have other options.

If you look at the money some of the recent games made especially with the financial recession, then I suppose it would be an advisable career. Notch's minecraft game is a good example. He did that near enough on his own and he now has nearly 1 million paying customers. It pays off if you hit a niche. It all comes down to luck like a lot of things in life.

So definitely just go with it if you think you'll enjoy it.
> 3 votes

# Answer
When thinking about C/C++ (because these are the industrial standard languages), I learned most of C by myself, but I admit that school helped a lot for C++: C++ is really a fat subject when used for game programming, but that doesn't necessarily mean I couldn't learn things by myself; school is a very efficient shortcut, but like every shortcut, it's harder and can cost money, and even worst, sometimes you might feel you are learning nothing.

Don't forget there are 2 sides for being a game developer; first you have to be able to use C++ fluently, and not just classes and virtual function: also the basic STL containers. Secondly, since game programming is all about code and nothing else, you have to learn about design patterns, but often that might not be enough.

I'm sure you could do some Ogre programming for example if you have some project in mind and time to spare. Don't forget that it's much much better to learn something new to solve a problem when you explicitly know what it's for: learning the theory while practicing is more logical because you have a concrete example which makes it better to remind you what it's for. It's more reassuring than school.

On the other hand, you have to have a pretty good amount of free time and self-confidence, because at school you have help not only from teachers but also from students, but don't forget that there's also pretty good help on forums and IRC channels.

To answer your question, I'd say it mainly depends on what you need to learn, since the basics are quite important, but it also depends on your curiosity and how autonomous you can be.

I have taken the opportunity to get into a private school because I had funds at the moment, I don't know if I would have risked to make a loan for that. On the other hand I met people, which is an important thing, but that won't change the way I conceive programming and how I like to learn things: most of what I see are people unable to seek the information for themselves and are too much used to being teach planned things rather than asking questions or asking themselves questions, after to watch them complain about the program.

I guess the answer would have been very much different would you have asked it 10 or 15 years ago, but nowadays multi-core processors and giga-powerful consoles require a game programmer to be able to get hold of bigger data structures and algorithms and design patterns etc etc.

Of course I'm not talking about hobbyist/low-project game programming, which can be done with unity for example, but more about professional/know-how-it-s-done/from-scratch game programming, which gives you a lot more.
> 1 votes

# Answer
Straight answer: it is **very** advisable. I'll explain you what I've learned, and hope it helps.

Formal studies always help when you want to take things to the professional level. However, the entertainment industry is very big and there is an advantage/disadvantage when it comes to media: everything comes down to portfolio and imagination.

Let's say you want to work on EA. Big thing, huh? They ask for formal studies; sure, but then they see your portfolio (and you need a strong one, not necessarily a big one). So... it helps, but imagination and portfolio helps better.

Now, let's say you want to go indie. Good thing. People don't ask for code standards, design documents or formal education; they want games. Good, funny, maybe free ones.

If you have the time, and the budget, to afford formal education; **go for it**. Why? You'll be on the shoulder of giants and you'll have subjects to focus your attention on; so learning will be kind of faster. But always remember that all of the theoretical material is worthless unless you make games, show it to people and get feedback from them to get the hang of it.

Finally, keep self-teaching yourself. That's key on being successful. Users/clients/bosses don't care too much if you were taught about a subject, but rather whether you actually **know about it**.

*PS:* As David pointed out, it's recommended to go for a specialized curriculum. Computer Science or Arts and getting a game development major. But that's up to you to decide and there are pros and cons that don't belong to this subject.
> 1 votes

---
Tags: education
---


# Question
Title: What is the best way to limit player movement?
I'm currently programming a 2d game where the player moves around on a rectangular playing field. The player has a direction and a velocity. What is the best way to limit the player's movement so he/she cannot move past the boundaries of the playing field?

Thanks,

DLiKS

# Answer
If your game is running iterations/frames, where each iteration takes up a certain amount of real time, you can figure out whether the velocity vector for the player will cause them to cross the boundary. How simple or complicated this calculation needs to be depends on how complicated your boundary is.

Some basic ballistic physics...

Measure the increment of time, t, between iterations. If your player's position is a set of coordinates, `x0 (x0_x, x0_y)`, and the velocity is a vector `v (v_x, v_y)`, the position at the next iteration can always be calculated as:

```
x = x0 + v*t => (x_x = x0_x + v_x*t, x_y = x0_y + v_y * t)

```

If the player is accelerating at a constant rate `a` during that interval:

```
x = x0 + v*t + 1/2 a*(t^2) => (x0_x + v_x*t + 0.5*a_x*t*t, x0_y + v_y*t + 0.5*a_y*t*t)

```

All of the above math is just to predict what the player's next x and y position will be.

Determine whether the destination coordinates cross the boundary. If the boundary is a simple rectangle (0 \<= x \<= 400, 0 \<= y \<= 300, let's say), you can detect whether a boundary is crossed:

```
if (x_x < 0) ...
if (x_x > 400) ...
if (x_y < 0) ...
if (x_y > 300) ...

```

When the boundary is crossed, instead of moving the player that direction, you can do a couple of things:

* Stop them at the boundary (if x\_x \< 0, set v\_x = 0)
* "Bounce" them at the boundary (if x\_x \< 0, set v\_x = -v\_x)
* "Wrap around" and put them on the other side of the screen (if x\_x \< 0, set x\_x = 400 + x\_x)

If the boundary is more complicated (like a map), you will have to do collision detection.

If you decide to stop them at the boundary or bounce them, you may wish to add in a margin equal to half the width or height of the player's icon (if the player's coordinates are in the center of the icon), so that the player's icon doesn't move partway off of the screen.

Hope this helps.
> 11 votes

---
Tags: mathematics, movement
---


title: Easing Functions

text:
# Question
Title: Easing Functions
I started to involve myself with easing functions (Flash AS3), came about in trying to understand TweenLite and Robert Penner's website: http://www.robertpenner.com/easing/

The question I have is what is the math basis for these functions. I've seen other sites modify the functions to create custom easing function.

# Answer
Well tweening in the general case is just parametric movement (specifically, defining a function *f(x)* where *x* can be 0..1 for position/rotation/scale/whatever) with a modifier on the parametric value you pass in. The modifier also has the range 0..1.

If you plot the algorithm on a graph you'll get something that starts at 0, ends at 1, and the slope of the curve defines the velocity at that point in time.

If you want the math for the easing functions themselves, check this out: http://iphonedevelopment.blogspot.com/2010/12/more-animation-curves-than-you-can.html
> 6 votes

# Answer
I've written a primer on interpolation, which may be of some use - http://iki.fi/sol/interpolation/

Another great resource is this interactive tool: http://www.gizma.com/easing/
> 4 votes

---
Tags: flash, animation, tweening, easing
---


# Question
Title: What things should an indie game developer never do?
What are some of the biggest - and better yet: insidious and unexpected - mistakes that indie game developers make? Especially when making the transition from hobbyist to full-time indie?

# Answer
One of the major pitfalls is focusing too much on developing the framework / tools / engine, and too little about making the actual game.

You risk to get all entangled up into that and lose focus. Never forget you are first and foremost making a game not making a middle-ware component.

i.e. You should not start by coding the math library but instead by figuring out how to make the game entertaining.
> 284 votes

# Answer
Don't start off with an MMORPG.
> 107 votes

# Answer
**Don't burnout early.**

You don't want to get started an awesome game idea and then burnout after a couple of weeks because of poor planning. Games take a long time to make, so make small, realistic goals.
> 100 votes

# Answer
Biggest indie mistakes:

* Choose a too big project.
* Have a too small team. (Lone wolf can work, but adds unneeded problems.)
* Don't set a *fixed* target date. (Yes, set the release date before starting and stick to it!)
* Keep it secret. (Get it out there, nobody will steal your idea. Ideas are 1%, execution is 99%.)
* Ignore the community. (Get some early alpha testers. Get early versions out to the review sites. They want your previews and will help you!)
* Ignore copyright. (It's not OK to steal code, graphics, sounds, etc...)
* Expect too much money. (Make your first title a gift. Expect nothing in return.)
> 91 votes

# Answer
Two things... The first one being the most critical

**Don't Ignore Marketing**
You're indie. Nobody knows you. You absolutely need to get yourself out and start building your brand as early as you possibly can. You can't expect to have the next big hit so you need to start dipping your toes into the water early. Marketing is hard. Building a brand can be a full-time position. Spend an hour or two everyday talking to your community or other people to help them discover you.

Nothing sucks worse than spending a year making something and you don't meet a fraction of your expectations or even reach anything close to your potential.

**Don't Sacrifice Quality**
Don't fall into the trap of thinking that just because you're independent that you can't produce something of extremely good quality. Yes, it **will** take you more time to develop than someone with a powerhouse of developers, but you're just going to have to be more creative. If you don't like your artistic style, fix it. If your procedural algorithm routine sucks, fix it.
> 68 votes

# Answer
Take note of the reply above about not spending too much time on a framework / tools/ engine.

Then remove the word 'tools' from it!

While it may be easy to spend way too much time on a well-engineered engine or over-ambitious tech-for-techs-sake, you really don't want to underestimate the importance of decent tools.

They don't have to be high-tech or optimized - but they need to be stable and very usable. Especially if you're making a game that needs a decent amount of content, or where level design is key.

And especially if you're working on a team of more than one. If your level-building tool sucks, even the best artists/designers out there will struggle to build good levels.
> 45 votes

# Answer
Give up. Don't ever.
> 44 votes

# Answer
Over-attention on polish early on. If a game concept isn't fun with blue and red boxes for characters, chances are it won't be fun with 6 weeks of art time.
> 33 votes

# Answer
Never steal code from another indie developer.

Sure, it applies to non-indie developers as well, but the indie development community is already a very collaborative and sharing environment for a creative individual. It's easier to ask nicely, and more often than not, folks will be quite happy to tell you how it's done. You might even find a teammate in the process.

Even if you're using code that other developers have made available on their websites, be sure to credit them, and send them an email to let them know you appreciate the resource.
> 28 votes

# Answer
Most important thing you can do if you're going from hobbyist to full-time indie: have a business plan. Seriously. What are your revenue streams? Do you have any right now, and if so, realistically how long will they be viable? What's your burn rate, and what are your cash reserves? In other words, how long can you be in development before you have to ship something to pay the bills... and how much do you have to make when that happens? Realistically, how long will it take you to develop your first game, and does that fit within your parameters? If you know these answers, and you're honest about it, then "do I go full-time or not?" should be a no-brainer decision.
> 20 votes

# Answer
Don't settle for programmer art. If you aren't artistically endowed, but there's no way around doing it yourself, work within your limitations for the art direction. Doodle Jump and Desktop Tower Defense are great examples of this.
> 16 votes

# Answer
**Do Build Your Community, Don't Be a Jerk**

Indie games, being small, have small but often fanatically loyal fan bases. No matter how your fans act, there's value in catering to your hardcore community and keeping them happy. Keep a dev blog and twitter account, personally visit the forums and respond to issues. The community loves a developer who gives them personal attention. Sometimes keeping a public list of bugs to fix or features to develop can be good too. ToadyOne (Dwarf Fortress) and Notch (Minecraft) both do this to some degree and the community really loves knowing when they can expect X feature or bug fix.

*As an Indie, your community is your boss and you should keep them informed and invested in your project as such.*

On a similar note, though, don't be a jerk, don't bad mouth other game devs. That's just unprofessional, and it makes you look petty. Sometimes big game developers talk too much and the gaming press usually annihilates them if the fans don't do it first. As an indie, you want friends, lots of them. You want other indie devs to go "Wow, that guy is a class act, I want to work with him, maybe do a bundle release of our games so we'll both sell more."

EDIT: **Caveat, Hardcore**

I forgot to mention one little clarification on "no matter how your fans act." Obviously you don't want to be a jerk, but you don't want your fans to be a jerk by proxy for you either. This is a serious problem in the fighting game scene, where the fans of some games are seen as so generally unpleasant that those games are banned just so their fans won't show up at tournaments. See also: No Mutants Allowed and Fallout.

If your game can sustain itself on a hardcore group, that's fine. But if you want broad appeal, take care not to encourage a community of elitism that scares away newbies. One big appeal of games like Minecraft or Dwarf Fortress is that both have active community wikis and forums that make the game more inviting to new players.
> 15 votes

# Answer
Finish stuff. Even if you end up hating the thing, finish what you intended to. Nothing is ever going to be perfect so be realistic and take incremental steps in your game career.

To know that you've finished something is positive feedback for yourself, so you won't end with self-nagging thoughts about never finishing anything.

There's a lot of work in actually finishing the programming of a game, much of which isn't as exciting as the initial work on a game.

By finishing something, you increase your portfolio and you end up with valuable lessons learned along the way.

There were lots of people about when I did games (back in the 80's) that never finished anything - most of the time this happened when the least exciting bits of the game needed doing - at which point they moved onto a new idea. Essentially, they were just demo writers instead of game producers (not that there's anything wrong with that, just sayin').
> 15 votes

# Answer
**Do what you know best**

Don't make a strategy game if you have been into action games all your life. Pick a genre you know well and stick to it.

**Follow your instinct**

There are too many different opinions and good advices out there. You will be ripped in parts if follow every complain you will encounter by feedback. That does not mean feedback is worthless. Write everything down and sort it by importance (e.g. occurance in your feedback stream). Then go through it and fix real issues. Forget the rest.

**Don't get browbeaten**

Every day brings a new load of game releases. Some of them are similar to your project and just look so good that you can't compete. Should you give up? NO! Brainstorm and make a list of uncommon USPs (unique selling points - features other titles don't have) and add some of them to your game. Differentiation will save your game from drowning in obscurity.
> 13 votes

# Answer
There have been some great answers, specifically: concentrate on making a fun game instead of working forever on your own developer tools (like an engine) and focusing on marketing.

However in regards to, "when making the transition from hobbyist to full-time indie?", here's what I think is the biggest mistake:

-- Do not go fulltime indie unless you have enough money to keep you afloat for years. --

You should hope for the best (selling tons of games) and prepare for the worst (losing money every single month for a long time). You don't need the additional stress of not knowing if you'll be able to afford rent when trying to make it on your own. Just find the money somehow; be responsible with your dreams.
> 7 votes

# Answer
Never Underestimate the time and effort it takes to get a game from a prototype to a full-fledged production-quality game. The last "5%" can easily take half of the production time.
> 7 votes

# Answer
Don't forget where you came from: from doing things yourself and keeping it simple. Don't try to imitate the broken "AAA" model of being the idea guy and hire others to do and manage your work; that will slow you down, and first you have to get something out there that is successful enough so that it can make you some money.

There's nothing wrong with bootstrapping; be proud of it!
> 5 votes

# Answer
Well the first thing I would say from transiting from hobbyist to indie game developer also means to are a different kind of developer now.

Before you were making games for demonstration or because you just want to play it, or try a new idea.

If you are a professional, which indies are (indie doesn't mean you are just only free from any editor telling you what to do), you are not doing the game for you anymore, you want it to please to people so they could buy it, and that means your game has to have quality content.

Being independent is quite risky, you try to have the advantages of a having an editor to support you, but staying free of doing what you wish, and you can't totally have both.

I think the most important is believing in your project, its ideas etc, meaning being ambitious, but knowing how it scales to your workload.

Do milestones ! Most project use alpha-beta-gold, but it's better to slice it more, for example with 5 different milestone, so you can implement features homogeneously, starting with core features which you feel are important and will make your game look like a game, and adding features one by one, so you won't work on several features at the same time.

Chrome is at its 8th version already, while firefox has not released 4 and IE is there since what, 15 years ? but only at its 8 version.

Don't forget that independent games are very important right now, so think well about the features, since they are the only games that can be really different than blockbusters games which will always sell but be much less innovative.
> 2 votes

---
Tags: business, productivity
---


title: Collision Detection for 2D

text:
# Question
Title: Collision Detection for 2D
I am working on a simple game, where I need to do a collision detection of two Texture2D. The code I have written is:

```
bool perPixelCollission = false;
            Texture2D texture1 = sprite1.Texture;
            Texture2D texture2 = sprite1.Texture;
            Vector2 position1 = new Vector2(sprite1.CurrentScope.X, sprite1.CurrentScope.Y);
            Vector2 position2 = new Vector2(sprite2.CurrentScope.X, sprite2.CurrentScope.Y);

            uint[] bitsA = new uint[texture1.Width * texture1.Height];
            uint[] bitsB = new uint[texture2.Width * texture2.Height];

            Rectangle texture1Rectangle = new Rectangle(Convert.ToInt32(position1.X), Convert.ToInt32(position1.Y), texture1.Width, texture1.Height);
            Rectangle texture2Rectangle = new Rectangle(Convert.ToInt32(position2.X), Convert.ToInt32(position2.Y), texture2.Width, texture2.Height);

            texture1.GetData<uint>(bitsA);
            texture2.GetData<uint>(bitsB);

            int x1 = Math.Max(texture1Rectangle.X, texture2Rectangle.X);
            int x2 = Math.Min(texture1Rectangle.X + texture1Rectangle.Width, texture2Rectangle.X + texture2Rectangle.Width);

            int y1 = Math.Max(texture1Rectangle.Y, texture2Rectangle.Y);
            int y2 = Math.Min(texture1Rectangle.Y + texture1Rectangle.Height, texture2Rectangle.Y + texture2Rectangle.Height);

            for (int y = y1; y < y2; ++y)
            {
                for (int x = x1; x < x2; ++x)
                {
                    if (((bitsA[(x - texture1Rectangle.X) + (y - texture1Rectangle.Y) * texture1Rectangle.Width] & 0xFF000000) >> 24) > 20 &&
                        ((bitsB[(x - texture2Rectangle.X) + (y - texture2Rectangle.Y) * texture2Rectangle.Width] & 0xFF000000) >> 24) > 20)
                    {
                        perPixelCollission = true;
                        break;
                    }
                }
                // Reduce amount of looping by breaking out of this.
                if (perPixelCollission)
                {
                    break;
                }
            }

            return perPixelCollission;

```

But this code is really making the game slow. Where can I get some very good collision detection tutorial and code? What is wrong in this code?

# Answer
> 2 votes
One problem with this code that can cause a slow down is that you are testing every pixel between the two sprites... So it the sprites are not colliding and are, say, at opposite corners of the screen, you are darn near brute force checking each and every pixel on the screen.

Consider a simple rectangle/rectangle test instead or a separating axis test.... Much faster.

Check out page 3 of this article. It works for 2d or 3d: http://www.gamasutra.com/view/feature/3383/simple\_intersection\_tests\_for\_games.php

# Answer
> 2 votes
Split your collision test up in several steps:

1. quick check if two sprites might collides: Rectangle.Intersect(textureRectangle1, textureRectangle2)
2. your elaborate pixel collision check

Only perform step 2, if step 1 is true.

You also can return the collision result directly in the inner for loop, if it's true and always return false, if both loops finish without finding a collision.

This should speed up things considerably. But it will be slow if you have a lot of object to check (\>100). Since n\*(n-1) checks are done each frame.

# Answer
> 1 votes
Generate a quadtree for each image. The lowest cell size of the quadtree lets you determine the tradeoff between speed of collision test and precision. If the last size is 1, you get pixel-perfect collision detection, but you can often get away with 2x2 or even 5x5 cells, depending on the application.

Quadtree vs quadtree checks are probably log(n), and since the first check compares the top-level rectangles, it's in fact the same as the early rejection test you'd do if you used only pixel by pixel checks.

This approach is extremely flexible - with some work you can make it work for rotated and scaled textures as well (implement a axis-aligned-rect-to-rotated-and-scaled-rect test, and then transform each rectangle of both textures so that one is axis aligned)

---
Tags: 2d, collision-detection, physics
---


# Question
Title: 2D platformers: why make the physics dependent on the framerate?
"Super Meat Boy" is a difficult platformer that recently came out for PC, requiring exceptional control and pixel-perfect jumping. The physics code in the game is dependent on the framerate, which is locked to 60fps; this means that if your computer can't run the game at full speed, the physics will go insane, causing (among other things) your character to run slower and fall through the ground. Furthermore, if vsync is off, the game runs extremely fast.

Could those experienced with 2D game programming help explain why the game was coded this way? Wouldn't a physics loop running at a constant rate be a better solution? (Actually, I think a physics loop is used for parts of the game, since some of the entities continue to move normally regardless of the framerate. Your character, on the other hand, runs exactly \[fps/60\] as fast.)

What bothers me about this implementation is the loss of abstraction between the game engine and the graphics rendering, which depends on system-specific things like the monitor, graphics card, and CPU. If, for whatever reason, your computer can't handle vsync, or can't run the game at exactly 60fps, it'll break spectacularly. Why should the rendering step in any way influence the physics calculations? (Most games nowadays would either slow down the game or skip frames.) On the other hand, I understand that old-school platformers on the NES and SNES depended on a fixed framerate for much of their control and physics. Why is this, and would it be possible to create a patformer in that vein without having the framerate dependency? Is there necessarily a loss of precision if you separate the graphics rendering from the rest of the engine?

Thank you, and sorry if the question was confusing.

# Answer
> Why?

Handful of reasons, take your pick: They didn't know any better. .It's quicker and easier to implement. They were focused more on the gameplay and less on the edge cases that might not crop up in most cases.

You did a pretty good job of explaining why not. I'm sure you've noticed there's lots of topics that cover the subject. I'm not sure you'll find a satisfactory answer beyond the ones I listed.
> 7 votes

# Answer
SMB was originally a console game where it's safe to assume that it's able to run at 60fps on all Xbox360s (well, maybe 50 for some PAL players). Assuming a fixed timestep simplifies the code a fair bit.

Whilst it's easy to scale a lot of things by a variable timestep - 'pos += velocity * timestep', it gets quite tricky to do it correctly when you're dealing with accelerations, and rates of change of acceleration, and so on.

Decoupling gameplay and rendering is a nice solution *in theory*, but implementing it well (with good interpolation) is quite tricky, and things can easily get messy. It's fairly uncommon for this technique to be used in real games (although some big games do do it, particularly RTS games, but more for network game synchronization).

When also designing for a fixed screen resolution as well as a fixed framerate, there's one other thing you can do to make the scrolling extra smooth. You can ensure that the game scrolls at a whole number of pixels-per-frame - avoiding any 'subpixel wobble' you may get by scrolling a fractional number of pixels per frame.
> 4 votes

# Answer
The obvious solution is to have 2 loops running in parallel - the rendering every 1/60 of a second and the game loop every 1/60 of a second.

But with my experience in Flash (AS3, which I'm pretty sure Super Meat Boy was created in), the scheduler isn't always very accurate. The accuracy also depends highly on the environment. In the stand alone flash player, it might have sub-millisecond resolution. But when run in some web browsers, it's accuracy becomes that of the frame rate.

So the closest way you can get to decoupling the rendering and game logic loops is to have all movements be time based (and run each frame based on how much time elapsed since the last frame). That can introduce some more complicated mathematics (like having gravity be applied continuously, rather than adding to the velocity of an object at set intervals). Because the game could lag for a second and then your player would be moving 200 pixels in one step, collision detection and response can become even more complicated. If the programmer was doing frame based collision detection (checking for a collision each timestep), they would have to switch to time based collision detection too. And if they wanted it to feel natural, they would have to use the gravity method described above, which causes object movement be a curve (as opposed to a line), which makes determining the time of intersection between 2 objects even more difficult.
> 1 votes

# Answer
I don't think its to much to ask for 2D PC games to play at 60fps anymore. Even most 2D games are hardware accelerated now so personally I wouldn't worry about the fps requirement.

The real question is why wouldn't you use a pixel based, games are full of cheats and shortcuts.

If you are making a physics based game (bird throwing perhaps?) the answer is obvious, but a super mario clone? time based movement might be a bit much.
> 0 votes

# Answer
To avoid strange behavior in the 2d physics they're using?

Honestly I can just guess. I'll try an explanation:

At heart of the game is the main game loop. Which basicly looks like this:

```
while(gameRunning)
{
  updateGame(timestep);
  renderGame(timestep);
}

```

updateGame updates the gameState: checks player input, applies player input to the game world and runs the physics simulation etc.

renderGame draws and animates the game.

This couples the physics update to the rendering. If you want to decouple it you would need use threads and properly synchronize each data access of the rendering and the gameUpdate thread to shared data e.g. player position. This can be done.

Another problem might be that the physics simulation requires a constant timestep to run stable. This depends on how supermeatboy calculates the movement (Again we can just guess how they've done it ;) ).

A naive approach would be (which I'm using in my game \*sigh\*):

```
position=position+speed*timestep;
speed=speed+acceleration*timestep;

```

This is called Euler Integration and is generally considered to be a bad idea. If the timestep is none-constant calculation errors occur which will make the simulation less stable. Object might move at excessive speeds or not all or fly through the walls off the screen. Even if the timestep is constant Euler Integration causes minor calculation errors. Better use another integration method like RK4 or use a physics engine.

Apart from that there can be problems doing the collision detection if the timestep gets too large. Since collisions are not checked between two gameUpdates, objects might pass through obstacles.
> 0 votes

---
Tags: graphics, physics
---


title: Flash game engine

text:
# Question
Title: Flash game engine
I need simple game engine with pixel-perfect collision detection, camera component with following function, network and particle components would be desirable. Anyone knows whether the engine right under these requirements?

# Answer
Definitely look into flixel. It already covers a lot of your requirements.

Also check out Flash Game Dojo. That will help getting you started.

**Update:** For the sake of completeness: Also look at FlashPunk. It is similar to flixel but has some other strenghts/philosophy. Check out the Flash Game Dojo page for a brief comparison.
> 9 votes

# Answer
I'd like to add Pushbutton Engine as another candidate. This is a modular engine so you don't need to include the whole feature set if you don't need it.
> 3 votes

---
Tags: flash, actionscript-3
---


title: How to give delay in java

text:
# Question
Title: How to give delay in java
I wan tto give delay in java without using thread. I need to load images one by one with approx half second delay. Is there any way to do this other than thread because if I am using thread my whole game is going into the sleep mode.

# Answer
Correct solution should be to use another thread for loading images. And the waiting aprox half second is not good. Your image loading function should have some callback to tell the loading thread that the image is loaded.
> 3 votes

# Answer
you said that you don't want to use "thread" because your whole game sleeps. I think you are referring to Thread.sleep(). This is just one static method in the Thread class. The main purpose of the Thread class is to allow parallel execution. So the idea is to execute the image loading code in parallel to your normal processing.

```
Thread imageLoadingThread = new Thread(new Runnable() {
    public void run() {
        // loop to load image
            // load image
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        // end loop
    }
});
imageLoadingThread.start();

```

The Thread.sleep(500) call will now only put the new image loading thead to sleep while the rest of the game continues to be executed.

Note: I assumed that you need the delay in order to keep load on the server low. If the delay is needed in order to wait until the image is loaded completely on the client side, a different approach would be better.
> 2 votes

# Answer
What are you trying to achieve? Can you only load the next image if the previous one has finished loading?

You can track the time when the last image was loaded and then check in your game update function if enough time since the last loaded image has passed.

Your game stalls when using sleep because you pause your main thread. As nhnb said you need to write seperate image loader thread class.
> 1 votes

---
Tags: java
---


# Question
Title: What do I need to learn so I can make games on XBox Kinect?
I am interested to learn more about game development especially on XBox Kinect. What do I need to learn and what books I should read so I can make games on XBox Kinect?

Thanks

# Answer
At the minute there is no support in XNA for Kinect (although, hopefully this will change in the near future).

There are two ways to develop for Kinect at the moment.

The first is to become a licensed Xbox developer (although it might be a little expensive :P)

The second is to use the open source drivers for Kinect known as OpenKinect (libfreenect, they're interchangeable I think)

The open source libraries can be found here: http://openkinect.org/wiki/Main\_Page

They are a C library and I think you'll probably need to develop in Linux to make stuff now, but I believe work is being done for support for Windows. Of course, you'll only be able to develop PC applications for the moment.

Hope that helps.
> 6 votes

---
Tags: xbox360, books, kinect
---


title: Cyclic Dependencies

text:
# Question
Title: Cyclic Dependencies
Are cyclic dependencies a common thing in games dev? I ask as I keep getting into situation where I'm using and have been told more than once that they should be avoided.

I am wondering if this is just a what people say as a general rule of thumb in the software development business. and that the nature of game programming produces such dependencies.

```
// Foo
#include <Bar.hpp>
class Foo {
    bar& m_bar;
};

```

and

```
// Bar
class Foo;
class Bar {
    Foo* m_foo;
};

```

I do this alot in Ruby, but dynamic languages are more forgiving in this instance, where as static ones, not so much.

# Answer
Since you're using indirect addressing (pointers or references), and you don't need to know the contents of the other object at declaration time (only at implementation time) this will work just fine in most languages. Obviously it falls apart when you have one object containing another (because to know the size of the containing object, you have to know the full details of the contained object).

All of that is just semantics though, the fact that you can do such a thing is not a reason why you should. The problem that you'll face is that you are essentially tightly binding those two classes together. You can't have a Foo without a Bar, nor a Bar without a Foo. So you can't re-use Foo elsewhere without also dragging Bar along as well, and that may just not be appropriate. So if the only reason Foo needs to know about Bar is for one little thing, that might even be optional, that's a massive pain.

For example, if you have a character instance which knows about an navigation state structure to run its navigation logic, but in turn, the navigation state needs a back pointer to the character instance so it can get, say, its position. The navigation logic might also be applicable to vehicles, but you can't use it, because navigation is assuming that it's hooked to a character.

A much better approach to this is to understand what the back-pointers are being used for, and define an interface which can be used instead. Instead of having a Character\* pointer, the navigation state has an IPositionable pointer (and Character implements IPositionable somehow). Now the navigation logic doesn't care how it is used, and can be re-used for characters, vehicles, anything. Better yet, the navigation logic could be split out into its own library / module, because it now has no awareness of anything above its own level - it's nice and self-contained.

Game development is not special in this regard. If you are producing many such tight circular dependencies like this, it is because your structures are poorly designed. This is a normal software engineering problem, and all of the same guidances apply.
> 7 votes

# Answer
Cyclic dependencies are a common design mistake in software development. Game development might be more susceptible to it, since you have a lot moving parts which have to depend on another in some way.

If you're overusing cyclic dependencies your code will turn into one tightly coupled mess.

Suppose you have Sprite class to render the player sprite on screen, a PhysicObject class for movement&collision detection, a Animator class to animate the player sprite, a PlayerControl class to apply user input to the player character.

If each class knows about the others you cannot use just a subset of these. An invisible wall might just consist of the PhysicObject. A wooden crate consist of a Sprite and a PhysicsObject and so on.

If classes have to speak to each other it is better to use an event system. Or have a parent class which encapsulates common data members. Child classes are also data members of the parent class and just manipulate the data members of the parent.

There is no single right ways to structure a game.

Another problem with cyclic dependencies is what if one of the classes is deleted? If the Foo object is deleted the Bar object has an invalid pointer and will cause an error the next time it tries to access it.

You also cannot use boosts shared pointer class if you have cyclic dependencies. Shared pointer will delete the object it points to if there are no more references to it. But if Foo points to Bar and Bar points to Foo, Foo and Bar will never be deleted and you have a memory leak.

Game entities with components:
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

I'm reading Mike McShaffry's "Game Coding Complete" which give a quite good overview how to design and build games. It also has a bunch of code samples. Might be worth a look ;)

Regarding your code sample:
Use inclusion guards to avoid multiple includes of the same header file:

```
#ifndef BAR_H
#define BAR_H
class BAR {
  //class definition
};

#endif

```

or if you're using Visual Studio:

```
#pragma once
class BAR {
  //class definition
};

```

This will stop the compiler from complaining.
> 1 votes

---
Tags: game-design, c++, software-engineering
---


# Question
Title: Why / how does XNA's right-handed coordinate system effect anything if you can specify near/far Z values?
I am told repeatedly that XNA Game Studio uses a right-handed coordinate system, and I understand the difference between a right-handed and left-handed coordinate system. But given that you can use a method like Matrix.CreateOrthographicOffCenter to create your own custom projection matrix, specifying the left, right, top, bottom, zNear and zFar values, when does XNA's coordinate system come into play?

For example, I'm told that in a right-handed coordinate system, increasingly negative Z values go "into" the screen. But I can easily create my projection matrix like this:

Matrix.CreateOrthographicOffCenter(left, right, bottom, top, 0.1f, 10000f);

I've now specified a *lower* value for the near Z than the far Z, which, as I understand it, means that *positive* Z now goes into the screen. I can similarly tweak the values of left/right/top/bottom to achieve similar results.

If specifying a lower zNear than zFar value doesn't affect the Z direction of the coordinate system, what does it do? And when is the right-handed coordinate system enforced?

The reason I ask is that I'm trying to implement a 2.5D camera that supports zooming and rotation, and I've spent two full days encountering one unexpected result after another.

# Answer
Okay, a couple of questions here, so I'll do my best to explain them all.

**Coordinate System**

The coordinate system of anything affects more than just the orthographic projection. It affects translation and rotation as well.

For example, set up your camera projection as you have described. Now create an object and set it to move either toward you or away from you. It will move toward the camera when you increase the Z-value of the object's coordinate and move away from the camera when you decrease the Z-value.

Now if you rotate your camera around the scene (for gameplay reasons, or whatever you like) then the world's Z-axis stays the same, so this time increasing or decreasing the Z-value will affect the object in a different way (depending on the orientation of your camera.

**Rotation**

Now for rotation:

Rotating around the X, Y and Z axis is slightly different in right-hand systems than left-hand systems.

I refer you to this picture:

The left image shows rotations in a left-handed system and the right shows rotations in a right-handed system (although not very well, but it was the only picture I could find relatively quickly from Wikipedia)

The easiest way to explain it is using your hands. If you put up your right hand when your thumb and index finger make an L-shape with your palm facing towards you, your thumb is the positive X direction and your index finger is the positive Y direction.

Now bend your middle finger so it is point towards you, this is the positive Z direction in a right handed system (I'm getting to rotations, honest! Just wanted to make everything clear)

Make a thumbs up and point your thumb towards your face. The direction in which your fingers coil is the POSITIVE direction for a rotation about the Z-axis.

So lets add +45 degrees of rotation to the Z axis on the object and it will dip its left side down and its right side up.

Phew, hope that explains rotations in a right-handed system.

**Projection**

Now to answer your projection matrix questions. No, creating a projection does not change the world's Z-axis. All it does is is creates a view frustum (Best explained here: Viewing Frustum)

To work with this rule enforcement, it might be best to have LOCAL axes for your world objects (including your camera).

I usually have Heading, Right and Up normalized vector members for each of my world objects to help me out in this respect. So whenever you translate an object, instead of adding X, Y or Z values, I simply map it relative to the vectors (e.g. If I press forward, then my camera moves towards it heading, if I press right, it moves when its right vector is pointing).

**Zoom**

I know you didn't ask about zooming, but I thought I'd nip it in the bud since you want your camera to support it too.

Personally, I do a cheap zooming effect by changing the FieldOfView member of the view frustum. This is usually set to around 45-60 degrees. Play around with this until you get the effect you want.

I think that's everything, hope it helps! :)
> 12 votes

# Answer
Your assumption that a -Z axis advances into the screen presupposes that a camera is looking in that direction. If the camera was looking in the +X direction, then +X would be advancing into the screen.

clip values are expressed in projection space. The -Z values you speak of are in world space. You must be able to convert between spaces when visualizing concepts.
> 2 votes

# Answer
Put simply, near and far is simply the closest and furtherest distance that objects will be rendered. You won't be able to see any polygons that are closer to the camera than the near distance, and you won't be able to see any polygons that are further away from the camera than the far distance. It has *nothing* to do with which co-ordinate system is being used.

It's not 100% accurate to say that increasing the Z-Value moves the object towards the camera, and decreasing it moves it away. This is only true when the camera is facing forward. If the camera was facing backwards, then the opposite would be true.

If the camera is in the default position and default orientation, then you would need to place objects with negative Z values in order for them to be visible. For instance, if the camera is at 0,0,0, then an object at 0,0,-10 would be visible, but an object at 0,0,10 would not be (as it is behind the camera).
> 1 votes

---
Tags: xna, 3d, camera, coordinates
---


# Question
Title: Resolution Independent 2D Rendering in XNA
I am trying to figure out the best way to render a 2d game at any resolution.

I am currently rendering the game at 1920x1200. I am trying scale the game to any user selected resolution **without changing the way I am rendering, or game logic.**

**What is the best way to scale a game to any arbitrary resolution?**

Edit: I am trying to achieve this:

http://www.david-amador.com/2010/03/xna-2d-independent-resolution-rendering/

but I think the code he has is for a different version of XNA because I cannot find that method overload he uses.

# Answer
Edit:

You're looking for the SpriteBatch.Draw(Texture2D, Rectangle, Color) call. The Rectangle represents the scaled draw target on the screen.

I'm assuming here that you're not using a grid layout - wasn't specified in the question so I'll go with assets being able to be drawn at any pixel rather than on a set grid.

1. First decide on what should be 'native' resolution. Probably just height though, different monitors have different aspect ratios so that'll have to be accounted for. Lets pick 1200 as the native height. All scaling will be based off this number.
2. Say I'm running the game on my TV with only 720p - 60% of the height. All unit coordinates and the Rectangle sizes then should be multiplied by 0.6. A hypothetical orc unit is 20 pixels tall and located at (50,45) under native resolution. At draw time, the target Rectangle would become 12 pixels tall and drawn at (30, 27)
3. Where exactly you calculate in the scaling may be an issue. You can run the game entirely as if it were running at native resolution - this would mean no extra scaling in things like distance computations, animation speed and interpolation, etc... Then, only do the scaling at draw time, or with hit testing mouse clicks. If you chose to scale everything, then you just need to make that scale accessible to all systems globally and remember to account for it.

Hope this answers your question better.
> 4 votes

---
Tags: 2d, xna-4.0, resolution
---


title: 3D Camera Problem

text:
# Question
Title: 3D Camera Problem
I allow the user to look around the scene by holding down the left mouse button and moving the mouse. The problem that I have is I can be facing one direction, I move the mouse up and the view tilts up, I move down and the view tilts down. If I spin around 180 my left and right still works fine, but when I move the mouse up the view tilts down, and when I move the mouse down the view tilts up.

This is the code I am using, can anyone see what the problem with the logic is?

```
  var viewDir = g_math.subVector(target, g_eye);
  var rotatedViewDir = [];
  rotatedViewDir[0] = (Math.cos(g_mouseXDelta * g_rotationDelta) * viewDir[0]) - (Math.sin(g_mouseXDelta * g_rotationDelta) * viewDir[2]);
  rotatedViewDir[1] = viewDir[1];
  rotatedViewDir[2] = (Math.cos(g_mouseXDelta * g_rotationDelta) * viewDir[2]) + (Math.sin(g_mouseXDelta * g_rotationDelta) * viewDir[0]);
  viewDir = rotatedViewDir;
  rotatedViewDir[0] = viewDir[0];
  rotatedViewDir[1] = (Math.cos(g_mouseYDelta * g_rotationDelta * -1) * viewDir[1]) - (Math.sin(g_mouseYDelta * g_rotationDelta * -1) * viewDir[2]);
  rotatedViewDir[2] = (Math.cos(g_mouseYDelta * g_rotationDelta * -1) * viewDir[2]) + (Math.sin(g_mouseYDelta * g_rotationDelta * -1) * viewDir[1]);
  g_lookingDir = rotatedViewDir;
  var newtarget = g_math.addVector(rotatedViewDir, g_eye);

```

# Answer
> 1 votes
3D cameras are simpler to implement using Quaternions, in my opinion.

Take a look at the sample code for the "Simple Scene Viewer":

http://code.google.com/p/o3d/source/browse/trunk/samples\_webgl/o3d-webgl-samples/simpleviewer/simpleviewer.html?r=215

In particular, the drag handler:

```
var rotationQuat = g_aball.drag([e.x, e.y]);
var rot_mat = g_quaternions.quaternionToRotation(rotationQuat);
g_thisRot = g_math.matrix4.mul(g_lastRot, rot_mat);

```

All you need to do with Quaternions is perform a simple matrix multiplication.

---
Tags: 3d, camera
---


title: Collision Systems Implementation

text:
# Question
Title: Collision Systems Implementation
Just curious what might be a good way to implement a decent collision system. As a class inherited by a base Entity class? Currently I'm stuck and could just use a couple better ideas than my own.

Any help is appreciated!

Edit: Sorry, it's 2D Collisioning but honestly, I'm not looking for specific collision methods. I'm looking more about the lines of implementation. Just curious of some of the common methods of how to implement collision systems such as:

Should the entire collision system be it's own class? What, if anything, should be inheritable?

These are some of my questions. Sorry for the confusion.

# Answer
Each time I ask about collision systems, discussions (online) goes this way :

* "Hey how should I do this kind of collision?"
* "You should try this algorithm."
* "No, this one algorithm would be better!"
* "Maybe a more global view of the system would help, like using this algorithm."
* "Just get the Real Time Collisions book and shut up."

So after several discussions like that I finally bought the book : http://realtimecollisiondetection.net/

It presents all aspects of the subject to inform you enough to let you decide what to do for each case.
> 5 votes

# Answer
This is a question of design approach, so there is no single optimal solution.

A possible approach would be to create a superclass for collidable objects which defines functions for collision detection and have all collidable-object classes inherit from this class.

How these functions work is dependent on other parameters, such as the type of collision detection (bounding box, bounding circle, bounding polygon, per pixel, ...).
> 3 votes

---
Tags: architecture, collision-detection
---