Swift in the development of video game
About the project “Birdie’s Dream”:
The project is huge: it takes ’26 min’ to compile the project on Intel i5 Macbook Pro with 16GB main memory. And the project contains 289 swift source files and 24,147 other files.
And it has also partly Object-Oriented Design (OOD) in some parts but mostly designed in the protocol value-oriented design plus partly the functional reactive design as well.
The Recent Trend from Machine Learning Framework, Google’s TensorFlow and Fast.AI:
Two years ago, Google started working on making Swift the first mainstream language with first-class language-integrated differentiable programming capabilities.
And according to the blog by Joaquín in MACHINE LEARNING
Python is by far the most used language in machine learning, and Google has a ton of machine learning libraries and tools written in it. So, why Swift? What’s wrong with Python? To put it bluntly, Python is slow. Also, Python is not great for parallelism. To get around these facts, most machine learning projects run their compute-intensive algorithms via libraries written in C/C++/Fortran/CUDA, and use Python to glue the different low-level operations together. For the most part, this has worked really well, but as with all abstractions, it can create some problems. Let’s go over some of those.
Swift is very strong and robust in parallelism and asynchronous applications. Not that but also safer language from both coding and design bugs than modern languages only equipped with objected-oriented-programming (OOP).
Yet, It is called a protocol-oriented language which I love to use for making a game.
Protocols, values, functions in Swift are much safer than classes with complicated object-oriented graphs: not only warding off side effects of OOD but also better in reusability in conjunction with generic.
I don’t dive into the deep fully here: doing so, only a limited number of people can read this article.
More about Swift in the development of video game
More Technical Part1
Looking back 9 years ago, as of 2021 March, all my searches about “Grand Central Dispatch (GCD)” for asynchronous programming (multi-threaded programming) reveal internet articles dealing with an elementary introduction. And this pattern hasn’t changed today even after the introduction of the Swift language.
Swift language adds more safety against memory leaks. On top of this, it rescues the complex project out of unexpected behaviors which may be caused by the infamous object-oriented-design. This mention may have you surprised, for these days Java, Javascript, C++, C# are still popular. And Unreal Engine and Unity are all based on C++ language.
After fully understood it, I found that Apple’s Dispatch framework is an amazing place to start with.
However, there is a catch.
Without enough understanding, your Swift code employing GCD will face serious memory leaks or data races.
And in the public domain, almost nobody knows that the target queues come to the rescue: without adding more burdens on threads, it is perfect in balancing the loads with a proper QoS setting. But I found from the internet search result (including the result from stackoverflow.com) that nobody knows how important it is.
Over the internet, one of the prevailing myths about the Swift language or Apple framework is the following: many misunderstood that some Apple frameworks which employ GCD under the hood may cause memory leaks or data races. ( Or, some mistakenly say that the Swift is the culprit. ) But this is a myth from the lack of experience.
In the multi-threading world, during over five years of my testings and usages, I found none of such memory leaks or data-race errors on Apple’s frameworks, GCD, Swift: memory leaks or data-race are common when the threaded codes are ill-designed.
For example, both SKTextureAtlas and SKTexture have the function
‘preload(completion
I love to use SpriteKit and GameplayKit which are performant and efficient for memory handling. When you’re further equipped with GCD, these frameworks will be your two-edged sword as a game developer.
More Technical Part2
The problem or the limit of object-oriented design (OOD) lies when the project grows large enough not to know what the side effect of the inherited class shall be under heavily crowded class design.
The protocol and value-oriented design in Swift language will come to the reuse in this case. And this is common in the design of a game. Because the design of the game should be subject to change over a long period of time as the nature of the game design is. It should evolve over time! Otherwise, any game without such great adaptability can not survive in the current competitive market.
Some latest, innovative frameworks like SwiftUI. Combine impose the functional reactive paradigm of programming, which is different from the object-oriented one that prevails in the iOS development community and all software development communities alike. This approach of a software system is more robust, more resilient, more flexible, and better positioned to meet modern demands. See Reactive Manifesto for more information.
In this, I’m surprised at the slowness of the game industry in accepting Swift and the “protocol and value-oriented paradigm” which should solve such long-held problems.