Need help? Want to contribute? What to see a feature? Email me.
Download the app here
When Homeworld first came out, there was an application called the Ship Viewer. Using this tool you could view individual ships – rotate them, change colors, and view the game-lore of how these ships came to be. Of course, this didn’t exactly show up in the subsequent Homeworld Cataclysm, Homeworld 2, or Homeworld Remastered release – so I took it upon myself to make the modern day equivalent.
So I took on this project for a number of reasons – other than the sentimental reasons mentioned above. Here I got to experiment with VIPER – a design pattern that I had read about and something that had popped up back in 2013. This design pattern involved several more objects outside the MVC paradigm that each held a specific purpose:
- View : Display labels, text fields, etc
- Presenter : Handle the cleaning / formatting of content in the view
- Interactor : Handle the business logic of the application
- Data Manager : Retrieve objects from various data sources
- Entity : Store object information
- Router/Framework : Ties everything together by associating each part
Of course, while this results in a bit more boilerplate – dividing up the application into specific functions does indeed (as I experienced) have the effect of making leaner ViewControllers. Actually – an outcome of implementing VIPER was twofold. On one hand, the ViewController becomes leaner, but you also end up adopting MVVM (Model, View, ViewModel).
In addition to VIPER – this project was also my first formal foray into Swift development and using Swift conventions for code. Needless to say, Swift is a lot nicer than Objective-C, not only in syntax but also in flexibility and clarity. It also exposed me to a number of Swift-specific tools that have grown out of the community to address some of what the classic Objective-C libraries would do. Of note:
- AlamoFire instead of AFNetworking
- Carthage instead of CocoaPod
The net effect? AlamoFire syntax is a lot cleaner than AFNetworking, needing less boilerplate and using closures to keep your code tight. Carthage? Well, as a dependency manager it really shines for not messing up your XCode Environment. It keeps your packages outside the project – which is good because XCode Interface Builder feels a lot more brittle with the Swift 1.2 release, and messing around with the project settings when using CocoaPods seems to completely destroy your Storyboard.
Finally – I was exposed to SceneKit for the first time, learning about nodes, lighting, positioning, and animations. It also helped me learn some nuances about SceneKit, specifically the dynamic loading of models into a specific Scene (which turns out to be not so trivial!).
All in all – a cute little project.
Want to join the discussion?
I do not own any of the creative content in here other than the application itself. Below are the original owners of all the creative content and assets:
- Ship Meshes and Textures: Gearbox and Relic
- Ship Descriptions and stats: Encylopedia Hiigara, Homeworld Shipyards, Relic & Gearbox