Good read!

Oh my gosh! The non-compiled size of the project was 5 terrabytes?

Very interesting read.

It's amazing what you find out about end users and how they behave. It's funny, it's never the customers fault. I am an IT consultant by profession, and when I used to do home pc work - it was a nightmare. They would tell me they never had a virus or downloaded spyware - or used PTP torrent sharing - --- until I opened up the logs or internet history or quarentine folders to see. Then complain when I charged them $200 to spend 6 hours cleaning their drives and OS of hard to find worms, bugs and other crawly things and restoring it to zippy good health.

Or tell me they had 'lots' of free disk space - over 1 GB - to find out the were talking about memory, and their hard drive was about to explode it was so full ---- my head would explode.

Or complaining that the internet did not work - that I broke it - only to drive 10 miles back out to their house to find out they had used an RJ-11 phone cord to connect their pc to their hardware router that I installed because they wanted to move it to another location and the cable I gave them was too short.

Very intereasting read! Don't ever stop doing interveiws/blogs like this.

I really appreciate articles like this. I will definately read this again a few times while I am programming my game. Thank you for being the best game developer in the industry.

Very interesting article i must say, one of the best i read the last months, found it quite gripping (?)
(excuse me please, English is not my native language,).
The spirit and philosophy behind stardock is very pleasant and familiar to my own sometimes -
conservative - style. Something like this article is surely one of the many secrets of your success -
your 'hot wire' from the top of stardock to every user in the forum.
In eleven years of pc gaming i never saw anything that was comparable. Stardock is an
outstanding developer (& publisher) and so far of that was i seen GalCiv2 is an outstandish
game. It has now remove Colonization from the first place of my favourite alltime-games.

'...a dialog that will simply not allow them to play the game until they update their drivers.'
that would be bad for me, should i realy update my old video card driver? (I'm ducking)
It (nvidia 71.89) works fine with my old Geforce Ti 4600.

And since i installed GalCiv2 i had no problems with the game, no CTD, no one of this mysterious region setting problems,
My german version 1.0X.2 works with the german region setting. I tested it in my dual boot system with Win98 and WinXP.

Only minor problems with the german localization, but such things i can handle by myself. I'm old and bold enough, -
the fifties coming closer to me. But as our suebian poet Schiller said: 'As long as a man played, he would never get old.' unfortunately he played for money and mostly lost.

But seroius Your article had convinced me, i make an attempt with nvidias newest stuff.

Can't better say as Omega wrote it:

Keep up the good work! Don't ever turn into a soulless corporation!

Dreaming to nite full of expectation forward to GalCiv III - perhaps with a greater universe 48x48 squares or so...
must not mean with much more stars only with more ... space between the stars an' clusters.

Nice Read, and thank you for allowing "regular people" to get a bit of a look at what you live normally. I wish more companies would take your approach and be up front with users, talk to them (even half as much as you do), listen to them, and see them as more than an income stream.

Thank you!

The first word of the update is spelled incorrectly.

Interesting article, as usual.

I read that yesterday, really interesting story.

Secondly, users won't heed warnings or readmes. Next time, the game will have a dialog that will simply not allow them to play the game until they update their drivers.

What about laptop cards, and vendor specific cards that won't work with the regular Nvidia or Ati drivers? Not all companies keep their drivers updated.

On driver updates... The suggestion of a .ini setting is probably a good one. Or something that forces the user to do something more involved than clicking an "I don't care" button (as I usually call the "I accept" button nowadays). Maybe make them type something in that they accept that any crash is their fault. Or detect when the game crashes, and tell them next time the game runs that "we're not kidding, you really need to update your drivers!"

There's nothing I hate more than a game that *thinks* it knows that it can't run on my hardware, when it's demonstrably wrong. I don't mind if they warn me, or make me jump through a few hoops. Worst example I can think of is a game demo years ago that claimed my Cyrix processor just couldn't handle its awsomeness, when a friend's much slower Intel processor worked fine... and after fooling the demo into thinking I had an Intel, I had no problems at all. There's also the current flap over Skype on AMD and Intel systems that's along the same lines. Complaining about driver versions isn't as slimey, but...

Very interesting read on the article.. nice to get an inside view of some of the things that can happen during a project like this.

Because there's a counter argument to how I tend to do things: From a career point of view, unless you plan to spend the rest of your career making games, you need to learn and keep up with these new techniques so that you don't one day wake up as one of those 50-year-old COBOL programmers who has long since fallen behind the latest techniques.

I find this disappointing. Granted, I find this generally conservative attitude towards new technologies disappointing in any programmer (after all, these new technologies exist to make our lives easier). But I'm specifically disappointed that you let this get in the way of being a professional. It's one thing for people on a project to have different coding styles. It's quite another when you (as lead programmer) allow this to become a personal problem.

Face facts: those new technologies are already hitting the gaming world. C# is going to become a very important part of game development in the next 5-10 years, without question. Scripting languages already are a vital component to most game development. Modern use of C++ (templates, STL, smart pointers, RAII, etc) is a vital component of game development.

And if you don't read the writing on the walls, you're not going to find good programmers who are willing to program like it's 1999 anymore. Pick up a few books on some of the new languages out there. Study them. Hell, just read it for fun; all kinds of new ideas will start popping into your mind when you do.

License more technology. One of the things we learned is that we will likely license more of our technology in the future. For instance, GalCiv I had its own built-in sound system. This time, we used the Miles sound system that we licensed from Rad Game Tools. It was much much better and easier to work with.

You really should look into Ogre (for graphics). Not that your graphics system was bad or anything. But it would have saved you a great deal of time and effort to take Ogre as your graphics rendering system.

Never "force" a user to do something like install new drivers to play your product. There may be legitimate reasons why they refuse to upgrade them.

Example: Alias (now Autodesk) Maya7 users (3d program) have issues with using the newer nvidia drivers. The only drivers that currently work well with this important application are the 7x.xx version drivers. The 8x.xx drivers have alot of issues. Oh and 7x.xx drivers work great with all games but your performance isn't as high and they arn't as optimised for some of the newer features of nvidia cards, But they do work, just not as fast. (if something didn't work then I know the issue is on my end)

Now if you forced me to upgrade or force installed a driver on my system I'd be pretty pissed, that is not your domain. It's mine. My problem not yours.

While you will no doubt have impatient ignorant people who will click past warnings and will moan and complain that things don't work, there is nothing you can really do about that without upsetting people who know better. The ignorant people will learn their lesson and be smarter next time. Such is the way of using computers. They do and will for quite sometime require a reasonable amount of knowlege to care and maintain it.

I did Microsoft OS tech support for TWO years, the foolishness of people can get to you sometimes, but patients and educating individuals is the key. Simply ignore those who refuse to listen and learn. If someone was beligerant or argumentitive we would ask them to call back when they are ready to proceed. If they still wanted to give us grief we would simply tell them that we are terminating the call (and yes you can get yourself blacklisted from microsoft support, but you gotta be a real a** to get to that point). Some people refuse to learn. there is nothing you can do about it except force it on them, but that just creates problems for everyone else.

I find this disappointing. Granted, I find this generally conservative attitude towards new technologies disappointing in any programmer (after all, these new technologies exist to make our lives easier). But I'm specifically disappointed that you let this get in the way of being a professional. It's one thing for people on a project to have different coding styles. It's quite another when you (as lead programmer) allow this to become a personal problem. Face facts: those new technologies are already hitting the gaming world. C# is going to become a very important part of game development in the next 5-10 years, without question. Scripting languages already are a vital component to most game development. Modern use of C++ (templates, STL, smart pointers, RAII, etc) is a vital component of game development.

Wow Alfonse. Do you have a list of commercial PC games you've been project manager of?  Do you know of any commercial PC games made with C#?

There's a lot more to making a commercial product than simply using the latest gee-wiz technologies.  I happen to know C# incidentally.  I am also reasonably familiar with most of the STL features, Boost libraries, etc.  That doesn't mean I think we should just jump in and use everything.

When you're using "new" coding techniques in a complex project there's a lot of other issues to consider.  How thread-safe are given libraries? Are we using libraries or tools in ways  they haven't been used before and hence possibly creating a support issue?  How readable is the code that is produced by a given technique, library, code base?  How good are the available debug tools at dealing with a given set of techniques, libraries, etc.?  How compatible with existing in-house libraries and tools is a proposed set libraries, tools, etc.?

Yes, I'm a conservative developer -- I'm interested in making products that work, can be maintained, and don't cost a fortunate to develop.   But that doesn't mean I don't keep up on trends. I just am conservative about which trends I start putting into million-dollar plus projects.  It's not about the code, it's about the game.

You really should look into Ogre (for graphics). Not that your graphics system was bad or anything. But it would have saved you a great deal of time and effort to take Ogre as your graphics rendering system.

Ogre didn't go 1.0 until this past year, far far too late for our project. Secondly, it's LGPL which precludes us from using it (yes, you can use LPGL with a commercial product but you have to ship your object files with the game which is not going to happen).  And it hasn't been used on any game projects of significant size.

I want to emphasize: I'm a game developer. I want to make games. I don't get all hot and bothered about using some tool. I don't care about writing the code, I only care about making the game itself.

Programmers program; they write code. That's what we do.

Code is nothing without results. If you indiscriminately throw new technology at an old problem, chances are good that you'll introduce entirely new problems into the mix and create a lot of chaos. That becomes even more true when you are dealing with a large project with many people working on it.

The best (group) programmers are those that recognize that their code is worthless unless the entire project is completed reasonably on time and bug-free. This means working with everyone else, making sure everyone is on the same page, and not charging off into something new. It also means realizing that yu may not be the one who maintains your code - in fact, you may not even be the one who finishes your code.

And if nobody's willing to prove unproven technologies, then nobody would ever use anything other than what they already had or made themselves.

There are more ways to prove unproven technologies than throwing them into your most recent, extremely expensive, group project. More sane ways, too.