iPhone Application Development
July 12, 2014
I have decided to cut out SpriteKit for collisions and use it only for rendering. In place of SK Physics, I will reimplement the physics and collision system from the Objective-C engine. I am taking this opportunity to refine my algorithm and make some necessary optimizations.
July 2, 2014
I have revised the entity class and added a component getter that uses Swift generics to eliminate the need for type casting the result. This will lead to more concise code in most cases, and makes it less likely for us to make mistakes when using the engine to build a game.
July 1, 2014
In my last post, I discussed how I made SpriteKit work with the Entity-Component-System approach to game development. I was not particularly pleased with my solution, so I have revisited it and come up with a slightly better way to integrate SpriteKit.
June 25, 2014
In the Swift engine, I want to use Apple’s SpriteKit for rendering and physics to decrease development time and increase engine efficiency. Unfortunately, SpriteKit is not particularly well-suited to the ECS architecture. I had to come up with a solution that would allow me to leverage SpriteKit without breaking the ECS paradigm in the process.
June 7, 2014
I’ve finished reimplementing the framework and a couple of the basic systems using Swift. I’m replacing my renderer, physics, and collisions with Sprite Kit, but I’m taking pains to make sure that I don’t break the entity component system paradigm.