Steam is launching Big Picture Mode this week.  I’ve been excited about this since I hooked our gaming PC up to our big TV. I put together a list of products that you’ll need to do this properly. Monoprice is insanely cheap but makes up some of the cost in shipping. It’s worth it.

First, for A/V, use something like this HDMI cable for video.

ATI video cards have built in 5.1 audio, so feed this into your receiver to get full 5.1 audio for your games. It’s really simple and avoids the need for a dedicated audio cable.

I also believe in having a POWERED usb hub at the destination near the TV rather than at the PC. This is great for headphones and hooking up wireless devices without straining them (and depleting batteries). You will be using a wireless keyboard and mouse.

This USB hub is powered and has a ton of ports. I own 3 and can recommend them.

You will also need USB extension cord(s) in order to run the hub to your PC. Depending on the length, you may need a repeater which amplifies the signal. One or two of these ought to do the trick: link

For controllers, the best is the Xbox 360 wireless controller. Here’s an Amazon linkto the Xbox 360 wireless receiver. These just work. Plug it into the USB hub that is near your TV.

For i/o, consider the Logitech Wireless Touch Keyboard K400.

You won’t be playing games with that touchpad, but it does let you navigate without hassle from the couch. Yes, you can do things like use iPhone apps for navigating but they are all useless when your computer goes into the BIOS and you have to drop everything and plug in a usb keyboard. This is the way to go.

As for setup, the PC is in my office with a monitor hooked up via DVI. On Windows 7, use Windows Key-P to bring up projector options to switch between the monitor and the TV. This allows the PC to continue operating as a normal desktop machine while making it easy to switch to running it on the TV.

Because the computer is in the office, there is nothing fancy about ethernet or power running that has to be done. And it’s a hell of a lot quieter than an Xbox because it’s in the other room.

Finally, we put the computer into sleep mode when we’re not using it and set it to wake on keyboard press. With this setup, we can fire it up to watch a show or play music and then it powers down again without having to boot it fresh every time.

Make sure your video card has good performance at 1920x1080, since that’s your TV’s native res. No 720p here — 33% more pixels than an Xbox. We use an ATI 6970 for this and it’s quite good at running most modern games at 60fps with 2xAA.

Grab zap straps from Monoprice so you can neatly tie your USB extension and HDMI cables together after you run them to your receiver.

Enjoy!

There are two ways to really beat something up in a physical game: first, throw the object against the wall and, second, toss a heavy boulder on top of the object. The former can be thought of as impact damage. The velocity of the two objects colliding determines the magnitude of the impact.

The second is more challenging to get right. This iscrush damage. It takes some processing to determine when something is crushed and how badly it is crushed.

In some games, you have a crushing ceiling that descends slowly and squeezes players into the ground. Let’s take this simple example as a starting point and work from there: the crushing ceiling descends on the player. As the crushing ceiling pushes the player further into the floor, the player starts losing health and dying.

That’s great, but what happens in a more complicated simulation with rigid bodies that can roll out of the way? Perhaps a heavy block falls on an object, but the object squeezes out to the left. Sure, the big block penetrated your ball for a single frame, but this was quickly resolved by the physics solver by applying an impulse at to the proper point on the ball. You can’t simply tag the ball as crushed and respond with death in your game code.

The rest of this tutorial looks at addressing this problem with Box2D. Box2D is remarkably stable when dealing with significant mass ratio differences.

One way of solving this is to look at how long two fixtures (components of rigid bodies) stay interpenetrated and to apply damage when a time threshold has been reached. The assumption is that the solver does a great job of applying impulses to separate the two bodies, so when they fail, it’s a sign that there is not enough space for them to coexist. This is encroachment, and if it endures for a period of time, one of the encroaching objects is crushing the other one.

Let’s recap what we want out of production quality crush detection, and then we’ll get into an implementation you can build from.

• Detect impact damage separately from crush damage. Crush damage is the continuous pressure from forces from one object to another, causing encroachment. Impact damage happens in a single frame. These fire different gameplay events.
• Determine which object is crushing and which one is doing the crushing. A heavy object crushing another because of gravity is one thing, but an object with propulsion can push another object against the wall, causing it to be crushed. Horizontal pressures causing encroachment are still potentially a crush scenario!
• Compute crush magnitude independent of framerate. Keep in mind that force-based solvers tunnel in most situations. Box2D is no exception — if you have a long frame, you’ll tunnel further. We need to pass predictable and stable crush values to the game code regardless of framerate variability.
• Handle light objects bumping without crushing. If a paperclip lands on your head, you don’t want to die. Most players would object and promptly post an embarrassing yet funny video to Youtube.
• Scale the simulation to a large number of objects. Spot all of the opportunities to exit early in your crush detection routines and take advantage of them!

So, that’s what we want. In the second part, we’ll get our hands dirty with some source code.

Scripting languages have really fallen out of favor in modern game development. It’s easy to rile a working programmer up to a lather about poor debuggers, lack of threading or slow compile times related to a scripting language they were saddled with on a given project.

That said, the pendulum has swung too far in the anti-scripting direction.

The beginning of a console cycle is epitomized by a need for compatibility: “how can we ship on multiple prototype hardware platforms?” and tool efficiency: “how can we reduce the spiralling cost of development inherent in expanding horizons?” These questions led developers to make scripting plays in their engines.

In contrast, we are near the traditional end of a console cycle. We understand how to get a lot out of the hardware so the focus is free to move towards code execution efficiency in order to exceed the experiences players have had on the fixed hardware to date.

Looking past the consoles, memory latency is forcing us towards cache-friendly approaches to implementation which avoids indirection inherent in runtime bytecode interpretation and vtable lookups. Even if we push the CPU Ghz up, we aren’t going back to peppering our runtimes with vtables anytime soon thanks to memory latency overhead.

In this environment, it’s fully understandable that we would deign to avoid developing in languages like UnrealScript where only the rote engine-level loops are not bytecode interpreted. None of this means that scripting languages should be cut out of game development.

I see two places where scripting still beats out compiled code by providing new experiences for players:

First, scripting can be for one-off level scripting events. Scripts will always have a place as glue code. If you are nesting your loops in a level script, you have probably gone too far. Because you are not attempting to implement large parts of the game world in script and beacuse they do not run on tick, the performance impact is minimal.

A few lines of script is a natural alternative to abstract event firing systems. Visual scripting languages, ironically, are rarely informative at a glance. It’s much easier to see all of the code in one place than to click around a 3D blueprint looking for wires between entities and still need to guess at execution order.

The second use for scripts is more interesting. Right now, a big trend in games is towards online.

If you send state updates to your clients, the only way to add new behavior to your game is to patch your client. If you send script code for interpretation, you are only limited by the assets in the local cache and the hardcoded simulation to what your players experience.

The first version of Capture the Flag for Quake was written by Zoid before QuakeWorld. He took advantage of the fact that, before QuakeWorld, the Quake client was mostly a dumb terminal sending a subset of QuakeC over the pipe. Players could connect to his unique server without any mods and play CTF. This low barrier helped make Threewave Capture the Flag the first really popular Internet teamplay game.

If you are sending script over the pipe in 2011, please remember to fuzz your interpreter… and don’t drop in an off-the-shelf language that wasn’t designed with unsafe code in mind. Thanks.