I remember one of the big war simulation companies, like Activision, having a Google IO session about how awesome their share moments to YouTube feature turned out. Users were happily sharing videos of their game all over the freaking place. Massive grass roots advertising and engagement. Someone will play the same thing 50 times just to record the perfect one to show off on YouTube.
I wish it was easier to implement. Taking screenshots and encoding them seemed too resource intensive for mobile. I did start tilting my app architectures toward streams of events that could be sent to a server and the graphics reproduced, though.
Maybe that's what is happening here. Instrument all Cocos2d calls and replay them to regenerate the video.
Yep, Call of Duty had a very successful YouTube integration (http://apiblog.youtube.com/2011/07/youtube-google-io-your-ga...). And yeah, we totally agree that being able to share videos with friends will lead to greater engagement and help others discover cool games.
We have made this super simple for game devs - we have a startRecording and a stopRecording API. Round based games lend themselves well to starting recording at the beginning of the round and stopping at the end without bothering the user. So, the cocos2d calls don't have to be instrumented and replayed. Check out http://kamcord.com/documentation/ for the details.
In the past I couldn't be bothered to deal with recording / saving my "performances" but in the 1-2 games I play where Kamcord is supported I now basically record everything cause its fast and easy. No noticeable performance / FPS hit either, which is great. Now if these guys could just hurry up and make it work with Temple Run & Drag Racing...
I noticed this implemented pretty well on the cloud OnLive gaming service. I am curious to know how they are recording the actions though. Is it capturing the frame buffer directly with OpenGL? There'll be a bit of a performance penalty associated with this but for 2D games it might not be so bad.
I'd suggest supporting something like MOAI (getmoai.com). Its cross platform and open source.
I think this is a great idea and will take off. We're launching a game in the next couple of days (with MOAI). Once its available we'll add it in for sure.
I feel minimal performance hit is an understatement. Assuming that screen captures are taken at a much lower frame rate, there's still disk write operations involved and writing 15x per sec to disk is definitely not minimal.
We use the same technology that Apple uses in its native camera app to write video. That experience is pretty seamless and has been optimized by Apple to not impact performance. We can record gameplay at 30 FPS while leaving the actual framerate at 60 FPS, as all of the games we are integrated with show: http://www.kamcord.com/games
The native camera is the active application when someone is using it, but for Kamcord's recording, the game is trying to render at 60FPS and Kamcord running in the background, how is it the same?
I'm just curious to know more about the "technology" that you are talking about since I'm pretty familiar with iOS's SDK.
I wish it was easier to implement. Taking screenshots and encoding them seemed too resource intensive for mobile. I did start tilting my app architectures toward streams of events that could be sent to a server and the graphics reproduced, though.
Maybe that's what is happening here. Instrument all Cocos2d calls and replay them to regenerate the video.