App Bundling

We first came across the App Bundle system, when we got prompted by Google Play to update our previous game to have a 64-bit build for newer Android devices. This seemed to be a very nice system: we provide a bundle, Google then builds up a suitable APK for the end user’s device, minimizing download size. And to accommodate for Google’s quite strong recommendations to always use App Bundles, Unity can now build those for us. However, it wasn’t quite as easy as it could have been… And hence: this tutorial, so that others might learn from our mistakes!

First of all, you need at least Unity 2018.3 to get the App Bundle option in build settings. We shifted to 2019.1.6 since it was the most recent stable version at the time. What should be noted about upgrading to this particular Unity version you might run into the following problems:

– if you get plenty of CS1644 errors from TextMeshPro or other components, your best bet is to go to Project Settings -> Player -> Other Settings and switch the .NET to 4.x, that’ll fix those pesky reds

– Error CS1029: “The Data Privacy Plugin is included in the Analytics Library Package and is no longer needed. Please remove this plugin” -> remove the old Data Privacy plugin and make sure you have at least 3.1.1 version of the Analytics Library (check from Package Manager)

A lot of *DK’s

f you’ve built for Android before, you should already have JDK installed and Android SDK for the target platforms. If your SDK Tools are old, Unity will prompt you to download the new ones when building so this isn’t much of an issue

However, you might not have the NDK, native developer kit, which is needed in order to build with IL2CPP backend, which in turn is needed for the 64-bit build. This one was a bit hard to find, as simply checking the “Android NDK installed with Unity” box didn’t work for us.

At first, I installed the latest NDK available, but it didn’t play well with Unity, so after a bit of googling, we got a slightly older version, Android NDK, Revision 16b (December 2017), from the NDK archives. After installing it, it needed to be linked to Unity’s Settings.

Configuring the backends

Then, we’ll have to play around with the Project Settings (-> Player -> Other Settings):

– Configuration, Scripting Runtime should by now be 4.x

– Configuration, Scripting Backend needs to be switched to IL2CPP, since we need this to build the 64-bit version of the native code

– Configuration, Api Compatibility Level needs to be .NET 4.x

– Configuration, Target Architectures, check the ARM64 box

– Identification, select the target platform and the minimum platform. Note that the minimum platform requirements are often updated by Google. As of now, the minimum can’t be lower than API level 23.

– Identification, also check that you update the version number and Bundle Version Code. Play Store won’t accept the bundle if it has the same code as a previous version. Also, if you do upload a bundle, but the release fails (for instance, if it detects that it isn’t 64-bit compatible) and you need to re-upload it, it still needs a new version code…

Getting your keys straight

Also, for the app to be signed for release, you’ll need to give your developer key in Player -> Publishing Settings. If you don’t already have a key for your company, you can make one with Android Studio. I recommend opting into Google’s app signing, but you still need a key to verify your app to any further updates for your game. But there are good instructions for it from Google

In the end, you should have a Keystore file, which contains your signing keys. In the publishing settings Project Keystore section, you’ll have to browse to find your keystore (keep it safe, on some other folder on your machine than the Unity project folder) and access it using that first password you determined when creating the keystore. Then in the Project Key section, select your key from the dropdown (it’ll update once the first password is cleared) and give the password for that key.

And then the finale!

Now, finally, we can go to the actual Build Settings (via File -> Build Settings). Switch the platform to Android and check the checkbox next to ‘Build App Bundle (Google Play)’. Browse to find a suitable folder where to build your app (personally I use a folder outside the Unity project and name it ‘Bundle Builds’ or something similar) and give it a name. The name is trivial, but I recommend using something that has version numbering. Then, click OK and wait for the building to start. If you get a warning message, follow its instructions. Usually, it’s either missing SDK Tools (which Unity can download for you), missing cert key (make sure you’ve given the passwords, they reset on every restart) or something else quite easy to fix, so don’t fret! 🙂 And then waaaaait for a looooong time for the build to finish…

And once you have that precious .AAB bundle file, you can upload it to Developer Console. On the first page of the upload process, you can drag-n-drop the bundle file and let Google chew on it for a while. If you get an error at this point, it is most likely to do with your keys, but the error messages are quite helpful to point you to the right direction. Sadly, it won’t clearly tell you at this point whether your bundle is 64-bit compliant… You can see it from the info just under the dropbox, if you click on the expand arrow next to your newly updated bundle. On the last row, it says how many and which client environments are supported. It should list at least arm64-v8a and armeabi-v7a. If you see only the v7, then your bundle didn’t have a 64-bit version included and it’s most likely due to configuration settings (first check that you have .NET 4.X everywhere). When you go to the next page of the publishing, it will give you a very nice red-flagged warning about it though, so you can’t really miss it at that point.

Well, I hope you now got your bundle ready and error-free! Just keep calm and ask in the comments if you get stuck somewhere! I don’t pretend to be any kind of an expert, but having struggled with this so many times now, I think I can at least point you in the right direction. Good luck!

Thank you, Beta testers!

It’s been a bit over a month since we released the Beta for our latest game: Anxiety of Alina. We got a nice amount of feedback from our amazing testers and we are so grateful for all the comments! Thanks to the testers we have a better understanding on how to go forward with the development.

The feedback was pretty uniform, and really highlighted the parts of the game that needed more work, mainly usability and user experience issues. We also heard from you what you liked about the game so we want to amp that up in the upcoming release later this year.

The game will now continue to be in development focusing on improvements to make the game more enjoyable experience, but you can still download the game and send us a message, even though the official part of our Beta testing is now over.

We’ll post more about that once we have a solid roadmap for these new features, so stay tuned!

Alina’s Beta is now LIVE!

hew ! We’ve been working on this game since January and now, finally, we’ve published it for you to download and play ^^ We sincerely hope that you’ll test it out and let us know what you think. There’s a link to a survey in the game and all feedback – whether good or bad – will be appreciated.

You can find the game as an APK from our Itch.io page. Soon you can also get it from Google Play. We’ve decided to make this Beta version free for you guys!

Outlet – Energy Hack 2019

A while back we learned about this hackathon that was coming up, with nice prizes and – more importantly – a gamification theme. The task was to innovate new solutions that would make mitigation of energy consumption something tangible and visual for young people. The organizers wanted to see solutions that could help visualize the energy data that can be collected from buildings and offer methods of saving energy through gamification.

Hackathon team: Pekka, Joonas, Sade and Matti

From our team, Sade and Joonas were up to the challenge and teamed up with Matti Krusviita and Pekka Parkkinen to hack away at the event. Sade and Matti had already had one very successful hackathon together last year, and Pekka had the industry knowledge of sustainable applications.

Since the theme and criteria was already known beforehand, we had a couple of brainstorming sessions before the event, to toss around ideas about our application. We came up with quite a variety of game ideas, but eventually we got really interested in the concept of an escape room, where instead of time the players would compete against depleting energy to get out. We quickly thought of some sample puzzles to demonstrate the concept, but the idea really struck us only after we decided that we would make it a multiplayer AR game.

brainstorming the idea

The jist of it is: a group of kids can take out their phones, anywhere, like in their living room, start the game and see the puzzle items appear all around them: on empty spaces on the floor, on tabletops etc. They then have to get up and go interact with the items (like in a real escape room), trying to find clues and solve the puzzles to advance. The puzzles would require choices that revolve around saving energy. Some options are easier, but not that energy-efficient. So in order to escape from the room (and get the highest score possible), they kids really will learn on those little everyday things they can do to mitigate consumption.

We also envisioned that there would be an escape room editor in the game, so that the players could generate content on their own as well. For this to work, the puzzles would be built modularly and they could easily be just dragged and dropped into a room to be designed. With this option, we saw how the game could be taken to schools and classrooms, where the kids could design rooms for each others and then play, all the while learning about methods to save energy at home environments.

The actual hackathon event was for two days, where we sat down to finalize our concept art, mockups and game design document. We got to tell the judges and mentors about our initial idea and got feedback throughout the event. They raised some very important questions about our design, which led us to work more on our puzzles to make them more varied, intertwined and cooperative. Time flew past so quickly! As it usually does at a hackathon… Matti and Pekka as the innovators were mainly in charge of the GDD and puzzles, as Joonas and Sade were putting together our mockups, slides and the pitch.

Luckily, by now we have quite a lot of experience in writing and presenting pitches. Although at this hackathon there was a chance to present a demo to the judges, the pitch still has a lot of weight. There was even a pitching workshop at the event, although it only threw a couple of vague concepts at the participants. We had gotten a much more thorough education on the subject at Boost Startup Journey last year. Still, it was past midnight once we had finally gotten a script together and called it a night. Not much time for rehearsing it, since we needed some sleep before continuing work early next morning.

Early morning on Saturday was the time for rehearsal pitch, which Sade botched – by our standards, since we know what she was supposed to say and how well she can actually pitch. The judges seemed to like it though and commended us on the pitch structure and deliverance. We knew though, that we had plenty of work to do, lots of rehearsing and the pitch deck was still mostly unfinished. We cut it really close to deadline with the deck, and our info slides meant for the judges to get a grasp of our application were really raw.

As the order was drawn, we got the next-to-last pitching slot. Our pitcher was as nervous as she always is before pitching. Luckily, after half a dozen competitions or pitch-events like this, Joonas is already familiar with the ropes to keep Sade sane enough up until her turn. Instead of listening to any of the other presentations, she was kept busy with rehearsing the pitch over and over again, so that she could nail it on the stage. She didn’t. But she nailed it enough.

One thing you need to know about pitching, is that you cannot freeze. Nothing is as irritating as watching someone on the stage, saying ‘ummm’ before every sentence and you can just hear the cogwheels turning as they try to remember their next line. Having a pitch script is good practice, you’ll need one to time it properly and to see that you’ve covered all the main points of the problem, product and plan. Script alone is not enough though, you also have to be able to improvise on the go once something goes wrong. Note, ‘once’, not ‘if”. This is something that Sade can do. She deviated from the script, but it was mostly unnoticeable to the crowd and it only cost us a cut in our ask-section. She’s still kicking herself over it though, since it was the first time ever she was in danger of going overtime.

pitching can be terrifying

One other thing we heard later on, was that Sade was the only one to actually literally to go on stage to pitch. The venue was at Turku SparkUp, a startup community where the main hall has an arrangement of chairs in front of a large screen and a small stage, not high enough to even have stairs. There is always plenty of room between the audience and the stage. The host of the competition later told us that maybe because he hadn’t used the stage himself when introducing the teams, none of the other pitchers had gone up to the stage, but had stayed in front of it. Sade didn’t even think twice about it – and remember, she hadn’t watched any of them before her – just got up there. Sometimes it is those little things that make it more convincing.

a happy team with their prizes

Improvisation and the ability to be convincing (enough) got us quite many praises, many came to say that our pitch had been the best of the bunch. And we got something to show for it as well: an honorary commendation for our AR solution suited for classrooms with a ‘very good, maybe even the best pitch’. All worth the nervous breakdowns before and after the stage.

Bit1 2019

Bit1 is a national student game competition in Finland, that was hosted for the second time this year. Last year we were there with our Fuzzy Runners, and this year we went to test our wings with Anxiety of Alina. In the main event the top teams from the largest game hub  cities in Finland compete for the points from a panel of judges who are top game industry people in the country. We were competing for Turku and scored a spot in the top three from our preliminaries – Prebit – advancing into the finals.

The Prebit event was the first occasion where others got real hands-on playtime with our game. We got some valuable remarks and pointers on how to proceed with the game in regards to game balance, difficulty curve, user experience, and business model. We took all of this into heart, discussed our options and made some changes into the game accordingly. However, we did not have that much time before the Bit1 2019 event, but did what we could, while still having a solid and bugfree(ish) build for the judges to test out.

Our demo booth setup

So, a group of three of our developers – Sade, Joonas and Otto – traveled to Tampere, where the main event was hosted this year. The event was for two days: the first day was reserved for pitching the games and playtesting for the judges only, the second day was open for public and at the end of the day, we heard which teams had made the best impression.

Pitching your game is… a very important skill to master. Also, highly nerve-wrecking, if you ask our CEO who has to actually do it. In just a few short minutes, you have be able to convey the basic idea of your game, convince everyone of the novelty of it, dive into the business model and praise your team. In Bit1 though, it’s not all about the pitch, since that’s mainly there to just give everyone the taste of  your game, to make them intrigued enough to come test it themselves. The real job has been made weeks and months before the event, since in the end, it’s all about how good your game actually is.

So the three of us were manning our demo stand, phones at hand, getting people to play the game. It wasn’t a real playtest setting, some of the visitors wanted to hear a brief intro of the game before trying it out, others wanted to just dive in and learn by trial-and-error. The latter got us true insight on first impressions of the game and although we got critique and new ideas on how to improve UX, it was quite encouraging nevertheless. One of us was taking notes of all the comments we got and that piled up into a huuuge list!

Game development doesn’t stop even at an event like this!

The second day was dedicated solely to demoing the games. Must say, there seemed to be less visitors this year than there were last year at Bit1 2018 at Helsinki, but this worked out for us nicely, since we had more time for each individual person. In the end, it was quickly apparent that our game was not something that could be fully grasped within a few minutes. It would have required tens of minutes or more to get really into the whole story behind the game. It was also very interesting to see who really responded to the whole theme and the story-driven aspect of it, because it really helped us in solidifying our target audience for the game.

All-in-all, most of the feedback was quite positive. Learning how the people played – and more importantly: wanted to play the game gave us quite a new direction on where to take Anxiety of Alina. Some might say that it is foolish to rescope the game at this point of development, but we really want to release a game we can be proud of, we would play ourselves and would invest money into.

Sadly, we didn’t make it into the top 3 of the competition. But that’s OK, the quality of the games was very high and there were many games that looked ready to ship although just being a few months in development. For us, it was mainly about getting networked and getting playtested.

So now, since we have recouped from the trip, we’ve been going through all the feedback. Of course not all of them are going to be picked for the development pipeline: we simply can’t cater to everyone with this game. But changes are coming up and now it’s crunch-time to get the game ready for an open Beta.

Rebranding

As you might have noticed, we’ve changed our name from Aioni to Vainary. It was not an easy change for us and truth be told, not really wanted it either. But unfortunately, we were forced into it. You see, when we formed our team and chose Aioni for its name, we didn’t notice that the name had already been registered in Finland for another company. Due to Finnish regulations, we could not get a formal company name Aioni, or even Aioni Games for ourselves so we had to fall back on a whole new name.

The change is a bit hard, since we are currently very busy developing our newest game: Anxiety of Alina and we would not like nothing more than to put all our time, efforts and resources into that game, instead of rebranding. This is why you might still see Aioni things around during the migrating phase. Please bear with us! We are working hard to get things organized again as soon as possible.

So what is Vainary anyway, you might ask? It’s a really silly pun, actually 🙂 When you think of how you’d pronounce “binary” in Japanese, it will sound very similar to “vainary”. Our CEO really likes Japan and the Japanese language and apparently, binary code. You might see a hint of this binary connection in our new logo 😉

Anyway, we hope that soon we’ll get used to calling our company Vainary and then we can again just focus on making our games!