2019 - State of the art
stuff
stuff
In the end 2017 got a little derailed by an number of emails pointing out that our Torino iPhone application had stopped working. On further inspection it turned out that NASA had updated their Close-Approach database from basic HTML (that needed to be crawled manually) to a more modern API based around JSON. Originally written in 2013 using Objective-C and having long since moved onto Swift and C# it quickly became apparent that we had a problem. As a consequence we decided to rewrite Torino using Swift 4 and the latest JPL Close-Approach Data API whilst also redesigning the UI and graphics to take full advantage of the iPhone X and its Super Retina HD display.
Unity development however did not get missed out altogether, we actively continued our evaluation, completing two games "Jumper" and "BadSprite" in addition to a number of internal tests. So successful were our endeavours that during the final quarter of the year we took the decision to officially adopt Unity as our in-house tool of choice with the purchase of our first Unity Plus license.
Now that Torino 2 is complete and back in the App Store we can once again turn our attention back towards game development. The plan for 2018 is to learn as much about Unity as possible and focus on producing a number of prototypes to quickly iterate game ideas and hopefully discover something amazing.
Lunanaut is still in development, we are happy with the design and art direction but given the fragmented nature of 2017 and our adoption of new tools we need to dust off the old project files and reevaluate where we are at. 2018 is going to be a fun year, finally we are at a point where we can focus all our efforts on game development.
2016 turned out to be a year of change, we waited patiently until WWDC to see if Apple would make any changes to SpriteKit, but were ultimately left a little disappointed with the presentation and the pace of development. An additional concern beyond the pace of development was that SpriteKit limited us to the Apple platform and restricted us to only developing 2D games. Over the course of the year we started to become aware of two important issues which both have the potential to impact our game development going forward. The first of these was triggered by the rather shaky couple of years that SpriteKit has had, its not so much that SpriteKit is broken or flawed its more the way that Apple responded (or rather didn't respond) to issues with the iOS9 & iOS10 versions of the API. Don't get me wrong SpriteKit is wonderful to use, but there are a fair few issues with the API and its not immediately obvious when (or even if) Apple intends to address them.
After evaluating Unreal Engine 4 and Unity 5 we decided that Unity better matched our roadmap with its cross platform capacities and an extensive list of both 2D and 2D design tools. Unity also uses C# as its scripting language which is surprising close to Swift in terms of syntax. Given the success of the evaluation we have decided (after a lot of discussion) to move our game development over to Unity Personal. Adopting Unity has a number of advantages, it gives us access to game specific tools, advanced lighting, full 3D and cross platform support from iPhone to XBoxOne.
The plan for 2017 is to complete and ship our first Unity project. Lunanaut was initially developed in SpriteKit, but over the last 6 months we have ported many of the key mechanics over to Unity. Our first goal for 2017 is to integrate these mechanics into a unified game core that we can build on throughout the year.
At the start of 2015 I mention that there were still issues with Swift, and this was indeed the case, although we really did not expect problems with the existing SpriteKit. Problems started with the beta for Xcode 7 in early June, although Apple added a number of new gaming features to the SpriteKit API they also somehow managed to break a few critical areas that had previously worked well. We have been actively working with Apple over the year to log bugs and to be fair Apple have now fixed (or suggested workarounds) for a lot of the issues that had plagued us over the year.
We have reworked out current project “Lunanaut” a number of times, some areas like the new GameplayKit State Machine have served us well, others like adding Texture Atlases to XCAssets have given us no end of problems. I am happy that we are now on the right track, a lot of what we did in 2015 was developing methodologies and creating workflows that should serve us well for years to come. Also one aspect of indie development that you don’t quite comprehend when starting out as a solo developer is that you are doing everything, writing code, designing gameplay, producing sounds and creating graphics, although hugely rewarding its a lot of work over a very diverse area.
The plan for 2016 is to complete “Lunanaut” whilst at the same time developing concept testbeds for future projects. I also plan to enhance our understanding and ability with Swift, although I now feel completely at home with the language Apple is constantly tinkering, Swift is a living language and that quite often means that new releases are not always source compatible with older (or even current) projects. Its going to be a fun year, in the last 5 years mobile games have gone from simple 1980s style games to near console quality. Currently there is no sign of this trend stopping, as the power of mobile hardware increases so to does what you can do with it, exciting times indeed.
Having learned swift I am now ready to tackle our first fully Swift based game. I am aware that there are still issues with Swift and its associated compiler but hopeful that I will be able to work around these in parallel with updates from Apple.
This year marks somewhat of a turning point for Fuzzygoat, as a company we now have a solid focus on games development, a new development language and new development machines on order for mid january. Since 2009 we have diversified from a 100% visual effects (3D modelling, animation and rendering) based company to a 100% software development based company. Up until now our focus has been to learn the required tools and attempt to release applications that at the very least cover our costs. The focus for this and future years is to design and release games that return a profit, our next two games are already well into their design phase with initial development and prototyping already underway.
Back in July 1985 whilst working as an apprentice carpenter I sat in the Nelson (Lancashire) public library reading Zzap64 Magazine, that particular issue featured an article called “Diary of a game - The birth of a Paradroid" by Andrew Braybrook which charted the trials and tribulations of developing an arcade game for the Commodore 64. Ever since that day I have been intrigued by the notion of writing my own game and this year I am going to put all our resources into making it happen. Seven years at university studying computer science, fifteen years doing visual effects for movies, three years and 3 published apps in the App Store and I am now ready to pursue that original dream
The Sprite Kit Framework from Apple is still in its early stages, after all it was only released at WWDC 2013. However my early tests have all been positive and I am sure at this early stage we can craft our game around any issues that might prove to be show stoppers for game developers with a more rigid game design. The working title for our first game is Shard, we already have a lot of the basic design done although we will refine this as we develop new technologies and better understand the nuances of working with this new framework. Shard will act as a prototype platform to cut our teeth, we want to get a full but simple game fleshed out and working so that we can quickly identify any problems or constrains (particularly with Sprite Kit) prior to starting a more ambitious second game project later in the year.
Last year was a busy year, I learned a huge amount, but Core Data and Grand Central Dispatch took way more time than I originally anticipated to research and implement. The core design and implementation for "Torino" is pretty much done, I just need to do a few finishing touches before adding all the fancy graphics needed to make the data easily accessible and visually interestng.
2013 is going to be a very hectic year, the iOS learning curve is looking more of a gentle slope and less like the imposing vertical wall that it did three years ago. There are still a lot of APIs that I need to master, not to mention all the new stuff that Apple adds at WWDC each year. But the upshot is that I am starting to understand the patterns and methodology behind iOS, Xcode and the various APIs and that is making each new topic a lot more understandable and far far easier to learn and implement.
The plan therefore this year is firstly to finish "Torino" and get that shipping, once that's done working towards a game release is the next priority. A game will require a substantial investment both in terms of learning, but also in terms of our pipeline, luckily a lot of our visual effects knowledge can be put to good use along with our existing 3D and 2D software, all in all that's just going to make things a lot easier and a good deal cheaper. So here goes, its time to buckle up and enjoy the ride, 2013 here we come ...
The plan for this year is to build on my previous years knowledge whilst also focusing on new areas like Core Data and Threading (See Below). The first application of 2012 will be called “Torino”, I don’t want to be too specific about its purpose at this stage, only to say that my hope is to incorporate as much new technology into its design as possible. I have again learned a huge amount this last year and I am hoping that I can put this to good use in the coming year whilst also expanding my knowledge in areas where I am less familiar.
Core Data: allows applications running on iOS (and OSX) to efficiently store an object graph in a persistent backing store. Implemented property Core Data can reduce memory overhead, increase performance and vastly simplify the development of applications with none trivial data storage requirements.
Threading: refers to handing off sections of code to an alternate thread (effectively creating a new path of execution through the application’s code) allowing the new thread to concurrently execute code in parallel with code executing on the original main thread. Although threading does have a relatively high cost in terms of memory and performance (e.g. allocating new memory and interacting with the system kernel) it does offer a number of advantages particularly in areas where interaction and responsiveness are important as complex or time consuming tasks can be spawned off the main thread. The A5 processor (iPad2 / iPhone4S) introduced dual processor cores, along with mounting evidence that the A6 processor (iPhone5) will introduce quad cores. Adding multiple cores to a CPU effectively adds multiple independent processors, each capable of concurrently reading and executing program instructions (i.e. a thread).
The last year turned out to be very eventful. I coded and released our first iOS application, Apple released the new iPhone4, a new iPhone OS and a new preview version of their development IDE Xcode4. The plan for 2011 is to expand on material learnt last year in addition to developing 2-3 new applications for submission to the iTunes application store.
The first application for development in 2011 is the CoreLocation based "Bear Trails", followed by a more in-depth look at the other iOS core technologies. Ultimately I would like to start looking at games development but that is a long term goal for now.
Now that I have a better grasp of Objective-C and the Apple foundation library the plan for the early part of 2010 is to expand my knowledge more into Cocoa and iPhone development. Currently I am working through "Beginning iPhone Development: Exploring the iPhone SDK" by Dave Mark, so far so good, the rough plan at this stage is to learn the ropes and get a simple app setup by around March (2010). Once thats done I will join the iPhone Developer Program (Standard) then I can start testing on the iPhone itself.