|
Video Game Programming. Hard or Easy ?
I was chatting with a friend of mine.
And I was arguing with him that mastering
the domain knowledge (3D, AI, low level prog, maths, physics) for programming video games is way harder than programming DB front ends or shrink wrap applications
What do you guys think ?
Question : for a newbie what it will be easier to master ?
an ADO API or the Direct X API ?
Writting into a database or writting into a screen buffer ?
I think game programming is one of the hardest discipline in programming (with crafting a compiler and designing a full blown OS)
__ IceMan __
Tuesday, April 20, 2004
Games: Harder.
Almost Anonymous
Tuesday, April 20, 2004
I agree that video game programming is probably the most challenging programming for the following reasons:
1. Incredibly competitive, both on an individual level (programmers dying to write games) and on a company level (lots of money in video games).
2. Needs to be cutting edge, pushing the envelope, yet must run on a wide variety of machines.
3. Customers are very tech savvy. You need to have high production values (graphics, sound, etc.).
It's tough to make a program that:
1. Meets the customers need well (fun, in this case)
2. Looks good
3. Functions well.
4. Supports a variety of machines.
Mr. Analogy
Tuesday, April 20, 2004
Oh uh... Sounds like a flamewar to me! :)
In game programming, as you counted, there are many different aspects such as 3D gfx, AI, sound, game physics, UI, etc... In a big game development team, there might be one coder per each of these components. If the game developer is an indie, s/he might have to know it all.
Shrinkwrap programming might be the same depending on the application. If you are writing a little utility program, all you might need to know is the problem you are solving and VB programming.
You have to compare similar things. In the least, you should compare one item at a time. For example AI coding to DB coding... Game UI coding to shrinkwrap app UI coding.
I think when you compare similar items, you will realize that each has its own quirks that need to be mastered. I don't think one is more difficult than the other. You might find one more interesting than the other, but that's another issue all together.
grunt
Tuesday, April 20, 2004
"""or shrink wrap applications"""
Too big of a domain. Some are easier than games, some are harder.
Tuesday, April 20, 2004
The whole question screams ignorance. What kind of games are we talking about? Are we comparing a database app thats little more than an ASP form that collects information, to the latest state of the art MMORPG? Or how about we compare a simple[er] rpg to a "shrinkwrapped" application such as oracle or websphere? To compare the two industries is a waste of time.
vince
Tuesday, April 20, 2004
Gee, you guys sound like a civil engineer and a mechanical engineer trying to figure out which one has the harder job. Or a ballet dancer and a painter arguing about which one works harder.
Flamebait Sr.
Tuesday, April 20, 2004
will this forum accept <b>html</b>,
<html>testing</html>
Hey!
Tuesday, April 20, 2004
"To compare the two industries is a waste of time."
So for those who want to waste their time...
Comparing Oracle to other average "shrinkwrapped" applications is a waste of time. Oracle is practically and OS. However, we can easily compare an average shrinkwrapped applications with average games.
For my opinion, see the second post!
But seriously, the biggest issue with games is that they have to be state of the art and the reliability factor is extremely high. Games can't crash or otherwise malfunction. Game networking is hard. State of the art graphics is hard. Advanced AI is hard. Dealines are tight.
Almost Anonymous
Tuesday, April 20, 2004
When I hear video game programming, I think about consoles, and when I think about console programming, I think the hardest thing is that you have to get it very Very right the first time. There's no way to distribute a patch for a Playstation game, and nobody's going to buy SpongeBob Nopants and the Jiggling Anemonies II if version 1 sucked.
Boofus McGoofus
Tuesday, April 20, 2004
Don't games count as "shrink-wrap" applications?
Jimmy Jo-jo
Tuesday, April 20, 2004
Fundamentally the two subjects are comparably complex (I say this having written a small relational database system and a software 3D engine). But writing a simple ASP form on top of an RDBMS is about as complicated as asking OpenGL to render a box, so it's important to know exactly what kinds of problems we're talking about here before answering that question.
Kalani
Tuesday, April 20, 2004
Boofus, console titles do have to be "bug free" but it's not all that difficult since all hardware platforms are the same (works on one, works on all), and console players don't input, modify or create data which is probably the cause of most headaches with other apps. When I was in the industry in PSX and N64 days it was usually only four weeks or so of debugging (ok, 100-hour weeks).
The hard part of games I thought was the need to have something technologically new with every title, since you can't really innovate with gameplay anymore (there's only a handful of genres -- shooters, sports, driving, RPG, etc). Thus you always have to push the limits with something -- more trees in the forest, better water effects, better animations -- which by definition you nor anybody has never done before. It's the stress of coming up with those, then testing and experimenting, and continuing despite failure and extremely tight schedules and budgets that made it hard. The physics, math, graphics and AI were just first and second year college stuff.
Adam
Tuesday, April 20, 2004
I worked on database applications in the enterprise software world, as well as client-side device software for pagers and PalmOS devices before making my personal hobby my career, being a game developer. And by being a game developer, I'm talking specifically about developing 3D graphics engine code for X-Box, Playstation 2, Gamecube as well as content authoring tools (including plug-ins for programs like Adobe Phootshop, Maya, & 3DS Max). So I can't help but to think I know at least something about comparing the two.
VB + COM + ADO + SQL was brainless work compared to game development.
Writing RIM pager & PalmOS apps as well as dealing with synchronizatoin issues in WinNT services was similar in terms of the difficulty level.
To answer the original question.
It would be much easier for a newbie to master SQL & ADO API and write simple DB apps than to master the DirectX/OpenGL, 3D graphics, collision detection, kinematics, & AI necessary to write even a very simple 3D game. I'm not talking about drawing a boxes on the screen vs querying rows from a table. I'm talking about a fully functional DB app vs a fully playable game.
BTW ... games ARE shrinkwrap applications, and the game industry is subject to many of the same rules as other types of commercial shrinkwrap software; the question of games vs. shrinkwrap applications doesn't make sense.
Oh, and Adam has it right. Sure, games need tighter quality control, but quality control in the console world is greatly simplified by the fact that an X-Box is identical to any other X-Box, a PS2 to any other PS2, etc. There are minor issues such as NTSC vs PAL, but quality control in the PC games world is generally more difficult.
Immature programmer
Tuesday, April 20, 2004
I guess in a way it could be argued simple CRUD programming is the hardest because of the extreme boredom factor that has to be overcome.
Just me (Sir to you)
Wednesday, April 21, 2004
Game programming is hard for one very good reason: "fun" is kind of a hard requirement to translate into code.
anon
Wednesday, April 21, 2004
As a former games programmer, I'd say that games is no harder or easier than main stream work.
Mr Jack
Wednesday, April 21, 2004
Oh, and anyone who thinks games have tight quality control has worked in games.
Mr Jack
Wednesday, April 21, 2004
I dabble in game coding a bit. There is no comparison. Seriously.
I took me about 1 week to learn how to use VB with ADO (I knew some SQL and VB script from earlier). Two weeks later I was doing dynamicly populated treeviews and stuff. Sure, designing normalised databases is a bit tricker, but its still small potatos when compared to LOD schemes, terrain negotiating AI, dead reaconing and other methods of syncing players of realtime online games.
Now Im not a proficient game coder, but I can whip together a DB app with 20+ table db and pretty sophisticated gui in about the same time it takes me to write pacman in basic.
Eric Debois
Wednesday, April 21, 2004
"Oh, and anyone who thinks games have tight quality control has <never?> worked in games."
1) I definitely wasn't talking about quality in terms of structure, readability, and maintanability of the code. Yes, commercial games often contain some of the sloppiest throwaway code you'll find.
2) I would say anyone who thinks that games don't have tight quality control in terms of usability/playability of the final product has never worked on a GOOD console title. A console title has to meet certain rigid minimum requirements to even be accepted by Microsoft, Sony, or Nintendo. And a decent console game cannot crash or enter corrupt states at all. That's more than can be said of other types of shrinkwrap software.
Immature programmer
Wednesday, April 21, 2004
"Yes, commercial games often contain some of the sloppiest throwaway code you'll find."
True, but this is slowly changing. Not so much due to some high idealistic principle on the part of the programmers (although this does occasionally come into play), but more because the exponentially increasing content requirements demand it.
With the amount of effort it takes to get production values for modern games up (even to a mediocre degree), the underlying system has to be heavily data-driven just to support it all. That effectively means that the programmers aren't so much writing a game, as they are writing tools (consider the game engine itself as a tool) for the designers and content guys to create the game with. And since the content requirements are huge and the schedule pressure is very tight, that means those tools have to be pretty sharp or you're going to get the squeeze from all sides.
If that's the environment you're in, and the project takes around 2 years to complete (not unusual these days), you can't be _too_ sloppy or you won't be able to support your production pipeline effectively, and that could make it hard to meet those tight schedules. The long term effect here across the game industry (thinking from an evolutionary "survival of the fittest" angle here) has been a gradual improvement of programming practices, since most of those who haven't improved haven't had their projects survive (although there are admittedly a handful that have, for better or worse).
BadgerBadgerBadger
Wednesday, April 21, 2004
I wonder what John Carmak would say if he was to answer the stated question from HIS point of view and experience???
And if John Carmak said "DB app programming is harder", would you all believe him?
looney bin laden
Wednesday, April 21, 2004
This seems like asking, "What's harder, writing a novel or writing poetry?" They're both about the same thing - ordered words. What makes one more difficult than the other is your personal talents and interests. That is to say, one may be harder for _you_, while the other may be harder for someone else.
bpd
Wednesday, April 21, 2004
Yes, I didn't think something so obvious needed to be stated, but since it was, i'll paraphrase: The barrier of entry to game programming is much harder compared to business application programming. Thank you all so much for pointing out that VB + SQL is easy. But to say thats the entire application domain is wrong. Why isn't anyone comparing similar *sized* projects? Maybe because its a waste of time?
vince
Wednesday, April 21, 2004
..maybe or perhaps because the number of DB app projects the size of a modern game production are few and far between.
I mean, how many of us have worked on a project with a 20 million USD budget and 2 years * 30 developers just to get to version 1.0.
Eric Debois
Wednesday, April 21, 2004
Modern games are usually budgeted at one to two million USD (3-8 programmers and around 10-15 others, for 12-24 months), and most lose money.
Adam
Wednesday, April 21, 2004
"a project with a 20 million USD budget and 2 years * 30 developers"
Wow, that is around 333K per dev. year for a software project? What was this thing?
Just me (Sir to you)
Thursday, April 22, 2004
-- that is around 333K per dev --
No way, Game developer are paid peanuts mate!
Snacky
Thursday, April 22, 2004
Yeah, 2 million is more like it. Gee whiz, I would have liked to work on the project that was budgeted at 20 million! Where's my 333K a year!?
But I agree that generally speaking, a typical AAA commercial game project is much larger in scale and really not comparable with a typical DB app project; you will find very few people (if any) who have and can compare the experience of working on SIMILARLY SIZED game projects vs. DB app projects in the business domain.
Immature programmer
Thursday, April 22, 2004
Games like Blizzard's World of Warcraft are budgeted with over 10 Million and have a development team ranging anywhere between 20 and 60 members, including net coders, game engine, graphics, sound, physics and much more. With expectations of no less than 2 to 3 million sold units world wide, they will be hosting hundreds of thousands of customers simutaneously. What is the programming difficulty of a project like WoW and how can it compare to the creation of a database engine like ORACLE?
Nubs
Monday, July 12, 2004
 Recent Topics
Fog Creek Home
| 
