Yan KalbaskaFollowBetter Programming--1ListenShareGoing back to game development, I created a simple prototype using the LÖVE Framework. LÖVE is a minimalistic game framework and not an engine, as e.g. Unity is. The main drawback of Unity for me was a very limited palette of game mechanics supplied as a WYSIWYG editor.My goal was to create a working iOS device prototype each week. It was not following any strict architectural patterns, I had no prior experience with the Lua language (and its limited OOP support), and I was mastering it along the way. After I had a working game in 2 weeks, I rendered some of my own feedback for improvements as well as showing the game to others. Ideas were competing in my head, and I wanted to keep the speed of iteration with a growing codebase. That’s how I ended up adopting Uncle Bob’s clean Architecture concept in my game.I experienced a few “aha” moments while trying to draw class dependencies and separate the layers. Coming from the background of rigid UIKit on iOS, it took me a while to rethink how independent layers fit into boilerplate app code or a non-engine-based game. Those might come naturally to you after reading the original piece, but along with the minimalistic full-cycle app (see diagram), I wanted to highlight those as well.I intentionally stripped all the game-specific classes from the diagram and only left the necessary life cycle events to understand the flow of control and instance creation. For example, there might be many more connections within each Layer, there may be a separate timer (for me the default LÖVE timer event worked), more observers than the Presenter listening to game objects changed (dashed line on the diagram), and many more complexities of game design.This is in no way a final design, but also not an out-of-context demonstration of clean architecture layers. It integrates nicely into a UI framework, be it LÖVE in Lua or UIKit in Swift. More than that, this integration is part of that architecture.It will all work together, and it starts with the framework action, not the game engine. See how in the diagram it all starts with love.load callback, similarly application: didFinishLaunchingWithOptions: on iOS.While coding iOS games and apps, I always wanted to separate my code from boilerplate UIApplicationDelegate and UIViewController methods. This is not the intent. If designed correctly, core layers (Use cases and Entities) will never know about the specifics of UIKit or LÖVE callbacks and can be easily ported to different platforms. The UI Framework layer is, on the other hand, the closest to user interaction, and as such is the most constrained by the hardware and least reusable.And each of them has a clearly defined purpose that makes it easy to keep the code in place. All four layers contain the code of your app. Framework provides UI, Presenter implements specific user interaction, including its visual / motion component, which is a very important differentiator for a game, Use case serves complex interconnecting rules, and Entities provide building blocks, containing encapsulated logic. At the top of the diagram above you can see an unambiguous description of layer responsibilities. The only obstacle to using those — is Lesson #3.It’s okay to reference and own objects within the layer as soon as they serve the same layer purpose. This is an easily reversible choice. It gets more complex as you cross-layer borders. This is where you should follow the dependency rule and design interfaces appropriately. In the end, it will provide the main benefit of clean architecture — maintainability of the codebase. Although this concept is key to clean architecture and many other architectures, it was not the purpose of this article to re-explain it.Spend time understanding those. No OOP is magic and just works. Behind the scenes, there is always a service, daemon, loop, dispatch queue, or notification center running and registering listeners that can respond to events and messages between objects. If you feel that you lack that knowledge, I encourage you to learn how that is done in the framework you use, e.g. this is how it operates in LÖVE.I wanted to provide you with an overview of how clean architecture can be applied to programming a game and help you avoid the complications I faced while doing it from scratch. There is much more to explore, including various GUI architectures, if you are interested, but remember that there is no perfect architecture, there is only one that solves a specific problem.UPD: This article is a part of the series on game development. In addition to this guide, it has a full primer on object-oriented programming in Lua. It also includes public domain GitHub repos: a template repo to create iOS game (little to no experience needed) and a minimalist game engine (intermediate/advanced coding proficiency) you can use as is or fork and modify to your needs.----1Better ProgrammingDigital Product VisionaryYan KalbaskainBetter Programming--Dmitry KruglovinBetter Programming--48Benoit RuizinBetter Programming--122Yan KalbaskainBetter Programming--Nick Samarin--Ryan Saunders--Ratic--Simon Nordon--1PoutinePapi--Dmitry KruglovinBetter Programming--48HelpStatusWritersBlogCareersPrivacyTermsAboutText to speechTeams