Every time I start a new project, I spend a fair amount of time reflecting on pain points from previous projects, what I enjoyed working with, things I would still like to try, current standards and patterns, and how my fellow engineers might react to something I write. One of the big problems every project faces: how to access what you need, from where you need it. I’ve done a bit of experimenting and decided to share something I think is worth further exploration.
Advanced
Breakout: Blocks
Now that we can hit a ball with a paddle, we need something to aim for. Breakout style games have an array of blocks along the top of the board for the user to destroy. We will create some blocks, then create something called a “Prefab” that makes it easier to apply changes to multiple instances.
Zork – Interaction
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.
Zork – Items & Inventory
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.
Zork – Navigation
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.
Zork – Actions
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.
Zork – Targeting
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.
Zork – Interpreter
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?
Zork – Data Manager
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.
Zork – Game Screen
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.