We have updated the BEST iPad Solitaire game on the market.

Pretty Good Solitaire for iPad has been updated to version 1.60, which is now available on the App Store for the extraordinarily reasonable price of only $9.99 US.

Pretty Good Solitaire Touch Edition 1.60 now contains 750 games, adding 50 new games, as well as 10 new bonus games (for a total of 100 bonus games).

In addition to the new games, the entire program has been reworked to support the latest iPad models and iOS versions, including dark and light modes, and all known bugs (most introduced by iOS updates) have been resolved.

Development

This is the first update of Pretty Good Solitaire Touch Edition in almost four years. To be honest, the game does not sell nearly well enough to justify spending a lot of time updating, although it is clearly the best Solitaire game available for the iPad. It has had 700 games for all that time, which meant that it was probably the best Solitaire value available.

Historically, Apple released iOS 10 during the development process for the previous version, and it did not make sense at the time to rework the entire engine to adjust to the latest SDK, so we released the product as originally intended. However, in the years since that version, four more major versions of iOS were released, each adding (few) new features but deprecating loads of methods, so without any intervening updates, the performance of the product deteriorated slightly, including (quickly) problems with the pile popovers, some issues with orientation changes, and (most recently) some game preview images not drawing.

Among the victims of Apple’s ruthless deprecation were nicely sized launch images (forced to use less capable launch storyboards instead), previous popover behavior and its subsequent replacement (yes, double deprecation, proving the level of aggression), UIAlertView and UIActionSheet classes (both in favor of UIAlertController), the CFGregorianDate class (too convenient, I guess), bordered toolbar buttons (UIBarButtonItemStyleBordered), methods of launching and dismissing modal views, and the entire concept of orientation changes (an inherent aspect of tablet and phone usage).

The image bug was the result of a poorly redesigned image view class, for which I found a workaround, and there are also a large number of spurious log errors generated by internal Apple processes that cannot be easily fixed or suppressed (with precision) by developers. The page curl transition was apparently completely broken as of iOS 13 (and/or the iOS 14 SDK), but that was just a cutesy feature I had already decided to change anyway. The redesign of the controls, compounded with the addition of light and dark modes (to be fair, a decent iOS feature), made several of our views difficult to use under certain circumstances. All of this created a great deal more work than was originally envisioned for this update.

The product has 4 popover views, and associated control classes, which all needed to be completely reworked, as well as 2 more views that used controls affected by the recent redesign or dark/light mode setting. Alert views were used in a variety of places, as were action sheets, plus there were several other locations where code had to be reworked due to deprecation; changes due to the loss of a Gregorian calendar class (to a generic calendar that requires an extra layer or two of indirection) were particularly pervasive, as it was used in several places in the code.

Oh, yeah, lest we forget… the latest version of the iOS Simulator has a particularly egregious bug in which it will not play audio in any version prior to iOS 14.0 and instead (the worst part) introduces a timeout delay of approximately 15 seconds for every attempt to do so. I had to disable the audio when running in the Simulator on unsupported versions just to continue. With all of the new models of iPad (with different resolutions and aspect ratios) and 5 more versions of iOS to test (well, really just 4, because the Simulator no longer supports iOS 10), just finding a representative subset of devices and iOS versions was a chore.

Nevertheless, I managed to get all of this done, and compared with that work, adding the new games and updated engine code was a (relative) breeze. The only concern at all going forward is the reported deprecation of the UIWebView class, which we use for game rules and credits, but because there is no replacement for all of the iOS versions we support, and using two different view classes is untenable for this case, not to mention that there are no deprecation warnings during compilation, we chose to leave that (working) code alone. All known bugs were fixed, the interface and animations were improved, and everything seemed to be working perfectly.

My Mistake

The update has now been live for a little more than a week, and despite how solid the product felt (and still feels) to me, there were a number of bugs reported quickly. When distilled, it actually appears to be just 2 minor bugs.

The first bug appears to be a problem with random number seeding for the ‘Random’ deal button, where the same deal numbers now come up in the same order. While the exact cause has not yet been determined, the precipitating cause was almost certainly the calendar deprecation. Time seconds were used to seed the random number generator, and because that would now take extra code, I replaced the seed with the system time reference, which (in theory) changes at the same rate, resulting in less code. Apparently, somehow it must have resulted in non-working code, although the cause was not obvious from inspecting the method.

The second bug was my bigger mistake, and requires some history.

The previous version had a legitimate bug in the game results code. Results are stored in a database with a validation code (based partially on date and time) to insure integrity. When the original iOS port of the engine was written, this code was inadvertently using local time, rather than a fixed time based on UTC or something similar. The effect was that results earned in one time zone may not appear valid in another.

The solution going forward, of course, was to fix that bug by getting the UTC time instead of local (and, coincidentally, that code all had to be rewritten anyway because of the calendar deprecation). However, that change alone would invalidate all previous results, which is not desirable at all. Since all previous results would have a valid code in (some) local time, I decided to simply replace the old codes with the newer ones. Because it would be tedious, slow, and potentially inaccurate to check all time zones, I decided to only replace codes that validate in the current time zone, figuring that those few users (including myself, actually) who had invalid codes because, for instance, they played the game in both California and Michigan 😉, could just manually set the other time zone(s) temporarily (or visit the other time zone organically) and let those results correct themselves.

So the implemented logic was that any result failing a current validation check was then checked against the old method using local time, and if that validated, the code would be updated. Note also that I limited this correction behavior to results purported to be in 2020 or earlier, when I still expected the update to be released last year. (Do you see the logical flaw in my thinking here?) In theory, this should be fairly straightforward, but testing it was challenging, because once fixed, the results stayed fixed.

In the simulator, I tested a small sample of results, and everything worked flawlessly. Then, I went to a physical device where I had built up a collection of around 50 results in one game just testing this development version (prior to the validation code fix) and it worked perfectly and transparently. I had legitimate results, then after the UTC fix, they all appeared invalid, then after adding the correction code, they were just back to normal.

Then we released the update. I had a bit of trepidation, because I had my 5000 games of Lower 48 that had loads of invalid results peppered throughout. (That was my “go to” game for waiting… doctor visits, airports and airplanes, a brief unhappy stay in hospital, etc.) I should point out that because I do the development work as SophSoft, Incorporated, but deliver the source code to Goodsol Development, who actually publish the game, the products are considered different (with incompatible signatures), so I cannot test my live data from App Store downloads on development versions.

I downloaded my update from the App Store even before the publisher told me it had been submitted and anxiously brought up Lower 48, which showed 5000 games played but only four thousand and some won (when I have, in fact, won every single deal). I opened up the game action popover with the results list and… Well, it worked, eventually bringing my results to the correct 100% win rate, but not perfectly, for I had not really considered the effect of that many writes to the database; it took a period of several seconds, several unresponsive seconds, before the fixes were done.

This seemed minor, at first. However, we have some devoted fans, and the first report of problems came from somebody who has played a favorite game more than 110,000 times! My several seconds, when I knew what was happening, multiplied by more than a score for somebody who was just trying to play a game, looks a heck of a lot like a lockup. Fortunately, it only has to happen once (per game) and that user is now back to happily playing Russian Solitaire. I have to hope that somebody who has played one particular game that many times does not have too many games with that much activity.

For fun, I just calculated that playing every game in Pretty Good Solitaire for iPad that many times, assuming you could average one minute per game, would take more than 175 years playing around the clock. Of course, with a more realistic average of 10 minutes per game, my 5000 games of Lower 48 would be the equivalent of more than 20 weeks of full-time work!

Anyway, with a couple of simple miscalculations, I managed to make life a little more interesting for the customer support people. Sorry about that. 😔

January release: check.

Happy New Year!

Although 2020 was fairly average for SophSoft, Incorporated and Digital Gamecraft™, I am not terribly satisfied with that outcome, given the huge number of internal (and external) projects we have and all of the unrealized potential. Therefore, with more than a little optimism, I have set a very aggressive development schedule for the coming year.

Development Goals

Our primary goal for 2021 is shipping our first, internally designed and developed, console title. This project is well underway, but still has a lot more to be done. We are hoping to be completed with the development within about 3 (more) months, but how long the approval and publishing process takes is beyond our control (or experience).

Depending on the success of that title, we may (or may not) adjust the rest of the schedule to take advantage of other related opportunities (in particular, adding another console platform or two to our repertoire). However, at the moment, the development schedule calls for brand new game releases in July and November, as well as the initial version of a productivity tool and the first look at another project, a reference site, as well as maintenance updates for Demolish! Pairs, during the year.

Combined with work for our current clients, we expect (amazingly) to have new products or product updates releasing every month in 2021.

For much of 2020, I have been working with a client who publishes a major utility to add a significant feature that will make an already indispensable tool (that I used and advocated prior to this gig) even more useful for programmers like myself. Although I have absolutely no control over feature integration or release scheduling, I am hopeful that the result of this work will become publicly available this year. (At some point, I will have to get permission to reveal the product name and promote it, instead of just teasing.)

Our work with Goodsol Development continues, too, and although I cannot give the planned schedule, you should expect to see many more games added to Pretty Good Solitaire Mac Edition, Pretty Good Solitaire for iPad, and Pretty Good Solitaire Mini for iPhone, probably some new layouts for Pretty Good MahJongg, and perhaps even some updates for Goodsol Solitaire 101, Most Popular Solitaire, FreeCell Plus, and Action Solitaire. Of course, these games are pretty great already, and Goodsol has not charged for updates for any of the above titles, so I recommend buying them all now. 😉

Business Goals

For the moment, the company has almost everything it needs to accomplish the above goals, although it will take a huge effort on my part. The one thing we still need is serious funding, such that we can afford more help, but for the moment we are still bootstrapping.

From the business standpoint, our basic goals are:

Stay healthy, safe, and productive.
Continue to reliably make payroll while growing income.
Connect with a great artist (or two) for our games, and maybe a marketing expert.

Note that we are not looking to take over the world until 2022 at the earliest.

Evaluation

This post lays out the goals for the year, obviously, so we can look forward, but part of the purpose of the post is also so we can look back on them at the end of the year and assess how the year has gone relative to what we hoped and expected. (More often than not, something external, like a new client, an emergency project, or an unexpected international hit game [knocking wood], causes priorities to shift.)

This is, truly, an incredibly aggressive development schedule, and if we can even get close, without disappointing ourselves or any of our clients, then that will be worth an A+.

If we can complete at least three of the (five) planned major releases this year, that will still be a great performance, but bittersweet for not getting everything done. Anything less would be disappointing, although just making it to our 40th anniversary early next year would be an accomplishment itself.

Of course, we give client projects priority over our internal projects, which is why (in the past) we have not made the desired progress with Digital Gamecraft products, but I believe (without going into detail here) that we have the organizational processes and development foundations in place to accomplish all of the above (without “crunch”).

Now, there is nothing left to do but DO.

Gamecraft

All about the craft of making games

Monthly Archives: January 2021

Pretty Good Solitaire Touch Edition 1.60