PDA

View Full Version : 'Business code' vs 'Game code'



VirtualAce
12-17-2006, 08:35 PM
Recently at work I've been working on a database for our department. Most of it entails components of Office 2000 utilizing VBA, etc, etc. I've come to realize that even though the business sector of programming always seems to require more experience, more knowledge, and more education....game programming is actuallyabout 100 times tougher.

So why the discrepancy here? Why do business post the alphabet soup stuff in their job postings when most of that boils down to a simple technology that has already been half written or completely written for you and all you do us utilize existing functions?

I was hesitant to apply for such things as database programming and so forth b/c I have a very hard time completing game code so I figured doing database code professionally was out of the question.

Boy was I wrong. This database stuff is actually quite simple and although it uses about 100,000 acronyms for various technologies...they are all quite straightforward.

Within a couple of days I had my own pop up windows with menus that opened databases, added to them, etc, etc. in Excel. Then I went to Access and it's not the toughest thing in the world once you get the hang of it.

It just seems odd for game companies, on average, to require less to do more. And then we have business who require everything you can think of...to sit and do something that is very simple.

Govtcheez
12-17-2006, 08:46 PM
Most game companies are a lot less conventional than traditional businesses. Tradtional businesses also just want you to be able to make stuff work (and work well), whereas gaming is usually about pushing the envelope as much as possible.

XSquared
12-17-2006, 09:12 PM
It depends what kind of business code you're working on, and what you enjoy. I've been working at my current job for about a year and a half now, and initially I was working on the boring stuff, but now I'm the 3rd most senior dev (small company), and I get to do the fun stuff. Examples of stuff which I call fun are: porting our codebase over from gcc3.4 to gcc4.0 and fixing all the breakages. Another example would be writing a custom shared/exclusive file locking mechanism to work on all of the flavours of UNIX which our prdocut runs on.

nvoigt
12-18-2006, 02:22 AM
In general, you are totally right: database programming isn't harder than game programming. It's different.



Within a couple of days I had my own pop up windows with menus that opened databases, added to them, etc, etc. in Excel. Then I went to Access and it's not the toughest thing in the world once you get the hang of it.


Excel and Access are to database programming what Macromedia Director or any other "BuildYourCool3DGameWithThisToolIn24h" applications are to gaming. It's horribly restricted, it's doing a lot behind the scenes that is better left to experts or at least real databases like Oracle or maybe MSSQL or MySQL. You won't notice your SQL shortcommings with Access because Access will do a lot for you and with Access you just don't have the amount of data, a database was made for. SQL is the language like C/C++ is the language. The difficult part is not the language. The difficult part is implementing optimized algorithms in C/C++ for games and the difficult part is implementing optimized queries and table layout in SQL.

With Access and 10K records, a badly formed query will take 1000ms instead of 0.3ms. That's probably less then the mouseclick event took VBA to handle. No one cares.

In the real world, a badly formed query in your callcenter application will not take 3 seconds while your callcenter agents jokes with your customer on the phone, but approximately 3 days searching through 100 Million adresses and a billion connected transactions in the worst way possible. And even if your service is for free and your callcenter agent is really charming, I doubt any customer will wait on the phone for three days straight.


As with game programming, database programming is all about optimization. I would say game programming is a bit tougher than database programming because generally speaking businesses look for database programmers who can handle the equivalent of a 2D Windows Tetris Clone that is running satisfying on a modern computer, while game programming seems always to be about the limits. I don't think you will get far in game programming without optimization techniques, while you can easily work with databases and never think about optimizing because the business in question just hasn't that amount of data. If your store has 10.000 Customers, a badly written query will run just as fast as a really good one. Same thing as that 2D Tetris Clone. No one would notice if I did that in GDI. Very few businesses have the need for optimization while everyone and their grandmothers dog want their game to be 4D DX12 optimized. Even Tetris.

Game programming scales better with math skills while database programming only gets easier with experience. With average math skills, database programming is way easier.

Mario F.
12-18-2006, 04:43 AM
Apart from what has been said already, business applications have a different set of challenges. For one, your problem analysis ability will be put to test. It certainly is easy to develop for an existing database, but it's quiet a different game to have to develop the database yourself.

On the other hand business rules and notoriously mutable and full of "except ifs" or "howevers". Coding successfully for a software that can and will change constantly is not easy at all.

Also available tools aren't always (in fact they aren't at all) the solution to business software of a respectable scale. Access certainly isn't the database of choice for anything but small sized companies. On the other hand some businesses or some business areas are simply extremely hard to deal with because of their complex rules. Try to code for a salary system for a mid or big size company. You'll see.

Companies require good (even excellent) coders for a number of reasons. Business software must run, run well, be reasonably fast, be consistent, most not have "acceptable bugs", must be scalable, must be precise, must be correct from the law and business rules POV, and must be ready to quickly adapt to changes on both.

The gaming industry certainly has its challenges, but the world of business programming is definitely not behind in any way at all. Connecting or not to Access and passing it SQL commands is not the whole story, it's not even a interesting part of the story.

Dante Shamest
12-18-2006, 08:08 AM
Companies require god (even excellent) coders

Wow. They're really upping the standards at these companies these days.

Mario F.
12-18-2006, 08:14 AM
Oops :) Edited

indigo0086
12-18-2006, 08:20 AM
cout << "Destroy World!" << endl;

IfYouSaySo
12-27-2006, 07:31 PM
It's a good thing they require 'god' and not 'God'. Because if I understand it right, there are plenty of gods running around, for example in the hindu religion, yet there is only one God (just ask a christian). So maybe their requirements are not so stringent after all. Just more proof of outsourcing, is what I say.

BobMcGee123
12-28-2006, 12:32 AM
database programmers are not people.

Period.

Frobozz
12-28-2006, 02:13 AM
All this talk about databases reminds me of a company I worked at for a short while. The software that was being used had recently been programmed in VB .NET. At the time .NET was a recent technology. But still, the program was horrible. It had tons of those so called "acceptable bugs" and whatnot. Drove me crazy. You'd accidentally enter something a text field didn't like and boom! Out went the entire database software and they would have to manually go in and correct the issue. :(

Shame they focused so much time on the database and not on actually checking if acceptable data was being put into the correct fields. :P

IfYouSaySo
12-28-2006, 11:36 AM
database programmers are not people.


They're more machine now than man; twisted and evil.

biosninja
01-08-2007, 10:55 PM
Imust admit....game programming is more dificult.

but just remember, not one business is the same regarding its business process/logic.

Jut an example, I work at a major finacial company in Sout Africa...Yes a bank....

the business logic and process are really complicated and the applications you write must cater for all of that

g4j31a5
01-09-2007, 12:13 AM
Apart from what has been said already, business applications have a different set of challenges. For one, your problem analysis ability will be put to test. It certainly is easy to develop for an existing database, but it's quiet a different game to have to develop the database yourself.



Well IMHO analyst and programmer should be separated because it will make life much harder for the person if he handles everything. Been there, done that. I've been an analyst, database programmer, and application programmer for the same project. Well, me and one of my friends that is. A living nightmare if I remember those days. Even worse, the company doesn't even use a computer. The filing system is still in papers. And the owner didn't have a damn clue about IT. He only assumes that IT is a "magic bullet" that can do anything without sacrificing anything.

Mario F.
01-09-2007, 02:23 AM
On paper perhaps. In practice most companies will not afford, or care to think, hiring one analyst and one programmer in separate. Most project managers do the analysis. But on most small to mid-sized companies (at least from what I know), they also program. And programmers join in the analysis process.

g4j31a5
01-09-2007, 03:33 AM
On paper perhaps. In practice most companies will not afford, or care to think, hiring one analyst and one programmer in separate. Most project managers do the analysis. But on most small to mid-sized companies (at least from what I know), they also program. And programmers join in the analysis process.

So true... So true... :(