A Q-Table greatly simplified the challenge of helping a computer agent “learn” to solve an environment. Unfortunately, this particular approach doesn’t scale well to the kinds of applications I would like to create. To help overcome this next hurdle, we will raise the complexity a bit more as the Frozen Lake environment is approached again, this time by using a neural network.
Telling a computer to perform an action based on an input isn’t too hard. Teaching a computer to learn what action to take based on what it sees is a whole different challenge. Now imagine that the computer wont even know if the action is good or bad until some unknown point in the future – how hard would that be? Well, let’s find out as we take a look at a machine learning algorithm called Q-Learning.
Machine Learning provides us an interesting way to solve special kinds of problems. If you’re just playing around, you may see that creating a good problem to work with can be a lot of work on its own. OpenAI gym has recognized this challenge and provided a great solution. They have created a whole collection of different “environments” that are perfectly suited to machine learning. To help us get started, we will be looking at one of the easy challenges which we can solve using Q-Learning.
You may have noticed things have been quiet here recently. The reason is that I have been hard at work trying to learn new things myself. Machine Learning is to blame for my currently distracted state, but if you haven’t looked into it, perhaps I can help you catch the bug too.
Scriptable Objects are a special type of data object in Unity. They have several important benefits but may not work ideally for every scenario. In this lesson we will cover what they are and how to use them.
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.
In the previous lesson I hard-coded a demo deck of cards. This wasn’t “necessary” because of my architectural choices. It was merely a simple placeholder which didn’t require me to commit to any kind of data store or structure. Still, to help avoid any confusion, I decided I would go ahead and provide an example post that shows how the same deck could have been created with some sort of asset – in this case a JSON file.
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.
Any card can have special abilities – by this I mean that it can cause one or more of our “Game Actions” to trigger based on special criteria. Spell cards are unique in that they must have at least one ability in order to serve a purpose. In this lesson, we will begin implementing spells, and by necessity, will also create an ability system that we can apply to our other cards as well.
Many cards require a “target” as part of their play requirements. For example, a spell might heal an injured ally, or a minion’s battlecry ability may deal damage to an opponent. Sometimes the target(s) can be chosen automatically, and other times they require the user to manually pick. In this lesson we will begin the process of supporting manually targeted play actions.