Posts Tagged games
Framerates do matter.
Posted by The Management in design on January 6, 2010

A while ago I was reading up on Starblade, one of the first commercial polygon-based games. What really struck me about the game was just how smooth it was compared to its spiritual successor, Starfox (granted the above links are YouTube videos that don’t accurately reflect framerates, but the differences are still quite noticeable).
It’s an extreme case, but one that nicely demonstrates the importance of rendering speeds.

Despite having animations that consisted of only 2-3 frames, many classic games ran at 60fps. This granularity helped to smooth out movement, including Mario's beloved jump.
Of course no one ever complains about games being too smooth, but the debate of 30fps vs. 60fps continues to pop up. What’s more, the 60fps side keeps losing ground, often to the argument that humans can’t really detect more than 30 frames in a single second.
And that is completely untrue.
It’s an inherently flawed statement as humans are not digital machines. The human brain is always on, always receiving input. Light hits our eyes as a wave, and the information it carries is almost instantly transmitted to the Visual Cortex. The brain analyzes this data, focusing on changes brought on by motion and fluctuations in intensity. Displacement is interpolated via motion blur and identical input is discarded to avoid extraneous processing.
The “decoded” image is further analyzed by various parts of the brain, but the overall process — as complex as it is — is quite fast and versatile. Much faster than 30fps. Faster than 60fps, in fact.
So where does the myth of 30fps come from? Well, film and TV for the most part, but the framerates of those media are not analogous to those of videogames. Others have written extensively about the topic, so I won’t go too deep into it. What I’d like to talk about, though, is why high framerates are important to games.
As a preface, different titles obviously have different requirements, and some suffer more from a low FPS than others. Also, the reasons for Insomniac’s decision to move away from their 60fps standard were completely understandable, if a little painful to accept.
With that said, here’s why I think high framerates are important:
1). Granularity
The framerate of a game is usually directly tied to the processing of its logic. As a result, action games that run at 30fps cannot have the same granularity of movement as those that run at 60fps. This might not matter much for turn-based strategy titles, but it makes an awful lot of shmups technically impossible to do at lower framerates.
2). Input Lag
Games are inherently an interactive medium, and as such the response times for input need to be virtually instant. On the hardware side this is rarely an issue, but a stuttering framerate can reduce the response times and greatly detract from the overall experience (especially in “twitch” titles).
3). Consistency
30fps isn’t bad, but what most people fail to realize is that it’s often the “ceiling” measurement, i.e., the best case scenario. Unlike TV and film, games are dynamic, and the processing required to render any given scene can fluctuate quite significantly. As a result, 30fps games actually tend to run at a rate of 20-30fps. These sort of inconsistencies can be very difficult to avoid, but they’re much less noticeable with higher benchmarks.
4). Motion Blur
Motion blur is the biggest reason TV and film get away with smaller framerates. The phenomenon of motion blur relies on the human brain’s ability to stitch together a series of blurred images into a single, smooth animation. Until fairly recently, games had absolutely no motion blurring, and even these days it doesn’t have quite the same effect. The reason for this is that post-process blurring is not always accurate, and in many cases purposely exaggerated to create a distinctive visual effect.
To properly accommodate for all these factors, a high framerate is a must. And when it’s there, it creates a certain synchronization between the player and the game; a smooth flow that more developers should strive to achieve.
Make games for the Xbox 360 without knowing how to program?
Posted by The Management in miscellaneous on February 20, 2009
Recently I decided to use my free time (hah!) to check out the XNA Game Studio. For those of you not aware, XNA is Microsoft’s outreach program to the homebrew/indy community.
The Game Studio itself is a suite of tools that can be used to make games for Windows, Xbox 360 and Zune. It’s not quite the same as Xbox Live Arcade, but similar in scope. What really surprised me, though, were the XNA tutorial videos. There’s a whole bunch of them, and some even assume that you know nothing about programming.
So how much can you really get from ‘em? Well, the videos take you step by step through various programming concepts and conventions, but eventually you will need to learn how to program. Or at least get very good at tweaking others’ code.
Still, this is as good a start as any.
When I began to learn programming — always with the intention of making videogames — I was a bit overwhelmed. There were a lot of languages, all with their own libraries, and all dedicated to particular pieces of hardware. Also, they seemed to universally cater towards tasks that had nothing to do with what I wanted to learn.
Eventually, though, I decided not to worry too much about the starting point and just dive in. The semantics of programming languages and their APIs vary, but they carry over, and the concepts are 100% portable.
In general, software tends to resemble a clockwork mechanism; a sprawling contraption of numerous interconnected parts. The logic behind each part is never that difficult to grasp, but the whole picture can be a bit daunting. Tweak and slowly change around the parts, though, and you’ll start learning how the whole thing functions. The XNA tutorial videos encourage this, and even point out places where you might want to experiment and where you should go to learn more. There are also plenty of videogame specific tutorials, and some even include entire “construction kits” (small-scale game engines that contain numerous pieces of functionality).
Microsoft seems to have put in a great deal of effort into the XNA community, and it’s definitely worth checking out. And who knows, if you develop something for it, you might also end up selling it to millions of Xbox 360 owners.












Hi, my name’s Radek Koncewicz, and I work as a videogame design consultant. I'm also the creative lead of
Orange Box designer commentary.
Posted by The Management in design on February 27, 2009
Valve first tried out designer commentary with the Lost Coast standalone demo. Apparently it was such a big success that they decided to do the same for all the games in the Orange Box.
Now Valve is a group of some very, very smart people, and it shows.
Escape from City 17 at the end of Half-Life: Episode One.
Generic behind-the-scenes specials tend to tell the same old story: the development cycle was hectic, but the team eventually persevered and released a great product (even if it was a little flawed and missing some features). In between all that you might come across an interesting tid-bit or two, but don’t expect any mind blowing revelations.
The commentary on the Orange Box, though, is full of pure-gold nuggets. In fact, playing through its four commentary-enabled titles will probably teach you more about various aspects of videogame production than any game design book. If you haven’t checked it out but are in any way interested in videogame design, I urge you to do so now.
Here are just a few segments I picked out:
Read the rest of this entry »
behind the scenes, design, developer commentary, episode one, episode two, Game design, games, half-life, Lost Coast, Orange Box, portal, steam, team fortress 2, valve, Valve Corporation, Video game
1 Comment