Repository navigation
Frequently asked questions_ja
Everyplay uses official iOS and Android SDKs and built-in device functionalities to capture video and audio as the game is played.
Everyplay helps your game succeed through:
- GAME DISCOVERY: the most powerful way for players to discover new games is when friends show the games they love - acquire new players through mobile replay sharing.
- ENGAGEMENT: create fans, enable players to bring in friends and build a connected community directly within your mobile game.
- PERSONAL EXPERIENCES: messages are more meaningful when they're from friends - make your games more personal and authentic to players through custom messaging and videos.
- SEAMLESS INTEGRATION: great for the user experience and even better for you - all the video game discovery, social sharing, personal expression and more happen automatically within your game.
- IT'S FREE: Everyplay is a free of charge service for developers and users.
For the iOS platform, Everyplay supports the following devices:
iPhone 3GS and later iPad 1 and later iPod Touch 4th gen and later
Everyplay SDK is possible to link against iOS 4.3 target application, but both playback and recording functionality require iOS 5 or later.
For the Android platform, most medium- to high-end devices are supported as long as they have Android 4.1 or later, and have an onboard H.264 encoder. For the devices that are not able to record, the recording functionality automatically disables itself.
Compared to many popular mobile gaming networks, Everyplay doesn’t charge a “platform tax” or charge a fee for using the service in your game. Instead Everyplay is free of charge for developers and end users. All viral & organic users acquired through Everyplay are free.
Everyplay is ad supported. Developers can promote videos shared from their game to large audience to acquire new users.
If you want to increase revenues, you can integrate our Unity Ads video ad product to display video ads in your game or app. Read more about Unity Ads at https//unityads.unity3d.com
In addition to integrating the Everyplay SDK, you need to provide access points to the end user to watch and share replays. These typically appear as instant replays in the game’s pause and end screens.
Everyplay allows you to distribute videos you like on the service to all of your users, and to do this you need to include either a video button (single video) or a video stream (the latest videos your developer account has shared or liked) in the main menu of your game. The main menu video function allows you to engage all of players and deliver powerful messages (e.g. new level pack, new update, check out awesome things created by other players).
Please note that watching videos doesn’t require the end user to create an account with Everyplay.
No, all sharing is always user-initiated. Users can opt-in to share their views and other actions with frictionless sharing to Facebook, Twitter and YouTube.
No, the user only needs an Everyplay account to share replays or to engage with other users (messaging, liking, commenting).
This is something we have on our upcoming features. Currently the videos are uploaded to our server where they are encoded into several different quality versions to support different bandwidth streaming.
We will be enabling developers a way to download their own videos as we update and expand our developer site.
For now, you can grab/capture the video the same way you would from say YouTube.
Statistics are a big part of what we intend to offer developers, see how players use Everyplay, what type of things do they like to share from your game.
We will be offering these statistics in an easily “digestible” form for developers own games once we have a chance to expand our developers side site.
Go to the video on Everyplay while logged in with the account that uploaded the video. By tapping the small info button on videos page you can select to remove the video.
Yes they can. From SDK version v1.0.11 onwards the users are prompted the Facebook, Youtube, Twitter and email sharing before they have registered or logged in. After they’ve shared they can choose to create an account or to close the dialog.
Nope, it’s all automated. Once your game goes live on the App Store and we detect a connection for a certified build; our system will know the game has been released and add you to our game listing.
We still require that developer upload creative assets for the games page at https://developers.everyplay.com before we can list the game on Everyplay; but players can start uploading videos right away.
- Social discovery, engagement and personalization!
Please see the overview of Everyplay at https://www.everyplay.com
- Increase revenues
Integrate our Unity Ads video ad service and increase your revenues with an opt-in, user friendly video advertising service. Read more at http://unityads.unity3d.com
- User testing lab
Use Everyplay recorded videos as a user testing lab. With the replays you can see how your players really play the game. What stops them from advancing or what frustrates them?
- Bug crunching tool
Use Everyplay during development see how testers play your game and what is the exact order of actions they did before an error occurred.
Everyplay is a social and mobile game network, recently acquired by Unity Technologies. We’ve delivered well over 120M FREE installs for social and mobile games through cross-promotion. Way way back, we were a social games studio, before we discovered just how powerful game discovery can be. Now, we are focused solely on enabling great developers keep their players more engaged, to grow their brand, and to drive FREE, organic installs.
Everyplay’s video capture leverages built-in functionality and an on-board H.264 hardware encoder, so there is virtually no performance loss: no impact on GPU and nearly zero impact on CPU. The video is streamed directly to the filesystem to avoid memory issues. The drain on the phone’s battery is considerably smaller than that of the game (especially when using 3D graphics).
Everyplay is built to be integrated easily with all game engines. In a typical case you can integrate the video capture with just few lines of code. In addition this you need to design how to show the replays to the end user (e.g. video preview that allows the user to watch an instant replay in the game over and pause menus) and how to allow the user to access see other videos you make public on Everyplay and plan to share with all of your players (e.g. a video button in the main menu).
For certain game engines like Unity3D, we provide built-in plugins for easily integrating Everyplay.
3. Do we need to worry about different storage configurations on different devices and versions? (iPhone, iPad, Android, etc)
No you do not, it’s automatic. Everyplay takes care of this automatically by detecting the device and adjusting the recording in accordance. The recording bit rate is optimized by an algorithm depending on device and resolution to create about 4-5 MB videos per minute.
Since SDK version 1.0.9 Everyplay automatically detects if the device has enough space to record on. When iOS tells the user it has ran out of disk space, it still has a few hundred megabytes left for internal use. When the user-visible disk space goes to zero, Everyplay will end any active recording and will not start a new one unless there's more space released.
5. Can I upload videos on to the service while I’m still developing without them going public to everyone?
Yes. When you share a videos from a development build of your game (build that has not been certified and released on the App Store) you will see a “private mode” option that is marked “on” by default.
Videos uploaded as private are not listed anywhere publicly and can only be viewed on by the user that uploaded them.
6. How do you handle saving of recorded videos on the device: do you have limited number of videos stored on the device?
Everyplay only keeps the latest gameplay recording. Once a new game is started, Everyplay deletes the old recording and creates a new one.
Sure if a gameplay session is extremely long, the bit rate is optimized by an algorithm depending on device and resolution to create about 4-5 MB videos per minute.
The video recording can run in the background for as long as the user plays. The user can the trim the video before sharing to highlight the best bits. There is no set limit for video length, but we recommend keeping videos to a maximum of ten minutes.
No, the front camera is not recorded by default. Users can opt-in to record video with the front camera or record audio-only while they are playing. They can also remove the front camera recording, add an alternative video or voice-only commentary before sharing the replay.
Note that as of this moment, front camera recording is not available on Android.
Everyplay takes care of everything, you don't have to worry about it
10. How does Everyplay handle video uploads and interruptions? Does it upload in the background while you continue playing? Does it continue to upload even if you exit the app?
Yes on both. Everyplay starts to upload in the background even if you continue playing. If you exit the app, it will try to continue uploading for another 10 minutes
As Airplay utilizes the same video encoder it may have an impact on game performance
12. Is it possible to detect when the user shares their video via facebook/twitter/youtube, so we can reward them?
Yes, there is a delegate in the 1.5 release that allows you to detect a share.
Please contact us directly via email (support@everyplay.com)
Thanks!
2. I have run into a error, crash, bug or some other event that is causing Everyplay or the game not to work, can you help?
First off, Everyplay should not crash an application; if this is happening then something is definitely wrong. If this is the case, it would really help if you could provide some logs from the crash (for example Xcode or "adb logcat" logs), information on what iOS/Android firmware version and device the error is appearing on.
3. How does recording work on games that have very long gameplay sessions, is it possible to limit this somehow?
Everyplay has a "continuous recording mode", where you can specify to for example to keep the last 5-10 minutes of recording; in this case the system will continue to record during the gameplay, but only keep the specified duration in memory.
The replay in only created at the point when you send the "stop recording command to Everyplay" depending on the game type, examples would be after a game ends from dying/failing or after a completion of a level. There is a "pause recording" option, but it does not create the recording at that point yet.
The expired message comes with development builds or pirated versions of your game using pre-january SDKs, not with games downloaded from the App Store or with a newer SDK.
6. What is the link format that we have to enter in the field "iTunes link" or "Google Play package name" on the game configure site?
In the most simple format;
Examples: For iOS: https://itunes.apple.com/app/id533644081 For Android: com.everyplay.coolestgameever
7. Before submitting our game to the App Store or Play Store, do we somehow have to disable developers sandbox mode?
No, this is done automatically. Development mode is not available on games acquired through the App Store / Play Store; Everyplay detects that the game is a release signed build and disables these features.
8. A new SDK version is out, when should i update Everyplay in my game? Will this require a lot of work?
It's recommended to update the SDK every time you are patching the game. The SDK is built with backwards compatibility in mind, so you shouldn’t need to do any changes. If there are changes required, the release notes will tell you that. Also, it’s always good to test the Everyplay recording & sharing before submitting to App Store. If you encounter any errors with our SDK updates, we’d love to hear about them.
We would need you to create and add Graphical assets for your game page on Everyplay, you can do it at https://developers.everyplay.com
Game icon: The same icon as in the App Store / Play Store. Game Promotional cover image: 800x4750 image to be used in Everyplay site and within games
Yes, there is a feature called continuous recording where you specify that you only want to record the last X minutes of the play session.
When this is activated, Everyplay will continue to record everything, but it will only remember the lengt you specified from the end. This feature is primarily intended for games that may have very long gameplay sessions.
SetMaxRecordingMinutesLength(int minutes);
For getting a thumbnail of the previously recorded session implement the EveryplayThumbnailReadyAtFilePath or EveryplayThumbnailReadyAtURL (the only difference is the format of the thumbnail path) from EveryplayDelegate to receive thumbnail notifications. The delegate will fire after the recording session is stopped and the thumbnail is ready.
The delegate protocol: https://github.com/Everyplay/everyplay-ios-sdk/blob/master/Everyplay.framework/Versions/A/Headers/Everyplay.h#L85
The interesting parts: EveryplayRequest (this fetches a list in the example, but by changing the url you can fetch only one clip) The request fetches the videos data: thumbnail etc. after this is done you can play the video by : [[Everyplay sharedInstance] playVideoWithDictionary:video]
13. I Updated my Everyplay iOS SDK to a new build, but I’m still getting the “Build has Expired, please update” error.
This is a issue with Xcode if you just drag and drop a new framework to a project, Xcode adds a new path to FRAMEWORK_SEARCH_PATHS
It's better to replace the framework/bundle from the folder where it's currently located than drag and drop a new one in Xcode project.
Otherwise, you might end up to a situation where the Xcode project claims you'll have Everyplay.framework against libs/everyplay-x.y.z directory but while linking, it'll use the first version that Xcode finds from FRAMEWORK_SEARCH_PATHS.
14. I upgraded Everyplay iOS SDK but not sure if it made the improvement mentioned in the release notes?
When drag and dropping a new framework to the project, Xcode adds a new path to FRAMEWORK_SEARCH_PATHS. Due to this, it's preferred to always keep your Everyplay framework in sync in the same folder.
We prefer git clone https://github.com/Everyplay/everyplay-ios-sdk.git and then do
git pull for upgrades instead of unzipping code to several locations and folders
across the hard drive.
Otherwise, you might end up to a situation where the Xcode project claims you'll have Everyplay.framework against libs/everyplay-x.y.z directory but while linking, it'll use the first version that Xcode finds from FRAMEWORK_SEARCH_PATHS.
First of all, while Everyplay is recording, it'll use a 32bit framebuffer for technical reasons.
With Unity projects, 16bit framebuffer is the default. Besides the extra cost caused by recording itself, your game might take more GPU fillrate than usual.
MSAA/Anti-aliased rendering is supported, but it'll come with a cost. To optimize extra memory usage while using anti-aliased graphics, switch to 32bit graphics so that Everyplay uses the same MSAA framebuffer you'd normally use.
On current devices and OpenGL ES implementation, MSAA rendering to texture has a heavy performance cost especially on iPad retina level graphics. You'll need to do testing against your app and see if it's possible performance wise to enable MSAA and recording at the same time.
Consider the following options on iPad3 or with retina graphics:
- Full 2048x1536 graphics without anti-aliasing
- 1024x768 graphics with anti-aliasing (upscaled)
- Disable anti-aliasing entirely
- Replace the use of MSAA with a shader based solution like FXAA
On Unity, you can disable Anti-aliasing from Quality settings: Set Anti aliasing to Disabled
The following concerns mostly Everyplay iOS SDK 1.7.x or older SDKs. With the latest
SDKs the integration has been changed into fully automated, check the latest example
applications and tutorials. However, if you still have problems with integration,
please contact us.
This shouldn't be an issue with Unity or Cocos2d engines for which we provide a built-in graphics pipeline integration. If you do have problems with Unity/Cocos2d, please contact us and if possible, prepare a test case.
With custom engines (currently supported on iOS only), if the screen goes black after the recording starts, it's most likely an
error related to your graphics pipeline's glBindFramebuffer usage.
In general, some simpler OpenGL apps only bind the framebuffer once while allocating buffers. In that case, a simple swap buffer like:
[everyplayCapture beforePresentRenderbuffer:defaultFramebuffer];
glBindRenderbuffer(GL_RENDERBUFFER, colorRenderbuffer);
success = [context presentRenderbuffer:GL_RENDERBUFFER];
[everyplayCapture afterPresentRenderbuffer:defaultFramebuffer];works out fine. For a simple test case to play with, check out EveryplayRecord
from everyplay-ios-examples and read the iOS Everyplay Tutorial
If glBindFramebuffer is called with each frame for your main framebuffer, make sure to
call afterPresentRenderbuffer: method after that with the same framebuffer, alternatively
you can just replace glBindFramebuffer altogether with afterPresentRenderbuffer:.
Both EveryplayCapture beforePresentRenderbuffer: and afterPresentRenderbuffer:
methods return a boolean. When recording, they return YES and may be used for optimizing
unnecessary OpenGL calls the engine would usually call. This is especially important for
EveryplayCapture beforePresentRenderbuffer: if using MSAA, as it is performing MSAA
framebuffer resolving and discard operations internally.
When recording, EveryplayCapture afterPresentRenderbuffer: binds to a custom
framebuffer, or depending on case, an internal MSAA framebuffer or the MSAA framebuffer
you provided. For technical limitations, an internal 32bit MSAA framebuffer is used
when having 16bit MSAA framebuffer. An internal 32bit framebuffer is also used while
not binding against MSAA framebuffer.
Both methods are lightweight and won't cause any performance overhead while not recording. It's preferred to always keep them integrated to your graphics pipeline.
Some engines store the original framebuffer id into engine specific structures and
call glBindFramebuffer outside the core OpenGL view handling, at the start of each
frame draw or within certain post-processing effects.
For these scenarios, you can set a lightweight callback in EveryplayCapture that can be used to know what's the current active framebuffer and upgrade the custom structures.
For example with Unity, there's a global variable gDefaultFBO that Unity uses within it's private rendering steps. For recording to work on several post-processing scenarios, we'll need to keep it's value up to date:
[everyplayCapture setActiveFramebufferCallback:^(GLuint activeFramebuffer) {
gDefaultFBO = activeFramebuffer;
}];With this callback, the framebuffer value gets updated with the help of
beforePresentRenderbuffer: and afterPresentRenderbuffer:, recording or not.
We aim to support a variety of different engines and use cases with minimal changes. While at first it may seem that parts of this integration could be implemented easier, there's always some performance pros and cons to consider, not to mention features on our roadmap resulting to this design.
The API that EveryplayCapture provides should be fairly safe and forward-compatible with our future SDK releases, sometimes there can be engine or device specific optimizations.
We recently launched the first feature that's directly benefiting from this design, the HUD-less recording functionality where you can snapshot the contents of your framebuffer to the video and then keep on drawing other elements that only show up to the device screen. Provided the rest of the integration is correct, it'll all work out without extra graphics state handling code, including MSAA support.
Quick recap:
EveryplayCapture afterPresentRenderbuffer: should be considered as the starting
point of your frame drawing. It's where the framebuffer is switched and we'll
start rendering to a video optimized texture.
In EveryplayCapture beforePresentRenderbuffer:, we'll use that texture to draw
a fullscreen image that gets displayed to your screen.
If the screen goes black while recording, it's caused by misplaced afterPresentRenderbuffer:
or that a glBindFramebuffer function gets called between afterPresentRenderbuffer:
and beforePresentRenderbuffer: calls.
In general, we try to be transparent with this and require no modifications to your audio code. At the moment, on iOS, you should be fine using the standard CoreAudio interfaces directly or common audio libraries such as OpenAL, FMOD or CocosDenshion.
For advanced, cross-platform audio processing, we recommend FMOD. It's also used by Unity and several AAA titles. FMOD is also available for Unreal Engine 3.
Unfortunately, we're currently relying on video post-processing backend that doesn't support both flipping and rotating transformations on videos at the same time.
For optimal recording performance, Everyplay sets a flip transformation on original raw videos and once they're re-encoded to several video formats after uploading, the transformation is gone.
Usually there's no need for rotating transformations, but on some cases the OpenGL view is initialized in portrait mode even though all the actual gameplay is in landscape.
For now, the best workaround is to renew the view handling to keep it in landscape mode and avoid glRotates or other extra for orientation handling, let the OS do it's job.
As you might notice the default behaviour in media apps such like the Music/Video player is not to silence sounds even the silent switch is on. This also applies to the Everyplay video editor. Our video editor requires a special audio session category for recording sound and video which does not respect the silent switch.
Another limitation related to the required audio category is that the Music player will be stopped when entering to the video editor. However when you exit the video editor the game audio category is restored but the Music player needs to be restarted by the user.
There are several different audio session categories on iOS for different purposes. Some of them respect the silent switch and some do not. The Live FaceCam requires a special audio session category for recording sound/video simultaneously with the game audio and unfortunately this mode is one of the modes that do not respect the silent switch.
Another limitation related to the required audio category is that the Music player will be stopped when a Live FaceCam session is started. After the Live FaceCam session is stopped the application default audio category is restored but the Music player needs to be restarted by the user.
21. How can I enable the Music/iPod player not to stop when returning to the game after suspend on a Cocos2d game with CocosDenshion background music (iOS)?
You can avoid stopping the Music/iPod player by setting the CDAudioManager resign behaviour to manual + kAMRBStopPlay.
[[CDAudioManager sharedManager] setResignBehavior:kAMRBStopPlay autoHandle:NO];You also need to add [[CDAudioManager sharedManager] applicationWillResignActive] and [[CDAudioManager sharedManager] applicationDidBecomeActive] to your AppDelegate. Otherwise Everyplay will override your CocosDenshion audio session category settings.
- (void)applicationWillResignActive:(UIApplication *)application {
[[CDAudioManager sharedManager] applicationWillResignActive];
// ...
}
- (void)applicationDidBecomeActive:(UIApplication *)application {
[[CDAudioManager sharedManager] applicationDidBecomeActive];
[[CCDirector sharedDirector] resume];
// ...
}Another way to solve this is to handle audio session category changes and background music playing by yourself instead of using the resign behaviour.