Category: Programming

The High Castle Challenge: One year later

In March of 2018 I accepted my wife’s challenge to publish an app in the App Store by the end of the summer, and I began porting my browser game High Castle to Swift and iOS. As of May, 2019, there’s good news and bad news.

The bad news: The end of the summer came and went, and the end of the year came and went, and I didn’t publish the app. Almost half of 2019 has gone by and I still haven’t published the app.

The good news: Even though the app isn’t published, it’s about ninety percent finished.

More good news: I learned a lot about Swift. Like how to compile and run Swift programs from the command line and how to work with JSON, and the differences between classes and structures. It’s one thing to read books and articles about Swift but it’s another thing entirely to implement a decent-sized program. I started by writing a model (as in MVC: Model View Controller) with a simple text user interface that runs from the command line. Then I hooked the model in to an iOS app.

Even more good news: After porting the game from JavaScript and HTML to Swift, I started work on a Java/Android version. As with the iOS version, I started by porting the model to Java. Porting the model from Swift to Java went faster than porting it from JavaScript to Swift, partly because I’m a lot more familiar with Java than I am with Swift, and partly because I had already figured out how to set up the command-line user interface.

MVC
The other thing that helped with the Swift-to-Java conversion is that I had a well-defined Swift model. I think I did a reasonably good job of separating the view and the model in the original JavaScript version, but there were still some things I had to figure out about exactly what should be in the model in Swift and how it should work. It also helped that Java is closer to Swift than Swift is to JavaScript, particularly in terms of types.

Web views
Web views have played a big role in the High Castle Challenge. The original JavaScript version used HTML and CSS for the entire user interface. Since iOS includes a web view component, I had three basic choices for the iOS version: use web views for all of the GUI, don’t use web views at all, or take a hybrid approach and use web views for some of the GUI but not all of it. I went with the hybrid approach.

There are two big advantages to using web views. The biggest advantage is that the JavaScript, HTML, and CSS used in web views can be used in all of the different platforms: the original HTML5 browser version, the iOS version, the Android version, and the JavaFX version. That means that once I have finished porting the model to a new platform, a lot of the work has been done because I just need to copy the JS, HTML, and CSS to the new app. Setting up the bridge between the native code and the JS code takes some work, but presumably that only needs to be done once for each platform.

The other advantage of web views is that it’s much easier for me to get things to look the way I want them to with HTML and CSS than it is with native GUI systems. I’m not an expert at web design, but I’ve done enough with HTML and CSS to know my way around and I can usually get things to look the way I want them to look. On the other hand, I don’t do a lot with GUIs on the mobile platforms or JavaFX, so anything beyond a basc screen can take a lot of time, be very frustrating, and still not end up the way I want it to be.

JSON
I used JSON a lot in the original browser version of High Castle. The board game version of High Castle uses a lot of cards, and JSON is a convenient data format for the cards. It goes without saying that JSON is extremely easy to use in JavaScript code. After all, the JS in JSON stands for JavaScript. JSON isn’t quite as easy to use in Python, but it’s still very easy. Swift and Java are another story.

I won’t go into all the messy details here, but the bottom line is that it isn’t conceptually difficult to work with JSON in Swift and Java, but it can be tedious, and I ended up writing a lot of code. Sigh.

What’s next?
In this post I’ve discussed a few of the main things I’ve had to figure out for the High Castle Challenge. In the coming weeks and months (and years?) I plan to write about each of these topics (MVC, web views, JSON) and others in a lot more detail and include plenty of sample code. Will that actually happen? Considering my past history of writing and posting articles, I’d have to say the chances aren’t particularly good. But I’m going to try. It’s all part of the High Castle Challenge.

The High Castle Challenge

This is the story of a game called High Castle, which I started making back in the summer of 2011 while on a trip to Mesa Verde with my family. While driving home from Mesa Verde I talked to my family and made a few notes about the game. Inspiration for the game came from a computer game called Heroes of Might and Magic II, although that might not be apparent. It also draws a little bit from Search for the Emperor’s Treasures, a board game that was published in Dragon magazine a zillion years ago.

On returning from Mesa Verde I started work on a board game. I drew the board and did some work on the cards, but I don’t think we ever played the board game much. Instead of continuing work on the board game, I started making a browser-based game with a tile map. Unlike the board-game version, the web game got a lot of play time, at least from me. It works well as a single player game. I don’t win every time I play it so it’s fun to win, but I win often enough that I don’t get frustrated.

Fast forward five or six years (I’m not sure when I finished the browser version of the game) to a time a few weeks ago when I was talking to my wife, who said (not for the first time) that I should publish an app. I’ve been thinking about doing that since about 2010 when I first started iPhone programming, but I’ve never liked Objective-C, and all the good app ideas were taken, and I didn’t have time… For one reason or another I haven’t managed to do it.

The time has come. I’ve accepted my wife’s challenge to publish an app by the end of the summer. Five months to write and publish an app. The app I’m going to publish is High Castle. It’s a fun, single-player game that works well on an iPhone (which I’ve tested with the browser version). The game design is done and I have working JavaScript code to refer to.

Of course, going from JavaScript, known for its casual (at best) approach to types, to Swift, which is known for its obsessive approach to types, is definitely a challenge. No more slurping in an object from a JSON file and sticking it in an instance variable. In Swift reading in a JSON file can be tedious, and Swift dictionaries are as picky about types as any other part of Swift, so I’m defining lots of structs and classes. But, I’ll get into the more technical parts of it in the coming weeks and months, because as I delve into Swift I’m going to write about it in my blog and post reference materials elsewhere on my web site.

It will be fun. It will also be a whole lot of work. Stay tuned.

Swift

For the past six years or so I’ve been programming apps for iOS and Android. I’ve never published anything in the App Store or Google Play, but it’s been interesting and fun.

I learned Java in the mid nineties when it was still new and have been programming in Java ever since, so using Java in Android apps has never been an issue. The iOS languages are another story.

First there was Objective-C. I’m good with the C part, and it was nice that Objective-C was a superset of C instead of being a kinda-maybe-sorta superset like C++. The problem was the things that they added to C to get Objective-C. I don’t like all the nested brackets or trying to remember when I can use dots or when I can’t.

Despite the brackets and other quirks of the language, my biggest complaint with Objective-C was that it had limited use. Other than iOS and Mac apps, there didn’t seem to be much use for it. Not only that, but it was easy to play around with and try things out.

Then Swift came along. Xcode playgrounds provided a way to try things out, which was a good thing. Some aspects of playgrounds aren’t intuitive to me, but they are a step in the right direction. Even so, I still felt like I didn’t have a good way to learn the language. The problem is that a lot of mobile programming is about learning to use the APIs, and I always ended up learning just enough Objective-C or Swift to get by, rather than learning the language well.

For me, the best way to learn a programming language is to choose a project that I’m interested in and then use the new programming language to implement that project. I decided it was time to do that with Swift.

The project that I chose is an adventure game. (The adventure game itself is a topic for another post, so I won’t say anything more about it here.) Although I would like to make an adventure game that’s a mobile app some time, I wanted to focus on Swift rather than the iOS APIs, so I decided to make a command-line program. I’d never tried writing that kind of Swift program before, so I started searching the Web.

One post I found was this tutorial on raywenderlich.com: Command Line Programs on macOS Tutorial I wanted to write a command-line program and it’s a good tutorial, but the first thing it says to do is to start up Xcode. I am not a fan of IDEs. Maybe that comes from being an old-school programmer. (I learned how to program when dinosaurs roamed the earth in the mid seventies.) I put up with Xcode when I’m writing iOS apps, but I did not want to use it for this project. I wanted to write my code in Emacs, not Xcode. (There’s that old-school-programmer thing again.)

I continued my search and found this: Scripting in Swift Is Pretty Awesome Yes, it does have a screen shot of making a Command Line Tool in Xcode, but then it talks about putting a shebang line (#!/usr/bin/swift) to run things from the command line. That’s what I was looking for: no IDE required and a shebang line just like I can do with Python.

The author of the post mentions Python near the beginning of the post, which caught my attention because Python is my favorite programming language and has been for a long time. There are some things in Swift that are reminiscent of Python: No semicolons at the ends of statements, and no parentheses on conditions, to name a couple of syntax things. Swift does use braces rather than using indentation the way Python does. That’s fine by me because I like Python in spite of the whole indentation thing, not because of it. Like Python and JavaScript, and unlike Objective-C (at least the early versions), writing a dictionary literal is quick and easy. That’s a big thing for me, and is the reason I use dictionaries all of the time in Python and JavaScript but only use maps in Java occasionally.

I started to wonder if maybe in a few months I would have a new favorite programming language. Could it be? Alas, no. (Actually I probably shouldn’t say “alas” because I’m not particularly interested in finding a new favorite programming language.) Swift has some nice features, but there’s a problem that I ran into when I started writing my adventure game (which at this point is still pretty short).

In a word, that problem is “Foundation”.

You see, when you use the Swift interpreter from the command line, you can’t use frameworks. I didn’t think that would be an issue, but then I started to do things that any respectable scripting language should be able to do blindfolded with one hand tied behind its back. Things like splitting up a string or trimming extra white space from the end of the string. You can do those things pretty easily in Swift, as long as you have the Foundation framework. (Yes, there is a split global function in Swift, but it’s changed, and it seems to require the use of closures, and seemed a lot messier than it should be.)

The Krakendev post tells how you can use the Foundation framework in compiled command-line programs. It’s relatively painless, especially if you use make files like I do. (Did I mention I’m an old-school programmer?) But that’s only for compiled programs. It’s not like compiling a program takes a long time (although that was the motvation for the Krakendev author looking for a scripting language) but it is an extra step and it’s a big step away from the basic idea of scripting languages.

I’m still working on my adventure game project in Swift. Overall, I like the language. It’s possible that at some point a question about how to split a string might not cause arguments on Stack Overflow with 17 different answers (and counting?) to a question, but for now I’m resigned to using Foundation for my “learn Swift” project and sticking with Python as my favorite language, scripting or otherwise.

Here are compensated links to amazon.com for the Big Nerd Ranch guides to Swift and iOS programming:
Swift Programming: The Big Nerd Ranch Guide by Matthew Mathias and John Gallagher
iOS Programming: The Big Nerd Ranch Guide by Christian Keur and Aaron Hillegass