Up until now I’ve had placeholder health bars that do their job as intended, but require a ton of manual work and take up a lot of memory. I’ve always had the goal of making the health bars work programmatically, and I finally got around to doing it. Well, version 1 at least. Have a look at how I’ve used SKShader, SKCropNode, SKShapeNode and CGPath all rendered to one final texture to make my health system work.

How do you launch a catapult, grenade, arrow, or any other projectile in an isometric world? I had to joy of figuring that out over these past two days, and I thought I would share. Before jumping in, let me point out that the code below is for my specific use case, and is not a full featured framework. So, you’ll still have to understand the concepts, but if you’re Googling for help this will hopefully get you on the right track.

Last year I wrote about saving game data in SpriteKit, and that code is now completely out of date. Swift 3 has brought about all sorts of fun changes, so it’s time for me to provided some updated code.

In case you’re wondering, game development is hard to keep up with when dealing with an infant. Now, I went into this knowing the first 4 weeks would be baby and family first. But, I secretly had hope that I would have some spare time to keep the game moving forward. Now that the first month is over, I’ve worked a grand total of:

Memory leaks suck. You know they exist, and you dread the day you have to track them down. In SpriteKit, I’ve encountered two main types of leaks. One is where the entire scene is not deallocated after transitioning to a new scene. The other is where memory is constantly being used up while interacting with a scene. For the latter, you have to use Instruments in XCode, or comb over your code, to get a handle on what is happening. But, for cleaning up scenes after you’re finished with them, here are a few tips that simplified the process for me.

This purpose of this post is to document some of the frustrations with pathfinding. I’m finding that it is too boring to try to implement every map at once, so I’m touching pathfinding every other week or so. As a refresher, the video below has served as my primer on GKObstacleGraph whenever I need to revisit pathfinding. So, if you’re a SpriteKit / GameplayKit user, you may find my approach interesting.

If you’re new to game development, you’ve probably heard of shaders but don’t quite understand them. If you’re new to SpriteKit, you’ve probably hit a few speed bumps working with shaders. Since I’m still learning more about the two, I figured it would be nice to put up a concrete example that covers cropping and effects using shaders. Specifically, we’ll cover two concepts:

When searching for tips on how to save game data in SpriteKit, most posts explain how to save one variable (high score, for example). In that regard, this Thinking Swiftly post was extremely helpful, and is where a majority of the code below comes from. I just wanted to extend that post, and look at how an entire object could be saved in a self contained way.

Cutscenes are a labor of love, so it is hard accepting that some people just don’t care. That story that took months to bring together may be amazing to you, but to others it is just an inconvenience. So, for that reason, we have to make cutscenes skippable. However, I didn’t want to just settle at skipping the entire scene. I wanted to also make it skimmable for the speed readers, or those who are mildly interested.

It’s funny how the tasks that should be easy end up consuming the most amount of time. As of this writing, there is no easy way to outline text in SpriteKit. It’s common to see approach that add a shadow node, but sometimes more contrast is needed. Here’s what I have discovered.

Those of you who follow me know that I’m working on a game that will have ~200 nodes on the screen updating every frame. Because of that requirement, I’m constantly looking at how I can incrementally improve performance. Slowly but surely, I’m making this game a well oiled machine. Today, I stumbled on a significant slow down, and the resulting fix that shaved off 16% CPU usage: caching enumerateChildNodesWithName.

I’ve been working through a particularly nasty issue, so it feels right to document it for anyone else who encounters it. Also, just to serve as a note and reminder that game development is full of unexpected, time consuming tasks on a near weekly basis. This most recent problem — releasing a build to an iOS device fails to compile, but it works on the simulator. Specifically, this occurs when I try to change the Swift compiler optimization level.

There is an awesome article on Gamasutra about Coordinated Unit Movement. They also have a companion post about implementing said movement. However, the posts are from 1999, and they deal mainly in pseudocode. Also, I’m convinced there is absolutely nothing else on the entire internet explaining the topic. So, an experienced developer may be able to read the ideas and know how to implement them, but it has been a bit of a struggle for me as a new developer. I’m going to try to document a step by step implementation of formations, squads, and movement for someone who hasn’t done it before. I’ll be writing in Swift / Sprite Kit, but the code should be easy enough for anyone to follow. I also welcome corrections / improvements from experts.

Now that I’m receiving real art for my game, I thought it would be a good time to learn about memory usage and limits. This was also prompted by my current level running at 55-60MB before any gameplay action or characters loaded on screen. That memory usage seemed a bit high, so I decided this was an issue that I needed to delve into. In hindsight, most of this is basic to an experienced game developer, but I found the process to be quite fun. You can just read my lessons learned below if you don’t want to follow my detective work.

The introduction of Swift comes at a perfect time for me. I’ve been working on a SpriteKit game in Objective-C for 10 weeks now, and some of the code is definitely in need of refactoring. Refactoring is known to be tedious, so being able to learn a new language during the process is a plus. I’ve been taking notes of any challenge I’ve come across during the conversion.

Lighting effects were curiously missing from SpriteKit in iOS7, so I’m happy to see them appear in iOS8. Here’s a quick look at what you can expect from the light source / raycasting implementation.

I hated school. I hate technical books. Generally, I feel like I can learn faster with the unstoppable trio of myself, Google and wonderful online communities. The trouble with game development is I don’t know what questions to ask. In web development, I can search how to make two elements sit next to each other and find what I’m looking for. In game development, I wouldn’t have looked for a finite state machine, much less double dispatch for physics. I may be late to the party compared to other developers, but I’m finding myself humbled by both books and open source projects that are extremely well crafted.

Not surprisingly, dealing with zPosition in a 2.5d game is about as complicated as everything else in game development — it will be harder to handle than you think it should be. For example, how should you handle moving a sprite from behind a tree to in front of a tree in perceived depth. While the initial drawing of objects is straightforward, things become tricky once they start moving around. Let’s take a look at how I’m approaching zPosition in my Sprite Kit game.

When learning a new language or environment, some things that should be trivial seem to take forever. Once you learn how to do simple tasks, it’s hard to remember how you originally struggled. So for that reason, I’ve decided to keep a running log of useful code snippets that were stumbling blocks at some point. Anything that I think I’ll reuse, or had trouble understanding as a beginner will be added as a gist to my Github account.