MAS Preparation, Part 4

Posted on by
2

Source code modifications

In the previous installment of Preparing for Mac App Store Submission, I provided some guidelines for application data and resources that should be followed (where applicable) as you transform an existing Mac OS X game project into a project that can be successfully submitted to the Mac App Store (MAS).

In this fourth part, I will describe a number of modifications to the source code of your project that you may want to make to avoid unnecessary MAS rejections and, perhaps, improve your customer support and project maintenance.  These recommendations build on the theme of earlier posts, as most of these changes are due to Apple restrictions against anything having to do with downloading or external sales, including the use of registration codes.

As before, these suggestions are based solely on our experience with our products, so it could help to understand the basics of our sales system.  We have two separate downloadable builds for each Mac OS X product: one is a trial version, with limitations, and the other is a full version, which is unrestricted but requires a customer-specific registration code (as well as the hidden download location).  In order to better understand our customers, each web link in the program adds a very basic tracking code, so we know which version is being used; when online high scores are submitted, we include a hash of the registration code so the scores can be applied to the correct player account.

For this process, we have created a new store version, which is unrestricted (like the full version), includes available extra data (avoiding downloads), and cannot require a registration code.  (Instead, the Mac App Store automatically includes a “receipt” which should be checked, as discussed in the next installment.)  Here are the steps we took…

1. Store game data within user library folder

For the Mac App Store, game data that is not directly created by the user must be stored within the user library (not documents) folder.  Originally, we stored our saved games and statistics in ‘~/Documents/<project name>/<player>’, which made them easily accessible for our customers, but MAS guidelines (and an explicit rejection) required us to relocate such files to ‘~/Library/<project name>/<player>’, where they are less discoverable by users, especially since ‘~/Library’ is now hidden in Finder.  In our case, we actually relocated the files for all SKUs, including a function in the downloadable versions to automatically copy this game data to the new location, to make future customer support more manageable.

Note that, with application sandboxing (as discussed in the final installment), the actual location of the (sandboxed) user library is a significantly longer path name, and the main user documents folder is not accessible by default.  Obviously, the paths given above are illustrative only; one should never hard-code a path in project source code.

2. Remove all registration code via conditionals

Since any sort of registration code is forbidden, you should remove all registration code functionality via conditional compilation.  As part of our Project modifications earlier, we added an APPSTORE preprocessor variable to the store version target (only), which now allows us to remove sections of code with “#ifndef APPSTORE”/”#endif” sections.

In our case, every place in the code where the trial and full versions were different were already denoted with the preprocessor variable ‘DEMO’, so we only needed to look at each such section and decide if it should be like the full version (i.e., no limitations), which was the case most of the time, or like the trial version (i.e., no registration codes).

3. Add fixed internal MAS registration code

Because we used registration codes to differentiate between customers, we needed to add a fixed internal MAS registration code for all store version customers.  In order to replicate the previous functionality for online high score submissions, we needed a way to distinguish among different users without accessing any individually identifiable user information.  Alas, in the end, we had to provide a hash of some system information that was reasonably unique, and simply accept the possibility of a certain number of collisions.  (Thus far, MAS sales have not been high enough to get to levels where collisions are likely, though.)

Honestly, there is a possibility that information from the included MAS receipt could have provided a better (unique) customer identifier, but our implementation (above) was completed before receipt checking was considered.  In this case, that is left as an exercise for the reader (but comments on implementation are encouraged).

4. Update version tracking codes

For the store version, you should update any version tracking codes in your project, using conditional compilation (APPSTORE) where necessary.  This will allow any usage statistics to differentiate between downloadable and MAS customers, as well as from trial version users (i.e., potential customers).

In our case, we simply add a character to the end of link URLs (i.e., as part of a single GET variable) that makes this distinction, so we just added another legal value for MAS purchases.  Additionally, our shortened version numbers are slightly different so (savvy) players can identify the product played on the online high score pages (for example, on this FreeCell scores page, see the ‘Product’ column).

5. Remove or modify marketing screens

Consider whether you should modify or remove any marketing screens in your product.  If you have dialog boxes which have the occasional link to ordering pages or downloadable content, you will need to remove those links (and any referencing text); if you have dialogs that are explicitly for the purpose of marketing, it may make sense to remove them entirely instead.

In the case of our products, we include a fairly self-explanatory ‘Help Center‘ screen which not only contains links to the help files for the product, but also serves as a portal to all manner of support services, including sales (verboten), registration code entry (not allowed), customer support email (probably OK), and suggestions for other games (who knows?).  We found that removing the disallowed and questionable content from these pages made them almost pointless, so we instead replaced the entire dialog with a direct link to the help file contents page (within the bundle).

6. Remove links to any downloadable content

You must remove any links to downloadable content or risk the rejection of your product.  Note that these links (and, in truth, a number of other “offenses”) may not always be obvious on initial review, so your product can certainly get accepted once and then later rejected for something that was there in the first version; it has happened to us more than once.  (All Apple reviewers are not created equal.)

In the case of Pretty Good Solitaire, we have card sets which customers can freely download, plus a feature to check for and download updates, both of which are forbidden in the Mac App Store.  The following subsections describe the issues that we had to address to prevent suggesting that there was anything outside the MAS playground.

6a. Remove download links from main menus

We had to remove our ‘Download Additional Card Sets‘ menu option from both the main and game menus.

6b. Remove version checking from main menus

We had to remove our ‘Download Latest Version‘ menu option, which includes an implicit version check, from the both the main and game menus.

6c. Remove download links from submenus

We had to also remove a ‘Download Additional Card Sets‘ menu option from our submenu that players use to select the desired card set (a logical and convenient place to find it).

6d. Remove download links from buttons

Finally, we had a ‘Download Additional Card Sets‘ button within the program preferences, which also had to be removed (actually, hidden).

Note:  In all of these cases, rather than modify our user interface (.nib) files, and thus have to manage different sets of files, we added conditional code that simply removed the offending menu option or hid the button, keeping the source code (including .nib files) identical between downloadable and store versions (distinguished solely by the presence/absence of APPSTORE).

7. Review any use of the Application Support folder

Before submitting your application to MAS, carefully review your use of the Application Support folder (if any).  Specifically, you are allowed to create and (appropriately) use a folder at ‘~/Library/Application Support/<app-identifier>’, where <app-identifier> “can be your application’s bundle identifier, its name, or your company’s name.”

However, there is a twist:  “These strings must match what you provided through iTunes Connect for this application.”  This particular requirement is somewhat buried in the guidelines, and it is not always checked.

In our case, we inadvertently created but did not use (in the store version) a folder, ‘~/Library/Application Support/Goodsol’, which seems to fit the criteria.  However, it was supposed to end in ‘Goodsol Development’ to meet the letter of this requirement.  This “violation” was not discovered until our third or fourth submission, and our downloadable versions already used the folder extensively as named.  Fortunately, the store version did not actually use it (by virtue of including all downloadable content), so we just removed the spurious creation of an empty folder.  Problem solved (albeit with yet another rejection and delay).

Conclusion

With the above modifications to source code, plus perhaps a little detective work finding similar issues with any particular application, your project should be tentatively ready for submission to the Mac App Store.  In the next installment, Part 5: Mac App Store receipt validation, I will discuss the reasons that you should probably validate receipts in your shipping product and provide a few links to useful code and resources.

MAS Preparation, Part 3

Posted on by
2

Data and Resource guidelines

In the previous installment of Preparing for Mac App Store Submission, I detailed changes to the information property list that are necessary (or recommended) for a Mac OS X game project being converted to one suitable for MAS submission.

This third part deals with practical implications of guidelines for project data and resources, in particular, artwork and help files.  These points are necessarily somewhat specific to the manner in which we implemented our products, but they should give you some idea of items to look out for, and as always, comments on your experiences are encouraged.

Now, please review all of the artwork and other (non-code) resources in your project with these points in mind…

1. Include a 512×512 image in the application icon

The Mac App Store requires a 512×512 image in the application icon file.  Although this is generally overkill for an application, it is necessary for MAS submissions, where that image size is (presumably) used for presenting your product to users.

We actually produce our Macintosh (.icns) icons under Windows using Axialis IconWorkshop, which handles the required sizes without problem; we recommend this tool for processing icons for multiple platforms.  (We have no affiliation with Axialis, except as a satisfied customer.)

2. Update branding artwork

Although it seems (and truly is) silly, you need to review your branding artwork and update anything that even hints that there is another way to obtain software than through the Mac App Store.

Herein lies a theme: Apple hates downloads; Apple hates external sales.  Any suggestion that a customer may download or purchase anything outside of MAS will result in the rejection of your submission.  (Trust me, we had this thrown in our face, via rejection, more than once.)

In our case, we had a static bitmap used as a splash screen.  It included the (innocuous) line, “Download the latest version of Pretty Good Solitaire from http://goodsol.com“; it was hardly noticeable, and the web address was not even a hot link.  Rejection.  We had to remove that text before resubmitting (and we also removed the line with our support email address, just in case).

3. Add any extra product data desired

Continuing with the theme, you will need to add any extra product data that you may want customers to have, especially any data previously available via download.  In our case, we have (20) extra card sets that are available for Pretty Good Solitaire customers to download (and, likewise, extra tile sets and custom layouts for Pretty Good MahJongg), so these needed to be added to the main bundle to avoid Apple’s allergy to downloading.

The one minor advantage of this, of course, is that Apple has to bear the full download bandwidth burden.  (Card set artwork is not small.)

4. Remove trial version resources from the project

If appropriate, remove any resources used only in trial versions of your product.  In our case, we have an exit screen for trial users, as well as a separate interface (nib) file with all dialogs displayed (only) in the trial version, so we removed these.  (There is no sense including unused files, especially if they could give Apple more places to find reasons to reject.)

Similarly, if you have an install bitmap in your bundle, as I recommended in Making Mac Disk Images Pretty, you may as well remove that, too (since there is no disk image packaging to be done).

5. Remove any ‘How to Order’ section from help files

Review your help files and remove any pages that discuss verboten topics, such as downloading, registering, or (especially) purchasing the product.  We have an entire section called “How to Order”, dealing with all of those topics, that is just removed wholesale for the MAS submission (but remains in our downloadable versions); it was the cause for a rejection.

Note that Apple does not reject for simple web links back to a product site, which itself may have loads of sales and download information, but you will want to be careful about the surrounding text.

6. Remove text referring to downloading or sales

Building from the previous guideline, after removing entire pages about problematic topics, check other help topics and remove any text referring to downloads or sales, even indirectly.

In our case, we have rule pages for our bonus games, which are provided in the full (purchased) version, and we removed the line, “Note: This game is only available in the full version of Pretty Good Solitaire.”  Elsewhere, we also replaced “the full version” with “this version”.

Conclusion

Using the above guidelines, you should be able to make sure that your project does not include any content that Apple may find “objectionable”, giving them cause to reject the submission.  In the next installment, Part 4: Source code modifications, I will discuss the numerous (small) changes that may be necessary in your project source code.

MAS Preparation, Part 2

Posted on by
3

Property List (Info.plist) changes

In the last installment of Preparing for Mac App Store Submission, I discussed the project modifications that are necessary (or recommended) for converting an existing Mac OS X project to one suitable for MAS submission.

This second part describes the changes to the information property list for your application that you should make for successful submission and to eschew rejections for simple issues.  As before, comments about any other issues or different experiences are certainly welcome.

Open the application information property list, usually named ‘Info.plist‘, in your project and follow these steps…

1. Update the bundle version format

First, update the format of the ‘Bundle version’ entry (CFBundleVersion) to contain exactly 3 period-separated integers representing the version number (e.g., “1.01.1“).  It cannot contain alphabetic characters (and although some documentation suggests that it may contain more or fewer integers, we did not take that chance).

For non-MAS applications, the format of this field was not enforced and, in fact, the default ‘About’ box encouraged the use of this field as a standard version description (alphanumeric string) by directly displaying it underneath the application name.  We used a format like, “1.01 (January 2012)”, which is more useful and aesthetically pleasing, but this was cause for rejection.

2. Add an application category

If you do not have one already, you will need to add an ‘Application Category’ entry (LSApplicationCategoryType).  The easiest way to set this value (in Xcode 4) is to select the ‘Summary’ tab for your target and select the appropriate setting in the ‘Application Category’ box.  In the case of Pretty Good Solitaire, we chose ‘Games – Card Games’ (public.app-category.card-games).

Note that Xcode 3 did not recognize this key, so it was necessary to explicitly add it, along with the appropriate category value, as found in the Information Property List Key Reference; fortunately, this is no longer necessary.

3. Set the minimum system version

Next, set the ‘Minimum system version’ entry (LSMinimumSystemVersion) to “10.6.6”, or higher if appropriate.

The Mac App Store does not work on versions of Mac OS X prior to 10.6.6 anyway, and leaving this at a lower setting (even if your downloadable versions support Leopard, Tiger, or even an earlier OS) may be cause for a rejection.

4. Review the supported document types

Finally, review the supported ‘Document types’ entry (CFBundleDocumentTypes), if any.  Remove any document types that will not be supported in your store version.

In our case, we supported a document type for saved games, which is still useful, but also a document type for automatic installation of extra card sets (which can be downloaded), or in the case of Pretty Good MahJongg, types for both extra tile sets and tile matching layouts.  Since downloading or installing any improvement to your application (outside of the Mac App Store) is verboten, we needed to remove this support.

Note that this initially passed muster with our first product, but it was cause for a rejection later on a different product using essentially identical functionality.  There is clearly some subjectivity to the application reviews, so a more thorough (or nitpicky) reviewer may find something previously allowed.  When a rejection can set your release schedule back a couple of weeks or more, it is not worth the risk.

Conclusion

With just these few changes to your information property list, your project should have the necessary application information for submission.  In the next installment, Part 3: Data and Resource guidelines, I will describe the issues you may encounter with your application data.

MAS Preparation, Part 1

Posted on by
3

Project modifications

In Preparing for Mac App Store Submission, the first set of changes you should make are to the project itself.

This installment describes the project modifications that need to be made to an existing Mac OS X game project.  The general assumptions are that the existing project is working and properly tested, and that, ultimately, you will want to maintain a single set of source code with conditional compilation to differentiate the store version from other builds.  Note that these are the steps that we took for Pretty Good Solitaire Mac Edition; your project may require some adjustments to these steps.  (Comments where any significant change is necessary would be very appreciated.)

So, without further ado…

0. Create a duplicate store project

Before making any other changes, create a duplicate copy of the entire project folder and name the copy appropriately.  In our case, the original folder was ‘Pretty Good Solitaire’ (which builds full and trial versions of the game) and we created a separate ‘pgsse’ (Pretty Good Solitaire [Mac/]Store Edition) folder for MAS modifications.

The version of your project that you will submit to the Mac App Store is a separate SKU (Shelf Keeping Unit), a build that uses slightly different code and configuration and which is distributed via a different channel.  While it is possible to have the store target within the main project, certain features (e.g., Power PC support, Mac OS X 10.5 support, downloadable data) are not supported in MAS, so it is easier to separate them (at first, anyway).  In any event, doing so at the start gives you a safe playground for making changes without messing up your working project.

1. Update the project version number

As just noted, the store build is a separate version and, thus, should have a different version number.  In our case, we decided that odd minor versions (e.g., “1.01”) would represent the store editions, while even minor versions (e.g., “1.00”) represented the direct downloadable editions.

2. Rename the primary build target

In the new project (of course), rename the primary build target to something appropriate.  In our case, we renamed the full version target to ‘Pretty Good Solitaire store’, which is now the store version.  You could also delete any redundant or obsolete targets remaining in the project.  For example, we deleted the trial version target, as it is built in the original project and the MAS version cannot have any vestiges of a trial version.

Note that this step is not strictly required, but it is a good idea to differentiate between targets, so it is always immediately obvious which project is active, and also to minimize any excess baggage, which reduces the possibility of mistakes.

3. Build with a current Xcode version

Make sure that you build the project with a current version of Xcode.  Submissions to the Mac App Store now require Xcode 4 and, as of this writing, the latest version is Xcode 4.2.1.

If you have an older version of Xcode, this would be a good time to upgrade, and although it will not be mentioned explicitly, you should build the project regularly, ideally after every change, to make sure that the build is not broken and behaves as expected.

4. Define a preprocessor variable

To allow for conditional compilation of certain source code, it is a good idea to define a preprocessor variable, APPSTORE, for any build targets intended for MAS.  In the ‘Build Settings’ for the target (or the whole project, if you prefer), find the setting for ‘Preprocessor Macros’ and add “APPSTORE” to each configuration.  Note that it is common to have different variables for ‘Release’ and ‘Debug’ configurations, so be careful to define APPSTORE for each one without accidentally removing or altering any existing definitions.

Of course, there is no requirement that the preprocessor variable be named “APPSTORE”, but beware that simply using “STORE” results in a naming conflict in the latest Mac OS X SDK.

5. Add necessary frameworks/libraries

In order to test the validity of app receipts, you will need to add the IOKit and Security frameworks and the crypto library.  From the ‘Build Phases’ of the primary target, open the ‘Link Binary With Libraries’ section and, by clicking on the ‘+’ symbol, add ‘IOKit.framework‘, ‘Security.framework‘ and ‘libcrypto.dylib‘.

Note that Xcode 4 adds these frameworks/libraries at the top level of your project; you will probably want to drag them into the ‘External Framework and Libraries’ folder with the other frameworks.

6. Configure debugging symbols

Despite submitting a release version to MAS, Apple requires debugging information to be included with a submission.  To accede to this requirement, you must set ‘Generate Debug Symbols’ to “Yes” and also set ‘Debug Information Format’ to “DWARF with dSYM File” (at least for the ‘Release’ configuration) in the ‘Build Settings’ of the target.

In our original project, we had all debug information disabled and/or stripped from the release builds, but one of our early issues was the lack of the dSYM file with debugging information for Apple.

7. Set correct build architecture

Finally, set ‘Architectures’ to an Intel (only) setting; for our project, that is “32-bit Intel”.

Even if your code and original project supports both PPC and Intel via a “Universal” application, the presence of a PPC build in your submission will result in rejection.  (We found that out the hard/lengthy way.)  At least now there are settings for this; in Xcode 3, you had to use “i386”, which was not even listed as a choice.

Conclusion

At this point, you should have a new project with a store target and all of the build settings configured appropriately.  In the next installment, Part 2: Property List (Info.plist) changes, we will discuss the necessary adjustments and additions to the information property list for your project.

Preparing for Mac App Store Submission

Posted on by
6

Making a Mac OS X game project suitable for MAS

If you currently have a Mac product and have not already done so, you may be considering submission to the Mac App Store (MAS).

In the upcoming series of posts, I will be detailing the process that we went through to get Pretty Good Solitaire Mac Edition, and some of our other game products, successfully submitted to MAS.  There were a number of rejections along the way, as the App Store Review Guidelines [note: requires Mac developer agreement], while extensive, are not comprehensive (nor are they 100% consistent, as we had some products accepted and others rejected with identical behaviors).

Over multiple submissions, and fewer rejections, we developed a submission checklist which I will detail roughly (some items are specific to our games) in these upcoming posts:

We have had product in the Mac App Store since launch day, more than a year ago.  If you already have a game that runs on Mac OS X, it makes sense to make the several modifications to get it into MAS, another channel to find customers.  However, in our experience, it is not a viable substitute for direct downloadable sales.  The channel is not (yet) the primary ‘go to’ location for Mac software, although the availability of Lion (Mac OS X 10.7) only on MAS should shift more customers.  Additionally, there is the same downward pressure on pricing (towards free) seen on the iOS App Store, sales are lackluster, and (of course) you are giving 30% directly to Apple.

I would certainly not recommend developing a project solely for the Mac App Store, nor eliminating a direct downloadable sales channel in favor of MAS, but with an existing project it may be worth the fairly limited extra effort it takes to be there, too.

2012: A Year of Connections

Posted on by
Reply

Planning for success in the new year.

We Rock!Now that the SOPA Blackout is over, we look toward the rest of this year with great anticipation.  Although Digital Gamecraft had a rather subdued performance last year, it looks like 2012 is certainly going to be our most successful year ever!

We are (again) preparing to release our first iOS title, Demolish! Pairs, with other projects (and platforms) in the works.  Additionally, SophSoft, Incorporated, our parent group, will be continuing our aggressive development program in conjunction with Goodsol Development.

For this year, we are making a concerted effort to connect with others more effectively; this means colleagues, customers, friends, and the game industry at large.  We are continuing to expand our presence on social networks and are being not only more “vocal” (and, hopefully, prolific), but also more open and transparent.

We are now laying claim to being The Most Venerable Independent Game Developer in the World, unless and until somebody proves otherwise!

Having recently watched this interesting TED video by Derek Sivers: Keep your goals to yourself, I am going to keep the specifics of my personal and business goals to myself; however, it can certainly be inferred that the unfulfilled goals for 2011 would be among them.

That said, I did adopt and will share one resolution for the new year: “Do Things Better…”  (Thanks to Frank and Ernest.)

Stop SOPA (and PIPA)

Posted on by
1

Stop PIPA, too.SophSoft, Incorporated opposes SOPA legislation.

You may have noticed that today several sites have “gone black” to various degrees.  You need look no further than the main page of Google (on January 18, 2012) to see a good example.

The reason for this is to draw attention to the dangers of the Stop Online Piracy Act (SOPA), which is proposed in the U.S. House of Representatives, and its counterpart in the U.S. Senate, the Protect IP Act (PIPA).

We at SophSoft, Incorporated oppose these acts because, despite the ostensible goal, namely to stop computer piracy (a laudable aim, which we fully support), if SOPA and/or PIPA were to become law, they would fundamentally change the free nature of the internet, while doing little of substance to prevent actual piracy.

The rise of the internet has been the most important cultural shift in the past two decades, bar none, and it has been a catalyst for change throughout the world.  These bills could reverse that progress by allowing sites to be blocked in the United States without due process, and it shifts the burden of policing users to legitimate sites, requiring defacto censorship.  It also provides a blunt tool for unethical practices against online competitors or, in the best case scenario, merely (in essence) assigns much of the control of the internet (in the US) to large media corporations.

One of the most troubling aspects of these acts is that they show a profound lack of understanding of the actual issues, and without due process of law, there would be no opportunity for one to make a case, nor even to correct a misunderstanding.  The “fair use doctrine” is not a bright line rule that is always clear, and these acts could force a company out of business simply because of a complaint about the fair use of an item, or due to an errant blog comment with a bad link (or a good link that was compromised later), nevermind the threat of simple malicious complaints.

Here is a very realistic scenario:  Your sister-in-law gets a tattoo of Winnie the Pooh (Disney artwork) on her butt and thinks it would be fun to post a picture of the tattoo on Facebook; legalities of the tattoo notwithstanding, the litigious owners of Disney find a link to said picture, file a complaint, and Facebook itself could be shut down.

Another example, just for good measure:  A small company like ours produces a game and includes background music contracted legitimately from an artist who is fully paid for his work; EMI decides that one measure sounds a little too similar to something from one of their artists, files a complaint, and our website is blocked.

Clearly, SOPA and PIPA are very dangerous approaches to resolving a significant problem for those of us in the software industry (though, in truth, the acts are still all about protecting large media conglomerates).  If Congress really wants to help the problem, it could provide an expedited legal process for suing those who deliberately infringe copyrights, perhaps with a schedule of default judgment amounts, so small companies could afford to go after the real pirates.  I have no problem with a court shuttering a proven pirate website, but the government already has that power.

For different takes on this issue, please see the Wikipedia and Google (“End Piracy, Not Liberty“) responses.

Finally, let me simply say that any U.S. bills that would use the same methods as those used by the governments of China, Iran, and Syria to suppress political dissent, and are rabidly supported by Rupert Murdoch, whose News Corp saw nothing wrong with tapping phones and illegally listening in to private phone conversations (until they were caught), are definitely to be avoided.

 

30 Years in Business!

Posted on by
2

Today we start our fourth decade in the computer game business.

Thirty years ago today, January 13, 1982, I walked into the Ingham County Clerk’s office in downtown Lansing, Michigan, and filed a “Certificate of Persons Conducting Business Under Assumed Name” (a.k.a, DBA, ‘Doing Business As’) for Sophisticated Software Systems.

You can read more about how this originally came about in A little bit of History, Part I, but for just a $10 filing fee and a notarized document, I started my first company.

After some false starts, Sophisticated Software Systems self-published its first successful game in 1990.  The company went full-time in late 1994, and incorporated in 1996 as SophSoft, Incorporated.

In 1998, SophSoft, Incorporated spawned a division specifically for developing in-house game projects, Digital Gamecraft (as well as another division for non-game products in 2003).

However, it all started officially 30 years ago today!

Below are a few of our logo images from over the years, demonstrating the changes over time:

Here’s to the next 30 years!

Pretty Good Solitaire Mac Edition 2.3

Posted on by
Reply

Now with 350 games!

Yesterday, Goodsol Development published Pretty Good Solitaire Mac Edition 2.30, the latest version of the premier computer Solitaire program for Apple Mac OS X.

Pretty Good Solitaire Mac Edition 2.30 adds 50 new solitaire games, bringing the total to 350 games in the trial version, and 400 games in the full version (with 50 bonus games).  This game also introduces the Tour Explorer, which allows players to play game tours for a total score in pursuit of the perfect tour.  Click here for a list of other features in PGSME.  You can download a trial version of the product and buy it for only $24.95!  This version is a free upgrade for all previous PGSME customers, and new customers will get free upgrades through the end of 2012, which will include even more releases and new games.

As mentioned in my 2011: Year in Review article, this product is the culmination of a fairly long development and beta test cycle.  Surprisingly, the game tours feature (like the game groups before it) was the biggest single issue in getting the product released sooner.  Not only does the feature consist of four separate dialog boxes, plus two more back-end data classes, but the only specification was a somewhat flawed implementation, so I needed to rethink and redesign the entire feature, and then tweak the behavior until we had something that worked well.  Complicating matters was the fact the beta testers were not inclined to play game tours, and none are quality assurance professionals (nor aspiring to be), so in essence, only we developers (mostly me) were doing any real testing of this feature.

Of course, the sheer mass of 50 new games, when combined, contributed much more to the overall development and testing time, though none (even the real “oddballs”) took a huge amount of time alone.  Fortunately, our beta testers were more meticulous about play testing individual games, so the few significant bugs I let slip through to the beta versions were (hopefully) identified and crushed.  I challenge anybody to find a bug in PGSME now.

After a short breather, I will be back on development of PGSME 2.4 (a.k.a., GS400), which will contain (surprise!) another 50 games for a total of 400 (plus at least 50 bonus games).  Bring it on!

 

2011: Year in Review

Posted on by
1

Overall Performance Grade: C+

As we officially begin 2012 after taking our annual two week “break” (during which I actually worked every day), it is a good time to do a quick review of the past year at Digital Gamecraft and SophSoft, Incorporated.

What went Right

We started the year with enthusiasm and energy.  A new product, Demolish! Pairs, was designed from the ground up for iOS, the artwork went from specification to final in short time, and a playable alpha version of the product was programmed within a few months.  Internal procedural changes brought better efficiency and productivity (and require few changes going forward), and our marketing and social media efforts got off the ground late in the year.

Additionally, our collaboration with Goodsol Development passed the 10-year mark in September (and continues on).  We shipped 10 different SKUs of Goodsol projects for publication, as well as 5 more that remained unpublished for various reasons.  We ended the year strongly with another 2 products essentially finished, one of which will be published this week (while the other will remain a private bonus for beta testers).

What went Wrong

Despite the quick development of Demolish! Pairs to a playable alpha version, it did not ship during 2011, which was one of my primary goals for the year.  In fact, I/we did not manage to reach any of the three challenging goals I set (business, individual, or family).  As noted at the beginning of the year: “no excuses allowed.”  I failed to meet those goals.

Although the Goodsol projects were flowing early in the year, during the second part of the year, I (personally) got bogged down in the development and testing of two lesser features for Pretty Good Solitaire Mac Edition, along with the 50 new games added, and the beta test became much longer (and more tedious) than anticipated.  That was not ideal.

What went Horribly Wrong

Of course, the worst and most significant occurrence of the year was the loss of my close friend, business partner, and artist, Rick Tumanis.  That, alone, colored the whole rest of the year a little darker.  (City Pulse recently included Rick in their remembrance of 10 people who died in 2011.)

Final Evaluation

In the end, I awarded a grade of C+ for overall performance in 2011.  Looking back, although specific goals were not met and perhaps productivity could have been higher, the fact remains that we are still here and viable, several products were published, new games were implemented, and progress was made towards our long term corporate goals.  Even in light of a major setback, we still left the year in better shape than we entered it, hence a slightly above average grade.

How did your 2011 wind up?