[Note: To access chapter selection, click the fullscreen button or check out the video on the GDC Vault website]
After nearly five years of development and plenty of major changes along the way, it's safe to say that Polytron's Fez has quite a storied history. It all began with a very small team -- just one designer and one programmer -- but eventually became one of the most anticipated indie games of all time.
Just ahead of the game's debut in April, programmer Renaud Bedard offered a behind the scenes look at Fez's creation in a technical postmortem at GDC 2012, where he showcased the techniques he used and the lessons he learned while creating the mind-bending platformer.
Now, that session is available (above) as a free video, courtesy of the GDC Vault. It's a detailed, comprehensive talk that examines not only the programming techniques that powered Fez, but also the dynamic between Bedard and designer Phil Fish.
During development, Fish dictated the game's design, while Bedard implemented his ideas. Of course, that's not to say Bedard was just taking orders. As the game's programmer, he had to decide what was worth implementing and what didn't make sense. Fez might have been borne of Fish's imagination, but Bedard had to call some of the shots to make sure the game actually came together.
"As a programmer you know what's possible," he said. "At one point, Phil said, 'I think it'd be really cool if [the character] was built in animated trixels,' and I had to be the one to say, 'I just don't think that's worth the time.'
"You can always say no [to a designer], but you can't just say, 'No, I don't feel like doing this.' It's a discussion, and in this case, Fez is Phil's game... But at the same time he had to recognize my limits so we could make the game together."
For Bedard's full breakdown of how Fez actually came to be, simply click the Play button above to start the video.About the GDC VaultIn addition to all of this free content, the GDC Vault also offers more than 300 additional lecture videos and hundreds of slide collections from GDC 2012 for GDC Vault subscribers. GDC 2012 All Access pass holders already have full access to GDC Vault, and interested parties can apply for the individual subscription Beta via a GDC Vault inquiry form.
Group subscriptions are also available: game-related schools and development studios who sign up for GDC Vault Studio Subscriptions can receive access for their entire office or company. More information on this option is available via an online demonstration, and interested parties can send an email to Gillian Crowley. In addition, current subscribers with access issues can contact GDC Vault admins.
Be sure to keep an eye on GDC Vault for even more free content, as GDC organizers will also archive videos, audio, and slides from upcoming 2012 events like GDC Europe, GDC Online, and GDC China. To stay abreast of all the latest updates to GDC Vault, be sure to check out the news feed on the official GDC website, or subscribe to updates via Twitter, Facebook, or RSS. GDC and the GDC Vault are owned and operated by Gamasutra parent company UBM Technology.
|
Nice tv3d shout out btw! :P
I was curious about one aspect though, if I'm understanding things. I know the boxes are mostly instances and that each box was tiny in memory, but, wouldn't it have still been a good idea to have implemented some kind of group and then expand** option in the editor?
So as in expanding, for large blocks that are made up of lots of little boxes, couldn't the middle boxes have been eliminated once an object is complete, or the final block combined into one larger polygon with of course no middle? So like any poly model created and optimized for a game?
Wasn't this the reason that the XML files were so large, was because every trixel block's location was being noted, so even for the ones that were never visible? If the levels had been optimized, so that only that seen geometry existed, wouldn't that have reduced the size of the saved/loaded levels, even with SDL format?
Hopefully the above makes sense? If I'm thinking right, it of course woud not eliminate the need for culling, but it would at least makes some of the larger sections load faster?
And I used a similar technique for handling environment transitions on a site I built back in 2008. I created an image in Photoshop with the color range I liked for the different times of the day -- I'm using the same method again on a new project I've been building for the past month. Anyways, it was cool to see I wasn't the only one that had this idea and I figured that was the case, since it ended up being easiest approach. :)
Here's hoping FEZ comes to the PC. PC gamers that buy games generally own gamepads -- I had a Gravis back in the 386 days -- along with other inputs, and there's always key-binding. ;)
This would've worked but there are moving/rotating platforms in FEZ, and some object you can take with you and throw. This could have been a special case, but in general it felt easier to keep everything in memory and render selectively. Trile data is pretty light memory-wise anyway.
Though for the file loading (and level loading), I agree that cleaning up as a content-compile step is something I could have done. Not sure why it never crossed my mind... or if it did, why I decided not to... 5 years is a long time :o
As for PC, it's no secret that Xbox exclusive aren't forever. It just made more sense to make it a console game from the start, as we feel it was the best fit.