How is game development different from other software development? [closed]

Question

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.

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.