Last time, I reported that I was working on iOS SDK updates for my existing projects, which required taking a short break from The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.
iOS build automation
So as I said last time, much of my iOS port work tended to be manual, partly because Apple development environments are so bizarrely different from everyone else’s, and partly because Apple seems to strongly discourage build automation.
Well, sort of.
See, I made the mistake of thinking that build automation is the same as everywhere else: you write scripts using command line tools, and then you can specify configurations and kick off builds whenever you want.
But last week I found out that the reason why I couldn’t find much info about using xcodebuild is because it was buried in the docs for using the Xcode Cloud. “Oohhhh, of course! You’re supposed to do it the Apple way!”
Well, whatever, I’m not planning on using their Cloud services, and I’ve figured out much of what I need to do with CMake and xcodebuild as it is.
In fact, I think I am at the point when I can run a single script to generate an Xcode project and then build it and install it on a simulator to test it, and a different variation of the script to build and archive and upload to the App Store for validation and potentially preparing for publication. Nice!
Of course, as I said, I have an old Mac Mini that runs an old version of Xcode, so when I try to do so, I get a fun error:
Asset validation failed. SDK version issue. This app was built with the iOS 16.2 SDK. All iOS and iPadOS apps must be built with the iOS 17 SDK or later, included in Xcode 15 or later, in order to be uploaded to App Store Connect or submitted for distribution.
BUT what this error also tells me is that I’m probably ready to use Mac in Cloud.
Mac in Cloud offers a Pay-as-you-go plan. While I could have gotten the day by day plan, I decided to go with the hour by hour plan because my own development efforts match it better. Some days I only get an hour of game development in, and it would feel wasteful to have access to 24 hours and use such a small part of it.
What I didn’t anticipate was that I found myself not logging in to make progress because this past week I found myself struggling to find an hour that I knew wouldn’t be interrupted. My desire not to waste my limited hours conflicted with the need to make forward progress and my own time capacity.
It didn’t help that when I finally tried to log into the Mac in Cloud instance that I kept getting an error message. When I contacted help, they offered no help (other than a screenshot that indicated that they had logged into my account successfully) and instead offered help related to connecting to the server in the first place. Obviously if I got as far as the login screen and error messages, then I didn’t have an issue connecting, right?
But I clicked the link they provided, which took me to the same place, and I couldn’t login still.
So I decided to finally get a screenshot, and…suddenly I could log in? I must have been typing my username and password wrong this whole time?
And of course, by this time, I didn’t have the hour to take advantage of anymore, so I wasted a session. B-(
Anyway, I expect I’ll make the time this week, and hopefully building with the latest Xcode and SDKs won’t pop up too many surprises to debug and address.
The Dungeon Under My House scope
Meanwhile, I’ve been slowly plodding along with The Dungeon Under My House (TDUMH), and I recently decided to figure out just how much work is left.
You might be thinking: wait, you don’t know?
No, I don’t. No one really knows how big a project is at the start. You can pretend to know, but often your initial project plan misses things, sometimes very big things, and so you find yourself working on things you didn’t know you would be working on.
So my approach to this project was to try to identify some major features upfront, but also to be flexible enough to handle the addition of new features as I recognize their need.
As you may remember (since I bring it up a lot!), I’m a very, very part-time indie game developer. Between family, a day job, and other obligations, I only spend so much time on game development.
On average this year, I have done around 7 hours of game development in a week. Some days I do multiple hours, and some days (usually weekends) I do almost none. Even some weeks have very few hours while others have more to make up for them. In other words, my productivity is uneven.
As much as I would like more time to work on game development, I currently can’t see sacrificing other priorities in my life to make it happen. Given my capacity, I’ve found my plodding efforts are fairly sustainable. I feel like I could keep up this pace forever.
However, I know this project has been in development for a very long time. At least, calendar time. The actual amount of time spent working on it probably works out to a bit over 650 hours, although I don’t keep track of time spent on individual project, so any chunks of hours working on my previous game updates aren’t separated from these numbers. But most of the time is definitely focused on TDUMH, so let’s pretend 650 is a good rough number.
If this was a full-time effort for me, 650 hours works out to a little over 16 weeks, or ~4 months. That’s not bad. Another 6-8 months, and I can this project being not only finished but also highly polished.
But since it isn’t a full-time effort, those 650 hours are spread out over 20 months. I’ve spent 20 months of my life on slowly adding features and creating the game content to take advantage of those features, and I don’t have a game anywhere near releasable.
When I started this project, my intention was for it to be a six-month project. Not a six-month full-time project. A six-month project at my current game development pace.
It’s not great being 20 months into a six-month project with no sense of how many months are left.
So when I wasn’t working on iOS SDK build updates, I was spending time trying to identify all of the remaining work for TDUMH. I’m not finished with the scoping work yet, but I can say that there is quite a lot left to do.
Once I get a much more solid sense of it, I can make a decision about the future of TDUMH. My goal is to release games more frequently than I am, stay tuned!
Thanks for reading!
—
Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!