Robert W. Rose

The US Playstation site just posted our downloadable demo of Dark Mirror here. Download it, copy it to your memstick and enjoy!

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.

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.

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)!

British Rails is a railroad building board game published by Mayfair. It’s sort of like the old PC games Railroad Tycoon or Transport Tycoon, except played at a slightly slower pace and, well, on a board. A lot of the early supply/demand video games were inspired by board games like this one. In British Rails you draw on the game board with a crayon for where you want your railroads to go, and move a little marker around that represents your train. You pick up supplies and drop them off at different cities according to the demand cards you’re dealt.

My wife and I love to play British Rails every now and then, and we recently came up with a variation on it that I thought was worth sharing. In our variation we simulate the railroading experience at a much higher level. There are no trains–just railroads and demand cards. Demand cards are also shared, which forces players to compete directly for supply lines. You earn money by connecting up supply cities with the current demands.

This variation would work in any of the games in the Empire Builder series, not just British Rails: India Rails, Australia Rails, Eurorails, etc..

Requires:

* A copy of British Rails 🙂
* A 6-sided die
* A unique set of tokens for each player: pennies, nickels, etc. would work

Game set up:

1. Deal out three demand cards to each player
2. Deal out three demand cards face up — these are the community cards
3. Give each player $60 and a crayon

The game is played in turns going clockwise from player to player. Each turn consists of:

1. Roll the dice and collect money for a connected routes (up to 1 route may be collected on per turn)
2. Build (up to $20 per turn)
3. Draw cards (so you have 3 cards in your hand)

Game end:

The first player to reach $250 wins.

ROLL AND COLLECT: In step 1, you roll a 6-sided die. If a 1 or 2 is rolled, the top row on the community cards is “active”. For a 3 or 4 => the middle row, for a 5 or 6 => the bottom row. If you have a railroad connecting a demand on the community cards that is active to a city that supplies that demand, you collect that amount. For example, if Coventry needs Hops for $9 (and it’s active), and you have a railroad connecting Hereford and Coventry, you get $9. You may only collect on one demand per turn. When you collect on a demand place one of your tokens on top of that demand.

Once a token has been placed on top of a demand, only that player may claim that demand. (There are three demands per card however, so other players can still claim those).

If there’s nothing in the community that you can–or want–to collect on, you may play one card from your hand and place it in the community and then immediately collect on it. The same rules apply for cards you play–the active row on the card you’re playing has to match the die roll. You can only play a card if you’re collecting on it too: you can’t just play cards willy-nilly. Remember once you claim a demand you have to place a token on it.

If you can’t collect on any of the community cards or cards in your hand you may take $1 from the bank for every city you have connected by railroads, up to $5.

If there are ever three tokens placed on a community card, that card is immediately removed from play.

If there are ever 6 demand cards in the community one of them must be removed at random. Roll a 6-sided die to determine which one to remove. All tokens on the card are returned to the players.

Once you’re done collecting from the demand cards, every other player is given one chance to collect, starting at your left (like Settlers of Catan). Same rules apply: if they don’t want to use a community card they can play a new one, and if they can’t claim any demand they can get $1 for each connected city, up to $5.

BUILD: In step 2, you can spend up to $20 to build railroads and connect cities. The same rules apply here as they do in British Rails, with one exception: you can only build into or out of ONE CITY PER TURN. You must begin building from a “big” city, and all of your railroads must be connected to eachother.

DRAW: In step 3, at the end of your turn, draw cards from the pile until you have 3 cards in your hand.

I think that sums it up. Enjoy!

Apple is great at making the old new again. 2-3 years ago you could easily get a Smartphone/PDA that had the same functionality as the iPhone for $300-400, it just wouldn’t have been as sexy or easy to use. Dell made a killer Phone-PDA-in-one there for a while that could play DivX on a 640×480 screen. It looked amazing.

But $499? Cingular only? 2 year contract?

I think I’ll pass. Too much, too late! 🙂

Make it $399 for an unlocked model or $149 w/ contract and I would seriously consider it tho.. Actually, I don’t even know about that. I’ve been device-less since about 2004. I lost faith in handhelds, it may take more than the iPhone to win me back.

From CNN: The government believes “meat and milk from cattle, swine and goat clones is as safe to eat as the food we eat every day,” said Stephen F. Sundlof, director of the FDA Center for Veterinary Medicine. Meat and milk from the offspring of clones is also safe, the agency concluded.

The article never addresses my primary concern with cloned food products: What happens when 10%, 20% or maybe even 50% of our beef comes from the same DNA “mother cow”, or possibly a small genetically similar group of cows? It seems like then it would just be a matter of time until a virus or bacteria strain crops up that has adapted to exploit some weakness of that cow, and then it spreads like wildfire throughout our cattle. But what if that virus was undetectable some how, and turned out to be the next Mad Cow Disease?

Maybe the FDA is within their jurisdiction “approving” cloned food products, but I would hope that the CDC (Center for Disease Control) or a similar agency would also examine the issue.

I hit on a pretty good mac and cheese recipe tonight. A few weeks ago I started with BBQ Dan’s recipe, and after a few modifications I think I hit on something pretty good and a bit easier to make.

Start by dicing up 6 oz sharp cheddar cheese, 8 oz medium cheddar, and 4 oz monterey jack. Melt 6 tbsp butter over low heat (real butter — no margarine). Slowly add 6 tbsp flour, stiring frequently. Once that’s going zap 1 cup 2% or whole milk in the microwave for 45 seconds, then add it to the butter/flour mixture. Repeat this two more times for a total of 3 cups milk, then bring the heat up to medium-low.

While that’s going put on a pot of hot water and start boiling 1 lb of elbow noodles.

When the milk/butter/flour mix is up to temperature, add about 1 tsp salt, 1-2 tsp black pepper and 1-2 tsp cayenne pepper, then start slowly adding the cheese. Start with about 4 oz of medium cheddar and 2 oz of the other cheeses, and then add more of each type of cheese as your taste necessitates. Depending upon the strength and flavor of the cheeses you’re buying you may need to adjust the ratios, but I found that 6/8/4 sharp/medium/jack works for me. I haven’t tried it yet but I think a hint of smoked gouda might serve well too.

Once the cheese sauce is ready drain the noodles and pour the cheese in. Mix it all up and bake for 30 minutes at 350.

I had an excellent hot buttered rum at Astro Lounge in Bend the other night, and I’ve been obsessed with making the ultimate hot buttered rum ever since. Here’s the best I’ve got so far…

Start with a tall 8oz glass. Get the top of it wet and dip it in brown sugar. Add a shot of 151. Light the 151 on fire and, holding it a little sideways, rotate the glass for a bit until the sugar caramelizes. Blow out the 151 when you’re done. Be careful not to burn the sugar! Add 1 heaping tsp powedered sugar, 1 heaping tsp brown sugar, a hefty pinch of ground clove, a drop of bitters, the smallest pinch-of-a-pinch of salt and 1/2 tbsp butter. Top with ~6oz boiling water and stir until butter has completely melted. Once butter has melted add a splash of half-and-half.

For a richer flavor, only use enough 151 to caramelize the sugar and for the rest use Bacardi Select or a dark rum.

Syphon Filter: Dark Mirror is starting to bring in some serious awards!

Best PSP game of 2006 from IGN.com: “…it showed everyone what the PSP could really do. It set the bar when it shipped earlier in the year, and no game has breached it since.” IGN also gave Dark Mirror runner-up for best graphics, and Sony Bend runner-up for best developer!

#3 game of the year on PSP from GameSpy.com: “Dark Mirror… absolutely floored us with what can be done on a PSP.“

Best PSP action game and Best PSP multiplayer game from GameZone.com: “Not only are the missions awesome but the multiplayer mode will steal your soul.“

Best game of the year and Best action/shooter game from eToychest.org: “It is, in a sense, the perfect game…“

#5 game of the year and action game of the year runner-up — on all platforms — from Game Revolution: “Here, finally, is a game that proves the PSP is a strong console in its own right—and for that, it is one of the best action games of the year.”