Project Postmortem: Panasonic VIERA Connect (3)

Apple Muncher IconThis is the third of a four-part story documenting my somewhat excruciating and wholly uncharted experience developing an indie game for Panasonic’s obscure VIERA Connect television app market several years ago.

In the first part of this postmortem, I detailed the pains of becoming a VIERA Connect third party developer and struggles of setting up the rigid development environment required by Panasonic.

In the second part, I documented the development process of actually creating a game using the often restrictive VIERA Connect framework.

Time to Submit the App!

Panasonic VIERA ConnectOver the course of approximately three weeks, I learned the ins and outs of the original VIERA Connect API (Ajax-CE) and used it to develop a Snake game. In coming up with a name for the app, I observed that the Pansonic app market sorted apps alphabetically by title, with no option to sort by latest releases or popularity (official partners like Game Loft were given preferential treatment, with their apps pinned above the rest). With that in mind, I decided upon the name Apple Muncher to ensure that it would appear on the first page of available games for added visibility. In this short window of time, I had developed a full-featured game with 25 levels, multiple themes and an online high score system.

As indicated in previous installments, I was one of the first independent developers to jump aboard the Panasonic app market. At the time, there were less than two dozen apps available across all categories and almost all of these apps were from official partners like Netflix, Game Loft and Amazon. Upon inquiry, I was told by Panasonic that these partners were allowed special access to a “native” API that was not available to third party developers. As such, the big players were able to port their existing Web apps over with little hassle and could leverage far more capabilities than permitted by third party members.

With my app ready to go, I ventured over to the app submission section of the VIERA Connect portal. There was limited information provided apart from a few general guidelines and the submission form itself. I assumed the review and approval process would be comparable to iTunes and Google Play, but had to go in blind as no outside information existed about Panasonic’s app vetting process.

Submission Form

App SubmissionThe first objective was to prepare all of the assets and complete the online submission form. One aspect that threw me off guard was that the app had to be hosted on one of my own external servers. Although not a big deal, I had assumed that for quality control reasons Panasonic would had hosted these apps on their own servers in the same vein as Apple and Google. Panasonic, in fact, required both a production and staging URL where the app was to be hosted. Bare in mind that these apps are essentially JavaScript packages so they are hosted and served up in the same fashion as typical websites.

The most difficult part of asset generation came when having to prepare a set of screenshots. Since the only way to execute the app was via the television set itself, there was no easy way to capture the screen. On computers and mobile devices, the print screen functionality makes this an effortless process.  However, even an HD capture card connected to the TV would do no good, since the entire app was executed on the television’s internal OS with no video out capability.  Since the television supported SD cards, a welcomed feature would had been a ‘screenshot’ function that could be called from the code to save the screen’s current view to a PNG. Alas, that functionality did not exist.

My approach to acquiring the mandatory screenshots was a mix of painstakingly recreating the scenes sprite-by-sprite using graphic editing software, and photographing my television set’s screen and cleaning it up as best as possible in post-process. In the end, I had 4-5 screenshots that had to be scaled down to 480×270 for the submission form, and several different icons at 360×252, 160×112 and 256×60. The various icons are used on different screens of the app portal once the app has been installed.

The five screenshots I recreated via sprite-by-sprite graphic composition and taking physical photos of my television screen, due to the lack of any available screenshot functionality within the Panasonic API.

The five screenshots I recreated via sprite-by-sprite graphic composition and taking physical photos of my television screen, due to the lack of any available screenshot functionality within the Panasonic API.

The rest of the required metadata was mundane: Title, Description, Price, Available Countries, Supported Devices and so on. I set the price to $1.99 USD and indicated that it would work on all VIERA Connect capable television sets, which at the time was really only a single generation of sets. Finally, I submitted the form.  I received an automated email confirming the submission but with no additional information about how or when it would be reviewed. The email simply said “Application created (automatic notification).”

Price Considerations

When submitting the app, I made careful considerations about the price point. Realistically, I had no knowledge of how many VIERA Connect capable television sets had been sold and, in turn, did not know what the user-base would ever conceivably amount to. I researched Panasonic press releases, stockholder data and other avenues yet was still unable to ascertain with any grade of certainty how many compatible sets had been sold.

Piggy BankIn the mobile and PC markets, freemium and free-to-play revenue models have become so popular for good reason. By releasing an application free-of-charge, the potential exists for many more users to discover and try it out without any financial investment required. Revenue from free applications can still be earned any number of ways including via in-app purchases and advertisements. I have had great success in other markets by releasing free ad-supported apps that offered optional paid upgrades.

Unfortunately, the Panasonic API did not offer any sort of revenue-generating capabilities for free apps. There was no way to include third party advertisements or in-app upgrades. Likewise, no ability existed to allow a time-based trial so that users could enjoy the full app for a limited amount of time before having to purchase it (a much-welcomed feature on the Microsoft app store for Windows and Xbox).

Given the fact that I had already invested a month of my time and approximately $130 on the developer license, the only feasible way to make any return on my investment was to charge for the app. Other apps on the market cost about $1.99 average, so that is what I went with. In this way, if I could sell even 100 copies I would at least break even after all fees and expenses.

A couple of days after I submitted my app, I was approached by a member at Panasonic who encouraged me to make a free version of the app. They only supported paid apps in the United States and Europe, whereas the free version would be available to “100 countries” and instantly open the doors for “tens of thousands of players.” Still unclear was how many potential users existed within the United States and Europe alone, but I was reluctant to rework the app as a free version and go through the entire submission process a second time when my first submission hadn’t yet been approved.

Required App Documentation

The first correspondence about my app’s submission came two days later, where a Word document attachment advised me to complete more detailed documentation for the app.  This paperwork was about seven pages long and required the creation of an application flow diagram, sectional information, technical requirements, cheat codes to allow the testers to progress through the game, screenshots and more.

The application flow diagram I had to create as part of the documentation for this simple game.

The application flow diagram I had to create as part of the documentation for this simple game.

With the documentation complete I sent it back via email. Four days later, I got another email that my app status had been changed to “In QA.

Quality Assurance

Approximately a week after my initial submission, my app went into the “quality analysis” phase by Panasonic.  I had assumed this was not unlike Apple setting the status to “under review” after submitting an app through their market.  However, that thought quickly went astray as I got the report back from “the first round” of my testing in the form of a detailed spreadsheet.

Round One Testing: Four Failures [January 30]

The spreadsheet I received included four reported issues across two categories including Message Prompts and Functionality.

  • If there is no connection to the network or server, an error message SHOULD be displayed.
  • The game speed is too fast for the lower level. Cannot go to next row. ↑→↓ / →↓← etc
  • Name Textbox is not cleared after Pressing Cancel / Submit.
  • Highlight Day week month year in scores

Three of the four listed failures were related to the user experience, and seemed heavily subject to personal preference. I and several others who tested the original game did not have any trouble navigating the snake across the levels at the default speed. The game also supports keyboard controls for more responsive input, for those who do have a USB keyboard hooked up. Even so, I agreed to amend this and subsequently added a ‘easy’ and ‘hard’ mode, where the hard mode is what the original speed was. I added some checking to see if there was a connection error and made it so the high score buttons were highlighted more correctly.

am-6

The reported issue of “Name Textbox is not cleared after Pressing Cancel / Submit” was a deliberate design decision I made when coding the game. In playtesting, I found that having to repeatedly enter your name at the end of each round was a nuisance and very time-consuming with the on-screen keyboard. In the majority of use-case scenarios, the same person would often play multiple rounds of the game in a row. As such, I intentionally retained the entered name until the user exited the app. They were still able to delete and replace the name as they needed, but as a user convenience I stored it in memory. This feature was seen as an issue by the QA person at Panasonic, who must have preferred to manually re-enter their same name every time.

[Sidenote: Panasonic did not publicly allow third party developers to interface with the SD card so there was also no advertised way to store any app data internally; once the app closed all data would be wiped clean. There also was no way to get a unique ID for each device to store and retrieve personalized data remotely in any easy manner.]

I took care of all of the issues and wrote my comments and arguments in the spreadsheet. I disputed the name issue and explained the convenience factor of storing the previous name, but still made some enhancements to it so anyone who did want to change the name could type it immediately without having to manually erase the stored value. I sent back the revised spreadsheet.

Round Two Testing: One Failure [February 2]

A couple days later, I received a second round of testing results. The three previously listed Functionality issues had now passed their requirements. However, they were still hanging on the network connectivity issues, and included these unlikely steps to reproduce the issue:

 

  • Start the game > Unplug the Ethernet cable > Play the game > Submit a score

I had already worked in safeguards against a loss of connectivity to my server for any reason, but now was being told that if a person explicitly unplugs their network cable or adapter from the TV it should detect and warn of this in the app. I personally felt that if it came down to a total loss of Internet signal, the television firmware itself should monitor and alert the user since no aspect of the app portal or OS is accessible without connectivity. In either case, I spent additional time reworking the behavior so that if the user did unplug their network cable or otherwise lost total connectivity, then tried to submit a score, a more direct error notice would display.

With this and some additional refinements in place, I submitted the revised spreadsheet once again.

Round Three Testing: No Failures [February 8]

Finally after more than a week of QA testing and fixing, I got the good word that my app has passed the “Initial QA” and would “be sent to the QA team at Panasonic Headquarters for final round testing.” Say what? Apparently even after all of this there was still another round of vigorous testing to go. In this email notice I had to also confirm that it was an original creation and did not violate any copyright laws. Still, progress was progress.

Round Four Testing: Weeks Upon Weeks in Limbo [March 19]

This last bout of testing took a staggering 5 weeks to complete. During this time, I received a few other emails including:

  • Paid app support was now available in Canada alongside US and Europe. [March 6]
  • The app is officially now entering QA testing. [March 7].
  • BlackBerry App World / RIM / Digital River contract data for managing the app sales. [March 12]

On March 19, my app was finally marked as Approved and Waiting to Go Live. Hurray! Well, it was approved, but still hadn’t gone live. So I played the waiting game a little longer.

App Status Updated: Finally Live! [April 1]

Finally, after more than nine weeks had passed since I first submitted the app, it went live on the Panasonic app portal. Keep in mind that my app was one of the only new submissions that would had needed to be tested as I was one of only a few third party developers to try out the platform. Meanwhile, Apple is able to test and approve apps in about a week’s time period despite having thousands of new apps to run through at any given time, Amazon generally reviews apps within 24 hours and Google within several hours.

I was just relieved to have made it through the unforgiving validation process. To Panasonic’s credit, the spreadsheets detailing the specific issues were thorough and far more informative than the details (or lack thereof) you get if your app is rejected during Apple’s approval process.

Apple Muncher Panasonic

Whew! After over two months of “quality assurance” testing, my app was finally available on the Panasonic app market.

In the final installment of this postmortem, I will be detailing all of the post-launch events. This will include app usage statistics, revenue and further developments.

SAMSUNG Remote Test Lab: Test Android Apps on Real Devices for Free

ScribblifyFor the past couple of months, I’ve been working on a much-delayed update to my Android application Scribblify.  The original Android version was released back in early 2013 and hadn’t been updated on Google Play since then. Although it paled in comparison to the iOS counterpart, the first Android version still received positive reviews and was downloaded 200,000 times. Having released a major 4.0 update to the iOS version earlier this year, it was time to bring the Android version up-to-speed.

One of the greater challenges experienced with Android development occurs when it comes time to test. I previously wrote about the increasingly fragmented iOS platform, but even with a handful of different iOS devices sporting different resolutions and technical specs, nothing quite compares to Android device dispersion. In my updated Android app, for instance, I support all Android devices from API Level 15 (Android 4.0.3) up. According to Google Play, this makes the app compatible with 9,098 Google-certified devices. This list encompasses at least four years of devices including phones, tablets, phablets and more. Understandably, with such a large range of devices comes an equally large range of technical specs.

So, when it comes time to test an Android app, the more devices available to experiment with the merrier. It is particularly worth testing against the multitude of different device resolutions and DPI specifications to ensure that all assets scale appropriately, as well as testing against various OS versions to ensure nothing breaks. Google provides the Android Virtual Device (AVD) Manager, available through Eclipse, Android Studio and as a standalone tool. AVD Manager allows you to create custom-tailored virtual devices spanning the entire core spectrum of Android units, provided you’ve installed the necessary packages via SDK Manager.  However, Android emulation via AVD is traditionally sluggish and will not always behave as expected. There are also more dedicated and responsive Android emulators for testing including Bluestacks, which I wrote a tutorial about previously (other popular Android emulators include Andy, Xamarin, and YouWave).

Testing on Physical Devices using SAMSUNG Remote Test Lab

Android DevelopmentFor more assured Android app testing than software emulation can reasonably provide, it is always favorable to test on physical devices where available. Basic Google-certified tablets with the latest Android OS can now be purchased for as little as $30-$75 at many retailers and work wonderfully for testing.  Even some of the more high-end phones and tablets can be affordable when bought used online at sites like eBay. As long as the device is Google-certified and supports Google Play, it is ripe for app testing.

Still, there is another avenue for development testing against an assortment of popular and new Android-powered products–without having to deplete your life’s savings while amassing a mountain of test devices. Cloud-based device testing is a growing way to test your app on physical Android units around the world. Popular players in this field include Keynote by Dynatrace, Sauce Labs and Remote TestKit. These and other related services are generally subscription-based but offer free trial periods.

Sometimes though, as the saying goes, the best things in life are free. One free cloud-based testing service that I’ve grown to love is the SAMSUNG Remote Test Lab. This completely free service, provided by SAMSUNG, allows you to interface with a couple dozen different phones and tablets of diverse specifications.

Getting Started

To get started, you will need to register a free account in the SAMSUNG Developer Portal. After registering and verifying your email address, you can make your way over to the Remote Test Lab landing page. The testing application has a few minimal technical requirements including JavaScript, Java Web Start and a browser from this decade. If any of the configuration is missing the page will alert you.

SAMSUNG Remote Test Lab

The SAMSUNG Remote Test Lab offers free app testing on a couple dozen Android devices.

From this page, you can browse through the various devices or narrow down the results by category using the tabs across the top.  Most of the test devices are available in multiple different OS versions,making them ideal for testing against OS changes that may affect particular features of an app. The range is substantial, from the now archaic 2.3.3 through 5.1.1 at the time of this writing. When you have arrived at an attractive device that you wish to test against, select the appropriate parameters from the drop-down lists (OS Version, Device List [Location], Reserve Time).

The free testing system works using Credits. Every day that you login to the SAMSUNG developer portal, you will receive 20 additional credits towards testing. These credits accrue so if you sign-in three different days you will accumulate 60 credits. Each credit is good for 15 minutes of physical device testing, and you have to commit to 30 minute minimum sessions (you can also cancel device reservations early to receive unused credits back). In any case you are not likely to run out of testing time too quickly, considering each day of logging in buys you another five hours of testing time.

When you are ready to launch the test device, just hit the Start button.

Running the Hardware Simulator

After starting a device simulator from the SAMSUNG Test Lab, a Java applet will launch. Depending on your browser and OS configuration, you may be prompted a couple of times to open and run the script (say Open / Yes / Run where appropriate). If you are currently not signed in you will still be able to do a 5-minute Pre-Test, which is a good idea to ensure the selected device is functional and usable on the simulator.

When the device first launches, hit OK after reviewing the terms and then choose the device’s language (a great way to test translations, but it is generally not changeable until you start a new session). Basically, SAMSUNG asks that you clean up any of your test files and data from the device before exiting so that they do not get cluttered with test content or interfere with other users. The devices are not reset after each session so it is relatively common to find remnants of past testers when connected, including their own signed-in accounts at times.

SAMSUNG Test Device

The test device after initially launching it.

From here out, you can interact with the device’s screen using your mouse to simulate touch. Some devices may support alternative touch simulators such as the use of a stylus. In my test cases, I did come across a couple devices that would not respond to mouse control due to various causes including a prior tester changing the unlock method (another reason why trying them without being signed-in first is a fine idea).

Uploading and Installing your App

The SAMSUNG simulator software uses right-click context menus to configure its setup and manage applications.

  • Right-click on the device’s screen to adjust screen properties including device orientation, and to capture screenshots and video.
  • Right-click on the device’s frame (chrome) to access test-related controls including app management and logs.

To easily upload, install and run your app to the device, do as follows:

  1. Right-click on the device’s frame (i.e., on the SAMSUNG logo in the screenshot above).
  2. From the context menu, select Manage > Application to load the Application Manager.
  3. From the Application Manager view, click New and then double-click on your desired APK to upload it.
  4. With your uploaded app selected in the Application Manager list, click Install.
  5. Once installed, make sure the test device is unlocked and that your app is selected in Application Manager, then click Start.
    1. You can alternatively browse to the application directly on the device, once installed, to launch it.

If all was successful, your app should then launch and you will be able to interact with it as if using a real device. If the device does not have working WiFi connectivity, simply right-click on the frame and select Manage > Reset WiFi. You can switch the orientation to landscape by right-clicking the screen and selecting Orientation > Landscape.

SAMSUNG Test Device Scribblify

The SAMSUNG device with my development app (Scribblify) installed.

Advanced Tools

The test device environment supports device logging akin to LogCat in Eclipse / ADB. To view the logs, you can right-click the device frame and select Test > Logs. All of the logs will then appear in a new window and can be filtered by log level and/or string. You can also clear the log or save the data to a file just as you could from Eclipse. In addition, the SAMSUNG devices support remote debugging by selecting Test > Remote Debug Bridge and then connecting to it from your local ADB shell (this is the same manner described in my BlueStacks tutorial).

When you have completed your tests, you can uninstall your app(s) from the Application Manager by selecting it and clicking Uninstall. To exit the emulator, right-click the frame and select Exit. Finally, it is a polite gesture to then cancel the reservation in the SAMSUNG Test Lab site (under “My Reservations“) so that the device can be used by other parties before the entire duration is up.

This free service is tailored to SAMSUNG devices and does not have nearly the number of available devices as some of the paid services mentioned previously. Even so, it offers a wide-enough spectrum of test devices to rather adequately test most of the problem areas of device. Another very promising and free cloud testing service on the horizon is Google’s Cloud Test Lab, which promises to offer virtual access to many devices as well as advanced automated tests. This service is not yet available publicly but is certainly worth keeping tabs on.

Project Postmortem: Panasonic VIERA Connect (2)

This is the second of a four-part story documenting my somewhat excruciating and wholly uncharted experience developing an indie game for Panasonic’s obscure VIERA Connect television app market.

In the first part of this postmortem, I detailed the pains of becoming a VIERA Connect third party developer and struggles of setting up the rigid development environment required by Panasonic. Now I turn my attention to the actual development process using the company’s available API.

…Time to Make My Game

Apple Muncher Title Screen

Apple Muncher Title Screen

The idea for my game was simple—I wanted to recreate the classic snake game for compatible Panasonic televisions and Blu-ray players. My first encounter with this type of game was in the early 1990s via Microsoft QBasic, which included a sample application known as Nibbles.

The plot is as simple as it gets: collect items placed randomly on the screen and avoid crashing into barriers or your ever-growing self. The ‘snake’ genre was heavily popularized by early flip-style cellphones, many of which included such a game preinstalled to the thrill of bored people everywhere.

To add to the game’s addictive qualities and replay value, I decided to implement a few core features:

  • 25 unique and increasingly difficult levels
  • Five graphical themes to change the overall look and feel
  • An online score system to increase competitiveness
  • Several collectibles including different colored apples and extra lives

The player would start as a tiny snake and would grow so many units with each collected fruit, depending on the flavor of apple eaten. As the user progressed through each level, the base speed of the snake would also steadily increase. After some consideration, I decided to call my game Apple Muncher. [An early working title was Nibblify—derived from Nibbles and my first iOS app Scribblify.]

Hello Ajax-CE

Hello World - Ajax CEDuring the time that I was actively enrolled in Panasonic’s developer network, the only API available to non-partner developers was what Panasonic dubbed Ajax-CE. As detailed in the first part of this series, I was unable to view any part of the API before ponying up nearly $130. At some point after my development stint, Panasonic enabled free registration for users to review the API documentation before committing to the platform. Alas, with the promise of JavaScript-driven development, integrated 3D functionality and rich GUI libraries, I blindly approached the platform with a lot of hope.

Within minutes after skimming over the API documentation, my aspirations for the platform as a third party dwindled. It was immediately apparent that the partner apps on the VIERA market, including the stunning Asphalt 5 racing game from GameLoft, were not developed using the toolkit I was supplied with.

The JavaScript-based API was, in fact, a highly restrictive subset of commands tied to proprietary Panasonic object methods. It was impossible to output any HTML elements or CSS styles. The underlying concept of the API revolved around “Stages,” with each stage representing a particular screen or interface. A stage is represented as a JavaScript object with a handful of methods (i.e., an event handler for detecting user input, in/out transitional methods) and some properties (i.e., an array for housing media assets, a background image declaration).

The code required to display Hello World on the screen using Panasonic’s Ajax-CE, simulated in the screenshot above, is as follows:

For Apple Muncher, I would require three stages (equivalent to three screens in a typical app):

  • Title Stage: The initial stage where the user can set options or start a game.
  • Game Stage: The heart of the app where the user actually plays the game.
  • Score Stage: The list of high scores with some basic filtering options.

Interface Design

As a traditional Web programmer, I was accustomed to loading in media assets and manipulating interface components using the standard HTML/HTML5 Document Object Model (DOM), CSS styles and JavaScript properties. Since Panasonic’s Ajax CE does not support HTML documents or CSS, you cannot simply load up an image or generate text in the usual way. Instead Panasonic provides a custom means of creating a few basic media types:

  • gbox: A class for creating basic rectangle shapes
  • gtext: A class for creating basic single-line text labels
  • gtextbox: A class for creating multi-line text boxes
  • gimage: A class for displaying image-based media

These components are instantiated in the usual way of creating a new JavaScript objects. Each type supports a number of properties to control position and appearance. For example, when the snake eats an apple in my game and it needs a new body segment, I perform the following function to load in and position a new body segment image:

Apple Muncher Gameplay Screenshot

Apple Muncher Gameplay Screenshot

In the snippet above, I push a new gimage object into the playerBody array (defined earlier) to extend the player’s body length. Depending on what type of apple has been eaten, this function may be repeated several times to add numerous new segments. The properties used for the gimage instantiation behave as follows:

  • translate [X, Y, Z]: Positions the new body segment at the player’s previous x/y coord. This puts it where the head of the player was in the last frame, so new body segments descend from the head.
  • rotation [ANGLE, X, Y, Z]: Rotates the image the specified angle in degrees. You specify which axis to rotate around by designating ‘1’ in the pertinent area. I rotate the new body image so that it is the same direction as the player’s head so that it seamlessly blends with the rest of the snake.
  • src: The path of the image to use. To support basic themes in my game, each graphic is prepended with a number corresponding to the theme. I create the source path by concatenating the selected theme with the requested image. Sometimes the player may turn as they collect an apple, whereby a ‘turn’ body image is loaded, while other times a ‘straight’ image is necessary. I determine this prior to this function and store the image name in the bodyImg variable (i.e., “turn.png”).
  • width/height: The dimension of the gimage, in pixels. In this case I use the size defined in the player object so that it matches the scale of the head.
  • visible_p: Sets the gimage to be visible on the screen.
  • color [r, g, b, a]: The color to tint the image. With all values set to 255 the image will be its original color. The images I created were grayscale so applying a tint of 255, 0, 0, 255 will give it a full red tint. In the ‘plasma’ theme of the game, the color of each new body node is cycled, so I adjust the color values before adding this node and retrieve the RGB values from an array.
  • draw_type: This value of this property determines how the loaded image will scale if the width and height differ from the loaded image resolution. Inscribed will stretch the image to fit the specified width or height while preserving the aspect ratio. Circumscribed clips the image to the specified width and height while still preserving the aspect ratio. Direct will simply scale the image to the specified width and height regardless of aspect ratio. In my case the image is the same resolution as the size specified so it makes no difference.

After the gimage is created for the new body segment and pushed to the end of the playerBody array, I then push it to the components array of the main stage class. This is needed to actually render it to the screen. There are a couple other operations available in a gimage object including a ‘flip’ property to mirror the image horizontally or vertically, and an onload callback function that is triggered as soon as the image has loaded (which I use to track what images have loaded; ones that haven’t loaded after a certain time are requested a second time). You can revise these properties after the image has been created to move it on the screen, rotate it and so forth.

I use gimages for all of the graphical elements in the game, gtext/gtextbox objects for the score labels and high score charts and gbox for the preloader background. Due to the limited customization options available for text objects, I opted to create custom menu options using graphics instead. I also had to create a custom on-board keyboard for accepting user input for high score entry, given the lack of any native input field options available through the Ajax CE API.

Mind-Numbing Sound Effect Limitations

Panasonic's Ajax-CE Software-imposed Sound Limit

Panasonic’s Ajax-CE Software-imposed Sound Limit

Despite feeling that the available graphical feature-set was quite imposing and cumbersome to work with, I was still optimistic that the audio support through the API would at least be solid.  After all, this was a top-end 1080p smart television line with built-in apps that could stream 5.1 surround audio. The integrated speakers themselves  support up to 48 kHz LPCM audio.  The audio of Asphalt 5 sounded great through the machine as well. Yeah, right!

The Ajax-CE third party API in fact restricts audio formats to a jaw-dropping degree.  Specifically, the only supported audio format is 16-bit AIFF, 11.025kHz to 12kHz, mono!  I hadn’t come across such a harsh audio restriction since the earliest console days.  None-the-less, audio wasn’t a particularly big point in my game but I was still taken aback by this software-imposed restriction when the television was capable of so much more.  For Apple Muncher, I created two music loop files (Title, Game) and about six sound effects (Menu Toggle, Menu Confirm, Item Collect, Level Up, Death, Countdown).

The available audio command set is also scant.  You can do precisely three things with audio through the API: load a sound file into an indicated slot, play it (up to nine sounds simultaneously), and mute sounds globally. There is not even an option to stop a sound prematurely, nor one to loop a given file. To achieve looping music, it becomes necessary to run a timer for the precise millisecond length of the music file, then request to play the music again when the time has elapsed, infinitely. I had to implement some other inconvenient functions to appropriately switch between the two background music tracks I included, but below is a simple demonstration of essentially how I looped the main game background music.

Due to the comparatively large file size of raw AIFF files even at such a low fidelity, coupled with the fact that sounds cannot be stopped once they begin playing until they reach the end, I kept the music loops down to just two seconds for the title screen and six seconds for the game.

Level Design

Not wanting to do any more coding in the Ajax-CE platform than I absolutely had to, I decided to craft my entire level editor as a macro-powered Excel spreadsheet.  Within the spreadsheet, I would fill in cells with certain colors to depict certain elements in the map.  Red/Orange indicated walls and wall edges, green indicated the player start position.  The number inside the player start cell instructed the app what way the snake will be traveling when the level starts.  Each level had a configurable amount of total apples needed to progress, as well as a base speed for the map and how much faster the snake would go per apple eaten.

Apple Muncher Level Editor (Spreadsheet)

Apple Muncher Level Editor (Spreadsheet)

To generate the level data, I wrote a VBScript macro that parses all of the cells.  The script analyzes the walls and wall edges to determine what type of wall texture to place in the game to save from having to calculate any of that inside the Ajax-CE script itself. Before recording the wall data, the macro locates the player start position and records those coordinates along with the other vital level data.

You notice that I store all of the parsed data into a string that starts with levelData.push (.  After analyzing data about every cell in the level and appending the results to this string, the string is closed and written to a new text file using the following code:

The end result is a text file that contains a single line ready to be pasted into the Apple Muncher source code, appending the data as a new element in the levelData array.  It isn’t something meant for public viewing or deciphering and the whole line looks like:

On the back-end in the Apple Muncher source file, I parse all of these numbers based on the level being loaded and do what is needed based on the values retrieved.

Apple Muncher Gameplay Screenshot

Apple Muncher Gameplay Screenshot (Plasma Mode)

Odds and Ends

Panasonic did not provide any means to emulate the application being developed on a PC. Testing always had to be done through the Panasonic VIERA Connect app on the television itself, the complexities of which I detailed in part one.  This led to a couple development hurdles that I’ve come to take for granted in other platforms.

Console Logging

When developing standard JavaScript applications, I make heavy use of console logging to trace variables and help debug any issues that arise.  Every modern browser supports a developer console and DOM inspector and it is as simple as calling console.log("message") to send messages to the console.  To achieve similar functionality in an app being developed via Ajax-CE for Panasonic’s market, a few additional server-side scripts were required.  To Panasonic’s credit, they supplied these files and it was pretty simple to implement as long as your server was configured with Perl.   The steps to enable console logging are essentially:

  1. Copy the supplied Perl script to your cgi-bin directory and configure the Perl path.
  2. Copy the provided JavaScript file to the main app folder and change the path to point to the Perl script.
  3. Add an include to the JavaScript file from the main source file.
  4. Create a blank log file in a temporary folder.
  5. Log to the text file using the standard console.log() syntax.

This essentially sends POST data back to the Perl script every second, and the Perl script then writes the data to the log file.

Screenshots

Part of the app submission process required the production of five screenshots.  This was easier said than done as Panasonic did not provide any documented way to capture the screen as an image.  Since the app must run through the VIERA Connect market embedded into the TV, it was not even possible to run the signal through a capture card.  It would have been fantastic if Panasonic could have incorporated a simple function to save the screenshot to the server or memory card.  As it was, I ended up taking photographs of my TV screen and then cleaning them up to produce most of the needed screenshots.

Memory Card Access / Data Storage

Speaking of memory cards, one key bit of information absent from the API documentation is how to read or write data to the device for storing user preferences.  I had assumed before purchasing the Panasonic developer license that I would be able to store and retrieve data from the internal or SD memory card just like the GameLoft games had done.  Not so. As it is, the Ajax-CE platform for third parties does not publicly disclose how to write data to the system in any way, shape or form.  You can make simple HTTP requests from the app to send data to the server and back, as I do for the high score records, but saving user data locally is more shrouded in secrecy.

Apple Muncher High Score Page

Apple Muncher High Score Page

I inquired to Pansonic about this specific point. In my app, I simply wanted to save the last entered high score name when the user exited the app as a convenience to them. I was advised that I could indeed save credential data and other basic information to the internal flash memory, but that the part of the system is sensitive so the solution is not published to their portal.  They did supply me with the needed script and API functions for doing so, but I feel like this is a crucial part of any app and should not be invisible to third party developers and it would have been nice to interface with the SD card as well, if one was installed.

In the next installment I will detail the long and drawn out submission and approval process.

Project Postmortem: Panasonic VIERA Connect (1)

This is the first of a four-part story documenting my somewhat excruciating and wholly uncharted experience developing an indie game for Panasonic’s obscure VIERA Connect television app market.

…and So It Began

Panasonic VIERA Connect Development

Apple Muncher for VIERA Connect

In 2011, I purchased my first SmartTV—a Panasonic TC-P42ST30 Plasma 1080p HDTV. This was the period of time when smart televisions were just starting to take off, with most manufacturers offering integrated WiFi support and a handful of apps from top media companies including Netflix and Amazon. Each brand was doing all that it could to stand out in the crowd of high-definition televisions. Some HDTVs, for instance, came bundled with remote controllers that included slide-out keyboards for easy online interaction. Panasonic observed the app phenomena that was taking the mobile world by storm and evidently wanted a piece of that pie.

On July 7, 2011, Panasonic announced the opening of its Developer Portal through the VIERA Connect (a.k.a. IPTV) platform: “The new portal allows developers to take advantage of quick response and rich multimedia HD expression capabilities of its VIERA Connect platform.” At the end of the year, I noted that their app market still contained less than two dozen apps, virtually all of which were developed by their AAA partners including GameLoft, Netflix, Hulu and Amazon. Having previously dived into the world of mobile app development, I was intrigued by this seemingly groundbreaking new platform, which to my knowledge was the first open app market in the realm of high definition television.

API Documentation? That’ll Be $129!

At the time I took interest, no information existed about Panasonic’s development platform or API aside from a single page on their own website. They described the development platform in glowing light, listing such features as:

  • Rich GUI and animation libraries
  • Built-in 3D functionality
  • Ready-to-use movie player, photo gallery
  • Applications are written in JavaScript only
  • Cloud-based IPTV service where applications exists in the cloud

Sounds great! As a JavaScript platform it should be a breeze to develop for,” I thought to myself.  With a strong background in JavaScript and Web programming, I assumed the platform was strictly Web-based using native HTML5/JavaScript and a few proprietary commands to simplify interfacing with Panasonic-specific components.  In that sense, it would have been much like the modern Opera TV Store that allows native HTML5 apps to play on compatible televisions [the Opera store did not exist for TVs at the time].

Panasonic VIERA Connect Development

The VIERA Connect technology overview, as advertised on its Developer Network.

The first of many frustrations was that in order to even view the API documentation, I had to become a paid member. This contrasted with the other app markets, including those operated by Apple and Google, which provide free access to API documentation and only require paid licenses to publish applications to the respective stores. I was unable to locate even a shed of evidence online about any restrictions pertaining to Panasonic’s developer API for independent developers. All I was able to base my initial assessment on were the apps already available on the market. GameLoft in particular had ported several of its popular 3D games to the VIERA Connect market, including a fun racing game known as Asphalt 5. This game featured beautiful and fluid 3D graphics, stored its data on an external SD card, showcased great sound and music and really got me excited about the platform seeing what the television hardware was capable of.

So, how much did the annual membership cost for this as-of-then unexplored app platform with a mere 18 apps in the store? Panasonic was asking $129 for standard membership and $599 for premium! The only difference between standard and premium was that “premium Account holders can get additional email support during development and testing and fast track reply and QA process.” Yikes! The standard membership cost $30 more than Apple’s own iOS development license, for a market that at best would still only support users who possessed a very particular subset of the latest Panasonic televisions (and, down the road, specific Blu-ray players).

Still, curiosity consumed me and I bit the bullet and bought the license.

Panasonic VIERA Connect Development

The original congratulatory email from Panasonic after forking over $129 for membership.

Setting Up the Development Environment

I will get to the API nomenclature in the next part of this postmortem, but first I want to summarize the excruciating process of establishing the proper development workflow. In my years of experience with other targeted platforms including iOS, Android and even Xbox, testing an in-development application was never too difficult of an endeavor.  I cannot say the same for VIERA Connect.

First, I was instructed to download Panasonic’s VIERA Connect developer tool from their TV app market. At the time I joined the developer program, it appeared that their infrastructure was volatile and mostly untested, presumably because I was one of the few who ever bothered to buy an independent developer license. The Panasonic application prompted you to sign-in upon launch, and then attempted to fetch the test app files from a local server to display on the television.

Now, developing for VIERA requires a local Apache server and an extremely specific network configuration. The developer app provided by Panasonic only checks one of two possible locations for the app test files: http://192.168.0.100/sdkapp/main.js or http://localserver.vieraconnect.com/sdkapp/main.js.  There is no way to customize this URL in the developer app. So, within my network infrastructure the only options were to:

  1. Manually reassign my network IP and subnet allocations so that my Apache server is accessible directly at 192.168.0.100
  2. Redirect outgoing traffic from localserver.vieraconnect.com to my alternate local Apache webserver IP at the router level
Panasonic VIERA Connect Development

The VIERA Connect server setup overview, as provided by Panasonic.

If memory serves me correctly, I ended up reconfiguring my entire internal network so that the PC with Apache running had an IP of 192.168.0.100.  I then had to ensure that the app files on the Apache server were explicitly within the ‘sdkapp‘ directory on the root of the server, or that an alias existed to point to another location from that specific URL. Even with all the network and server configurations in place, I had not much luck testing applications through VIERA early on in the process.

Days after becoming a paid member, I was still receiving an “Authorization failed. (code : 200)” notice three out of four times I tried signing into their app on the TV. Even when successful, every change I made to my app’s source code required a full termination, restart and sign-in of the developer tool. This added greatly to the development time. Ideally, a command should have existed to force-refresh the app cache on the TV without having to exit the app entirely every single time. I reported the sign-in issue and within a couple weeks it was resolved. In the properly configured environment, the recursive flow of development was as follows:

  1. Edit the source code on the Apache server and save.
  2. Launch the Panasonic Developer Tool on the television.
  3. Sign-in on the Developer Tool application.
  4. Wait for the application files to download onto the television.
  5. Exit the Developer Tool application.

As it turns out, this local development flow closely matches the final application flow after it has been published to the VIERA market. Each third party developer is required to host the final app on their own server space and domain. Therefore, the self-described “Cloud-based IPTV service” for serving up apps through the Panasonic TV rests in the full responsibility of the third party developer and whatever server they are using. While this makes logical sense for media streaming applications, I originally held the assumption that simple standalone apps by third parties would be hosted in the confines of Panasonic’s own “cloud”for quality control and to ensure availability.

Panasonic VIERA Connect Development

The VIERA Connect server communication overview.

In the next installment of this postmortem, I will detail the extreme limitations of the programming API when developing for VIERA Connect as a third party—a far cry from what I was lead to believe before signing up and the opposite of what the partner apps were provided with.

Diagram graphics created by Panasonic