Image File Size in Unity and their Impact on Start Up Time on Android

Xander here…

We have been Beta Testing our soon to be released game The Dog Run and it’s been mostly OK but we had a number of issues with memory on smaller or older devices.  We made some gains with modifying our audio files (See this post) but were still running into niggling crashes on start up and longer than normal load times.

We were getting feedback like:

“Hey, I installed the game and couldn’t run it. When I started it there was a black screen for about 15s and then it went back to the launcher. Then each time I went back to the game there was unity and game logo fading out and again the app crashed/hanged and I was sent back to the launcher.”

(Thanks slomoian and the_blanker for all your help testing)

Obviously feedback like this is a little disheartening and far from ideal.  The game was running fine on every device and emulator I had access to but it’s only when you send something into the wild that you realise the full breadth of the spectrum that is the Android platform.  I guess this is another lesson in the importance of proper Beta testing.  One we hadn’t learned last time we released an app (see this old post on the perils and difficulty of finding Beta Testers).

We were using adb logcat to monitor our start up problems but not finding a “smoking gun” that solved every case. It seemed to be a memory problem and often with the graphics cache so again we went back to the Unity Editor build log to investigate our image files.  The game uses multiple large files to ensure that our animated sprites were always in the right spot. The game is dependent on the titular Dog hitting the ground line accurately on every frame to achieve the look we wanted when he runs and the paw breaks the ground line and appears as a gap.  We used a “flip-book” old fashioned style of animation where each frame sits exactly on top of the old frame and everything lines up on a transparency like in classic animated movies.

By using this schema we had to keep to a certain scale that fit within the constraints of a typical Android device format. This meant that when the images were imported the POT was not going to be something we could play with easily to get performance gains.  (Image files that have a width and breadth that is a power of 2 are faster and easier for the compression functions to work with – so 2, 4, 8, 16, 32, 64, 128, etc).  If I had the chance to do this again this is something I would probably start doing right from the beginning of development. When going through the Editor Logs we did find something interesting (get to the Editor Logs by right clicking on the arrow or tab near the Console and selecting it).

We found that some of our image files were 10 MB and a few were 2 MB.  Which was a little weird as they were all exported as layers from the same Gimp file so I must have done something in the import settings or the editor to change them.

This is a comparison of two files of the same dimensions and basically the same content but with two very different file sizes:

10.6 mb 0.8% Assets/artwork/RunOnSpot6.png

2.0 mb 0.1% Assets/artwork/DogSitHeadWag.png

The difference that I found was MIP Maps.  I’d selected to use MIP Maps fairly early on as it made the art work look smoother in the Editor.  MIP Maps are generated in the engine to make smaller more compressed versions of your artwork that can be used at longer distances from the camera where the detail is less visible. My game is 2D and has everything running at pretty much the same distance from the screen so really MIP Maps should not be required.  My art did look a bit better in the editor with them turned on but on a smaller device like a phone I couldn’t really tell the difference.  See below the difference in a file with MIP Maps selected and a file without.

With MIP Maps turned on (see the file size at the bottom and that the type is RGBA 32 bit):

The same file with MIP Maps removed (down to 2 MB and using ECT2 compression):

This is the difference that generating those MIP Maps makes. Your file is converted from the Android default compression to a larger (harder to process) 32 bit compression format.

So by turning off MIP Maps across the three hundred plus image files in my game reduced my application start up time to under a few seconds and reduced the APK file size by over one thousand MB.

This is the Build Report from the Editor Logs that shows the larger texture sizes and final build size:

Uncompressed usage by category:
Textures 1292.3 mb 94.6%

Complete size 1365.9 mb 100.0%

Compare this later Build Report with MIP Maps turn off to the original one above:

Textures 284.5 mb 82.6%

Complete size 344.6 mb 100.0%

It’s a considerable difference with little or no quality loss on most devices.  When I say most devices there were a few cases where the running dog did look a little tatty.  On very small emulated devices (3.5″ screens and low memory) the images were being scaled down quite a lot and the results were a lot less enjoyable but still an acceptable compromise considering previously the game would not run on these devices at all.

The next thing I started playing with was the different texture compression variables available for Android. I tried all of the settings (see screenshot below) in a different build and tested them against at least ten different devices with various architectures and screen dimensions and Android versions.

In each of the cases but one there was at least one test device that failed to start the game.  Once again exposing the issues of working with so many platform variables on Android.  Even when I built the APK with the (default) ETC selected one device failed the start up test.  So in the end the final build used the “Don’t override” setting which seemed to work on all devices.

Hopefully this is helpful to someone else out there and if it is try hitting the “Like” button below or sharing the link (the feedback keeps me going).

I found these references useful when troubleshooting my start up issues and learning more about compression on Android:

https://docs.unity3d.com/Manual/android-GettingStarted.html

https://docs.unity3d.com/Manual/class-TextureImporterAndroid.html

https://docs.unity3d.com/Manual/class-PlayerSettingsAndroid.html

https://answers.unity.com/questions/1406451/sprites-increase-android-apk-size.html

https://www.unity3dtips.com/unity-texture-compression-android-ios/

Unity Editor Tool Tips, Headings and Clamping Ranges

Hi Xander here…

Firstly a reminder that we are Beta Testing The Dog Run. If anyone would like to join please opt in here: https://play.google.com/apps/testing/com.ZuluOneZero.TheDogRun

(Apologies in advance for the pop up on this site advertising for help! It should only come up once)

The Dog Run has just been reviewed by Daikon Media if you are interested in reading what they thought please follow this link: https://daikonmedia.com/the-dog-run-review/

This post is about how to help yourself organise scripts in the Unity Editor using Tool Tips and Headings.  When you are developing as an Indie there can be long gaps between coding runs.  There is never enough time and so much to do so using anything that can help you quickly understand what those behaviours are supposed to be doing is a godsend (and adds to your godspeed).

Take this script for example from our game currently in development Endless Elevator.

This is the raw Editor display before beautifying:

I come back to this after a few days and have no idea what all those things should be and as they are so terribly unorganised it makes it all the harder to work it out.  Sure the code is commented and hell I wrote the stuff but it still takes time.

This is the same script with the addition of Headers and Tooltips (unfortunately the Tooltips are a bit hard to capture in a screen shot but you all know what they are).

Much Easier!

How to Make and Do!

I’ll use a quick example project to demonstrate how to use Tool Tips and Headings. They are super quick and easy.  I’ll also go over another extremely useful Editor function which is the Range. The Range can be used to clamp down a variable between a maximum and a minimum. This allows greater control over it’s setting while working on your game in Run Time so that you can tweak the variables easier.

Have a look at this example script:

HandyEditorTips Class


using UnityEngine;

public class HandyEditorTips : MonoBehaviour {

[Header("Speed Settings")]
[Tooltip("Speed value between 100 and 500.")]
// Show this float in the Inspector as a slider between 100 and 500
[Range(100.0F, 500.0F)]
public float speed = 100;

[Header("Point to Rotate Around X Axis")]
[Tooltip("Location Across the screen on the X axis")]
public float vector_x = 0;

// Update is called once per frame
void Update () {
// Rotate the object around the given point
// (Point to rotate round, direction of rotation, speed * frame rate delta)
transform.RotateAround(new Vector3(vector_x, 0, 0), Vector3.forward, speed * Time.deltaTime);
}

}

 

This script is added to the Sphere in the project and the Slider is a huge help in setting the required speed of turning.

Juxtapose this with the other setting for the X Axis vector variable and see when I try and use that when it’s not clamped into some sensible settings. It sends my Sphere cycling all other the shop.

It’s not groundbreaking stuff I know. But it’s easy to implement and does make your coding job easier in the initial phases.  Once you’ve got all your scene elements into some kind of decent shape you can start moving those variables that shouldn’t be exposed into a private scope and setting them to static.

Here is the Unity API Documentation Links if you want to do more reading:

https://docs.unity3d.com/ScriptReference/TooltipAttribute.html

https://docs.unity3d.com/ScriptReference/HeaderAttribute.html

https://docs.unity3d.com/ScriptReference/RangeAttribute.html

Unity Debugging with ADB for Android

Hi Zulu here… (First of all … sorry for the cat)

Let me say straight off that your first port of call for any Unity debugging should be the Unity Console.

Though sometimes you need more low level operating system logging for Android. This is where ADB (in lower case) comes in.

On Windows this is a command line tool to view the logs from a connected Android device.

The command line is not the only way to use the tool sometimes it’s better to use the Android Studio interface (a bit more graphical).

You will need to have your Android device connected to your workstation and USB debugging turned on  (Google that if you need to). You could also use an Android emulator on your desktop.

I use Leapdroid or KoPlayer.  (Leapdroid have now joined Google and no longer support the emulator but it’s still available to download on the internet).  I guess you could also use the emulator that comes with Android Studio.

When your game is installed and running on your device go to the directory in your workstation (PC) where the Android SDK Tools are.

On mine they are here:

C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools

In the tools directory open the monitor.exe (this tool was depreciated in Android Studio 3.0 and replaced with profiler.exe mine is still on the lower revision).

This documentation on the Android site is a good start investigating the profiler:

https://developer.android.com/studio/profile/android-profiler

You can also get into LogCat directly from Android Studio (if you have it open):

Go to  View | Tool Windows | Android Monitor

At the bottom of Android Monitor in it’s own tab is the LogCat console window. This contains all of the information about what’s happening in the Android operating system.

As you can see the LogCat console contains a lot. It logs everything.

To filter it type “tag:Unity” in the textbox at the top to see messages that relate to Unity.

Using adb logcat from the command line

Open a command prompt on your development workstation and find the location of your Android SDK platform-tools folder.

Mine was here:

/Users/YourUserName/Library/Android/sdk/platform-tools

If you get this error when you run adb.exe using the command prompt:
‘adb’ is not recognized as an internal or external command operable program or batch file

You can add ‘adb’ to the $PATH environment variable (and restart the command prompt).

setx PATH "%PATH%;C:\Users\AppData\Local\Android\sdk\platform-tools"

 

To run logcat through the adb shell, the general usage is:

[adb] logcat [<option>] … [<filter-spec>] ..

This is the official Android Developer Logcat Command-Line Tool documentation:

https://developer.android.com/studio/command-line/logcat

but you can get –help on the command line.

It can be handy to know the device id of your Android phone/tablet whatever. This command will help:


C:\Users\<user_name>>C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe devices
List of devices attached
ce10171a5c19853003 device

 

You can specify that the log spew into a file instead of into your console (the console is pretty much useless as there is too much to scroll through).


C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe -d logcat > adb_logcat_out.txt
-d use USB device (error if multiple devices connected)

logcat show device log (logcat --help for more)
-s SERIAL use device with given serial (overrides $ANDROID_SERIAL)

 

The default Log Location on my machine was:
C:\Users\<user_name>\AppData\Local\Temp\adb.log

A few seconds of output got me a 6.5 MB file so a bit of filtering is advisable

If you run into trouble with the adb server just kill it and restart.


C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe kill-server

C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe logcat -s ce10171a5c19853003 DEBUG

C:\Users\<user_name>>C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe logcat -s ce10171a5c19853003 DEBUG
* daemon not running; starting now at tcp:5037
* daemon started successfully
--------- beginning of main
--------- beginning of system

 

If you want further help check out these pages from the Unity Manual and Tutorials:

https://docs.unity3d.com/Manual/TroubleShootingAndroid.html

https://docs.unity3d.com/Manual/LogFiles.html

https://unity3d.com/learn/tutorials/topics/mobile-touch/building-your-unity-game-android-device-testing

As a final word I’ll also direct you to this package called Device Console on the Unity Asset Store. I’ve not used it but it looks really good and for fifteen dollars might save you a lot of hassle.

https://assetstore.unity.com/packages/tools/utilities/device-console-44935

Key Quest! Google Play Store Key Signing and the Pain of a Long Slow Death

Should Google Manage Your Keys for Games built with Unity?

We recently had a problem that caused weeks of pain and struggle and it had nothing to do with coding. It was the damn java keystore signing process that we signed up for on the Google Play Store.

The basics are that the Google Play Store requires that all APKs be digitally signed with a certificate before they can be installed.  Apps must use the same certificate in order for users to be able to install new versions or updates.  This is a good and secure system. No issues here.

If you lose your key you cannot distribute any updates to your app/game. This would be really bad for some companies so Google offers to keep your keys safe so that you if you did lose them you can ask to have the key sent to you which gives you authority distribute again. Yay for Google!

But our problems start here in Unity when you build your game for Android the keystore is defined on the Player Settings tab of the Build Setting (CTRL+SHIFT+B).

In the first case when running your project from Unity the package (APK) is automatically signed with a debug certificate generated by the Android SDK tools. The debug keystore and certificate are in $HOME/.android/debug.keystore.

This debug certificate is insecure by design and can’t be used on the Google Play Store for publishing an Alpha release but you can upload it for Beta releases.  I think this is where we started going wrong.

When you upload an APK to the Play Store you can opt in to app signing by Google Play. They recommend it but it’s optional. If you prefer, you can continue managing your own keys.

The advantages of opting in to the Google Play Store App Signing program is that 1. You ensure that the app signing key is not lost. 2. If your app signing key is compromised only a user with an account linked to your app can manage an upload key which makes it harder to do something malicious. (If you sign in your apps are signed with an upload key proving your credentials – Google then manages your APK and assigns it the correct and valid signing key).

To quote their documentation: “When using Google Play App Signing, you will use two keys: the app signing key and the upload key. Google manages and protects the app signing key for you, and you keep the upload key and use it to sign your apps for upload to the Google Play Store.

When you use Google Play App Signing, if you lose your upload key, or if it is compromised, you can contact Google to revoke your old upload key and generate a new one. Because your app signing key is secured by Google, you can continue to upload new versions of your app as updates to the original app, even if you change upload keys.

If you lose your keystore or think it may be compromised, app signing by Google Play makes it possible to request a reset to your upload key. If you’re not enrolled in app signing by Google Play and lose your keystore, you’ll need to publish a new app with a new package name.”

Alright. Read that last bit again. It’s important and why app signing might be a really good idea. If you manage your key yourself and you lose it and want to make an update to your app then you have to publish your whole app again under a different name. Again just to drum that home … If you lose your keystore, the only solution is to upload a new instance of the app to the Google Play Store with a new key, a whole new store listing like it’s a different product, as it will not accept an APK signed with a different key.

See: https://support.google.com/googleplay/android-developer/answer/7384423?hl=en
(Manage your app signing keys) The support team only accepts key reset requests from the Play Console account owner. The account owner can fill out a form and attach the upload_certificate.pem file. Then you can update your keystores and API provider registration.

It seems easy and if you want to read funny people on the internet slagging off the Byzantine process check out the comments under this tutorial:
https://www.youtube.com/watch?v=qGoCF0Et_CU&feature=youtu.be

I was a little lost so I started looking for the help of my peers and of course from Unity.

I found a post from one poor soul who was in the same boat as me and the response from Unity Support was: “What do you want to be supported from Unity side? I see this unrelated to our build process.” So someone needs to have a little talk to that chap.

There are more than a few forum posts around this for Unity (and that last one is for andromo but the subject is the same issue).
https://answers.unity.com/questions/1434637/can-google-play-app-signing-be-used-with-unity-and.html
https://forum.unity.com/threads/android-signing.62137/
https://answers.unity.com/questions/1372982/how-i-can-sign-my-apk-with-an-google-plays-upload.html
https://stackoverflow.com/questions/50608172/unity-google-play-app-signing-issue-and-keystore
https://forums.andromo.com/discussion/1980/important-do-not-opt-in-to-google-play-app-signing

Look – and this is really the bottom line – it all got too frustrating and annoying trying to work out what the hell was going on and since I was only in my third release cycle I just opened up a new App on the Play Store and ditched the old one.  But that’s just not possible for anyone who has an App out there and has no other option. So this is the process to getting that pesky key back.

In the Google Play Store you can see your App Signing Keys here:

You got your App signing certificate – this is the one that actually signs your app.
SHA-1 certificate fingerprint (above)
SHA1: A8:C0:F2:25:E6:A4:17:A3:F7:13:7B:96:37:FB:B8:59:69:72:9B:8C

And your Upload certificate – this is the one that you use to upload with your APK so that Google knows it’s you.

Your upload key is only registered with Google and is used to authenticate the identity of the app creator.
Your upload key is removed from any uploaded APKs before being sent to users.

SHA-1 certificate fingerprint (above)
SHA1: 74:5A:11:31:6E:2E:C0:DD:8C:F5:6E:65:24:5F:77:B8:2C:EA:6A:9A

In my case the upload certificate was from the default android debug keystore (that I shouldn’t have used):

C:\Program Files\Java\jdk1.8.0_111\bin>keytool.exe -list -keystore C:\Users\<user>\.android\debug.keystore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

androiddebugkey, 10/08/2016, PrivateKeyEntry,
Certificate fingerprint (SHA1): 74:5A:11:31:6E:2E:C0:DD:8C:F5:6E:65:24:5F:77:B8:2C:EA:6A:9A

 

To generate and register a new upload key, follow the instructions in the Android Studio Help Center.
https://developer.android.com/studio/publish/app-signing#generate-key

You don’t need to use Android Studio you can also do it on the command line (which is easier I think).

First generate a private key using keytool. For example:

# keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias my-alias

C:\Program Files\Java\jdk1.8.0_111\bin>keytool -genkey -v -keystore D:\ZuluOneZero\Demo-Unity-Android-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias Demo4Unity
Enter keystore password:
Re-enter new password:

What is your first and last name?
[Zulu]: ZuluOneZero
What is the name of your organizational unit?
[Unknown]: TheDogRun
What is the name of your organization?
[Unknown]: ZuluOneZero
What is the name of your City or Locality?
[Unknown]: Melbourne
What is the name of your State or Province?
[Unknown]: Victoria
What is the two-letter country code for this unit?
[Unknown]: AU
Is CN=ZuluOneZero, OU=TheDogRun, O=ZuluOneZero, L=Melbourne, ST=Victoria, C=AU correct?
[no]: yes

Generating 2,048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 10,000 days
for: CN=ZuluOneZero, OU=TheDogRun, O=ZuluOneZero, L=Melbourne, ST=Victoria, C=AU
Enter key password for <Demo4Unity>
(RETURN if same as keystore password):
Re-enter new password:
[Storing D:\ZuluOneZero\Demo-Unity-Android-key.jks]

Note: keytool is located in the bin/ directory in your JDK. To locate your JDK from Android Studio, select File > Project Structure, and then click SDK Location and you will see the JDK location
C:\Program Files\Java\jdk1.8.0_111\bin\keytool.exe
(I used this one but you will have a keytool for every JDK and JRE on your machine – doesn’t matter which one you use)

Then, export the certificate for the new key to PEM format:

# keytool -export -rfc -alias <upload> -file <upload_certificate.pem> -keystore <keystore.jks>

C:\Users\<user>\AppData\Local\GitHub\mingw32\bin\openssl.exe x509 -inform der -in C:\Users\<user>\Downloads\deployment_cert.der -out D:\ZuluOneZero\deployment_cert.pem

Add the certificate to the signing keystore:

keytool -export -rfc -alias Demo4Unity -file C:\Users\roderick\Downloads\upload_cert.der -keystore D:\ZuluOneZero\Demo-Unity-Android-key.jks

C:\Program Files\Java\jdk1.8.0_111\bin>keytool -export -rfc -alias Demo4Unity -file C:\Users\roderick\Downloads\upload_cert.der -keystore D:\ZuluOneZero\Demo-Unity-Android-key.jks
Enter keystore password:
Certificate stored in file <C:\Users\roderick\Downloads\upload_cert.der>

If you want to inspect the certificates (on Windows) right click and open with Crypto Shell Extensions.

Or you can inspect the certificates like this:

C:\Program Files\Java\jdk1.8.0_111\bin>keytool.exe -printcert -file C:\Users\<user>\Downloads\upload_cert.der
Owner: CN=ZuluOneZero, OU=TheDogRun, O=ZuluOneZero, L=Melbourne, ST=Victoria, C=AU
Issuer: CN=ZuluOneZero, OU=TheDogRun, O=ZuluOneZero, L=Melbourne, ST=Victoria, C=AU
Serial number: 3e64dcd1
Valid from: Thu Sep 13 16:28:59 AEST 2018 until: Mon Jan 29 17:28:59 AEDT 2046
Certificate fingerprints:
MD5: F8:D3:CF:84:88:8E:16:EA:3D:74:F0:7E:9E:18:13:C9
SHA1: BD:1B:A2:99:05:11:0E:F6:A0:B5:1A:7B:7D:EB:01:3C:8B:A7:98:6D
SHA256: 7C:24:86:CD:58:1A:2F:74:21:B0:A6:9B:3D:DF:BC:BE:2A:15:F3:23:B9:44:7F:98:5D:8D:FB:24:98:37:82:9C
Signature algorithm name: SHA256withRSA
Version: 3

Extensions:

#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 21 44 48 FA 63 97 2D B0 A4 92 2B 38 41 E4 2F 7D !DH.c.-…+8A./.
0010: EA 26 E0 10 .&..
]
]

You can inspect keystores like this:

C:\Program Files\Java\jdk1.8.0_111\bin>keytool.exe -list -keystore D:\ZuluOneZero\Demo-Unity-Android-key.jks
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

demo4unity, 13/09/2018, PrivateKeyEntry,
Certificate fingerprint (SHA1): BD:1B:A2:99:05:11:0E:F6:A0:B5:1A:7B:7D:EB:01:3C:8B:A7:98:6D

 

All the detail above are dummy one’s for demonstration purposes only.

The Dog Run – Game Play Demo

Hi Harmony here…

Today I did some game play testing of the new game we are beta testing right now.

If you want to do some beta testing you can opt in here:   https://play.google.com/apps/testing/com.ZuluOneZero.TheDogRun

Feedback can be posted on the website in the comments or directly by email at
zuluonezero.z10@gmail.com

 

Do NOT Restart Unity After a Crash!

It all started when my laptop went into sleep mode.
I was doing some play testing of my Dog Run game and had to take a work call.
I know I know “real” work getting in the way of my real life.

Something happened and the laptop stopped responding. Wouldn’t come out of sleep mode and had to be restarted.

Now normally Unity is pretty stable. I actually can’t remember any time when it caused a crash or stopped responding or has died on me but I guess being in run mode while the laptop was asleep may have been a contributing factor.

When I restarted my machine and opened my Game again in Unity the editor barfed and gave me an error in the console like:

GetPathNameExtension(path) == “unity”
GetPathNameExtension(path) == “unity”
GetPathNameExtension(path) == “unity”
Unknown error occurred while loading ‘/Scenes/MainScene.unity’.

Then it asked if I would like to open the default scene which I promptly took to be My default scene. But sadly it wasn’t. It was the Unity default scene that you see when you open up a new project.

All of my assets and settings were gone. All those hours of tweaking objects’ positions and rotations getting things just right were wiped off the board like an angry chess master.
Poo.

 

This is the big lesson of today.

If the Unity Editor or your operating system crashes do NOT start Unity again without making a backup!

I know there are a few other lessons here like: 1. Always backup your project, and 2. Use source control, and 3. Backup your project again, and 4. Save your project regularly during your workflow and 5. Save the scene and the project BEFORE hitting Play when you are testing your game.

But I want to say it again because opening your project up after a crash in Unity is a really easy thing to do and seems like the right thing to do and is normal and natural and good. But it’s NOT!

DO NOT OPEN UNITY AFTER A CRASH!

Not without first backing up your project folders.

Now I know backup is a whole subject in itself and I’m going to make an entry on that soon but there are some simple ways to save the day here.

When you hit the Play button in Unity the scene and all the running elements are saved in the project’s Temp directory.

If you have a crash and want to restore your scene file, you cannot re-launch the Unity Editor after the crash.
If you do it will blow away the Temp directory and you will lose the last saved scene and all your progress with it!

Inside your Project directory folder there should be a Temp/__Backupscenes directory. If you are lucky in here you will find a file called either 0.backup or “__EditModeScene” (depending on Unity version) which is your saved scene file.

First! Make a backup of your Project directory. Take the whole thing. Easiest quickest way is to copy the whole project folder to another directory.

Then all you have to do is to copy this file back into you project and replace the broken scene file with the copy. Set the file extension to .unity in order to make this file recognizable as Unity scene file.

Please backup your project folder before making the change.

When you Run Unity and open the Scene you just moved from the Temp folder hopefully all or at least most, of your changes are there and the scene is restored.

So Unity is saving your scene every time when you hit the play button, but not over the original scene file, instead it is saved in the project’s Temp directory.

But be careful. You cannot start the Unity editor after the crash. This is by nature a Temp directory whose content is created dynamically when working in Unity.
If you restart you will lose the scene file and all the progress with it.

Once you have done this start using a new workflow.
Take regular backups.
Use source control.
Hit Save regularly while working in Unity.
Hit Save before you hit Play when testing in Unity.

Animating the Running Dog with Unity and GIMP

I finally got the game I started in November into some semblance of how I wanted it to look.  The running dog animation anyway.  Still playing with different backgrounds but this one is sure “fun”.

It took a long time to get all the dog actions done drawing each one by hand and getting a lot of unsatisfactory results.  The animation is all “flip-book” style with each frame a different drawing.  There were between 70 to 80 pictures for the entire set.

The art was done in gimp with the help from some nice veterinarian manuals on the dog gait.

I mocked up a few transitions from an opening scene to a nice zoom down to playing position.

Then moved between a sedate walk to a running gallop and a little jump.  She looks like she’s really flying now!

 

During this time I also had a big problem with corrupted a scene after playing in the Animator window.  Big tip and future post – do not restart Unity if it crashes without taking a copy of your temp directory first. It took me about two weeks to rebuild everything but more on that later.

How To Get Beta Testers

Yay! We Are In Beta!

When ZuluOneZero published NumBlocks on the Google Play Store we went through the requisite development phases.

The game has been released now – have a play:
NumBlocks published on the Google Play Store for Android.

Click to Play:

Also on the Amazon Play Store for Android and Kindle.

Click to Play:

This was our first app that we thought looked good enough to give away to real users.
I was very proud of the artwork and how the game played on screen.
It’s a simple no-frills game but it was a perfect test platform to scope out what’s required to get a game published.
Which incidentally is a little daunting but in reality the whole process of publishing a game on the Google Play Store was pretty easy.
The Google Play Console was easy to use and there were plenty of official and community references to help us through it.

Uh Oh … Problem …

We went through several development iterations and found a revision that worked on most Android platforms.
We were running Unity 5 and targetting all mobiles above Android API 15 4.03 called “Ice Cream Sandwich”.
Not being a big shop our test devices were old personal phones that were around this API version. It was running well and looked great an a VM but once we started using our physical test devices we found a few issues dealing with different screen resolutions and one phone didn’t have enough resources to run the random number generator so that the same numbers kept spewing out.

Then we upgraded to Unity 2017.1.0f3 and lost support for those older API’s. Oops no more supported hardware to test on! We really needed to get some Beta Testers who could trial the game on a variety of different platforms that we couldn’t access. We could test thoroughly with virtual machines but as we found when testing on real phones there are some things about how the game looks and plays that can only be reproduced on the real platform.

Solved! (Not!)

So our marketing team (Harmony and Felicity) and I did some research on recruiting Beta Testers and we quickly realised that we couldn’t affort to pay for the service.
We did find a wealth of paid services out there which I’ll list below in case someone can make use of that information.

Not all of these services were paid but most of them required some sort of effort or buy-in up front that we couldn’t match.

http://appstorm.net/
http://appuseful.com/app/add
http://betacandy.com/
http://betali.st/
http://betalist.com/
http://betapage.co/
http://betatesters.io/?utm_source=InstabugBlog&content=betatestbeginnersguide
http://erlibird.com/

Ready to introduce your startup to the world?


http://makeuseof.com/
http://market.thenextweb.com/
http://momb.socio-kybernetics.net/

Contact us


http://quora.com/
http://startupli.st/
http://startuplift.com/
http://web.appstorm.net/
http://www.betabound.com/
http://www.betabound.com/announce/
http://www.mob4hire.com/

Submit Your StartUp

Submit

Submit Startup


http://younoodle.com/
https://betafamily.com/
https://feedmyapp.com/
https://inspiredbeta.com/
https://www.topcoder.com/
https://www.usertesting.com/
https://www.utest.com/

Social Media Save Me!

So we turned our attention to the online communities that might be able to assist us.
We did some more research and found that social media is literally teeming with sites and groups that want to Beta Test your app. Awesome. Problem solved.

We published a Beta version of the app on the Play Store and mocked up some Beta Testing campaign ideas along with a set of goals that we had for Beta Tests. We were looking for technical testers as opposed Marketing and I can tell you I was pretty excited about getting some feedback on the game. When we pubished the Beta version of the game we could choose a number of Beta testers that the game would be released to. The interface gave us a minimum of 1000 users so we went with that and given the number of social media sites we found thought that this didn’t sound all that unreasonable.

This is a brief list of the social media sites and lists and groups that we advertised for Beta Testers on….

Google Communities:
Android Beta Tests
https://plus.google.com/u/0/communities/109783274236354693762
Android Game Developer
https://plus.google.com/u/0/communities/107240075790372473394
Indie Game Developers
https://plus.google.com/u/0/communities/116817422244345691332
Game Developers
https://plus.google.com/u/0/communities/100673606633986699530
Game Developers
https://plus.google.com/u/0/communities/101640237427303194102
Game Programmers
https://plus.google.com/u/0/communities/102656807509358954492
Mobile Game & App Developers
https://plus.google.com/u/0/communities/107514033174068960125

http://www.reddit.com:
/r/TestMyApp
/r/alphaandbetausers
/r/AndroidAppTesters
/r/startups
/r/betatests
/r/androidapps

https://twitter.com/:
search?q=%23Betatesting%20&src=typd
search?q=%23Betatesters&src=typd
search?q=%23Testmyapp&src=typd
search?q=%23Indiedev&src=typd

We even did a big call through our Facebook Page and Blog.

Big Reveal!!!

Guess how many Beta Testers came flocking to try out our great new game…..

None. Zero. Zilch. Nada. Not one.

We checked around the boards on these sites and groups and actually found very little actual Beta Testing going on.
After a few weeks of interacting with these communities and even testing a few apps ourselves thinking that we might get some kind of Beta Testers Karma we still found that no-one really wants to test your app (unless maybe if you are building a huge free MMO that’s going to be awesome – anyone doing that?).

Free Advice!

So there you have it – Beta Testing using social media groups doesn’t work. You don’t get nufin’ for free in life.

So my advice to you is that if you don’t have one already, start building an email list now. For a startup game dev studio with no support framework it’s pretty hard to come by free help when you need it. Ideally, start collecting email addresses before you even have an app, and keep at it! Because even a handfull of Beta Testers is better than none.

The Five Games in Ten Weeks Challenge!

Some months back I went to a local presentation by the Unity champions at The Arcade (a collaborative workspace specifically for game developers and creatives) in Melbourne.  It was one of those “learn about others and gain insight into one’s self” moments.  One thing I picked up from one of the presenters from Hipster Whale (makers of Crossy Road) was that when they were developing a new game they tried to keep the proof of concept to a two week period.  Some time later with this in mind I presented to myself the “Five Games in Ten Weeks Challenge!” to see if I could really push out five different games in ten weeks.

Five Games in Ten Weeks

Continue reading

New Game! Peace Run

Hi Zulu here  – We started work on a new game this week called Peace Run.  I wanted to do a continuous runner and really liked the idea of having a line drawing animation that looks like the player character “grows” out of the line.  The runners will be animal silhouettes like the dog shown here.

Doing the frame by frame animation has been really fun but it took a lot of trial an error to get to this point – which as you can tell isn’t perfect yet.

All the artwork was done in GIMP 2 and the game design is in Unity3d.  We used a simple animation script to play the start of the walk sequence.  I can’t wait to get this puppy into a run and a full sprint.