Do you think that you could fit a special case for LiveUpdate to bring the data from apk-expansion package instead of hosted server? From game package perspective it is really close to the same. Both are very important features. Little depends on developer which one is priority 1. For us it is apk-expansion 
We are currently not looking into “apk-expansion packages” or “app store hosted content”. These two features would require special integration with each platform and would be very different compared to our current design and approach. Further more they wouldn’t be able to support Desktop or HTML5.
I doubt we would be able to fit either of these features into the LiveUpdate design.
What would you be able to achieve using an APK expansion that you’re worried you wont be able to achieve using LiveUpdate?
3 Likes
With APK expansion the cost of the extra content goes to distribution channel and with LiveUpdate cost comes to me as developer / publisher. I am already paying for distribution channel with their cut 30% of revenues and it would be nice to avoid additional data related cost if possible. Other than that, LiveUpdate is great feature to make it possible to have smaller apk.
I was also interested in this feature, LiveUpdate sounds great, but off-store hosting isn’t a reality for a lot of devs.
Can’t the LiveUpdate system be extended to support “obb” and google’s system?(in the case of apks)
Or maybe another one has to be built that supports the mobiles.
Otherwise what you are essentially saying is that Defold Android games are mostly limited to 100mb(after export), unless the developers are ready to dish out some major cash for server hosting and maintenance. Like you said, its an ‘advanced’ feature. This will likely be a deal breaker for a lot of potential Defold users.
On a side note, for LiveUpdate are you guys gonna be working directly with say Amazon for easy integration with their services?
I think the guys at Defold are doing the right thing by working on something cross platform for their system, it makes sense.
I also agree that the use of iCloud, APK expansion, etc is also needed, but that I guess will start coming once the extension system is in place. Is editor 2.0 holding off a little that extension system?
2 Likes
Would it really have to be that expensive? I’m not sure what kind of cloud hosting that would be recommended for this. Amazon S3 maybe? It would be cool if we could provide hosting, but I’m not sure how reasonable that would be. What has been discussed so far? @jakob.pogulis?
1 Like
I did my math once a while back, i think for the first year it’s not that expensive, it could increase depending on what you setup if you are not careful.
Could go from a few dollars(or less) a year to a lot more.
I think the real “cost” would be in your dev time, or in other ppl doing it for you, setting things up.
You would use, S3 for the files, incognito for signups/saveFiles sync and DynamoDB for the db setups.
Dynamo is surprisingly basically free for startups and small studios(low-end consumption), incognito is pretty much the same i think, and S3 is potentially “inexpensive”. That’s going to be a relative term based on how much your game made vs how much you used.
Setting things up is not necessarily simple. I looked up their unity integration in the past, it seemed ok, but this is something they made themselves not third party.
Frankly just the sheer responsibility of accounts(personal information), sign-ups, handling downloads and server times, etc. Will frighten a lot of ppl away form this, hence why built-in solutions are a better solution. Also most “services” that pretend to handle this(back-end), offer way much more than simply “dlcs” and co, and therefore charge a lot more also.
I think if you guys set this up in an easy built-in manner, where gamers would login with their “King(Defold) Accounts” for all games made with Defold, it could work.
Even if you guys charged a very small amount like a few dollars or whatnot an year you could probably make some money off of the storage, not sure about the maintenance costs.
I mean how much is the most advanced and bloated Defold game going to use? 1GB, 500mb? You could max the storage at that. The key thing is how much all the maintenance will cost for you guys. Unity offers unlimited cloud builds, which is potentially more expensive and complex, for free, but they are selling a product, so they have the cash.
Idk really. Someone who knows a lot more than I do has to sit down and really add the numbers, but maybe there is a system that works for you guys and for everyone else.
Either way, seems like native extensions will be a solution for integrating third party services and apis, for ppl who want/need them.
I wish you guys success!
3 Likes
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…
1 Like
@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.
1 Like
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.
3 Likes
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.
2 Likes
Just dropping into this old thread. I made a native extension to handle this whole process, if anyone’s still interested: APK Expansion Extension
6 Likes