The US Playstation site just posted our downloadable demo of Dark Mirror here. Download it, copy it to your memstick and enjoy!
Achieving work-work balance
Life-work balance always seems to be something that comes up in the games industry. Yesterday Kotaku put an article up about some former Insomniac developers that are setting up shop in China, promising to create a studio that supports a better lifestyle for the people that work there: “We want to make great games while living a good life.”
While I think their hearts are in the right place: “[we want our employees] to pay as much attention to their social and personal lives as they do their time at work,” a quote immediately following that one struck me as a bit of a contradiction: “We will have an onsite chef for breakfast, lunch and dinner… Massages, dry cleaning, company supplied drivers, language and cultural tutoring (English or Chinese), haircuts, fitness memberships, car washing and maid and grocery services…”
This sounds more to me like Google-style work-work balance than it does life-work balance. How do you have a 40 hour work week and justify buying everyone breakfast, lunch and dinner? What you’re really doing is creating a great working environment that encourages employees to stick around more often–not necessarily spending more time on their “social and personal lives.”
“Sorry I’m gonna be late tonight honey, I’m gonna eat dinner here and then take a massage. I’ll see you at 9pm.” Before you know it, you’re working 80 hour weeks again, the only difference is you’re happier doing it. Your family and friends aren’t necessarily happier though.
The article states that soon it won’t be possible to make games in the West without burning people out. I couldn’t disagree more. Crunches in game development are the result of poor planning and (sometimes–rarely) flat-out abusive management practices. People work this hard in games not because they don’t have a choice but because they’re willing to do it. We love what we do. It’s unfortunate, but often times employers take advantage of that. It’s our own damn fault.
It doesn’t have to be this way though. Many studios are starting to take a hard look at the game development process and management practices that lead to crunches. Andrew Eades (Relentless Software) has said numerous times that “you don’t need pizza-fueled crunches to make a million-selling game,” and his company is based in the UK. And this article from the International Game Developers Association states simply: “When used long-term, Crunch Mode slows development and creates more bugs when compared with 40-hour weeks.” The writing is on the wall.
I don’t believe the argument that Western game development is headed quickly to a breaking point. I think managers in the games industry are starting to come around to understand “work-life” balance, and are beginning to put in place new practices that lower workloads and schedule pressures. I see it all around.
Skype to POTS to VOIP = poor sound quality
My Dad recently discovered Skype and has been calling around using their SkypeOut 2.1 cents/minute rate. When he called my VOIP number I was a little shocked how poor the sound quality was. It was like talking to someone through a tin can and string with 1500ms latency.
Even though I’m on VOIP (via Packet8), I would assume that Skype wouldn’t be clever enough to detect my number as a VOIP number and use a VOIP link between us, especially since Skype’s protocols are supposedly proprietary. So when my Dad called me Skype was probably using a POTS (plain old telephone system) bridge of some sort. The sound quality problems were probably somewhere in this bridge.
I set out to find if there was a way my Dad could just call my VOIP number directly through Skype, and was a little surprised to see that there wasn’t. (OK I’m lying, actually I wasn’t surprised at all). Since there wasn’t, and my Dad now didn’t seem to be adverse to calling people from his computer, I sent him a link to Free World Dialup. FWD is sort of a global VOIP address book, except now they have their own free VOIP software that you can download to use it. (I had previously used X-Lite and was skeptical of their free offering, but it turned out to be a lot more user friendly than X-Lite). My Dad signed up for FWD, configured the software and can now call me from his computer for free.
What’s even better is the sound quality is great–no latency or artifacts. Forget Skype, if you want to call somebody on a VOIP number just use FWD! Check out their peering access numbers for more information.
Component-oriented programming
I’ve come across a lot of cases lately where programmers have made poor use of inheritance. A common situation I’ve seen are classes inheriting from other classes to gain some small set of functionality which results in a lot of special case code in both the child and the parent to deal with their relationship. The relationship between the classes may have started off well, but over time and many iterations by different programmers the relationship has become obfuscated. As a result it’s hard for yet another programmer to go in and make improvements. I guess you could say this situation is a lot like a kid that’s all grown up and needs to move out of the parent’s house: things may have started out well, but now the kid is different and the relationship is becoming disfunctional.
You can’t place the blame for the development of this situation on an individual programmer or a poor initial design decision. Usually, these sorts of relationships made a lot of sense at one time, and they probably continued to make sense for a quite a while. It’s only after many last-minute iterations or a few late night frantic programming sessions do these things start to appear. You might be saying, “well I would never let that happen,” or “if I saw something like that I’d fix it,” and that may be good and noble of you to say, but wouldn’t it be better if things were designed from the beginning to avoid it from ever happening?
This problem is especially apparent in game programming. The classic example is in game objects. Say you have a cHuman class and a cVehicle class. These both share some common functionality: they are both “moveable” and they are both game objects. The inheritance hierarchy might look something like this:
class cMoveable : public cGameObject…
class cVehicle : public cMoveable…
class cHuman : public cMoveable…
OK, now what happens when you want to add physics to the game? Does that go in cMoveable, or do you make a new class that handles the physics? Does cHuman get the physics functionality too?
What if you want to add a crate class, and this crate is not “moveable” by the player, but it is deformable (destroyable) by the physics system? Where would that go?
These are simple examples, but you can see how things may get quickly out of hand. Following this inheritance design after a few years of development you’ll end up with a big mess.
One alternative to a tangled inheritance web is to build classes by composition. Instead of having a cVehicle inherit from a cMoveable, have cVehicle own a cMoveable. cMoveable can then be made into the smallest set of functionality necessary. If you later need to add physics, have cVehicle own a cPhysics too. How does cPhysics communicate with cVehicle? cVehicle requests the interface cPhysics interface from it’s owner.
By compositing objects together through “ownership” relationships rather than “parent/child” relationships you can also build your classes with very strict interfaces. This is where the “component-oriented” programming comes in: cVehicle may not even know it owns a cPhysics–it may only have a reference to componenent interface (cComponent, perhaps). Each of these component classes can provide a standard interface that allows their owners, their owned components, and other objects to query for and request component interfaces from them, without the class itself having to know anything of the details.
The best part about compositing objects using a component-oriented approach is it allows you to completely data drive the object building process. You could have an XML, Lua script, or some other asset format instruct the engine how to build game objects. This puts game object development into the hands of game designers (where it should be), and puts the programmer in charge of developing the right repitiore of components.
I found these references useful while exploring component-oriented approaches to game object design…
Bjarne Rene, “Component Based Object Management,” Game Programming Gems 5
Chris Stoy, “Game Object Component System,” Game Programming Gems 6
Clemens Szyperski, Component Software: Beyond Object-Oriented Programming, Addison-Wesley 2003
Scott Bilas, A Data-Driven Game Object System, GDC 2002
The first chapter of Programming .NET Components lays out the case for component-oriented programming. It’s a great place to start, (and you can read it online)!