Game Cloning.

There are 3 ways:

1.) The smart ones discovered the way to copy the source (logic and resources)

2.) Others try to create a 90% clone by using most of the original graphics+sound files and recoding the flow

3.) The last group is using the "visual recoding from scratch" approach

Approach 1.) allows a new 1:1 copy to be created within minutes, a known problem which is to be fixed in BB2 release version. Still I do not understand why "The Pit" was released before fixing this...

 

wow... a clone of The Pit has appeared? That's freakin' fast!

 

as @TreySmith mentioned, the legal approach (DMCA and similar approaches) is the way to go.

Don't be too heated up thinking that this is a problem that affects only Buildbox: all other tools (Gamesalad, and similar) face the similar problem.

The real issue lays with Android and the way that is followed to create the APK file (very technical and boring stuff)

One possible way to "delay" these people is to "injecting" text/messages into images. The lazy ones will give up and if they will sell the template you might get "calls" from people who genuinely bought your pirated app (from codecanyon and similar) and you can then have more "way" for an action against the pirates.

 

That is exactly the first part of the problem: it's known for ages that game engines are attackable by design and this is why I am surprised to find it so easy without any protection. Because one should learn from the painful experiences of others...

Furthermore, it doesn't really help to know others are suffering the same, if you need to protect your hard work.

If a company's product, like a game engine, would like to be better than a competitor's, it should try to avoid common mistakes made by the others for decades !

It's a wrong assumption that it's an APK problem only, as the problem is a design topic of BB and IOS is affected as well

 

I don't know enough about it but whoever copies the apk file would have to find a way of adding their own game ID com.MYSTUDIO.MYGAME and change the advert IDs to their own. There's probably software out there that does this.

 

of course IPA suffers from the same problems. But since Apple and Google decide how a program for their platform has to be packed, there is really little that we can do. Don't forget that on top of "code" per se to run the game, these tools have to embed third part libraries too (Cocoa2D, etc) and each one has its own requirements too...

So given the fact that - per se - it's not possible to change how APK and IPA work , these are some ways that could potentially be adopted to solve this issue:

- remote compilation of the APK/IPA; (since even the demo produces source code, every Tom Dick and Harry knows the structure of a Buildbox app) adopting DEX Guard Enterprise for Android and similar tools for iOS (this could be a paid service @TreySmith might want to look into)

 

Mind you DEX Guard does not prevent to reverse your code or resources, it just slows bad guys down. There is no 100% solution as the app itself still needs to access to resources and execute code, so the decryption key needs to be embed in the app... Having said that doing something is way better than doing nothing.

With DexGuard Enterprise resources are encrypted by AES, so it is good. Also they constantly change the placement of key in the obfuscated code, so that is also very good from our perspective. Protecting resources are super important for BuildBox as the key logic is there and therefore the program code is not as important to protect (which is only the game engine).

 

I do not want to disclose any information, so I will comment this in a generic way:

a.) the game engine is using pseudo code, more or less some kind of "scripting language"
b.) the core functionality is stored inside a native app

Having this in mind, there are several possibilities where to start improving...

The graphics/sound/FX resources have to be considered differently because of the OS, Cocoa and OpenGL requirements but there are possibilities too.

If you check other games, e.g. made with unity, you will see that image resources are protected...

Furthermore it has to be distinguished between hacking design environment and runtime player...

OS requirements are a burden but the apps can still be designed to be compatible and compliant (which might effect performance/size, of course)

As BB is not even compiling directly Xcode, integrating 3rd party tools/libs etc. is not only complicated but may increase the risc of failing when building the app. We see this already with ad libraries which haved caused problems to non-dev BB users the last months.

As a result, adding 3rd party libs when compiling remotely is not even working better, so I do not really consider remote compiling an useful option unless this service would be offered by BB with all the knowledge around their solution to get it up and running.

As for for 3rd party solutions like DEX Guard, I'd like to make sure that it's clear what is behind:
DEX Guard claimed to encrypt the app while the developer had to admit it was obfuscating the source, like @trudnai mentioned, to make it more difficult to reverse. Therefore it's important to strength that encrypt does not always mean, according to the software manufactures, what others would expect.

This has slightly changed with DEX Guard Enterprise where classes are encrypted while the string "encryption" has been hacked already. Yes, there is still the class encryption but I personally do not trust solutions which have been hacked several times in the past and the manufacturer made false claims about the security level (even if it has been improved meanwhile). Yes it still provides a certain level of security but I'm confident that this can be achieved by the BB dev team without 3rd party tools as there are already some measures included

To summarize this: in my opinion it comes down to design changes in BB which could dramatically enhance security, even without using 3rd party tools. The hacker-creator duel might still occur but at least it's not as easy as it is right now...