Thursday, October 28, 2021

Making Word Share for SharePlay

Word Share is a "swipe the letters to make a word" game that is based on a popular genre on the App Store. I decided to make a version of this game that would work with Apple's new SharePlay feature.

It requires iOS 15 and above as it uses new SwiftUI features, and of course, SharePlay which are exclusive to the new iOS.

You can download Word Share for free on the App Store.

Word Share game play

Development Time

The game had a relatively short development time. I started building the game on the 21st of July 2021, a few weeks after the 2021 Apple Worldwide Developers Conference, and shipped it on October 27th, 2021. Development time was 98 days from conception to being on the App Store.

The project was a part time effort, with the actual working days spent on the project totalling around 18 eight hour days. I have a full time job, so work was done after 8pm every night. I also have a number of projects on the go - so I often switch between projects depending on the state they are in.

Design Goals

I wanted to make Word Share as minimal as possible.

One thing I noticed with a lot of competitor word games is that over time their UI has become cluttered. A typical competitor screen can have:

  • Daily bonus claim button
  • Social standing statistic (eg. Solved by 25% of players)
  • Currency counter and buy more currency button
  • Shuffle button
  • Use a hint button
  • Special power up button
  • Word definition button
  • Quest status button
  • Watch video for currency button
  • Banner ad

Below are some example screenshots.

Word Cookies example game screen

Word Trip example game screen

I added only what was necessary. 

Monetization

Word Share is a free game supported by ads.

I did debate over wether I should have a banner ad. For Snappy Word they account for  around 8% of revenue, which is still a reasonable amount of money. I decided to not have banner ads for a less cluttered screen. 

For the launch I went with interstitial ads between levels, and rewarded ads to earn 3 hints. I introduce the ads after the player has played a number of levels, and only show interstitials if they haven't used rewarded ads.

SharePlay

This game was built for SharePlay. Apple gave a great demo of SharePlay in one of their WWDC sessions and released sample code of the demo project. This was invaluable in getting up and running.

The biggest challenge I had was trying to figure out the best way to get players into the SharePlay experience. Because SharePlay was so new, there were no other games to look to for guidance or inspiration. So I had to make up the onboarding experience myself and hope that it was to Apple's liking!

I also had to figure out how a multi-player word game would work with FaceTime. How do you identify the users to each other? What is the scoring system like? Can players use hints while competing?

I opted for a simple system. A player starts a FaceTime call and then a big button appears on the front screen letting them know they can start a SharePlay game.

I decided on 3 rounds with the highest scoring player winning the game. Scores are based on 1 point per letter for a solved word. No hints are available to any players.

In my planning I was considering adding taunt buttons to the game - but quickly realised SharePlay is built on FaceTime - so players can smack talk each other, or even help each other using video and voice.

Building on a Foundation

I have another word game on the App Store called Snappy Word. This project began as an Apple Watch launch game and I wrote about it here: Making Snappy Word for Apple Watch

I updated Snappy Word to add in a new "swipe the letter to make a word" mode to keep up with the growing word game genre in the App Store. I used this existing codebase to help give me a headstart in making Word Share.

I took the base code for showing the unsolved word tiles and handling the word building input and added it to the new Word Share project. This code is built using the SpriteKit framework.

In my previous game I had used Storyboards for all the menu and UI screens, but for the new game I decided to use SwiftUI. I've used Flutter and SwiftUI a lot and I love reactive programming. It makes creating screens so much easier!

Storyboards for Level Select in Snappy Word


SwiftUI for Level Select in Word Share

I used the same level select screen format in Word Share as I did in Snappy Word. Writing it in SwiftUI took me around an hour compared to almost 2 days it took in Storyboards for Snappy Word. Of course that may just be me. For some reason I could never get my head around Storyboard and its use of constraints, layout margins, insets and all the stuff that had to be set inside the inspector. I love being able to lay out the UI in code which is why SwiftUI appeals to me.

I wrote about SwiftUI and Flutter here: Flutter vs SwiftUI

Since writing that blog post SwiftUI has seen a number of great improvements, and I have to say that I would rank Flutter and SwiftUI as both excellent choices for development with SwiftUI edging out Flutter in terms of ease of use and code simplicity, and Flutter edging out SwiftUI in terms of platform reach. I have another word game coming out soon that has been written in Flutter - expect a blog post about it when it launches!

I have to give a big shout out to James Swiney, another iOS developer from Brisbane, Australia who helped me get my head around using SpriteKit with SwiftUI. James had done a lot of the groundwork in his game Aruna's Adventure.

Visual Style

A big part of this genre of word game is the background images on each screen. I'm an Aussie developer, so for the images I chose a bunch of photos I had taken from my trips around Australia - with many of them taken around the suburb where I live.

I'm quite lucky that we have access to a lot of beautiful beaches - so the game is full of lots of sand and inviting blue waters :-)

It's great to have these views within driving distance :-)

I also chose yellow as the primary colour in the game. It pops well agains the predominately blue and green photos I chose.

The icon was a challenge. I did attempt to create something new and original but I settled on a simple W on a yellow background. I may update this but it's hard to get a word game icon that stands out from the rest.

Creating New Content

Another thing that helped speed up the development process is that I had created tools for Snappy Word that I could easily re-use and extend for Word Share. I built a bespoke app that would generate lists of anagrams from a dictionary, checking for duplicates and offering me the ability to output in a format that my game used.

This utility allowed me to create over 400 brand new levels for launch, with another 500 or so waiting for future updates.

I plan to add new level packs regularly and address any issues found by players.

Conclusion

I had a lot of fun making the game, and while implementing SharePlay was challenging, I'm proud of what I achieved. 

It was also great to get a New Games We Love feature from Apple in the launch week!

Thank you Apple!

Please check out Word Share on the App Store and let me know what you think!

Cheers,

John






Thursday, February 04, 2021

Flutter vs SwiftUI

It's a new year and time to make a new app.

So what do I build my new app in? SwiftUI or Flutter?

TL;DR - I'm making my new app in Flutter.

I arrived at this decision by making a vertical slice of the app using SwiftUI,  Flutter and standard Swift with SpriteKit.  

The app I'm building is an update of my Brainiversity brain training game. Brainiversity has a number of small games that test your math, memory and word skills. I've been making versions of this app since 2007, so I have code bases written in C++, ActionScript and Lua. I used the existing "Add It Up" mini-game for my vertical slice.

Swift and SpriteKit

Line count: 647
SpriteKit version

This version is very similar to the original C++, ActionScript and Lua versions. It uses sprite animations to give the game zing, and everything is imperative - so the text in the answer counter label in the top left of the screen is manually updated when a new question is generated. 

I found SKAction  was useful in handling animations. This made it really easy to chain together a sequence of events like:
  1. a cross appears when the user presses the wrong answer button,
  2. the correct answer scrolls in from the right of the screen,
  3. after a pause, answer counter pulses as it counts up one,
  4. the answer scrolls off screen to the left as a new question scrolls in from the right
  5. the buttons flop over to reveal new answer values.
Compared to the SwiftUI and Flutter versions, there was a lot of code to make stuff happen, and to be honest, after making apps with reactive UI, programming this way felt old fashioned.

SwiftUI

Line count: 210
SwiftUI version

I've already made a few apps in SwiftUI so I was used to the reactive paradigm. Reactive programming results in reduced code which makes reading the code so much easier. I love how SwiftUI handle state with the @State property wrapper - it seems a lot cleaner and less code than Flutter's SetState or Provider solutions.

The use of VStack, HStack and Spacer makes it really easy to lay out the screen. Here is the code to layout the question and the answer buttons.

   VStack {

      VStack {

        HStack {

          Text("Correct: \(correct)")

            .bold()

            .font(.system(size: width * 0.20))

          Spacer()

          Text("Wrong: \(mistakes)")

            .bold()

            .font(.system(size: width * 0.20))

        }.padding()

        Text("Select the correct answer for the math equation below from the multiple choice buttons.")

          .font(.system(size: width * 0.20))

          .padding()

        Text(question)

          .font(.system(size: width * 0.35))

        VStack {

          HStack {

            Spacer()

            RoundButton(title: "\(answer1)", color: Color.red, size: width, function: {tryAnswer(button: 1)})

            

            Spacer()

            RoundButton(title: "\(answer2)", color: Color.orange, size: width, function: {tryAnswer(button: 2)})

            

            Spacer()

          }.padding()

          

          HStack {

            Spacer()

            RoundButton(title: "\(answer3)", color: Color.green, size: width, function: {tryAnswer(button: 3)})

            

            Spacer()

            RoundButton(title: "\(answer4)", color: Color.blue, size: width, function: {tryAnswer(button: 4)})

            

            Spacer()

          }.padding()

        }

      }

      Spacer()

    }

    .navigationTitle("Add It Up")

    .onAppear {

      generateResults()

      width = UIScreen.main.bounds.width * 0.3

    }


This is fairly similar to Flutter, which uses Columns, Rows and Spacer - here is the button section code in Flutter:

return Column(
children: <Widget>[
Row(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
answerButtonRound(
answer: answerList[0],
color: Colors.green,
size: buttonSize,
func: () => {_answerButtonPressed(buttonNr: 1)}),
answerButtonRound(
answer: answerList[1],
color: Colors.blue,
size: buttonSize,
func: () => {_answerButtonPressed(buttonNr: 2)}),
],
),
Row(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
answerButtonRound(
answer: answerList[2],
color: Colors.red,
size: buttonSize,
func: () => {_answerButtonPressed(buttonNr: 2)}),
answerButtonRound(
answer: answerList[3],
color: Colors.orange,
size: buttonSize,
func: () => {_answerButtonPressed(buttonNr: 4)}),
],
),
],
);

Swift code is definitely a lot cleaner to read with less nesting and less boiler plate. The child and children parameters of Flutter take up extra space and cause more visual clutter.

I hit a brick wall with SwiftUI when I wanted to chain animations together with some state updates in the midst of all the action. I could not find a way to make the question label animate away, then update the state for new questions, then slide an updated question text back on screen. The best answer I could find was to start the slide out animation with a slide in animaion, then set a timer to call my generateNewQuestions() function so it occurred halfway between the slide in and out.

Maybe I didn't look hard enough for the right way to do this, but that's currently an issue with SwiftUI documentation. There's not much of it out there. Whereas I found multiple examples and tutorials on how to do what I wanted in Flutter on flutter.dev and other web sites.

Swift Pros

  • Light weight code that is easy to read. You can do a lot with so little.
  • Dark theme just works out of the box.
  • I can target Apple Watch.
  • CoreData is nice and works out of the box with Apple devices.
  • The state system is really easy to use.
  • No semi-colons!

Swift Cons

  • App Preview is slow to update, even on my M1 MacBook Air - and I constantly had to keep hitting Resume to rebuild the preview.
  • Documentation is lacking, especially compared to Flutter. Thank goodness for Hacking With Swift - the best resource for Swift developers.
  • Can only make apps for the Apple ecosystem.
  • Refactoring is less advanced than Flutter.

Flutter

Line count: 304
Flutter version


Even though Flutter has sightly more boilerplate code to set things up, I like how everything is a widget and it's pretty consistent. You generally nest widgets within widgets - and when you go too deep you refactor out into new widgets which makes for easier to read code. SwiftUI has nesting as well, but also has modifiers which I'm not 100% sold on.

In SwiftUI to make the text bold you add a .bold() modifier.

          Text("Wrong: \(mistakes)")

            .bold()


In Flutter you add the bold as part of a parameter of Text.

                        Text('Wrong $mistakes', style: TextStyle(fontWeight: FontWeight.bold)),

I guess what feels weird with SwiftUI modifiers is that to give a screen a title, you add the modifier at the bottom of the view - so when you read the code you aren't seeing the layout as it occurs. Whereas with Flutter, you add the screen title at the top so you read the screen in the order it's drawn. Maybe I'm being picky, but I found that a little weird.

Even though Flutter is a bit more wordy, I found it a lot easier to find out what modifiers are available by simply pressing CTRL-SPACE in VSCode. Maybe there is an easy way to find out what  modifiers are available for Text() in Xcode apart from going into the Library Panel and searching (which is a pain) - but I have yet to find it.

Another plus with Flutter is that it's so easy to refactor code. Are your widgets nested too deep? Turn them into a new reusable widget by hitting Refactor and choosing Extract to widget. Want to wrap everything in a new Row? Hit Refactor and choose Wrap with row. Want to get rid of a top level widget? Again, hit Refactor and choose Remove this widget.

Xcode has a refactor option, but doesn't offer as many features. 

In terms of Dart vs. Swift - I have to admit I found them fairly interchangeable and could happily switch between the two. Most of the stuff I am using to build my apps is common across both. All the modern language features like helper functions for lists such as sort, insert, and index functions were common to both and in many cases had the same name.

Flutter Pros

  • Hot reload is amazing. Instant updates on my actual target device makes development so much faster.
  • Great documentation. Not only is the documentation at Fluter.dev awesome, but there is a dedicated YouTube channel with lots of content including the useful Widget of the Week.
  • Lots of great packages at Pub.dev. The odds are, if you need something, there is a package already available. Want to add charting to your app? There's are many packages for that.
  • There is a Widget for literally everything. 
  • Refactoring with VSCode is super easy.
  • Supports a lot more legacy devices and older OS versions.
  • Can make apps for iOS, Android, Mac, Windows and web. My website, www.redspritestudios.com is written in Flutter :-)
  • Flutter is open source. So you can drill down into any piece of code to see how it works. There is no blackbox like Swift.

Flutter Cons

  • Can't build for Apple Watch :-(
  • 2D only. So no chance of doing any activities in 3D.
  • Slightly more verbose compared to SwiftUI.
  • State management is not as clear cut as SwiftUI.
  • I have to type a semi-colon at the end of every line.

Conclusion

I love SwiftUI and have already published apps built with SwiftUI. 

But, for my new app, Flutter has the edge. It has lots of widgets, a large amount of good quality documentation, cross-platform support, and an animation system that does what I need.

More importantly I actually found it a tad faster to build my vertical slice in Flutter. This was probably due to the abundance of quality documentation helping me solve roadblocks quickly, and having a faster feedback loop with hot-reloading.

I plan to get an MVP of the new Brainiversity up as soon as I can, and I will build out the rest of the activities with feedback from users. I'll post again when it's ready to play.

Let me know if I got anything wrong, or if there is a better way of doing things.

Cheers,
John