GUI/Tools programming vs Game programming

Published October 08, 2015
Advertisement
Dear diary...

I've been doing a lot of GUI/tool programming for the last two months (mainly building a level/character/campaing editor).
And I have noticed a huge difference in my mental state while programming GUI/tools sutff.

As in, when I'm programming games, I'm constantly on my toes: "Is this efficient? Am I making a copy of this? What O(n) is this? How can I avoid this loop?" etc etc... basically I didn't realize until now that every time I'm game programming I'm like this:

Stressed-out-guy-at-keyboard.jpg
Pictured: 10.000 actions in 16 ms.


Now, don't think I'm a optimization maniac. In fact, after seeing this talk on gpp2015... apparently I'm not even doing enough.
I try to live by the rule number 1 of optimization: "Don't do it"; but I do tend to have a sense of awareness that if I can effortlesly redesign my algorithm to make it faster, I do, as long as it doesn't take me 2x+ the time to code it.


But... my eyes openend when I programmed my tools and my GUI. It felt like this:

summer-worker.jpg?1338906689
Pictured: 1 action in 100 ms.

My mind was like: "Iterate through all 20 items? Lol, sure... Open 15 files to build this menu? Be my guest!"

Like, the reaction time was huge (user dependant), the number of items being handling was ridiculous low, 20... 30 options. It felt like a vacation.

So, my question to you... Is this a normal feeling?

If it's not: am I doing something wrong? Game programming should not be more stressful than "regular" programming. Any advice?

If it IS: If this is a common feeling, I am seriusly considering not coming back to the game industry once the indie-dream is over. I mean, if I can feel this relaxed on my work environment (and the higher salary is nice too), then maybe my doubts about what industry should I go back to is easier to answer.

Any thoughts?
Previous Entry Character Editor is done
Next Entry New Demo out.
9 likes 9 comments

Comments

ferrous

You should feel like that for game programming as well, at least for stuff that isn't being done on a per-frame basis. Big O notation is interesting, but I think people get really caught up in it. When N is small, and only being done on startup or once or whatever, then yeah, don't bother optimizing it. You can find out of it's a problem later once your startup time becomes an issue.

October 08, 2015 08:22 PM
Aardvajk
Re industries, I've never gotten the impression that the games industry is the easiest way to make money as a programmer. I work for a small company in the business application development sector and find the pressures on me are nothing like those I have heard about from those who work in game development.
October 09, 2015 06:49 AM
Eck
Eck
I suspect game development is quite a bit more stressful than business development just for simple supply and demand. There's tons of people dying to break into the industry so game developer employers can demand more of game developer employees for less because there's 10 people lined up behind them waiting and willing to do the job.

That being said, business development is not without it's stress points. There are hard deadlines and performance concerns in business development as well. Performance for the mundane tasks is often ignored, but you don't always get a free pass. I was dealing with a database with millions of records identifying potential duplicates for a Customer Merge process. A naive implementation could not have worked, so I had to get fancy with my SQL.

I think game development is a much tougher job and you probably get paid less too. But again, these are just my suspicions. I have no proof since I've only been a professional business app developer.
October 10, 2015 03:46 PM
ferrous

I've done both. Games paid less, tended to be less professionally run, and had much longer hours. OS development on the other hand, sane hours, professionally run (if a bit corporate at times), and better pay and benefits. Granted the latter is way more boring most of the time. If you have the fortitude to do non-games and work on hobby game projects as leisure, then go for it. Though it can be hard to spend 8 hours coding, and then go home and spend several more hours coding.

Funny quirk though, OS development, because the turnover is so low, the onboarding process for new people was terrible. I was used to the games industry, where it's much easier to get ramped up to work, with step-by-step instructions on how to get machines set up, sync to projects, build the necessary bits, etc.

October 10, 2015 06:10 PM
desdemian

Thank you everyone for sharing your experiences.

October 11, 2015 02:32 AM
coderx75

I prefer to keep game development as a hobby and engineer enterprise applications/web services by day. I rarely work late which affords me some time to work on a game. This gets tricky though. I spend nights with the wife and kids so I'm usually up anywhere from about 3:30am to 5:30am. I'm at work by 7. I bring my laptop so I can work on the game during lunch. Sometimes, I get some time in at night on the weekdays and I usually knock out a good 8-10 hour day on the weekend. It's tough but I get the best of both worlds: professionally engineered solutions vs. crazy-fun game stuffs.

My two cents on keeping game dev sane:

- Learn to refactor and keep doing so until you have a solid, comfortable-to-work-within(TM) game framework

- Make time for the non-gamey stuff: tools, menu systems, etc.

- Make time for the cool stuff: I used to put all my time into the big tasks but have started maintaining a list of really cool, easy(-ish) to implement features and tackle those whenever things get stale. A lot of great gameplay and unexpected features have come out of this.

October 14, 2015 01:58 PM
tnovelli

I've dealt with some pretty hairy UI code in business apps and websites. On the web now especially, you have to worry about optimization to get a bunch of bloated javascript to run smoothly on smartphones. It's not exactly well-engineered; I only get a chance to do that in games. Grass is greener on the other side.

October 22, 2015 04:42 AM
sirpalee

Have to chime in on this.

I was working as a tool dev for a couple of years (and slowly migrated to an r&d position), and building tools / UIs are definitely not a simpler tasks than working on more lower level problems (like rendering). It's even harder, because you not only have to create a pleasing UI but also a very efficient / optimized workflow. Both performance and pipeline wise, move the least amount of data and do the least amount of calculations, because users (artists) want to have the fastest possible feedback from all their tools. Also, most of the times you have to do this inside a closed source environment (maya, unity, unreal whatever), and not only deal with the actual problem but the bugs and sometimes inconvenient inside your host application.

October 28, 2015 03:13 AM
Ed Welch

The guy in the second picture isn't a programmer. Dead give away: programmers don't wear suits! :-D

October 30, 2015 10:50 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement