Exploring Game Development with SwiftUI: Part 1 - Emergent Narrative through Coding

I thought I would start chronicling my coding experiences in a blog. That way I can think through what I am currently working on and also keep track of the various projects I am involved in.
I recently replaced my 2019 MacBook Pro i9 w/ AMD to a 2025 MacBook Air M4. I got a blue one. Night and Day Difference! But more on that for a later date which will include a short story of how I spilt coffee all over its keyboard on day 2…
I decided to start working on a game using Xcode/Swift[UI]. Here are some thingsSome things I have found interesting so far..
Functions Triggered by Events not by Loops
SwiftUI is a Departure from the Init() → Update() programming architecture that I am used to when working on games (all done in C/C++ with an allergic reaction to OOP).
I am used to structuring and understanding the operation of a program happening in a sequence; line by line happens starting with initialization and later on game stuff happening inside of an update loop.
SwiftUI is a bit different. When first opening up the default application, I tried to find where the update loop was happening. But this isn’t how SwiftUI applications operate. Instead, functions are triggered in reaction to certain events happening. When some action occurs within the application, the application will only then execute a function.
While there are ways to make an update loop using Timers, I want to take this time to embrace this new way of doing things. Eventually, some logic will likely have to happen in an update loop, but I’d like to see how far and where this different style takes me.
That question of where this will take me leads me to my next point…
No Fancy Rendering Stuff to Occupy Time
SwiftUI coding is providing me an opportunity to examine gaming principles without having to spend too much focus on rendering/visualization. When working on a game, I find myself getting so caught up in the tech/code/setup of things that it leaves little time or energy to create actual gameplay.
I was reminded of this point when recently talking with a game dev friend of mine about common roadblocks to making games some people experience.
Not focusing on those technical things is something I loved about the first Game Jam I ever participated in. It was an Interactive Fiction game jam hosted by Dallas College’s Game Dev department. I used Ink/Inkle
which provides a very bare bones structure of making an interactive fiction story. I worked on this very early on in my game dev journey and I fondly recall the freedom and excitement I felt when exploring where and what the player would experience based on very simple rules.
‘If the player chooses A, then they can do B; else if the player chooses X, they can do Y.'
This simple structure is at the heart of what a game is. Remembering this and finding ways to get back to this method may help me to find interesting or emergent narratives that come from programming.
Anyway, here’s the project so far. I’m thinking of making something of an idle tapping game mixed with some resource management stuff that somehow tells a story.
SwiftData
When starting a new project in Xcode, the user is presented with a few options on the initial structure of the application. This includes the language (Swift, Objective-C), the interface (SwiftUI, Storyboards), and something I haven’t quite seen before Storage. Storage had something called SwiftData so I figured i’d give that a shot. For this project, I selected Swift, SwiftUI, and SwiftData. Why not use Swift for all the things, right?
Xcode opened the project and I ran the default application. What appeared was a really easy to use way of storing data related to an application after the application closes. I’ve spent weeks creating a JSON parser for my own engine (Zayn Engine which I will discuss at another date).
Fairly straightforward UI for this so far. The data persists even after closing the application which is neat. I have the Sidebar View, Content View (split into 3 Item data on top and a console/dashboard on bottom), and an inspector view. A lot of this design is inspired from Xcode’s structure.
I hope that moving forward with this project will bring me back to my initial days of my Game Development journey when I was first struct by that magic feeling of creating a story based on the structure (and hopefully limited friction) of my coding environment.
Let’s see where this goes!
Subscribe to my newsletter
Read articles from Adam Socki directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
