I’d like to thank the wonderful Beta Testers who have signed up for our Open Beta of Endless Elevator over the last month. I was really surprised how many people responded to our call and very grateful to all those who provided feedback.
Your feedback helps us make a better game – thank you!
One feature of our Beta Testing was opening multiple channels to provide users to get back to us. Not only did we use the Google Play Beta Feedback and Stars system but we also took feedback on email and through social media. One new thing we did was to incorporate a chat channel on our Beta Landing Page where users could provide anonymous feedback directly on to our web site. I feel that the anonymity of this format was a really important source of quality comments for us.
Endless Elevator went into Beta Testing on May 27, 2020, 8:10 PM.
Finally we made it to public testing! After a few months of keeping myself quiet and a seeming eternity of bug fixes I think I got a minimum viable product fit for your eyes, ears, and phone-ready fingers.
Please head over to our Beta Test Page and try it out. I’d love to get some feedback from other enthusiasts and developers.
We have an anonymous Chat Channel right there on the page that you can trash talk into so go for broke! (You are also allowed to be supportive and kind as well if that is your nature).
🙂
The Beta Page has more information about the game as well links to articles written during development that explore the mechanics of the game.
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:
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:
But when it came to the application start up we found that we had a problem. It was taking over 20 seconds for the game to open up after a user pressed the icon.
Obviously this was way too long as much of that time was spent sitting on a black screen.
Trouble was with the Debug builds of our APK’s running in the profiler it would only pick up on game play issues and we couldn’t identify what was causing the slowness on start up. So we switched to using ADB the Android Studio Debugging Bridge to see what was actually going on under the hood of Android system while our game was loading.
If you want more info on the ADB tool have a look at my previous post here.
We had a handfull of APK’s that we wanted to test against on out local workstation and used APK to copy them over to our attached development device using ADB commands.
Like this:
Then we ran the adb command with the logcat argument and passed that output into a file to read afterwards.
Now pumping logcat into a file generates lots of data including the buffer that was recorded before the command was run so you will get lots of info from earlier that you either need to filter out or grep through.
This is one way to filter out in adb command line but it’s not as useful as grepping through the file:
>adb.exe -d logcat -e isApplicationExternalStorageWhitelisted
It’s a pretty big log generated in just a few seconds of logging:
I preferred to have the full log in the file and use notepads and command line greps and epreps to get the info I wanted to hone in on.
On Windows I have a great Unix like tool called MobaXTerm which is really useful for this sort of work. https://mobaxterm.mobatek.net/
It’s a Windows ssh client but includes a Cygwin type access to your local Windows file systems.
So when we were searching through the logs (and it takes a while to get used what you are looking at. I’d recommend getting on google for anything that looks interesting).
Here is an example of the log:
It changed a little bit with each run but this is the main info that I was using for to make my judgements about start up speed on.
### This is the initial call for the application
09-28 10:29:08.684 4938 4938 D StorageManagerService: getExternalStorageMountMode : final mountMode=1, uid : 10495, packageName : com.ZuluOneZero.TheDogRun
### This is the process being allocated
09-28 10:29:08.752 4938 4938 I ActivityManager: Start proc 8679:com.ZuluOneZero.TheDogRun/u0a495 for activity com.ZuluOneZero.TheDogRun/com.unity3d.player.UnityPlayerActivity
### The Window for the game is open had has focus
09-28 10:29:09.336 8679 8679 I Unity : windowFocusChanged: true
09-28 10:29:09.337 8679 8679 V InputMethodManager: Starting input: tba=android.view.inputmethod.EditorInfo@23ee73 nm : com.ZuluOneZero.TheDogRun ic=null
09-28 10:29:09.346 4938 6402 V InputMethodManagerService: windowGainedFocus : reason=WINDOW_FOCUS_GAIN client=android.os.BinderProxy@9752c36 inputContext=null missingMethods= attribute=android.view.inputmethod.EditorInfo@ea1162f nm = com.ZuluOneZero.TheDogRun controlFlags=#105 softInputMode=#20 windowFlags=#80e90500
### The Game has the Window on
09-28 10:29:09.420 4938 5124 D SamsungPhoneWindowManager: Turning screen on : com.ZuluOneZero.TheDogRun uid = 10495
### Splash Screen is coming up
09-28 10:29:09.424 4938 5124 D InputEventReceiver: channel ‘d7f15c8 Splash Screen com.ZuluOneZero.TheDogRun (client)’ ~ Disposing input event receiver.
### This is a Debug Package but the Unity Debugger or Profiler was not attached so there is a 4-5 seconds delay while it times out waiting for the connection
48832 [Id] AndroidPlayer(samsung_SM-G930F@192.168.1.139) [Debug] 0 [PackageName] AndroidPlayer” to [225.0.0.222:54997]…
09-28 10:29:09.544 8679 8696 D Unity : Waiting for connection from host on [0.0.0.0:55070]…
09-28 10:29:14.571 8679 8696 D Unity : Timed out. Continuing without host connection.
### Scripting Engine starts up
09-28 10:29:14.682 8679 8696 D Unity : InitializeScriptEngine OK (0xe7543ee0)
09-28 10:29:14.682 8679 8696 D Unity : PlayerConnection already initialized – listening to [0.0.0.0:55070]
## Creating Open GL
09-28 10:29:14.761 8679 8696 D Unity : OPENGL LOG: Creating OpenGL ES 3.2 graphics device ; Context level <OpenGL ES 3.1 AEP> ; Context handle -1013109888
### Unity Reports it’s Unload time
09-28 10:29:22.067 8679 8696 D Unity : UnloadTime: 2.403000 ms
### Ads Start up
09-28 10:29:22.309 8679 8696 D UnityAds: com.unity3d.ads.cache.CacheDirectory.getCacheDirectory() (line:42) :: Unity Ads is using external cache directory: /storage/emulated/0/Android/data/com.ZuluOneZero.TheDogRun/cache/UnityAdsCache
### About this time the Debugging on the Application side kicks in and you start to get these sorts of messages in the log:
09-28 10:29:23.533 4938 9976 I ActivityManager: DSS on for com.ZuluOneZero.TheDogRun and scale is 1.0
09-28 10:29:23.731 8679 8696 I Unity : Building GPG services, implicitly attempts silent auth
09-28 10:29:23.731 8679 8696 I Unity : #0 0xc6578460 (libunity.so) GetStacktrace(int) 0x44
09-28 10:29:23.731 8679 8696 I Unity : #1 0xc5f5e978 (libunity.so) DebugStringToFile(DebugStringToFileData const&) 0x230
09-28 10:29:23.731 8679 8696 I Unity : #2 0xc546bf9c (libunity.so) DebugLogHandler::Internal_Log(LogType, core::basic_string<char, core::StringStorageDefault<char> >, Object*) 0xa8
09-28 10:29:23.731 8679 8696 I Unity : #3 0xc546be8c (libunity.so) DebugLogHandler_CUSTOM_Internal_Log(LogType, MonoString*, MonoObject*) 0xb4
09-28 10:29:23.731 8679 8696 I Unity :
09-28 10:29:23.731 8679 8696 I Unity : (Filename: ./Runtime/Export/Debug.bindings.h Line: 43)
09-28 10:29:24.925 8679 8850 I UnityAds: com.unity3d.ads.api.Sdk.logInfo() (line:70) :: Requesting configuration from https://publisher-config.unityads.unity3d.com/
Total start up time around 16 Seconds – we got lucky with this one.
But you know it’s system dependent so we did it another ten times for each package to make sure that the readings were comparable to our out loud counting of seconds while watching the device.
To make a long story short we started getting an idea of what happens when the app starts up.
In the end the thing that most improved our startup time was the build that had changed settings to our audio files in the Unity import settings.
Basically all audio files were converted from the Unity default to the Overide for Android setting. The background music was streamed and shorter sound effects were compressed in memory.
So hopefully if you take this advice do that up front and you won’t have to spend a fun rainy Sunday debugging the start up time problem.
Interesting as it was it would have been more fun doing promo art for the upcoming release!
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:
This is a quick demo of the basic play mechanics from our new game in development Endless Elevator. We got the basic movement working a while ago (see our Smooth Moves post) and now that The Dog Run is in BetaTesting we can spend some more time working on this game.
The Good Guy Cop Character movement (oh yeah he goes left and right)
Firing his awesomely powerful dumb dumb gun
Using (the eponymous) Elevator (see if you can spot the camera tracking bug!)
Traversing (the namesake) Escalators
Finally entering a doorway with a Power Cube (I’m not sure what it will look like in the final game yet). When he goes into a doorway with the special block the game flips and he goes into a Super Spy Store (not shown) where new fun weapons and power-ups are available! Cool.
An Endless Runner for Android goes into Beta Testing.
Take your dog for a run – it’s good for your heart – and supports animal rescue!
This is a free game – with no pop ups. In the Alpha release there is the option to watch ads.
All profits from the ads go to support animal welfare and animal hospitals.
The game is about taking your fun lovin’ pooch out running – but watch out! There is a bunch of obstacles in your path – it’s a good thing you are a natural jumper and can run all day in all sorts of weather.
Hi Gene here ! We are getting really close to pushing our Dog Run game into Beta Testing on the Play Store. The original soundtrack was a little too moody for the game so we started working on a new one.
If you want to be a Beta Tester Subscribe to this mail list on the right.
We started with a basic rhythm and then built it up into eight different loops. Next the crazy funky keyboard riff was added in a really simple twelve bar step pattern. It took a while to get it right but the wailing howling synth was laid over the top in about sixteen takes. Worth it though. Last we added a few undulating effects for interest and mixed it down inside the box. I’ve been listening to it loop about in my head for a few hours at a time and I think it’s making me loopy. Damn fine effort even if I say so myself.
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.
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
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.
