How can one add a level to an already published ios/android unity3D game on a daily basis?

How can one add a level to an already published iOS/Android Unity3D game on a daily/weekly basis?

I know this probably isn't feasible but it won't harm if I just made sure of it. Our game requires to allow access to just one level a day/week. You may access levels that were released on previous days and play to your heart's content but all players will get access to a new level every day/week. I know this may sound crazy but the concept requires it so just roll with me.

Is there anyway to achieve this for iOS/Android games built with Unity? Of course, we could package a whole game with 10 levels and allow access to each level after a set time, but the game will need to talk to a back-end CMS all the time to allow login and verification of users, make sure they aren't cheating, etc, etc, over proper security and https (proper anti-cheat solutions are a must and that's why maybe HTML5 route is better).

We are now moving towards doing all this in HTML5 and completely bypass Unity, but was hoping to find a solution with Unity because 3D is better than 2D depending on the situation, and some levels could be 3D while others 2D. Patching/updating everyday to upload new levels won't go down well with anyone, the app stores or the users.

 

Dunno if they work on mobile, but asset bundles, perhaps?

 

Asset bundles are great if you need new assets each level.

But if you are just rearranging existing assets, then I would simply load each days level from a data file on the server each day.

 

Ditto.

 

thanks guys. But ran into an issue here with asset bundles.

So we are making a game where players will be granted access to new levels every week and these new levels will probably be downloaded from our server as Unity Asset Bundles The only issue is, as mentioned here , ios and other app stores dont allow loading/executing of scripts this way even if they allow you to load these newer asset bundles without doing the full update cycle. So really we need to know how game-logic scripts, etc can be executed for the new levels that are going to be released via Asset Bundles and downloaded from our server. Our server will be authoritative btw. I am sure there is a way since big game publishers are able to do post-release DLC and really, thats what we are after too - Just more regularly, whilst being in-line with app store regulations. Our usual workflow until now was just publish and then release a big update months down the line. Not every week.

 

What are you asking is not possible on iOS due the lack of a JIT compiler and thus you are reliant on AOT compilation, so yeah, that counts asset bundles out.

If your server is truly authoritative then you shouldn't be running any game logic on your client. It should be accepting input and that's about it.

So I'm not sure what scripts you would need to include in each new level?

 

Just game-play scripts really for each new level.


See I have always just done it the usual way. Just develop and build and publish. Never needed the authoritative server to control the gameplay. So basically, make the authoritative server instead of just verifying client info, logins, registrations, scores, leaderboards, etc, also take care of actual gameplay?? Hmm... can u pls advise me further on this.

 

You can actually implement a surprising amount of stuff without changing a line of code. If you set everything up right to begin with. Do any of the levels require unique logic, or can they be built by combining various bits of logic already present?

 

Completely new logic and new assets. Assets can be taken care of with asset bundles, logic is the issue since ios doesnt allow executing scripts as u know.

 

Yeah, if the logic doesn't exist before hand, and can't be created using existing components and the like, then you are out of luck.

I would look very hard at this option before discounting it. Its surprising what a clever programmer can do.

 

I am just hoping that the authoritative server solution that @Meltdown mentioned above can be my saviour. Hopefully, gameplay code can be handled by it properly and without too many issues.


Also, until now my authoritative server was gonna be sent for example, scores whenever the client next connected to the internet, and during the initial login phase. I didnt even consider having server handle game logic cos of two things - 1. lag. 2. asking player to only play whilst online was something of a negative i always though. But maybe not so much nowadays and the authoritative server should be my solution. Everything else that I need to consider whilst having the server also handle all game logic?

Each new level will mostly be a simple 2D game. No multiplayer networking or other complicated stuff. This shouldnt make it lag and should make it playable on even 3G connection, right?

 

You should just implement custom/existing scripting system (such as lua) to your game and manage your level logic with it if you cant manage to predict and make the level logic like BoredMormon said. Hosting offline games online just to prevent cheating is not a good idea if its only for highscores unless you have the money or server capacity to do so. Yes it might and will probably lag if your server validates all movements, actions etc. player does especially on low end mobile connection.

 

Server will handle:
1. keep score. Get highest score, leaderboards, social (post scores to facebook/twitter). anti-cheating
2. in-app purchases
3. game-logic
4. Maybe some levels will have physics so the server will have to handle that too.
5. User login/registration authorization/verification (user will be asked to login before being allowed access to the game/levels)

 

btw the reason why anti-cheating is so crucial in this game is cos the in-play purchases are based on scores as well. So just roll with me. I cant give out more details. Its just that we need to absolutely make sure that they cant cheat.

 

@Ostwind - Lua? My plan B was actually just go the webGL/three.js route and just not use a game engine then and just make it a html5 app. Sucks, but what can u do.

 

You can use lua or similar things on iOS and bind stuff to your c# methods and properties and is more flexible than logi in custom level format. It still requires you have the core stuff available though.

With WebGL you can just guesstimate how many potential customers you lose due lack of proper WebGL support in various devices and platform versions. You will also lose the platform payment system and will have implement own or pay for one and the barrier for payments raises.

 

This confuses me. Can't you just release it as an update? Just increment the release number each time.

This is the normal process so I dont see how people will be adverse to it. Simply if they want updated content they need to update the game... So many people have access to unlimited bandwidth these days so its not really a problem.

It is possible to have a game dynamically download all its assets as it requires them (like Pocket Legends) but of course this is not possible on an already published game.

So, yeah, sorry Im not being very helpful.

 

It takes a lot more time to publish a version than just push level files/bundes to users. Example scenario for iOS, do and possibly test the changes for different branch than development, build the app (takes 10-30mins to compile). version control it, archive and upload to Apple and fill all update info, wait the reviewer to accept it. Then users download the whole game again... all this for single level

 

UGH. This happens for updates? Enough said.

I bow out gracefully from this discussion

 

You don't need to push scripts with assetbundles. Just make sure your client has all the scripts. When loading assetbundles, the class references point to the local (client) ones. All of our content is pushed via assetbundles, levels/units/buildings/ui/art/etc... All the classes are already in the game, simple or complex, everything is reattached when loaded. Any public vals are passed along.

 

Apologise for the late reply. Problem is that our concept requires future levels to have completely different logic to the current levels and we haven't even come up with gameplay down the line yet. So since thats bound to change, we cant really make use of what you suggested.