I’m still on my SpriteKit journey and am ready to tackle a few more hurdles. Primarily, these include making some easy and reusable code to allow me to place one node relative to another. We will then expand on this solution to help us place one node relative to the screen’s edges. Finally, this solution will also show how to handle the “safe area” you’ll see on an iPhone X.
As a native iOS developer I have found a wide range of amazing tools and libraries that are freely available. Some of this is designed toward a specific end goal, but much of it is very flexible and could even be used for a variety of purposes including game development. With this in mind, I decided to explore what an Entity Component System (ECS) might look like when backed by Core Data. So far I am enjoying the results, and welcome you to try it for yourself.
A lot of sprite games include tiled backgrounds. Tile Maps are a special tool which allow the creation of these backgrounds without needing large arrays of nodes, which could otherwise potentially cripple your game’s performance. This post will provide a quick overview for tile maps and features including: tile animations, tile variations, 8-Way Adjacency Groups, Custom Adjacency Groups, and a Tile Definition’s User Data.
One of the first learning hurdles encountered with SpriteKit comes when determining how to get the contents from a scene to display as expected on various devices, each with their own resolution and aspect ratios. We will review a scene’s scaleMode property as a built-in solution that may work for some projects. Then, we will build a custom solution to overcome the limitiations we were otherwise stuck with.
I have recently been tasked with the implementation of accessibility related to blindness on a few different iOS projects. There is a lot of documentation on this already, but finding it all in one place and getting a “quick” overview of the basic idea were a bit harder to find. Following are the notes I made for myself as well as some tips and gotchas that others might benefit from.
Now that we can take items, it is time to enable more specific interaction with them. Some stuff you can read, others you can eat or drink. If the interaction includes a trigger, then it should be exectued. We will implement each of these interactions in this lesson, and then to finish it off we will add the ability for the player to persist their game state. Yep, they need to be able to save and load their games.
It’s great to be able to explore our game world, but personally I don’t want to feel like a window shopper. There is “stuff” in this world and I want to interact with it. By the the end of this lesson we will be able to take things or put them back, drop them where we stand, or keep them around and brag about our growing inventory.
We have quite a bit of functionality in our game now, but its hard to show it off without being able to move. In this lesson we will finally allow you to explore the world by navigating from one room to another. Along the way we will also update our systems so you can see the descriptions of the rooms and the entities that you find there.
Previously, we created a “User Action” which demonstrated how our interpreter could map out a sentence. In this lesson we will expand the concept of an action with some reusable classes. Then we will implement a few actions which are actually intended to be used by the game. By the end of this lesson you will be able to interact with the mailbox in your starting room by opening or closing it. This also means we will actually be modifying some data in the database for the first time.
Our interpreter system has succeeded in converting words to actions and objects. However it is still only providing candidate matches. There are a variety of reasons why we may need to filter or disregard those results based on other game constraints. For example, even though the interpreter might understand the word “leaflet”, you still shouldn’t consider it a valid object to interact with unless your player can actually see it. It could be in a different room, or could be located in a closed mailbox, etc. In this lesson, we will provide a way to help validate our object targets.