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.

Most people who come to this site would be under the impression that it is abandoned. That’s partially true. But just because there is little activity here, that doesn’t mean I’ve been doing nothing. The truth is that a lot has been accomplished, followed by burnout, followed by a crossroads that I’m now at.

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:

Before I wrote a line of code, I knew that I wanted my game to have a story. And, of course, not just any story. It had to be a decent story with sound, art, movement and voice overs. Basically, a movie. Now that I’m 75% through the process of creating and implementing a story, I thought I’d share some lessons learned about this surprisingly difficult task that cost me around $7,600 and nearly 3 months of my development time.

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.

Health indicators are found in almost every game. As Chris pointed out, they come in a variety of shapes and sizes. When it became time to think about them in my game, I wanted to add something that was functional, but also unique or interesting in some way.

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.

It’s amazing how long it can take to make your first level. It seems so simple at first. Just put a castle here, some grass there, and call it a day. But, questions arise. What art style should we go with? Will sprites be light or dark, so that we know what color grass and flooring to use? How wide do walkways need to be? Basically, figuring out your first level is like figuring out your entire game. Because of that, my first level continues to change. I thought it would be neat to take a look at where it started, and where it is now.

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.

Now that I’m working with other people, all sorts of questions come up about my game. How many illustrations where there be? How many actors? Is the script finished? What tone should the game have? Pretty much every single thing you could think to ask about the game needs an answer. Everyone I have spoken to says to start art / sound / music / copy editing / storyboarding early in the process. Don’t wait until the last minute, they say. And while most people have my best interests in mind, it is still a ton of work to answer questions in a thoughtful way.

Finding an artist has been my biggest fear since this competition started. There are so many things that could go wrong when you have to depend on someone you don’t know to contribute a third or more to your project. The style may not be a match, they could leave half way through the project, the budget estimations may be way off — the list goes on and on. I must say though, I’ve gained confidence in art contractors in the two weeks I’ve been speaking with them. I thought I would share some of my notes.

It’s hard to believe that we’re already 3 months into the competition. My first quarter of game development consisted of many highs and lows, but most importantly I still consider it among the most rewarding things I’ve done. From a purely stats perspective, I think my productivity can be summed up as a strong start, medium middle, and lacking end. I thought it would be fun to look at some concrete numbers, so here is what I came up with.

I’ve ventured into the unknown while working on my game — I don’t know what art costs. This is becoming an issue because I have all sorts of grand ideas for levels, characters and features. It is clear that art, or more directly my budget, will be the deciding factor on the scope of my game.

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.

While working on the catapult for my game, I came across the first of many design problems I will face. Turns out it is much easier to critique another game’s design than it is to create your own with confidence. In my situation, I was deciding between a player controlled catapult and an automated catapult. I was so torn that I posed the question to /r/gamedesign and had to write the code for each. Let’s look at the results.

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.

Forget the big ports like X-Com or Final Fantasy Tactics and you’re left with mediocre stories in most mobile games. Hits like Angry Birds and Fruit Ninja excel in gameplay, not story. Even standout indie games like Hunters and Battleheart fall short. I expect almost every mobile game I buy to be light on gameplay and even lighter on story. I thought the same would be true for my game, but The Adventures of Princess and Mr. Whiffle by Patrick Rothfuss changes everything.

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.

I was going to sit down this morning and write a post on why I’m choosing Sprite Kit, but instead I feel the need to express how fun game development has been so far. It will be interesting to track my mood over time because I do see the tedious nature of the craft lurking around the corner, but for now I’m loving life.

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.

Since this contest is in the spirit of sharing and learning, it makes sense that my first post should report on our launch traffic, and how many users will come back to read more. We primarily reached out to people on Reddit, Hacker News, Facebook and Twitter and saw varying levels of success.

Whether it be video games, web development or mobile software, coding is coding. And launching something is hard. Every developer knows that. One of the main difficulties comes from design. Or, more specifically, polish. Anytime I can exercise my design muscles, I’ll be better prepared the next time around.

One of the interesting parts of documenting a journey is seeing how wrong (or right) you can be in the beginning. Whether it be budget, timing, quality, success, enjoyment or one of the many other measurements — something will not go as planned. I thought it would be fun to try to write out some concrete guesses about the future so that they can be revisited.

Welcome … to Medieval Times! Ahh, I wish I was eating there right now. Wrong place though. You’re at my blog for the Battle of Brothers game development duel. My brother, Chris, and I will take a year and $25,000 to see who can make the most profitable game.