Apr 21, 2011

Personal Choice of Version Control System

UPDATE: I have changed my mind on this. Read my new blog post on this.

Being in the gaming industry about 10 years and playing with some open-source projects means I have dealt with different version control systems, or VCSs, from complete free, brute-force manual file copy method to very expensive commercial-grade Perforce.

So which program am I using at home? Subversion.... I know! A lot of people will argue that other programs are better, and I am not gonna say they are wrong. The reason why I'm using Subversion is because it does what I want with the least amount of annoyance.  Below is the list of what I need/want from my personal VCS and how the most popular VCSs do the job:

Windows Support
Yes, I'm a MS whore.  I use Windows all the time, and I, as a game programmer, personally don't see huge need for Linux for myself.  Also if I can maintain only one OS at home, that's less drama for me. (Yay?).
  • Git(-2): I like Git a lot, especially how it handles branches, so I really wanted to use it on Windows.  But, as far as I know, the only way to use Git server on Windows is through Cygwin or msysgit.  Cygwin is basically doing Linux emulation in a sense, and I personally don't enjoy installing Cygwin. msysgit is a bit easier to install on Windows, but still I had to set up SSH or what not, so there's no one-button solution for Git on Windows.  So big no-no to a MS whore like me.
  • Perforce(+1): Perforce supports Windows pretty well.  It comes with easy-to-install server program/service for windows.
  • Subversion(+2): This was actually a big surprise to me.  There is a program called VisualSVN Server, which is one-click solution for Subversion server on Windows.  It just works and comes with https access and access control all in one nice and simple GUI.  This was even easier than installing Perforce.
Occasional Multi-User Support
Although my VCS is mostly there to keep a history and backups of my own codes, sometimes I open it up to my friends so that I can get useful feedback from them.  So having multi-user support is very useful for me.

  • Git(+1): Git can easily support multiple users.  But setting access control for each users can be a bit of PITA on Windows.  When I tried it last time, I had to make fake Windows user accounts and hook'em up with SSH.
  • Perforce(-1): Perforce is free for either i) 2 users and 5 client workspaces, or ii) unlimited users and up to 1000 files.  I have more than 1 friend (at least I wanna believe that :P ) so first option doesn't seem to work that great.  What about 1000 files and unlimited users?  Well, I've already passed 1,000 files: Playing with 3rd party open-source project breaks this boundary very easily.  Furthermore, I don't want to pay a few hundred dollars for the simple need of VCS.
  • Subversion(+2): As I said earlier in Windows Support section, VisualSVN Server comes with a nice GUI where you can simply setup users and access control.  So another big thumbs up from me.

I'm cheap. I love free stuff.

  • Git(+1): free
  • Perforce(-1): free for limited use. And apparently I'm not limited?
  • Subversion(+1): free

GUI Client
I'm in love with Perforce's nice GUI clients. Not so much with P4V; more with P4Win. But P4Win is discontinued.... Oh well, P4V is still good enough.  Sure, I still use command-line a lot for certain things GUI clients don't support, but I found 90% of time, using GUI clients are much faster and easier.

  • Git(-1): it doesn't have any nice free GUI client as far as I know.  There are some being developed at this moment, but they don't seem to be mature or free enough to use them.  TortoiseGit is good enough most of the time.  But I still prefer P4Win style, real GUI clients. 
  • Perforce(+2): P4Win is awesome. P4V is great, too.
  • Subversion(+1): I found a program called SmartSVN.  It has limited functionalities unless you buy the pro version, but I found the basic free version is good enough for day-to-day operations.  Anything that cannot be done through the free SmartSVN version, I use TortoiseSVN.  Then anything that cannot be done by TortoiseSVN, I use command-line.  
Who doesn't love branching?  It's such a neat tool to fuck around(read it as experiment) your code without ruining your projects.
  • Git(+2): I love the powerful branching feature of Git. You don't need to make a copy in different directories, so it helps a lot with path referencing in the code.  Say you have a program that links with library Awesome, and now you wanna branch library Awesome.  With Git, you simply need to switch to different branch and build.  But with other source control systems like Perforce, you will have to branch the library into a different directory and change the library path in your program code.
  • Perforce(-2): As I just explained in Git section above, branching into different folder sucks.  Also the speed of branching a large number of files is slow because Perforce server controls everything.  Network speed is slower than your HDD's spin rate.
  • Subversion(-1): The speed is fast enough.  But still you have to branch into different directory.. uggh.. that bothers me.

Final Score
So final score for me is like this.
Don't forget.  This is the score for my personal need. Not for the big giant game studios.  So if you ever comeback and say "but Perforce is better because it can supports 200 users easily", I'm gonna make you watch this video for 2 hours before you go to bed.

Apr 19, 2011

Shipping Mindset

As some of you already know, I'm currently finalling a game called Space Marine.  So it's obvious that everyone needs to shift to the Shipping Mindset.

The Shipping Mindset is basically about being extra careful on changes you make since everytime you touch something, there is chance that you break something else. Sure, normally it's not that bad.  You can fix it sooner or later, but at this time, you wouldn't have enough time to test everything that used to work again.  So what happens if a crucial bug doesn't get caught by the time the game is submitted to the first-party publishers, such as MS and Sony?  You will fail at certification, and you will re-submit with the fixes.  Not bad. eh? Oh, did I tell you that each submission easily cost the half of your yearly salary? Now you think it's bad? Hope so.

So, with the Shipping Mindset, this is what you MUST and MUST NOT do.

  • fix broken things only: As said earlier, any code you change might break other things.  Please, don't risk your whole project for whatever excuses you come up with to fix things that are working fine.
  • do NOT beautify existing code to your taste: you introduce more bugs while you are moving around codes, changing 4 spaces to 1 tab, breaking a line into multiple lines and so on.  Just make a note and fix it for your next game.  Also I should say that if there's some coding style you don't like, but it's everywhere in the codebase, the chance is that most people in your company agree with that coding style. Maybe you are from the Wild West, but 21st century is not the time for a cowboy programmer to shine.
  • fix things that are not right to gamers(or testers), not to you: You found something that's mathematically wrong? Don't fix unless the end-users care about it.  Did you know even Photoshop is mathematically wrong?  Photoshop users don't care, and for the same reason gamers don't care about mathematical correctness.  Instead, this math change could impact your fellow contents producers.  "Hey, some math changed, so contents need to be changed too.  Do you have enough time to fix all the arts you've been producing for the last 2 years? What? No? But it's mathematically correct."  If you ever make this type of argument, you are being inconsiderate.  Noone cares about your own satisfaction for being a math-wiz. 
  • if you find something you think it must be fixed, talk to everyone who could be even remotely affected by this change: other people might have something more important things to fix.  If that's the case and your fix adds too much burden onto other co-workers, it's better not to fix your bug.

I always thought whatever I wrote above is a common sense for any developer who shipped at least one game, especially on console. However, my belief has been proven wrong recently; for the last month, I was hit by numerous bugs produced by a self-claimed seasoned console game programmer and I had such privilege to investigate those bug to simply find out they had been caused by the missing shipping mindset of that programmer.

Programmers, please be considerate and be responsible for your code at least once when you are finalling.  I seriously beg you.