Enhanced process for hybrid apps

Some months ago I wrote about the pain that it was to create a new build, I’d like to update that with my current setup which is much better tho not still super optimal.

I have reduced the manual steps prone to failure as well as the bandwidth cost. The release and announcement part is still manual tho, so I still don’t to release for all platforms and forget to announce thru all channels.

The cocoon.io parts have been removed in favor of a pure Cordova/Crosswalk approach, which have made possible lots of automatisation.

Still, what takes more time is the manual process to be done for each different storefront via its own web interface. Each one requires different info, and all uploads have to be started and monitored manually. It’s pretty uncommon for a store to supply a command line tool.

This is the current process executed for each new release of Ananias:

Packaging

  • Mark the new version in the source code (client and server)
  • Execute the packaging script for each platform, it does the following:
    • Generate a new JS bundle using browserify
    • Generate the player’s manual
    • Copy the required assets based on the platform
    • Do platform specific things like using cordova/crosswalk, nw.js, signing and zipaligning APKs, etc.
    • These are currently shell scripts, no fancy gulp or grunt for now
  • Rename and zip the executable packages for Windows, Mac and Linux (Should add this to the script)
  • Execute the cordova build for iOS
  • Build changes log from git commit messages

Distribution

  • Upload new build to web (ananiasgame.com/play) (About 15MB) (Only Standard edition)
  • Deploy new server version and restart (About 1MB) (including executing migration database scripts)
  • Upload to itch.io via web interface (About 200MB )
  • Sign in to google play developers console
  • Summarize change log for Google Play
  • Upload both x86 and arm APKs (About 100 MB)
  • Upload both APKs to Amazon via web interface (About 100MB)
  • Upload to indiegamestand via web interface (About 200MB)
  • Upload to gamejolt via web interface (About 200MB) (Only Standard Edition)
  • Upload to IndieDB via web interface (About 200MB) (Only Standard Edition)
  • Open xcarchive in xcode organizer
  • Submit package to App Store
  • Wait for processing
  • Go to iTunes Connect
  • Go to Testflight / External Testing
  • Select new build to test
  • Wait for beta review
  • Go back to Testflight / External Testing
  • Set the new build as active.

The process should be executed twice, once for the Standard Edition and then again for the Fellowship edition.

The dream of having a single web endpoint, and have all the clients deal with the updating is still far from happening.

 

My Pokemon Go Quest, Update 12

It’s been over a month since the last update; for the most part it had been a booooring month with little to talk about… I was about to give up in my quest, however by the end of October and start of November things started getting interesting again….

The halloween event brought lots of additional candy and creepy Pokemon…

And recent changes in the game have put some fresh air into the experience, you now get a lot of items on your first pokestop, lots of XP on your first catch and the game keeps track of your daily engagement.

 

Leveling up after Level 20 is hard… it took a couple of Lucky eggs and a whole month to get to Level 21!

  • New caught pokemon: Onyx
  • New pokemon via evolution: Butterfree, Victreebel, Polywhirl, Primeape, Gengar, Haunter, Golduck, Rapidash, Tentacruel, Marowak
  • Collecting a lot of nidorano and nidorana candy for Nidoking and Nidoqueen
  • I’m level 21 now, 73.5 km walked, 87/99 pokemon

SPID 8 – Captain Tsubasa online

I will be posting SPIDs (Slashie’s Project Idea Drafts) in the blog, they will be short ideas for games or other projects I may or may not develop into full projects. May be someone will be inspired by them and save me the trouble of developing them.

Based on Captain Tsubasa II: Super Striker for the Famicom, create a game that keeps the spirit of the original including the 2D graphics and cinematics, while allowing online play and other game modes.

tsubasa3

Features

  • Playable in any browser and mobile
  • No history mode.
  • Select a team and play with your friends or…
  • Create your own persistent team, and participate in tournaments.
  • 2D illustrations similar to the anime

tsubasa2

 

Some of the things to improve:

  • Usability,  keeping  the style of the interface but removing it’s rough parts (fan translations had to struggle with it to make it work)
  • No experience points / level up, players have fixed stats and it’s up to the player using their best abilities in the field.

 

tsubasa1

Lorenzo

One week ago, Victor Barrios died in the Bullring of Teruel, Spain. He was killed by Lorenzo, a bull from Ganadería Los Maños.

Lorenzo was sacrificed shortly afterwards, and his mother Lorenza may have been slaughtered too as part of a tradition to end the lineage of the “Killer Bull”, but she had reportedly been killed already weeks before, because of her old age.

I did this small game, as a tribute to Lorenzo.

Play now!

All of his life Lorenzo was trained to become a fierce fighting bull, but instead of being hailed as a great champion when he manages to defeat his opponent against all odds, he sees the world turn against himself and his family. Will Lorenzo be able to escape and save his mother from being slaughtered?

SPID1 – Concordia Tournament

I will be posting SPIDs (Slashie’s Project Idea Drafts) in the blog, they will be short ideas for games or other projects I may or may not develop into full projects. May be someone will be inspired by them and save me the trouble of developing them.

SPID1 – Concordia Tournament

dumeril

A simple 4-players hot-seat death-match game themed on the universe of Ananias, players would pick a class and try to defeat the others in 2D combat (similar to Towerfall). Art will not be pixel art but rather illustrations in chibi style.

Each class would have different features:

  • Paladin: Uses a crossbow as weapon, shoots bolts in a short range. Jumps low, can withstand 3 hits (heavy armor). Can attack with the Holy Sword of Destruction at close range.
  • Hunter: Uses a Magic Longbow as weapon, shoots arrows long range in an arc. Jumps high. Can withstand 2 hits (light armor)
  • Alchemist: Uses the Alchemist Carbine as weapon, shoots acid to a mid range in an arc. Can throw explosive potions.
  • Arcane: Uses a lightning wand as weapon, shoots lighting to a long range in a straight row.

During combat, players can find potions and spells they can use on their advantage.

A better build and deploy process for hybrid apps?

The current build and deploy process for Ananias takes a lot of time and requires lots of focus and bandwidth. Everything is done manually (and is thus prone to errors). Most of times I just can’t afford to release for all platforms, and I forget to announce thru all channels.

The cocoon.io parts are a bit cumbersome since they don’t have a CLI and it requires some back and forth, while also adding a dependency to an online service (for how long is it going to work?) I’m going to experiment with some native crosswalk builds to see if that step can be saved.

But probably what takes more time is the manual process to be done for each different storefront via its own web interface. Each one requires different info, and all uploads have to be started and monitored manually. It’s pretty uncommon for a store to supply a command line tool.

May be I should automatize parts of this? Someday I may do that, in any case it’d simplify packaging but wouldn’t make distribution any easier.

This is the current process executed for each new release of Ananias:

  • Mark the new version in the source code (client and server)
  • Generate a new JS bundle using browserify
  • Upload new build to web (ananiasgame.com/play) (About 15MB) (Only Standard edition)
  • Deploy new server version and restart (About 1MB) (including executing migration database scripts)
  • Use nwbuild to generate the executable packages for Windows, Mac and Linux
  • Rename the directories and zip them
  • Upload to itch.io via web interface (About 200MB )
  • Zip web directory
  • Update config on cocoon.io for next version
  • Upload web directory to cocoon.io (About 15MB)
  • Hit the build button on cocoon.io, wait for build to finish
  • Download APK packages from cocoon.io (About 150 MB)
  • Unzip package, copy release APKs (one per architecture, x86+arm7) to APK directory
  • Run script to sign and align APKs
  • Sign in to google play developers console
  • Upload both APK (About 100 MB)
  • Build change log from git commit messages
  • Summarize change log for Google Play
  • Upload both APKs to Amazon via web interface (About 100MB)
  • Upload to indiegamestand via web interface (About 200MB)
  • Upload to gamejolt via web interface (About 200MB) (Only Standard Edition)
  • Upload to IndieDB via web interface (About 200MB) (Only Standard Edition)
  • Set cocoon.io for iOS builds
  • Hit the build button, wait for build to finish
  • Download xcarchive (About 50MB)
  • Open xcarchive in xcode organizer
  • Submit to App Store
  • Wait for processing
  • Go to iTunes Connect
  • Go to Testflight / External Testing
  • Select new build to test
  • Wait for beta review
  • Go back to Testflight / External Testing
  • Set the new build as active.

The process should be executed twice, once for the Standard Edition and then again for the Fellowship edition.

THIS IS A LOT OF WORK. WHY CAN’T IT BE SIMPLER? This process takes out HOURS (Not exaggerating) of valuable and scarce development time for an Indie dev.

Why can’t I just simply update a single web endpoint, and have all the clients deal with the updating? they have to deal with it anyways, they just have to do it with their own, different store.

Also, the game is already multiplatform, if your platform has an HTML5 browser, like all modern platforms, you can play the game (Yes, you can even play the game on a PS4), then why go through all this?

I understand the advantages of having a downloaded app… people wants to feel they own the app, and they want to play their games while offline or in poor network conditions.

It would be awesome if the app could automatically check and download the updated scripts and required assets. This is not a new idea… some people has already tried but there are some obstacles:

  • Both Play Store and the AppStore are not very clear about their support of this model. You may be risking your app being taken down for not complying with the terms of service. They are also not MEANT to work like this, so you are always fighting against their nature.
  • For in-dev games, the player wouldn’t be notified a new version exists unless he runs the game or you implement some kind of push notifications.
  • The system has to work perfectly, if it doesn’t then your players will be stuck with an old version, or will be unable to play offline, or will end up with a malfunctioning app.
  • Another thing to consider is that this would prevent players from updating the web runtime in which the game runs, although I guess that may be fixed via a normal update.
  • If the player uninstalls the app or erases its data cache, they will have to redownload all assets.

There is a cordova plugin (cordova-app-loader) which adds support for “hot updates”. It seems to work but has some issues (based on what people reports). I don’t know of any similar tool for node-webkit / NW.js, I guess it’d have to be done manually.

Any thoughts?