Tag Archives: software

Hire us. Hire me.

Posted on by
Reply

Straight scoop: I need to find more (paying) work, and soon. I am raring to go on new development, bringing my extensive experience and expertise to bear on another interesting project (or several). If you need software development done, I can help you, whether that is via consulting and/or contract development through my company or as an employee at yours. I am also very open to funding opportunities for the next game product we are creating internally.

SophSoft, Incorporated has developed and/or consulted on dozens of commercial games over the years, including the complete production of more than 20 SKUs, and our clients have included companies such as Microsoft, Zombie, Legend Entertainment, MVP Software, Goodsol Development, and Scooter Software, as well as numerous other small companies. We have the skills and contacts to create any small to mid-size game from scratch, to assist the development of any size project, and to provide technical research and industry knowledge to help resolve issues and remove roadblocks.

I am Gregg Seelhoff, a lifelong game developer, a uniquely experienced programmer, and the founder and principal of SophSoft and Digital Gamecraft®, its game publishing division. Games and computer programming are two of my passions. In pursuit of those passions, I have worked on scores of published titles, as well as countless unpublished projects. Here are a few notable facts to illustrate the breadth and depth of my expertise:

  • I have worked on blockbuster titles, smaller retail products, shareware and self-published games, as well as multimedia software, tools, and hardware drivers.
  • I have led small development teams, programming groups within larger companies, and solo projects from conception to release.
  • I have worked on cutting-edge AR products within a hardware manufacturer and written VR drivers for first generation hardware.
  • I have personally developed custom AI engines for playing traditional games at world-class strength.
  • I led programming on a major Star Trek title, a cancelled Dungeons and Dragons project, and drivers for a Star Wars product.
  • I founded, and still run, the oldest indie game development company in the world.
  • I have worked on adventure games, RPGs, board and card games, FPSes, and arcade games, as well as in other genres.
  • I won an international programming competition while still in high school and have continued to steadily improve my abilities since that time.
  • I contributed to a Game of the Year winner, and had a solo project featured in books and magazines.
  • I have developed more solitaire games than anybody else on the planet.
  • I was twice elected as Chairman of the Board for an international industry marketing organization.
  • I won a Shareware Industry Award for a game that I developed as the sole programmer and primary designer.

In addition to my programming expertise, ability to quickly learn and adapt, and general resilience, my industry experience provides the skills to build cohesive teams, mentor developers, and improve standards and processes, as well as to provide useful feedback beyond my core competencies. Imagine how I can improve your team.

GreggSeelhoff_resume_abridgedDownload

For (perhaps too many) details, you can get my full unabridged resume/CV here:
https://sophsoft.com/samples/GKSresume.pdf

Whether you have a game project you want my company to develop (or port), want to give some additional direction to an existing team, or simply need to get some programming done, please contact me to see how we can reach your goals together.

“So don’t delay! Act now! Supplies are running out!” 😉

Unity and the Art of Self-Evisceration

Posted on by
Reply

Let’s Talk “Integrity”

Last month, Unity Technologies announced that they were changing the licensing terms for their Unity game engine, which they claim is used in the development of more than half of the top games for mobile, PC, and consoles. They boast that they have 1.5 million creators and two billion monthly end users. Well, maybe they had that many.

The Problems

Under the new terms, Unity were going to charge publishers up to $0.20 per installation of their games; note that this is not per sale, but per installation, which means that creators pay regardless of whether or not their game is bought or even played. The term “install bomb” came into broad usage immediately as shorthand for a method where nefarious actors could damage a developer financially by repeatedly or widely (via bots or networks) installing a trial version (and, not coincidentally, profit Unity).

This first problem was that it potentially turns game marketing on its head, where the free-to-play model (currently the only way to make money on mobile) is damaged, free trial versions are now costly, giving away software for charitable purposes is no longer viable, and the economics of other marketing models, such as bundles or console subscriptions, are disturbed. Ironically, this was introduced under (now former) CEO John Riccitiello, who infamously called game developers “some of the biggest f***ing idiots” for not focusing on monetization early, and then his company screws any early monetization plans.

The second problem is that professional developers (i.e., those making money or disinclined to advertise for Unity) are already paying at least $170 per month per seat (according to the website; it had been somewhat less when I considered licensing Unity a few years ago), with the calculation being that this was the cost of development to avoid backend expenses. Now, the backend costs are added and even if they replaced the monthly cost (which they have not), those companies have already paid that licensing fee; it is a sunk cost, so they are paying twice.

The third problem, related to the above, is that the installation charges are retroactive; even though they are started accruing in January, 2024, they applied to games that have already been completed and published. Companies could have moved on, no longer be using Unity at all, just selling a game they built in the past, and suddenly be on the hook to pay a company that they no longer have a business relationship with, or in the case of acquisitions, perhaps a company that they never had any kind of agreement with.

The biggest problem, however, is that Unity promised game developers that the game engine would remain royalty-free, built the Unity ecosystem based on that promise, and then reneged in a very big way. To be clear, this was not merely implicit: John Riccitiello made it very clear in his quote to GamesIndustry.biz:

If you’re a seven-figure developer, you can afford $75 a month, but if you’re not, if you’re just getting started or just choose for artistic reasons to give your games away for free, or if you’re a hobbyist screwing around or a student, this is free. You get the full power of Unity 5 for free. There’s no royalties, no f***ing around. It’s simple. That’s really what we’re announcing.

Well, they are definitely introducing a form of royalties (but worse) and are definitely “f***ing around”. To be clear, the costs would only apply after a game makes $100K, but the simple fact is that no professional game developer targets making less than that. Students benefit Unity greatly (and probably still don’t plan to make no money), and amateurs who are just making games as a hobby would simply move to a different engine that is truly free.

The Fallout

I don’t dispute that Unity Technologies had the legal right to increase costs and impose additional charges, especially after surreptitiously changing the licensing agreement (although I think the claim that they can charge retroactively for previously built games is tenuous, at best). I think that the manner in which they went about it was critically flawed. I am certainly not alone.

The backlash from the announcement was immediate, strong, and (appropriately) unified. Developers of indie games, who were arguably the most affected, were quick to condemn the pricing change, and many threatened to leave Unity, some stated they had already decided to move their games to a different engine, and the developer of one popular game even posted that they would remove it from sale when the policy took affect (although they later recanted, saying that it was a joke, but I remain unconvinced). Terraria developers Re-Logic donated $100,000 to Godot and FNA, two open-source engines, alternatives to Unity. Meanwhile, nobody outside Unity leadership tried to justify the new fees.

Unity tried, likely in vain, to quell the potential revolt against their game engine and, definitely in vain, to repair their damaged reputation by backing down on some of the changes. The revenue cap for not getting charged is being doubled to $200K, games which make less than $1M in “trailing 12-month revenue” will be excluded, and the fee will only apply starting with the next version of Unity, which will not ship until 2024 (at the earliest). They also gave an alternative option of a straight 2.5% revenue share (pure royalties) based on self-reported data. (To be honest, I find the concept of explicitly reporting revenue data to a tool manufacturer to be perverse.)

John Riccitiello was also “retired”, which step, to be frank, was way overdue. That should have been done well before this little debacle took place, but once it did happen, he should have received his marching orders within days or hours, not a month later. To be fair, it is not clear that he was behind this mess; it may have been forced by the soulless profiteers on the board of directors. As CEO, though, his ouster was an absolute minimum.

My Relationship with Unity

I personally have no skin in the game, nor does SophSoft, except insofaras Unity decided to eviscerate themselves before the SophPlay System™ was ready for external developers; we really could have had a boost from 1.5 million creators looking for a new home.

The company does not use Unity for its own projects, only for client work (and even then, not for a while now), and I do not particularly care for it. I know Unity fairly intimately, now, because the team I lead at DAQRI, the Advanced Concepts Group, was responsible for the development and maintenance of the Vos Extension for Unity, essentially the Unity SDK for the Smart Helmet and Smart Glasses. More particularly, I personally ported most of that SDK (with the assistance of a very talented colleague for the 3D mathematics) to run on hardware using an entirely different operating system, so any existing project would work with a simple setting change and rebuild.

Despite this knowledge of Unity, I find that I much prefer the “old school” approach of writing code and, importantly, being able to identify and enumerate all of the processes. I certainly appreciate the democratization of game development that a more visual engine provides, especially as I have watched designers and artists produce some wonderful prototypes without requiring a programmer, but I find that it doesn’t work as well for me.

About Integrity

Integrity is, literally, central to our company motto: “Quality. Integrity. Fun.“

When we decided on this motto, we actively discussed the meanings and intent of each word, and in particular, the dual meanings of “integrity” and how we intended both. The first definition that usually comes to mind involves adherence to principles and values, honesty, ethics, and forthrightness. We want the company to be the business equivalent of a “person of character.”

The second definition, that is less common, is related to being complete and solid. We intended this meaning to apply to the company’s self-reliance, specifically in its production approach, being able to perform any (and all) aspects of game development, from concept and design, to programming, artwork, audio, and writing, through quality assurance, packaging, and publishing. (To be honest, marketing was the only development skill we have never really mastered.)

Our interpretation of this second definition was why we never tied ourselves to an external game engine (Unity, in this case, but there were several earlier options as well). To maintain corporate integrity, we would never commit to an arrangement where an external entity, particularly a money-grubbing conglomerate, could directly harm our interests. Developing in Unity binds a company to external actions and decisions, since there is no quick alternative should things go wrong (which we always articulated as “disappears tomorrow”); this is why the Unity policy change was so impactful to many developers. There is no way to quickly move a game developed in Unity to an alternative, so you can become a victim. On the other hand, if any major tool we use, say Visual Studio or Photoshop, were to disappear tomorrow, it would be an inconvenience but the code and artwork would still be usable; we would only lose the time it takes to switch tools.

Of course, Unity also badly violated the first definition of integrity. Making a promise of a royalty-free engine and then, deliberately, making unannounced changes in the licensing agreement to allow royalties and installation fees, and then enacting (or trying to enact) such additional costs is a high stakes “bait and switch”. The fact that it can be argued as legal does not make it ethical, and it definitely is not. The fact that this whole story arc unfolded under one CEO makes it that much worse, since the hypocrisy and unfair treatment cannot be explained by a signaled change of direction. Had Unity been acquired by another company with vastly different goals, one should prepare for such a turn of events, but for the most part, most people don’t consider an IPO a form of corporate takeover, though they probably should.

I contend that no company was ever purchased (including via IPO) to benefit the customers. Game developers are the customer here, and Unity’s actions signal their obvious intention to take as much profit from them as they can get away with. In this case, I think that they reached too far into their pockets and got caught, red-handed.

Conclusion

If Unity truly just wanted to get funding to improve the game engine, it could have signaled that policy change, consulted with its customers, rolled out a workable new policy and license agreement starting with the next version (not forcing anybody to upgrade), and then made tangible improvements to the new version. Game developers could make the choice between shiny new version with bells and whistles (and royalties) or the status quo (with the inevitable slow technical decay). I would even have planned to cut the older version loose, totally free or (better yet) open source, at some point a couple years down the road. They did none of that.

Instead, they blindsided customers with new, unworkable, and retroactive fees, against explicit promises, as an obvious consequence of attempted profit-taking for investors, not any concerns for their customers nor the end users that they claim (but do not service). I have no doubt that some hobbyists will keep using Unity because it is “free”, but those who harbor hopes of eventual success, or care about integrity, will likely look to other engines. Students will still learn Unity and other engines, but professors who currently focus primarily on Unity should be reducing this emphasis (and increasing emphasis on Unreal).

Professional game developers, however, will turn from Unity in droves. Some have already begun porting their projects in development to alternative engines. Some will hold their noses and continue with Unity for current projects, due to the cost of switching engines, but then use another engine when starting future projects. A few will determine that their processes are too dependent (unfortunately) on Unity and will continue with them rather than bear the expense of porting everything to a new engine.

The fact is that Unity no longer has any significant advantage over Unreal Engine, which has a reputation for better technology and a more stable platform, while Unity is known as the engine of low quality games and, now, a major lack of trustworthiness. As many professionals switch to Unreal, and Godot and others improve through additional support and users, the Unity community which has been building for years will deteriorate. Unity Technologies will be repaid for their greed by a substantial loss of value in their core asset.

Although it is not always (read: rarely) the easy path, is sometimes nice to see that our decision to commit to integrity can prove the correct choice. 😉

Demolish! Pairs 1.1 for Android

Posted on by
1

An update of this fun puzzle/arcade game is available for Android users.

Demolish! icon

Last week, Digital Gamecraft® released a game update, Demolish! Pairs 1.1 for Android, which refreshes the product to support the latest technology, including Android 12, and brings Demolish! Pairs 1.1 for Android current with Google Play requirements.

This update parallels the release (last November) of Demolish! Pairs 1.3 for iOS, which likewise did not add any new gameplay features and required no bug fixes, but makes sure the software supports all the latest mobile phones and tablets.

Development

As noted, there had been zero bug reports for the product (on either platform), but Google Play has been steadily advancing the SDK requirements for products in the app store, so this update was a proactive step to prevent the game from being dropped from the store.

Clearly, this update was not an exercise in direct ROI (return on investment), as the Android version has had, literally, ones of sales. 🙁 Instead, this was an exercise (in frustration) intended to keep our tools and skills up-to-date, despite never having had a client request Android work, for reasons that seem fairly obvious (i.e., nobody pays for Android software).

Because the product had not been updated since its release in September 2018, it had last been built entirely with Android Studio 3.1, and while we had been updating Android Studio quasi-regularly, we had not been making the associated script changes (unnecessary on any other platform) to keep all the tools in sync. This fact alone makes Android development the least appealing of any platform; it takes so much non-programming effort to maintain.

We upgraded to the (then) latest Android Studio which, to my chagrin, has been named, “Android Studio Arctic Fox | 2020.3.1 Patch 4” (because “Android Studio 4.3” was too cryptic and, you know, left out the confidence-building “2020” from a 2022 download 😉 ). Then the real fun commenced, because (of course) the Gradle version was out of date, not to mention the fact that there are two different Gradle versions, and various helpers offered to upgrade these once, and then again, and yet again, to newer versions each time. Of course (because it could never actually just work, you know, like Visual Studio or Xcode), this upgrade chain ended before actually getting the correct versions installed, though it did install three (or is it six?) separate obsolete versions of Gradle, thus leaving me with loads of (all) incorrect options and the necessity to spend a significant amount of time searching the web for a solution. This should not be necessary for development (hello, Gradle) nor using an OS (that’s you, Linux).

Ultimately, I did find the solution and get the Demolish! Pairs code to build correctly, and no actual code (i.e., Java) changes were necessary. However, I did choose to migrate (per recommendation) to AndroidX, for which the conversion tool was essentially flawless. I also am a strong advocate of strict code linting, so I made a few code changes due to new lint messages, although only one that could have made any difference in program operation (and only then if it ran on a theoretical Android device that reports neither ‘portrait’ nor ‘landscape’ orientation, which should not exist in reality).

I should note that, despite its absurd naming, Android Studio is fairly nice to use (once Gradle has been subdued). The static code analysis (i.e., linting) system for Android/Java projects is comprehensive, albeit often self-contradictory, but once one determines which items are pointless and disables them, it is useful. Also, Google provides excellent online documentation of its SDK, the way Microsoft did. On the negative side, I shutter to think how many millions (or billions) of dollars worth of development time are wasted on Gradle configuration, and I weep that some managers think code metrics are a good way to judge source code.

The final hurdle for me was at bundling time. Now, to submit a product, one must supply an App Bundle instead of a prebuilt APK, but that was not the problem. The problem was that to build a final App Bundle (or APK), one must provide the certificate and type in its password. In the intervening 3+ years, which notably included my world being turned upside-down, I had forgotten and misplaced this password. The certificate had been diligently preserved, but without a password it would be rendered useless. After hours of trying different methods to retrieve the password (all failing, as they should), I finally took the tried and true approach: count the asterisks and guess. It worked! 🙂

So… Act NOW and you can be the first person to buy Demolish! Pairs for Android in the current decade!

Also: second January release: check.

Pretty Good Solitaire Mini 1.10

Posted on by
Reply

The best iPhone Solitaire game on the market just got even better.

Pretty Good Solitaire Mini icon

Pretty Good Solitaire Mini (for iPhone) has been updated to version 1.10, which is now available on the App Store for the unbelievably affordable price of only $1.99 US. This is the best Solitaire software value to be found anywhere!

Pretty Good Solitaire Mini 1.10 now contains 800 games, adding 50 new games (and still has 100 bonus games).

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

Pretty Good Solitaire Mini launch screen

Development

This is the first update of Pretty Good Solitaire Mini ever, since the first version was released almost three years ago, becoming Goodsol Development‘s first (and, thus far, only) iPhone title. That version has a perfect 5.0 rating on the App Store (out of only 12 reviews 🙁 ), and as I write this, the new version is climbing up the charts (according to Apple).

Best Solitaire Game

I have played the Mac, iPad and now iPhone games and this is the best solitaire game out there.

Labtech89 (app store review)

The only real issue with this game is that it is a rip-off… for the publisher and developer. We work hard to make an excellent game, and there is almost no chance that it will ever recoup the cost and effort put into developing and maintaining it. It costs the customer less than a quarter cent per game, and still not enough people are buying it to justify maintenance.

Nevertheless, we continue to do so. Of course, after this amount of time, it is no surprise that Apple has completely rejiggered the internals of the iOS operating system, including the eliminating of the concept of screen orientation entirely, so there was plenty to update to resolve problems created by their aggressive (and unnecessary) deprecation.

You can read about most of these issues in my post from about a year ago, Pretty Good Solitaire Touch Edition 1.60, where I detailed how I first dealt with these (same) issues. For the iPhone version of the Goodsol Solitaire Engine, when compared to that iPad version of GSE, the engine (i.e., model) code is identical (as it also is on Windows and Mac); that is its whole point. The controller code is very similar, but requires a review of all changes, rather than a wholesale code replacement, but that was much less effort than it could have been.

The view code, however, is very dissimilar. On the iPad version (i.e., Touch Edition), the interface consists of key screens and several popover views. On the iPhone version (internally, Phone Edition), a smaller screen and no popover support requires that the interface is constructed in a different manner, with only two main views, supported by 3 tab bars and 10 various tab views. While the low level code to display images, fill tables, and whatnot, is nearly identical, all of the surrounding view code is incompatible, and it was much of this code that was affected by the deprecation. The best we could do was establish certain templates for the types of changes that had been necessary in PGSTE and use those to both identify places where changes were likely necessary and guide us in making the necessary alterations.

I say “we” and “us” but, of course, I am the only programmer working on either of these products, which fact, frankly, probably makes it a little easier to coordinate, though all of the programming work (and a lot of testing) falls to me.

There were a couple of minor positives to this development process. First, the bugs I accidentally introduced in PGSTE 1.60 had been fixed in PGSTE 1.61, so they never entered the code base for this update in the first place. Second, the fact that the iPhone version necessarily has no popover support means that we completely avoided the double deprecation problem that we experienced with the iPad version development.

The most amusing item was that just prior to development on this update commencing (and after its originally planned start date), hence about 2.5 years after the last release, Apkmonk Blog did a very nice review of Pretty Good Solitaire Mini. Right up front, the very first screenshot is (embarrassingly) a background missing the intended game preview. The writer actually (unknowingly) makes lemonade out of this bug: “Don’t worry about the plain look of the app when you first open it“. They go on to give a very nice review (with the odd factual mistake here or there) and rate the game 5 stars (out of 5).

Now what really happened is that the game worked perfectly when released, showing a game preview image on that first (“plain”) page, or a splash image if no game is currently selected. Then, as so often happens, Apple makes unnecessary changes to iOS and breaks things. In this case, it changed the process for initializing a view and its subviews in a way that broke the code we were using to show these preview images (and a few minor images elsewhere).

Specifically, what happened was that Apple made changes to the layer objects of general views after the viewDidLoad method was called. Our previews were not image views (deliberately), and in that method we initialized the contents of the layer object associated with the subview, resulting, as expected, in the preview images displaying properly. When a later version of iOS changed the way that (and when) Apple did this initialization, the preview images stopped displaying. In the end, we had to convert to image views and implement our other behavior on those. It looks like Apple introduced a bug into their system, and though they could argue (illegitimately) that we were not using a sanctioned method, the fact remains that they should not have been messing with view initialization in this way in the first place!

January release: check. 🙂

Pretty Good Solitaire Touch Edition 1.60

Posted on by
2

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

Pretty Good Solitaire for iPad

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.

happiness
productivity

Still Coding After All These Years

Posted on by
2

Today is my 40th anniversary of programming a computer.

December 22, 1978: This day marked the first time I walked into a computer store, the first time I played a game on a home computer (or even touched one), and the very first time I wrote a computer program.

Exidy Sourcerer

Of course, that very first program was pretty BASIC. 😉  I learned the concept of programming, line numbers, how to RUN and LIST a program, and (at least) my first two commands, PRINT and GOTO, on that same day.

The very next day, I learned (more) about variables, FOR loops, and number theory (mathematics, not programming), as I helped an MSU student debug his program, and then further experiment with it.  We noticed that abundant numbers are often bounded on each side by primes, but this is not universal.

I urge you to read more about My First Programming Experience.

Computers were awesome!

A few years later, as I was on an airline flight, I took out my pen and paper and started writing a wishlist for the “perfect computer” for me, dreaming about what could be possible in the future.  I envisioned lots of colors, crazy amounts of memory (like 64K!), and larger custom character sets, which idea gave way to (really out there) thoughts of individually addressable pixels at very high resolution (say, 640×400).  At a conference, I saw a display with a “true color” screen image of an apple (fruit) at 1024×1024 and that blew my mind.

In the intervening years, I have had loads of milestones and accomplishments:

  • January 13, 1982: founded Sophisticated Software Systems
  • Summer 1982: had first professional programming job
  • Late summer 1982: purchased very first computer, a Commodore VIC-20
  • 1984: won the ComCon ’84 International Programming Competition
  • 1984: started first full-time programming job with Michigan State University
  • 1988: landed game programming job with Quest Software
  • 1989: published first retail game product, Legacy of the Ancients
  • April 22, 1990: self-published shareware game, Pacmania 1.10
  • February 1, 1993: started as Senior Software Engineer at Spectrum Holobyte
  • 1994: went full-time as an independent game developer
  • 1995: incorporated business as SophSoft, Incorporated
  • 1996: launched Digital Gamecraft for developing independent games
  • 2002: Goodsol Development released Pretty Good MahJongg
  • 2004: served as Chairman for the Association of Software Professionals
  • 2007: created first Mac game, Pretty Good Solitaire Mac Edition
  • March 27, 2013: A Little Solitaire became the #1 card game for iPad
  • 2013: published first Digital Gamecraft title for iOS, Demolish! Pairs
  • 2016: established and ran Advanced Concepts Group at DAQRI
  • 2018: published an Android version of Demolish! Pairs

These are just a few of the major highlights, but none of these events made as much of a difference in my life as that day I walked into New Dimensions in Computing.  Of course, there are a few personal milestones that really affected things as well, but most of these also happened within this time frame (more than 76% of my lifetime).

Today, I am back doing what I love: programming.  Even when things are tough, I truly enjoy the development process and can get ‘in the zone’.  When people would ask me what my favorite game was, I would often reply something like, “C++”. 🙂

Amazingly, I now have a stable of portable devices, each of which far exceeds my ultimate imagination for my perfect computer, and many of them blow away the visual capabilities of that screen that mesmerized me back in the early 1980s (and I never even considered the possibility of 3D rendering capabilities).  My phone fits in my pocket yet is more powerful than my first PC, and my watch is more powerful than that first computer.

Computers are awesome!


Demolish! Pairs for Android and iOS

Posted on by
Reply

Awesome puzzle game now available for almost any mobile device.

On Tuesday, Digital Gamecraft released both Demolish! Pairs 1.0 for Android and Demolish! Pairs 1.2 for iOS.  This pair of releases represents a recommitment to this product that is enjoyed by game players on a daily basis. Demolish! Pairs 1.0 for Android is the first release on the Android platform, after numerous requests, and it runs on 99.7% of Android tablets and phones. Demolish! Pairs 1.2 for iOS is a long-awaited update release that adds support for the latest iOS devices, including the iPhone X, and resolves compatibility issues with iOS 11. The goal of Demolish! Pairs is to remove pairs of adjacent, matching blocks until the entire board is cleared.  Each time a pair of blocks is removed, the blocks above (if any) drop down and empty columns are filled by pushing the remaining columns together.

Release Date

The release date, September 11, is significant, if somewhat coincidental.  (We decided to release the Android version on that date, and the Apple approval of the iOS version just happened to arrive later on the same day.) Demolish! Pairs began life as a secondary project in the early years of Digital Gamecraft.  After many years of discussing the idea, we started actual game design in August 1999, and we completed the first playable (Windows) prototype shortly thereafter.  A couple of years later, we made the decision to proceed with Demolish! (as it was known at the time) as a primary development project, and we were making good progress for a few weeks. The original design theme was an actual building that was being demolished brick by brick, and the gameplay was fun.  However, the events that occurred on that date 17 years ago suddenly made the idea of tearing down a building very disturbing, and it became clear immediately that the game could not continue along the same path.  We initially renamed the project to Diminish, making the destruction as abstract as possible, before finally shelving the whole thing for almost a decade. In early 2011, we picked up the project again, deciding to continue with the abstract design and target mobile devices, but to return to the original name.  We had a number of different play mechanics that we were implementing, but determined that the one with selecting only pairs of blocks was both unique and the most obviously skillful, so we focused on that particular mechanic.  Demolish! Pairs was born. The dramatic history of this game does not end there, but this post does. 😉

AWESOME Solitaire AR

Posted on by
Reply

Digital Gamecraft™ is delighted to announce its latest development project, AWESOME Solitaire AR Edition™, shipping in July.

You have known us as the development force behind the award-winning, best-selling, and most numerous Solitaire games, Pretty Good Solitaire, Goodsol Solitaire 101, Most Popular Solitaire, FreeCell Plus, and A Little Solitaire for iPad (to name a few).

Today, we announce the upcoming availability of AWESOME Solitaire AR Edition™, the world’s first augmented reality Solitaire product shipped with its own AR hardware.

Imagine being able to take all your favorite solitaire games with you wherever you go.  Play FreeCell on the wall of a building.  Find your Spider moves spread out over a city block.  Meet people on the street and explain to them that, “The game is called ‘Klondike‘ and, yes, there are many different types of solitaire.”  See the cards right out in front of you, almost as if they could be real, physical objects.

Best of all, AWESOME Solitaire AR Edition will come with premium augmented reality hardware from our friends at DAQRI, which hardware you can also use for, you know, other stuff (when not playing solitaire, of course).

Unique Features

  • includes hundreds of types of solitaire, complete with rules on how to play
  • ability to select virtually any size playing cards and tableaux up to 1 mile wide
  • play multiplayer mode and fight strangers for the cards you need to win
  • choose between two hardware configurations based on quality of neighborhood
  • ships with special “decks” of 52 cards each for low power desktop operation

Prices

Professional system, includes AWESOME Solitaire AR Edition software, DAQRI Smart Glasses, and two decks of standard playing cards – $7495

Even more professional system, includes AWESOME Solitaire AR Edition, DAQRI Smart Helmet, and 4 decks of Poker size playing cards – $call for price

Solitaire gang discount on fleet purchases – call for details

Preorder now!  Due to anticipated overwhelming demand, orders will be shipped on a first-come, first-served basis, so reserve your place in line today.

 

Pretty Good Solitaire ME 3.30

Posted on by
Reply

The latest upgrade to our flagship macOS product is available.

Pretty Good Solitaire Mac Edition 3.3Pretty Good Solitaire Mac Edition 3.30, available from Goodsol Development, is the best Solitaire game for Mac computers.  This version of the game can be purchased and immediately downloaded for only $24.95, and it is a free upgrade for customers.

This Pretty Good Solitaire Mac Edition update adds another 100 games, for a total of 700 games, plus another 90 bonus games not accessible in the trial version (for those who want to try it first).

In addition to the new games, this version 3.30 update addresses several minor requests from customers, fixes all known bugs, and fully supports Apple macOS Sierra.

Fifteen Years with Goodsol

Posted on by
Reply

We have been working with Goodsol Development for 15 years now!

Goodsol DevelopmentOn this date back in 2001, SophSoft, Incorporated made our first software delivery to Goodsol Development.  Since that time, we have never stopped working together, producing the best solitaire software ever created.

I posted about this collaboration 5 years ago in my post, 10 Years of the GDcard Library.  We have continued our progress since then, adding an entire line of iOS products and 400 more games to Pretty Good Solitaire Mac Edition, along with much more.

For fun, I thought that I would take a look at some of the numbers:

To save everybody a little bit of math, this means that, on average, we have delivered a new product version once every 10 days, and we have added a new game of Solitaire every two days, for the entire 15 years.  Amazingly, the number of delivered versions for Pretty Good MahJongg and for Pretty Good Solitaire Mac Edition are currently exactly the same: 88 of each.  [Spoiler: PGMJ will take the lead with a macOS Sierra bug fix.]

In lieu of anniversary gifts 🙂 , just tell your friends about our excellent products!