So, almost two weeks on from the last posting, here’s where Dexterity Design are right now.

Aaron has stopped messing with maze testing and tinkering with asteroids to help out with my little project. He’s now neck deep in iDef code again doing the conversion into SpriteKit. This is being done because conditions can be set in Swift source code to compile certain sections of code only if compiling for a particular platform which gives all sorts of power to bring it to more people.

As an example Swift, at present, has the ability to develop OSX applications (not something we’ve even looked at, as yet), create IOS games (be it Ipad or Iphone / both) but the platform is now open source. This means it’s likely in future that someone will bring out exporters for Xcode to compile binaries for other platforms such as Android or Windows. I’ve touched on it before but I’m skirting over it again so I can explain a bit better about the compiler directives I mentioned earlier.

If you write a game from scratch and decide you want to use it on say both an ipad and run it on your Mac desktop then now it’s possible to do something like:-

#IF OSX

run code which displays the game screen in a format which is Mac friendly.

read the keyboard and process the game flow accordingly.

#EndIf

#IF IOS

run code to display the screen in a format which Ipads/Phones work.

we don’t have keyboard on our ipad/phone so run code which pops up the screen keyboard instead and takes input from that. Or look for touches in areas to read controls from the player.

#EndIf

It’s not exactly like that but it gives you an idea how the system actually works. So your one project is all you need to work from when you’re doing stuff later on such as bug fixing, adding new features, or whatever. All the specifics for each machine is handled in structures like this. A huge time saver when you don’t need to do the same fix in all of the source code for each platform. Which may or may not have been the case as each one might have been written from scratch and have different things to fix otherwise, as well.

Now it’s not saving you all the work because you still have to write the code that needs to be written to get it running for all the platforms but how much code would you not need to rewrite as it works for most of your project? Maths functions are a good example, as are AI routines possibly. It will obviously depend on what the game is all about and how much has to be wrapped in directives accordingly, but it’s something that will be used more and more as we go on.

It probably actually already has by others but I wanted to post about it as it’s pretty new to me. All those games out there that you’ve played that you know have been on mobile first don’t look much different on your flashy PC, right? Maybe because they’re reusing a lot of the code and just a different graphics engine that will work on that machine. SpriteKit will work for both Mac and IOS but not for something like Windows and it may never do that. So a different graphics system is needed for both those platforms if we release for them. And that’s still assuming that Swift does get some kind of exporter to shunt the code across even without SpriteKit.

As for what I’m up to then I’ll update on that later on when I’ve got a little bit further on with the project so I can go over my development process on the new language a bit better.

Thanks for reading and, as ever, please keep an eye on the website for updates.

Tony

Categorised as: Development | SpriteKit | Swift