100TB of bandwidth for $200 a month. Of course not CDN… but some files you could put onto CloudFlare domain, set it up right, and it would cache it for you on their CDN and you do not pay for bandwidth when they deliver cached copies.
You should check out PlayFab. There is a Defold version.
Incognito and DynamoDB doesn’t have anything to do with the storage of LiveUpdate data does it?
LiveUpdate is the term we’re using for a technique similar to downloadable content, it will not be a general-purpose backend solution. We understand that maintaining a large scale server operation is not ideal for indie developers, and we are putting a lot of effort into designing these kind of systems to be as easy as possible for people to use. We’re looking at the default/basic use case to be uploading files to a server or hosting solution that are capable of serving these files over HTTP(S), no configuration specific to Defold required.
Since you mentioned S3 I took a look at their prices for cloud storage (which can be found at https://aws.amazon.com/s3/pricing/), I looked at their EU Ireland prices.
I’m looking at a worse-case scenario here where no optimization is done in terms of batching, and I’m also assuming that every user has to download all the content and ignoring the possibility to download new content as users progress through the game.
For a game with 500 different resources that requires 500 MiB storage, there would be a fixed cost of $0.0115 and a moving cost of $0.05 per new user.
For a game with 1000 different resources that requires 500 MiB storage, there would be a fixed cost of $0.0115 and a moving cost of $0.055 per new user.
For a game with 500 different resources that requires 1 GiB storage, there would be a fixed cost of $0.023 and a moving cost of $0.095 per new user.
These are of course very basic calculations of price without factoring in retention, major updates etc. A more in-depth analysis of the cost for a small, medium and large game would be very interesting if it would be possible to use numbers from an actual game for these types of variables.
Edit: Realized I mixed up the posts of @seepia and @Aiki while writing this…
@britzl yes it’s not related to storage, i mentioned it for completion’s sake.
The thing is, how are you going to handle encryption? you will have the keys saved on your game code?
There a bunch of control problems and incognito is the way to get around that, and you use dynamo as a support for any other info you might require in that process. So it’s not necessary but I thought it was worth mentioning.
@jakob.pogulis
I think what you want is this: http://calculator.s3.amazonaws.com/index.html
These cloud services and their prices are just cryptic.
I mean you can always use your own combination of server/custom solution, it’s just never gonna be as friendly as the alternative that’s built in to google/apple services.
Encryption of what? I feel like we’re not really talking about the same thing here.
@jakob.pogulis You have good calculations there. They might not look big numbers, but just to compare. Our first two products we launched, not financial successful, but still did in average 0.03€ / download. Risk of having even 0.01€ extra cost for a product can make it intolerable for indie developer when amount of downloads goes up. By optimizing the extra usage and by having a good monetizing product makes it almost tolerable, but then in Android you have quite big amount of pirated versions of the game that do not give any money to developer but still loads extra content.
1M downloads -> 0,01€ per download -> 10 000 eur cost. Not every game gets 1M downloads but our first two did 2.5M. That is why I am worried for any extra cost that could be avoidable by using distribution channel services.
Whenever you offer any type of download anywhere on the web, it’s good to make sure that the only ppl downloading it are the ones that should be downloading it. So normally, you would need some sort of control mechanism to avoid the server being overrun by unwanted requests.
Amazon S3 has it’s own security mechanism to access content, long story but i think you got the idea.
Just a thought. Would it be possible to create apk-expansion module by using native extension with live update feature?
Hmm, maybe that would be possible. Maybe it would be possible to combine apk expansion modules with LiveUpdate and put the content in the expansion module instead of on the internet somewhere.
We’ve just released a first version of LiveUpdate with the 1.2.97 release. We’re still producing documentation and @sicher is currently working on a manual to describe how to use LiveUpdate together with Amazon S3. We’ve put a lot of effort into simplifying the process of managing content and after an initial setup of Amazon S3 the steps required to publish a game with LiveUpdate content won’t differ from bundling your game without LiveUpdate content.
As you’ve implied it is possible to require authentication when requesting resources from S3 which will allow you to control the requests for resources.
Given that the obb files will automatically be downloaded and show up on a fixed location within external storage, I think it can be achieved by fetching the resources using http and asking for permission to read from file-storage. You can read more about it here: https://developer.android.com/google/play/expansion-files.html
Storage location
{shared-storage}/Android/obb//
- {shared-storage} is the path to the shared storage space, available from getExternalStorageDirectory().
- {package-name} is your application’s Java-style package name, available from getPackageName().
Getting the file names
As described in the overview, your APK expansion files are saved using a specific file name format:
[main|patch].<expansion-version>.<package-name>.obb
And the actual java code which could be possible to change for http and a URI pointing at the final location.
// The shared path to all app expansion files
private final static String EXP_PATH = "/Android/obb/";
static String[] getAPKExpansionFiles(Context ctx, int mainVersion,
int patchVersion) {
String packageName = ctx.getPackageName();
Vector<String> ret = new Vector<String>();
if (Environment.getExternalStorageState()
.equals(Environment.MEDIA_MOUNTED)) {
// Build the full path to the app's expansion files
File root = Environment.getExternalStorageDirectory();
File expPath = new File(root.toString() + EXP_PATH + packageName);
// Check that expansion file path exists
if (expPath.exists()) {
if ( mainVersion > 0 ) {
String strMainPath = expPath + File.separator + "main." +
mainVersion + "." + packageName + ".obb";
File main = new File(strMainPath);
if ( main.isFile() ) {
ret.add(strMainPath);
}
}
if ( patchVersion > 0 ) {
String strPatchPath = expPath + File.separator + "patch." +
mainVersion + "." + packageName + ".obb";
File main = new File(strPatchPath);
if ( main.isFile() ) {
ret.add(strPatchPath);
}
}
}
}
String[] retArray = new String[ret.size()];
ret.toArray(retArray);
return retArray;
}
Q&A
So what does this give us in the end, you stil have to update the google-play page, why not the whole game?
It enables developers to exceed the 100mb limit and just upload the .apk + .obb file when releasing a new version. It is not “live update” but a workaround for the size limitation.
Just dropping into this old thread. I made a native extension to handle this whole process, if anyone’s still interested: APK Expansion Extension