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.
One of the biggest challenges of this project is trying to create a flexible system that can understand the English language. How do I get the computer to understand that certain words relate to certain actions and objects when there are so many possible configurations of words to use?
In this lesson we will start by creating a class to manage the connection to our database. Then we will create a few models to represent the data we want to work with. Once all of that is in place, we will finish by creating a short demo that will allow us to grab an entity by typing its ID. The demo will then tell us information about our entity such as its label and the kinds and counts of the components it contains.
In this post we will begin the first real step of the project as we create the game screen – this will consist of a simple text field for user input and a scrollable text view showing the history of messages throughout the game. I will go in-depth on the description of code for the view controller as well as the manager object that records the message history. When we complete this lesson, you should be able to type messages into the text field and see them get appended to the log of messages in the text view.
I have recently needed to learn Swift at work, so I decided to come up with a new game project to help inspire me. Since I am not using Unity, I wanted something light on art and I decided to look at old text based adventure games, like Zork, and found that it actually held quite a few interesting challenges. Simultaneously I have been intrigued by an architecture pattern called Entity Component System (ECS) which I have really wanted to dabble with for awhile now. Although I am new to both Swift and the ECS pattern, I feel that the results are worth sharing!
You’ve probably been told before not to re-invent the wheel, but when it comes to my own code I couldn’t disagree more. I love re-inventing the wheel because it helps you understand why things are designed the way they are, and occasionally allows you to make something better. I’m currently “thinking out loud” about a whole new approach to the way I implement state machines that can provide functionality I had been wanting but not thought was possible – until now.