2021: Year in Preview

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.

Digital Gamecraft logo

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:

  1. Stay healthy, safe, and productive.
  2. Continue to reliably make payroll while growing income.
  3. 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.

The Beauty of Code

Programming itself provides opportunities for self-expression.

In the midst of chaos and strife, when I need to take a break from the “real world”, I most often find my escape in source code, programming anything really. Of course, having more projects than I could hope to finish, and clients providing additional work to boot, means that I always have a ready avenue for directing my focus. However, it is not solely about the product, nor the money; it is also about the pleasure and enjoyment of coding itself.

There are a number of fairly passive experiences that I (and I imagine most of us) use to pass the time: playing games, reading books, watching television or movies. There are also more productive activities such as exercise (I quite enjoy hiking, bicycling, and swimming), house cleaning and organization, home improvement, and “gardening” (of a sort). None of these activities, however, provides the same creative outlet as programming.

When it comes to creative expression, appropriately, there are lots of different ways that people find to fulfill that need, which is important to our being. I know lots of people who like to sketch or doodle, or to write (for which I have gained some appreciation over the years), and others participate in higher commitment activities such as making stuffed animals, woodworking, or designing jewelry. When I was younger, I turned to more “design” oriented expression, such as creating original mazes, designing pinball machines, and architecting dream houses; at one time I designed a complete go-kart business, including the tracks and buildings.

The beauty of code is that it allows for self-expression within a systematic framework. I have always enjoyed numbers, logic, and the rational, and these all factor into programming. Within the rules, though, there are essentially infinite ways to express an idea, both in terms of method and of presentation. Of course, there are demonstrably “wrong” ways to do things, such as code that does not compile, fails to work, or crashes, but there are many levels of “right” ways to accomplish things, including how to efficiently increase functionality, how to handle errors and unexpected situations, and (importantly) how to make the source code understandable.

When I was required to attend an “advanced” BASIC course in high school, having already programmed for years (but with no formal education to show it took vociferous insistence just to avoid the “beginner” class), one of the first problems we were presented was to take a three-digit number as input and reverse the digits. I was the very first person to complete the task, twice. My second version was the anticipated method of accepting numerical input, with constraints placed on the operator (not the program) to limit the input to 3 digits, separating the number into ones, tens, and hundreds places, and printing them in reverse order, just to prove that I knew how to do it that way. My first version accepted the input as a string and printed the characters in reverse order, which worked on the specified input type, but also on numbers of arbitrary size, or any characters that could be input.

Around that time, I also set myself a challenge to create an “unbreakable” game, which I was able to accomplish with a high degree of confidence. To be unbreakable, the program had to be bulletproof, once executed, such that nobody could deliberately nor accidentally get to the prompt (and, hence, have access to the source code). This meant that the program needed to have no syntax errors (BASIC was interpreted code, rather than compiled, so such errors would only be found when executed), no logic or constraint errors that would allow a crash (such as selecting an unexpected/illogical action or overloading an input buffer), and also disallow breaking (via ^C), which was accomplished via system-specific methods. The only ways to end the program were turning off the power or hitting the reset button.

Programming has a lot in common with the scientific method. Although you use known logic to devise provably correct solutions, rather than testing hypotheses, you still test to confirm your approach and resolve errors, whether they be in your understanding of the problem, your design of a potential solution, or your execution of the plan. In fact, I constantly use this approach when building a program to regularly test my assumptions. I will make an interim change and state (to myself) the expected failure outcome, whether that be a compiler error (or specific number of compilation errors) or some weird behavior, just to confirm my understanding. If some code compiles unexpectedly, or the behavior is not as anticipated, I revisit the problem and make sure than I can explain why things went differently.

This shows yet another beautiful aspect of programming: its digital nature makes it precise and enables, at least ostensibly, the pursuit of perfection. You can experiment with something new with confidence that, if it does not work out, you can return to exactly the original situation. It does not matter how far out in the weeds I get with an idea; I can always get back to where I started. (Try that with oil painting.😉) Also, as my first computer book helpfully pointed out at the start of my career, nothing that you do with source code, short of typing it with a hammer, can break your computer (and while that is not strictly true, exceptions are exceptionally rare and not worth concern).

The fact that I value the actual source code as well as the outcome, which tends to be better for such appreciation, explains why I am not a fan of “visual programming”. With traditional source code, everything is enumerated and readily viewable, having been written by you or another programmer. While visual programming is ostensibly the same, it hides aspects of the code and logic behind objects, making development more like hide-and-seek. My first experiences were in the very early ’90s with Asymetrix ToolBook and Borland ObjectVision, where one would have to check every page and object to find all of the scripts to have a complete understanding of the logic, which unnecessarily fragmented the code. Today, such tools as Unity, Unreal Engine, and Interface Builder certainly make visual layout easier, but with the inherent risk that the complexity hides some of the logic, removing it from the source code and fragmenting it. It can be quicker to develop visually (especially if one is inclined toward fast results over quality), but it is inarguably harder to debug.

Outstanding programming is more craft than art, by which I mean that it can be learned and refined over the course of years, and one does not necessarily require an inherent creative ability. I can explain the rationale behind decisions in my source code, and I can teach you techniques, and if you have the requisite logical intelligence (which many people do not), then you can become at least a very good programmer. (I doubt one can read a book about fine art and learn what it takes to be a master.) One of the best compliments I can get is when I am told that I taught somebody the value of maintainable source code, or defensive programming, or quality assurance techniques.

With that in mind, I intend to document more of my approaches to development in general, to provide insights that interested parties can take or leave, along the lines of my Quality [index] series from many years ago. One current focus is refining my programming standards, so look for that in the near future.

Digital Gamecraft 2020

It has been just more than a year since SophSoft, Incorporated lost its second founding partner (of three) and I lost my wife of 31 years.  In a week, the company will be celebrating its 38th anniversary, and it will continue to develop game software.

During 2019, I took time to reflect on what was really important and what I wanted to do with the rest of my life, and I decided that the plans that Sherry, Rick, and I had devised (and undertaken) as business partners were honest and true representations of what we wanted to achieve.  Therefore, I will continue those pursuits, not just out of a sense of loyalty, but because they are why we got into this venture in the first place.

Digital Gamecraft will continue to develop and publish game titles in a variety of genres, and this will be our primary focus.  While some of these games may be a little different to what they would have been with my partners to help guide the development, the games will nevertheless embody the spirits of Sherry and Rick to the best of my capabilities.

SophSoft will also continue to do consulting work; however, due to sheer limitations of time, our regular client roster is effectively full.  Please feel free to contact us if you are in desperate straits or need our help with a fully-funded project that is right down our alley, but realize that we may not be able to fit you into the schedule.  (If you have just an idea, a shoestring budget, or a need for fleet management software, go somewhere else.)

We also have a couple of adjunct projects that I expect to see the full light of day within 2020; announcements will be made here as and when appropriate.

In an industry where companies come and go with a disturbing regularity, remember that we have had the same address for 30 years:

Post Office Box 4936
East Lansing, MI  48826-4936

We have had the same business phone number for 25 years:

(517) 337-3905

Our web site has also been in steady operation since 1995 (though this blog is just a baby at a mere 15 years old).  Plus, having been originally founded in 1982…

We are the oldest independent video game company in the world.

I truly appreciate your support as we continue to move forward.

Sincerely,
Gregg Seelhoff

Still Coding After All These Years

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!


Launch Screen Sizes for iOS 12

If you still use launch screens, these are the sizes you need.

As with mobile icons, the proliferation of new Apple mobile devices demands an ever increasing number of launch images.  This post lists the necessary artwork sizes to directly support all devices (and possible orientations) as of iOS 12.

Of course, Apple realizes that adding new launch screen sizes every time they introduce a new form factor will quickly become unsustainable.  (It is close to that now; otherwise, this post would be unnecessary. 😉 )  For that reason, they introduced launch storyboards, which allow a launch screen to be defined by a layout of controls and constraints, rather than by individually sized images.  The only problem is that, unlike normal storyboards, the launch storyboard is loaded before the application runs, so only automatic layout can occur; no code can be executed.  Therefore, customization is restricted, which prevents developers from accomplishing the same thing that is possible with launch images, namely, use of the entire screen on each individual device for displaying an image.

Apple takes the position that the launch screen should display an image reflective of the first screen of the application to give the impression that the app has launched that quickly.  This certainly is better for Apple, who is not known for missing branding opportunities, but using the launch images for branding, i.e., a splash screen, is expected in the game industry (and, arguably, for any software).  Also, games usually have custom background artwork, and if that is customized to screen sizes, there is no easy way to mimic that with a launch storyboard, at least at the moment.

To be fair, nowadays the launch screen is a somewhat rare occurrence, as it is only shown at first launch, or when the application has been unloaded, either closed by the user or removed from the background by the system to recover resources.  If you design your splash screen to be an image in a sea of solid color or a repeating texture, you can reproduce that with a launch storyboard.  The kind of splash screens that Rick Tumanis designed for Demolish! Pairs or Pretty Good Solitaire, however, do not lend themselves to this approach.  It is for that reason that we still use launch images in those games (and others).  In fact, Demolish! Pairs will reshow the splash screen if you shake the device from the menu.  (It is an ‘undo’ when done from within a game.)

So without further ado…

iPhone Launch Screen Sizes

Apple iPhones provide the bulk of the variety in device screen sizes, so you need to provide 11 (or 12) launch images for full coverage, as follows:

  • Portrait iOS 12+
    1. 1242 x 2688 (@3x) – iPhone XS Max
    2. 828 x 1792 (@2x) – iPhone XR
  • Landscape iOS 12+
    1. 2688 x 1242 (@3x) – iPhone XS Max
    2. 1792 x 828 (@2x) – iPhone XR
  • Portrait iOS 11+
    1. 1125 x 2436 (@3x) – iPhone X / iPhone XS
  • Landscape iOS 11+
    1. 2436 x 1125 (@3x) – iPhone X / iPhone XS
  • iPhone Portrait iOS 8+
    1. 1242 x 2208 (@3x) – Retina HD 5.5″ (iPhone 6 Plus / 6s Plus / 7 Plus / 8 Plus)
    2. 750 x 1334 (@2x) – Retina HD 4.7″ (iPhone 6 / 6s / 7 / 8)
  • iPhone Landscape iOS 8+
    1. 2208 x 1242 (@3x) – Retina HD 5.5″ (iPhone 6 Plus / 6s Plus / 7 Plus / 8 Plus)
  • iPhone Portrait iOS 7+
    1. 640 x 960 (@2x) – 2x (iPhone 4s)
    2. 640 x 1136 (@2x) – Retina 4 (iPhone 5 / 5s / SE)
  • iPhone Portrait iOS 5, 6 (legacy)
    1. 320 x 640 – 1x (optional – unused on iOS 8+)
    2. 640 x 960 (@2x) – 2x (same as #10)
    3. 640 x 1136 (@2x) – Retina 4 (same as #11)

Note that the lowest supported target system for Xcode 10.0 (latest version as of this writing) is iOS 8.0, and no devices at the original iPhone resolution (320 x 640) can run that version of iOS, so the final unique size (#12) is unused in modern apps.

iPad Launch Screen Sizes

There is good news and bad news when it comes to supporting iPad launch images.

Good News

The good news is that you only need 4 launch images for iPad support, as follows:

  • iPad Portrait iOS 7+
    1. 768 x 1024 – 1x (iPad 2)
    2. 1536 x 2048 (@2x) – 2x (iPad Retina / Air / Air 2 / 5th gen / 6th gen)
  • iPad Landscape iOS 7+
    1. 1024 x 768 – 1x (iPad 2)
    2. 2048 x 1536 (@2x) – 2x (iPad Retina / Air / Air 2 / 5th gen / 6th gen)

That is pretty straightforward, especially given that they are the same aspect ratio, so you can just create the double density size and directly reduce the image.  Further, if your target platform is iOS 10 or higher, the iPad 2 is no longer supported, so you only need the two larger images for all remaining iPads.

For completeness, here are the legacy sizes for iPads running iOS 5 or 6:

  • iPad Portrait Without Status Bar iOS 5, 6 (legacy)
    1. 768 x 1004 – 1x (optional – unused on iOS 8+)
    2. 536 x 2008 (@2x) – 2x (optional – unused on iOS 8+)
  • iPad Portrait iOS 5, 6 (legacy)
    1. 768 x 1024 – 1x (same as #1)
    2. 1536 x 2048 (@2x) – 2x (same as #2)
  • iPad Landscape Without Status Bar iOS 5, 6 (legacy)
    1. 1024 x 748 – 1x (optional – unused on iOS 8+)
    2. 2048 x 1496 (@2x) – 2x (optional – unused on iOS 8+)
  • iPad Landscape iOS 5, 6 (legacy)
    1. 1024 x 768 – 1x (same as #3)
    2. 2048 x 1536 (@2x) – 2x (same as #4)

The only (4) new sizes here are just the same launch screen sizes with an area for the status bar (20 or 40 pixels) removed.  These sizes are never used in modern apps.

Bad News

The bad news is that, as keen observers will have noticed, I did not list any of the iPad Pro models above; this is because an iPad Pro acts like an iPad Retina.  Without a launch storyboard, all iPad Pro devices show up as though they are only 2048 x 1536 resolution.

To be fair, the smallest iPad Pro, the 9.7″ model, is only 2048 x 1536, but the two larger models have higher resolution that is not used: 12.9″ is 2732 x 2048; 10.5″ is 2224 x 1668.

If you want to have the full resolution of iPad Pro devices, you must use a launch storyboard rather than launch images; you cannot use both, as (experimentation suggests that) the inclusion of a launch storyboard supersedes launch images.  Damn.

Conclusion

The release of iOS 12 added the need for 4 additional launch screens (to support both orientations for the iPhone XR and iPhone XS Max), so a “universal” app needs to provide a total of 15 launch images to support all iPhone and iPad devices.  However, if your game or app needs to take advantage of the full resolution of the iPad Pro, you will need to provide a launch storyboard instead, and adjust your launch screen appropriately.

All Apple needs to do to provide complete support is to provide constraints for individual form factors, allowing different images to be selected from the launch storyboard based on device model, OR use a provided launch image in preference to (or prior to) a launch storyboard.  Best of all, they could just remove the arbitrary and silly restriction that prevents access to full iPad Pro resolution unless we provide a launch storyboard, which restriction seems to be in place for the sole purpose of strong-arming developers into supporting launch storyboards (before they provide equivalent functionality).

In the meantime (which will likely be forever), it makes sense to start figuring out how to adjust your launch design and strategy to work with launch storyboards.  This is not unlike what is currently necessary for Android support, anyway.  For our next project, we are investigating a high resolution square-ish logo that can be the sole image in a field of white, scaled to largest size possible to fit the launch screen.

Abandoning this expected branding opportunity, though?  Not likely.

Modern Mobile Icon Sizes

Icon sizes you need to support iOS 12 and Android Oreo devices.

With the explosion of mobile devices, it keeps getting more difficult to keep track of the myriad icon sizes required for mobile apps.  This post simply lists the required sizes and uses for iOS and Android devices (as of now).

When creating an application icon, it is best to start with an image that is (at least) the size of the largest icon necessary, which is currently 1024 x 1024, and then reduce that image to the necessary sizes, reducing level of detail as/if necessary for smaller icons.

iOS App Icons

As of Xcode 10 (iOS 12), iOSApple iOS devices have application icons for the app on three different device types (iPhone, iPad, and iPad Pro), the store, spotlight (search), settings, and notifications, and these icons may need to be provided in single (unadorned), double (“@2x”), or triple (“@3x”) scale factors.

For a “universal” app, you need to provide icons in 13 resolutions (for 15/18/19 different uses, depending on how you count).  iPhone only apps need 8 resolutions; iPad only apps need 9 resolutions.

Here is a list of the iOS icon sizes, along with a color-coded list of the uses:

  • 1024 x 1024
    • App Store – all applications  (<title>.png)
  • 180 x 180
    • iPhone application @3x  (<title>_iphone@3x.png)
  • 167 x 167
    • iPad Pro application @2x  (<title>_pro@2x.png)
  • 152 x 152
    • iPad application @2x  (<title>_ipad@2x.png)
  • 120 x 120
    • iPhone application @2x  (<title>_iphone@2x.png)
    • iPhone spotlight @3x  (<title>_search@3x.png)
  • 87 x 87
    • iPhone settings @3x  (<title>_settings@3x.png)
  • 80 x 80
    • iPhone spotlight @2x  (<title>_search@2x.png)
    • iPad spotlight @2x  (<title>_search@2x.png)
  • 76 x 76
    • iPad application  (<title>_ipad.png)
  • 60 x 60
    • iPhone notification @3x  (<title>_notify@3x.png)
  • 58 x 58
    • iPhone settings @2x  (<title>_settings@2x.png)
    • iPad settings @2x  (<title>_settings@2x.png)
  • 40×40
    • iPad spotlight  (<title>_search.png)
    • iPhone notification @2x  (<title>_notify@2x.png)
    • iPad notification @2x  (<title>_notify@2x.png)
  • 29 x 29
    • iPad settings  (<title>_settings.png)
  • 20 x 20
    • iPad notification  (<title>_notify.png)

Android App Icons

AndroidAndroid icon requirements had remained fairly consistent, but as of Android 8.0 (Oreo, API 26), those application icons are now classified as “legacy”, though still required for support on earlier devices (i.e., 85.4% of the market); the latest devices can use “adaptive” icons.  All applications should have a store icon.

For most Android apps, you should provide application icons in 6-8 resolutions (none of which overlap with the iOS resolutions).

Store Icon

Android apps, if they are to be published, require a store icon:

  • 512 x 512 – Google Play

Legacy Icons

To support devices running Android 7.1 (Nougat, API 25) and earlier, which you absolutely should, provide legacy icons in resolutions supporting 5 (or 6) different screen densities:

  • 192 x 192 – xxxhdpi
  • 144 x 144 – xxhdpi
  • 96 x 96 – xhdpi
  • 72 x 72 – hdpi
  • 48 x 48 – mdpi
  • 36 x 36 – ldpi (optional)

Note that some legacy icons can (technically) be omitted, but those sizes will be generated by the Android system from other sizes, and not necessarily the best resolution (i.e., a larger icon may be generated from a lower resolution icon, which looks poor).  Therefore, only the low density (ldpi) icon is considered optional; no modern devices are low density, and if one was it would necessarily generate the icon from a larger source.

Adaptive Icons

Adaptive icons were introduced in Android Oreo to allow the system to perform visual effects with the shape and/or contents of an application icon.  In order for this to be supported, adaptive icons need to be separated into foreground and background layers; the foreground contains the important content of the icon, toward the center, and the background is an image or color that may provide branding but could be clipped.

These are the components:

  • foreground – 108 x 108 image with transparency, icon content in center 72 x 72
  • background – color or 108 x 108 image to be composited with foreground

The foreground and background may be moved or sized independently before being composited together, and the resulting image will likely be cropped into an arbitrary shape; Android reserves an 18 pixel border for these kind of visual effects.

For more information, see this page about supporting adaptive icons.

Conclusion

For a mobile app to support all recent iOS and Android phones and tablets, you will need to create about 20 icons, in the resolutions above, including separate foreground and background layers for adaptive icon support.  If possible, start by creating an App Store icon (1024 x 1024) from a separate foreground and background.  Use that as a source icon to generate the smaller Google Play, iOS, and Android legacy icons, adjusting detail as necessary.  Finally, resize the foreground and background layers appropriately to generate the components for the adaptive icons.  (Then, take a deep breath.)

Now you are ready to implement your application. 😉  Of course, if you want to support Android TV, Apple TV, Android Wear, Apple Watch, Android Auto, and/or Apple CarPlay…

Elite Game Developer Needs More Paying Work

Don’t bury the lead.

Game Developer for hire

Digital Gamecraft: What I Do

I will make your game idea into a real product.  I will make your existing game much better.  I will instill a sense of fun into your team.  I will imbue your code with quality.  I can help get your project shipped to customers.

This game developer is seeking additional work.

I generally work on a contract basis, but I can also do hourly or even full-time salary, as needed.

What?

  • Game development (Windows, macOS, Android, iOS, Linux, online, …)
  • Programming (C++, C, Objective-C, Java, C#, PHP, JavaScript, …)
  • Software Engineering (API design, UI/UX, mobile, AR, networking, AI, …)
  • Project Management (agile, leadership, standards, marketing, quality assurance, …)
  • and much more (from concept through customer support)

Who?

My name is Gregg Seelhoff, and I have more than 30 years experience in the game industry.  I have worked on more than 30 published products, usually in a principal role.

  1. Peruse my current résumé.
  2. Check out my LinkedIn profile (especially the recommendations).
  3. See my online portfolio.
  4. Read the archives of this Gamecraft blog site (since 2004)
  5. Just ask (in the comments, or via email to seelhoff@sophsoft.com).

Note that I have many talented colleagues upon whom I can call, especially for art and music, to form a team of the necessary size for nearly any project.

Where?

Here.  I can travel to almost anywhere in the world, and I have clients all over the United States, but I am most efficient (and prefer) working from my comfortable home office.  That said, I will relocate (and have) for the right opportunity.

When?

I am available immediately.  My time is booked to about 25% of capacity right now but that can change quickly.  Act now, while I am still available for additional projects.

Why?

Love and money.  I love what I do and I need to have enough money to keep doing it.

 

Seriously

If you want to have a top quality game developer on your team, or you have a game project that needs to be created or improved, contact me now.

 

New Old Home Office

Michigan development at full strength.

This week we completed some basic remodeling of the main Digital Gamecraft™ headquarters.  After three years splitting time with Los Angeles, California, we have again consolidated here in East Lansing.

Before we piled too much equipment into this office, we took the initiative to clear it out, remove the nasty linoleum tile floor, repaint the walls bright white (from beige) to increase brightness, seal the floor to insulate the office from external odors, and install proper carpeting to muffle the ambient noise from multiple systems running in a limited space.  With the addition of another bright lamp, this space is now very (i.e., even more) comfortable and conducive to productivity.

Of course, over so many years, we collected lots of equipment that is not as necessary, or downright obsolete, and (I hate to admit) an abundance of cables running every which way, including some that were no longer connected to anything on one or even both ends.  Now we are reloading the office with only the necessary, convenient, and/or inspirational items (and the best ones, in the case of duplication).  At the moment, it is still a little spartan with just the fundamental development systems, but we will build it out for better efficiency as we perform our primary programming tasks over the next month or so.

Meet the working stations

We have a few different stations set up for development work:

Windows and Android station (dual-boots Linux)

This primary development station currently handles Windows and Android development, as well as Linux, Unity (desktop), Unreal Engine, HTML 5, or almost any other platform for which we build products.  It is positioned in the optimal location for seeing outdoors and minimizing reflections (to reduce eye strain).

Mac and iOS station (dual-boots Windows)

This secondary development station currently handles Mac and iOS development, as well as Unity (mobile), and other platforms when on the road.  It, too, is positioned for reduced eyestrain, with minimal reflections and a direct view outdoors.

Relaxation station (in progress)

This station facilitates development by giving an opportunity to relax and break away from direct problem solving, which often gives the unconscious mind some time to work the problem, or to simply blow off some steam.  This pinball machine is a Williams Fun-Fest, an electromechanical (EM) model produced in 1973, which is fully playable, but slowly undergoing some restoration.  It has been accompanied by an original arcade Galaga machine from 1981, but that cabinet currently needs a replacement CRT or board.

This room also houses our primary server, which is headless, and a mobile device station consisting of two multiple device docks capable of charging 15 mobile devices (including Apple Watch) simultaneously, though we still need to charge the iPad Pro pen separately.

Older makes way for newer

In the course of setting up and making room for the latest equipment, we find that there are older systems and devices to be retired from ongoing development.  In this go ’round, the following were retired:

  • Apple Mac Mini PPC
  • iPad (original, still on iOS 3.2)
  • iPod touch (2d generation)
  • Android 2.2 (Froyo) phone
  • Ouya
  • Microsoft Xbox 360

Some of our peripherals may be retired as well.  Our duplicate X-Arcade Tankstick, as well as the older Dual Joystick and (separate) Trackball devices, are destined for storage.  Our Microsoft Sidewinder joystick and Logitech/Momo steering wheel/pedals, force-feedback devices, will stay.  We have 4 printers, 3 scanners, and 2 external optical burners (all useful) to optimize, and we have extraneous monitors, speakers, and various network routers and switches to stash.  I guess we will retire the fax machine, too. 😉

Efficient usage of resources

Now that the remodeling, consolidation, and configuration of the office is (essentially) complete, we find that we have some extra time for external development projects.  In these slow, summer months, we are booked to only about 25% of maximum capacity.  If you have (or know anyone who has) need of a massively experienced game developer or team, please check out SophSoft, Incorporated at sophsoft.com.

Of course, we have (literally) 32 more game projects prioritized for development under our Digital Gamecraft brand, plus a separate productivity product (to be announced), but I would love to discuss how we can help you make your vision into a published reality.

Looking Forward to 2018

Happy New Year! 🙂

Digital GamecraftThe Roman calendar started in March (Mensis Martius), so by that measure I am not too late.

OK, so we are already two months into the Gregorian year, and this is only my second post.  Frankly, those of you who know me personally will appreciate that I often have a lot to say, but when it comes to setting aside time in my busy schedule to write it down, well, my preference always tends to actual development (and my task list reflects that preference).

So, SophSoft, Incorporated and Digital Gamecraft have been acting like a duck, appearing calm and quiet on the surface, but paddling like crazy under the water.

Yes, we have been ducking. 😉

That said, we have been doing a great deal of development work on a few fronts.

What We Have Been Doing

Recent development work has been divided pretty clearly into three categories:

  1. SophSoft has been continuing our long-term association with Goodsol Development, and there are a couple of products in the pipeline for release in the near future and, of course, more to come thereafter.  There is a major release scheduled for March 21st (stay tuned), followed shortly by our two products, the first of which is already “in the can”, and the other being completed now.
  2. Digital Gamecraft is going to be releasing Demolish! Pairs for Android soon, in conjunction with the refresh of Demolish! Pairs for iOS, which is currently in progress (as required by Apple).  Another game is prototyped and approved for full production once that simultaneous release is (successfully) completed.
  3. I have been leading a team, the Advanced Concepts Group, at DAQRI, to produce AR (augmented reality) software for enterprises (Professional Grade AR™), including the majority of the Worksense™ productivity suite, as well as the development tools necessary to build applications for the DAQRI Smart Glasses®.

With more than a dozen products actively developed already this year, not to mention also properly purchasing our Michigan home/office during the same period, perhaps that will put some perspective on my lack of blog progress.  Now…

What (else) We Will Be Doing

In addition to the work mentioned above:

  • SophSoft has another (unannounced) product designed and in the early (prototype) phase.  It is a slight departure from other projects we have previously done, but it should be groundbreaking.  The first version is scheduled for release in “late Q3”.
  • Digital Gamecraft has a planned and prioritized list of game projects to undertake, with four more expected to be developed during 2018.  However, we should probably emphasize the “agile” nature of this schedule.
  • With DAQRI, there are several exciting (but, alas, non-game) projects scheduled throughout the year and into 2019 and beyond.  I am not at liberty to reveal any of these plans, of course, but I have seen the future of industry.

Personally, I have two close family weddings and a big family reunion all scheduled during the summer (in three different months), so I should be increasing my air miles, too.

Conclusion

Everything is looking quite positive, and after Looking Back at 2017, I fully expect 2018 to every more productive and fulfilling.  In fact, composing this blog post reminded me why I should be doing it more regularly: it helps me increase both my enthusiasm and my focus.

Looking Back at 2017

Overall Performance Grade: C-

Digital Gamecraft / SophSoft, IncorporatedIt has been more than four years since we have done a proper ‘Year in Review‘ post and, frankly, it will be still longer before we do a proper one.  However, we should take a look back on the previous year and take an honest appraisal of our performance and the work we have done at Digital Gamecraft and SophSoft, Incorporated.

Overview

Excluding politics, 2017 was not a terrible year for us, and for the most part we moved in a positive direction, with no catastrophic setbacks.  However, it must be noted that our ostensible performance was disappointing.  While we made big strides with internal development, we did not publish enough product (nothing directly from Digital Gamecraft) and did a poor job of communicating and marketing.

When one is spinning plates, it does not take much loss of focus to allow things to come crashing down.  Right now, SophSoft is as “streamlined” as it has been since 1994, so with fewer manhours to utilize, we tend to focus on the crucial issues (e.g., paying bills) and the tasks that we perform best and enjoy the most (i.e., development).

What Went Wrong

Because I gave us a below-average grade, we will start with the negatives for 2017:

  • We did not publish any Digital Gamecraft products (or even updates).
  • One of our Demolish! Pairs products was removed (forcibly) from the App Store.
  • Our primary web server crashed (hard) in the summer and we are still recovering.
  • Time spent in Los Angeles is far less productive than East Lansing (for reasons).
  • The current US Government is attempting to destroy this country for generations.

What Went Right

Now, we can end this with the positives about 2017:

Conclusion

Ultimately, being disappointed with shipping an average of more than one product update per month is probably a good thing; however, we can definitely do better, and that will be the subject of my next post, Looking Forward to 2018.