Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

For a solid general purpose software developer, what specifically is different about game development, either fundamentally or just differences in degree?

I've done toy games like Tic-tac-toe, Tetris, and a brute-force sudoku solver (with UI) and I'm now embarking on a mid-sized project (mid-sized for being a single developer and not having done many games) and one thing I've found with this particular project is that separation of concerns is a lot harder since everything affects state, and every object can interact with every other object in a myriad of ways.

So far I've managed to keep the code reasonably clean for my satisfaction but I find that keeping clean code in non-trivial games is a lot harder than it is for my day job.

The game I'm working on is turn-based and the graphics are going to be fairly simple (web-based, mostly through DOM manipulation) so real time and 3d work aren't really applicable to me, but I'd still be interested in answers regarding those if they're interesting. Mostly interested in general game logic though.

P.S. Feel free to retag this, I'm not really sure what tags are applicable.

share|improve this question

closed as not constructive by Josh Petrie, Byte56, Trevor Powell, Anko, msell Apr 8 '13 at 6:19

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers 5

I'm primarily a game developer and not a traditional software developer, but I think there are several key differences.

These are obviously several generalizations and not comprehensive:
Bigger teams. More varied backgrounds (artists, programmers, producers, with each there is even more variation). Longer development cycles. Higher standards of performance. Larger scale of projects. Bigger and more expensive risk of failure. More stressful environment.

As for object interactions and laying out your architecture, you can still properly decouple systems. Your gameplay objects and behavior, will clearly have dependencies on each other and on these systems. That is the nature of the game though (pun intended), it combines all of these systems into a single, cohesive unit, and there's nothing wrong with that. It might seem so because the scale of it all is larger than you're accustomed to.

Some easily identified and segregated systems?

  • Collision Detection
  • Collision Response
  • Physics
  • Animation
  • Graphics (2D and 3D)
  • Artificial Intelligence
  • User Input
  • File Input/Output
  • Networking
share|improve this answer
1  
+1 for many diciplines –  Jari Komppa Feb 27 '11 at 9:45
    
+1 for a good answer to the question even though for my particular game I don't have to deal with most of those (turn-based and tile-based so no real collisions, no physics, graphics consist of sprites and throwing more JQuery at it, 2-player so no AI yet, user input is handled in a mostly RESTful manner which also covers the networking aspect) I'm not quite sure what you mean by File IO though, other than say saving/loading a game what kinds of IO are needed in typical games? –  Davy8 Feb 27 '11 at 14:46
3  
I agree with most of this post, and gets a +1 from me, but I would call into question the "bigger and more expensive risk of failure" line. If you work for a bank, or a large manufacturing firm, or a very high traffic website, your failure can be measured in hundreds of thousands per minute of downtime as a result of failure. In an hour, you could lose (in lost sales, lost customers, etc) more than some game-dev shops months worth of full payroll. I'm not saying it can't be big, I'm just saying I'm not convinced it's any bigger than traditional software. –  corsiKa Feb 27 '11 at 15:11
    
@glowcoder I know what you're saying but I think I also understand the point Sion's trying to make, that with games generally either the whole project is a success or it's a failure, and it's usually a factor of what you mentioned in your answer: is it fun? You can do hot-fixes for bugs but you can't hot-fix a lack of fun. –  Davy8 Feb 27 '11 at 15:30
2  
I'm not at all convinced that "bigger teams" is true even as a generalisation. Sure, AAA games have big teams - but so do complexity-equivalent non-game software products. Vast numbers of games are produced by individuals or teams of two or three people. –  Peter Taylor Feb 27 '11 at 21:32

There is one major difference. In my opinion, it's the only difference that really matters.

We can go over the technical details of why it's different, sure. 3D engines, particle physics, lots of different things come into play.

But lots of different forms of software have strings attached. Modeling software has to do a lot of the same things. Every piece of significant software has some specialized library it has to use.

So what makes GAMES different?

Here it is: Software is designed to fill a business need. You want an inventory system? You can define what types of items you ahve to handle. You can define what you want for your production scheduling. You can do all that. Or if you want banking software, you can define what you want to do with it.

With games, your business need is "fun". Try writing a technical specification for "fun".

That, in my humble opinion as a developer, is what makes games different than regular software. You simply can't say "Great! This software is now feature complete as per the client's requests!" because all they want to do is have fun.

That being said, you don't need 3d graphics and extravagant physics for something to be fun. Why do people still play Tetris? Its physics consist of "move block down" "don't let block go out of bounds" and "stop block when it hits something", and while over the years there have been numerous versions, some with fancier graphics than others, but the bottom line is -- it's fun!!

So if you want to be a great game developer, do not throw out what you've learned as a regular software developer. It's still very useful stuff. And @Sion is right about separating your components, just like you would in a regular piece of software. But the single most important feature you can add to your game is fun. Fun fun fun fun fun. That's why game development exists, that's what you need to make your game successful. And trust me on this however fun it is to play, it's at least 10x as fun to make!!

Good luck with your game-dev'ing!! :D

share|improve this answer
2  
If you swap "fun" with "useful" I think you run into the same problem with designing a product (as opposed to writing software for a client). I suppose there is a difference in degree though. People are sometimes wrong about what would be useful, they are usually clueless as to what makes something "fun" to them. (+1 though) –  Davy8 Feb 27 '11 at 16:05
1  
There was an infamous supreme court ruling regarding the adult film industry and what classified "hardcore" in the the '60s. The justice said "I could never succeed in [defining it] but I know it when I see it." I think the same can be said for fun. I mean, I can jot down things I like about games, but I often find myself playing a game and asking myself "What makes this fun?" (Obviously I want to know so I can recreate it in one of my games!!) People don't know what makes something fun, but they definitely know when they found it! –  corsiKa Feb 27 '11 at 16:49
    
I really liked this post. You are so right. I really like game development but I don't really have it in me to see what "fun" is to "ordinary" people. Which has had the effect that I only make games that I and some other loons like me like :) –  Phil Mar 2 '11 at 10:22
1  
@Phil and that's fine. If you know what's fun to you, you have to remember there's only a couple hundred character archetypes in this world. Look around your workplace, and match up your co-workers' personalities to those you went to high school or college with. You'll find most of them can be matched up. So if something is fun to you, it's probably going to be fun to more people than you realize. The trick is getting them to know about the game so they can enjoy it! –  corsiKa Mar 2 '11 at 17:51

I don't think game programming is any different than other application domains from the standpoint of it being harder to pick the right separation of concerns. Anytime you take your skills to a different type of application domain you are going to find that the transition isn't as smooth as you may have hoped because there's always differences. What worked in your database application has many patterns/idioms that don't work so well in your embedded app, which has many patterns/idioms that don't work so well in that real-time system which also has many patterns/idioms that don't work in game programming. However, the game programmers have the same problems when they leave their game programming domain. It's all just a matter of what you are used to.

With that said, I think game programming seems harder for many people because it requires you to work with parts of the computer that most programmers never have to deal with at their real job (low-level graphics and sounds) and more applied math than many people are comfortable with and not because of separation of concerns. While there's always difficulties determining the right choice for separation of concerns, I think the difficulty with separation of concerns you are experiencing is simply moving to a new problem domain. Once you build a few applications then it'll be like anything else, you'll learn what you like and not use what you don't.

share|improve this answer

and one thing I've found with this particular project is that separation of concerns is a lot harder since everything affects state, and every object can interact with every other object in a myriad of ways.

I think you have an answer there, there are a lots of interactions. I made a few games with XNA (C#), now im doing a mid-size game as you say, a strategy-simulation game, been working on it for almost 2 months now, and im do it alone with no help, so i must keep my code simple. One huge difference i think, is to understand and design some classes for functionality, and other for drawing, this helps and makes your program cleaner. Of course, if you are doing a game you need to have more resources, like images (2d or 3d) and music (or sounds). So there are differences, i think its harder, but its very funny.

share|improve this answer

I think Game Programming is more fun. You can constantly test your game, you implement different physics, which results in different behavior.

From my experience, game programming is actually a lot more fun compared to software development. In software development you have certain business rules to abide by, it gets little boring. You're creating a software, its not fun. Using software is great, helpful, useful, but not fun.

Games are fun. Maybe its just me, but I find game development much more intriguing and exciting than traditional software development, regardless of the tools use.

PS: I use the latest tools for software development, HTML5, Asp.Net, C#, etc. I still find DirectX, UDK, XNA, Unity more fun to code.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.