Build your Own AI - Part 1

Or

Implementing Live Ops and In-App Artificial Intelligence

Date first published: 13th March 2021

Introduction

Live Ops is about introducing Artificial Intelligence (AI) to customise the user’s experience keeping them engaged and maximising the value they get from the software.

It is particularly appropriate for video games where the AI can dynamically change the game parameters making it easier or harder, rewarding the player or even just providing hints and tips at the right time. Live Ops Services are available out there on the Net but they are expensive and require third party APIs to be built into the code potentially putting them beyond the reach of those who can afford neither the cost nor the impact on their apps.

This is the first in a series of articles where I will demystify Live Ops and Artificial Intelligence by describing my journey to build an AI from scratch and incorporate it into my existing mobile games. Do you want to read about a real-world example of making AI work or are you a software engineer or an Indie game developer who wants to build Live Ops into your own projects? If the answer is Yes then read on as these articles are for you!

About the Author

My name is Graeme and I’m a career software developer with more than 25 years of experience. I build Indie games for fun at night but by day I’m the global DevOps lead at Expleo, the world’s largest software quality consultancy. I’m a massive proponent of agile and DevOps practices as well as software architecture and design.

I first experienced AI back in university in the early Nineties when we were working with Transputers and Data Flow programming languages. Things have moved on since then and for this project, I’ll be subscribing to the IBM Fundamental Approach for Artificial Intelligence.

Finding out More

These articles are live and will be released as we go through this AI project. I invite you to be part of this exciting journey not just by reading the articles but to affect the end result through your comments and feedback.

Every article will have an Overview and Summary sections for the general reader. For the technical person it will also have a separate ‘Diving into the Detail’ section where I'll present the engineering – requirements, design, code, tests and all other details. Every article will be published on both Linked-In and Itch.
Every feature and update will be released into my free to play games. Experience the effect for yourself by downloading and playing the games as we go.

Overview

In today’s article, I will look at the IBM AI Fundamentals Approach that we’ll use in this project and also provide some background into the target game and how Live Ops will make a difference to it. In the ‘Diving into the Detail’ section, I’ll present the requirements engineering for the project, surely one of the most aspects to get right at the start.

The IBM AI approach

Artificial Intelligence is, in its basic form using a computer model to simulate the thought processes of a human and the IBM approach considers not only the building blocks for the AI but also how it should interact with the player.

You can read all about it here on the IBM website but below are the main things I glean from the documentation:

We must be customer-centric and put the user experience as top priority so that the solution addresses their needs at any point.
We must provide the player with insights, empower them to act, and build a relationship between the player and the game.
The AI must establish tone and personality to build the relationship effectively.
The AI is not programmed, instead, it is taught and must learn as our user plays the games.

Secondly, the main building blocks of the AI are (that will come out in our software design later)

Data – raw information collected from the game.
Understanding – data put in context of the game (putting data in context is called Machine Learning).
Knowledge – metrics or KPIs drawn from the understanding that we can use to make decisions.
Reasoning – the algorithms that use the knowledge and make the decisions.
Feedback and Learning – ensuring the player can provide feedback and help the system to learn and improve its responses.

As we develop the games and implement new features, we will expand on the AI by adding additional knowledge, understanding, and reasoning. The power of the reasoning algorithms will continuously improve as more knowledge is available to base decisions on.

But what does this actually mean for our game? First, part of the AI will be focused on customising the game to suit the player, but the second part will need to be geared to how this is displayed to the user and how they interact with the AI. This must also change based on experience.

Target Game

Let’s now move on and look at the game that we’ll build Live Ops into.

My game and pet project for the last couple of years is Otherworld: Epic Adventure. This is an adventure game for mobile devices, designed in the style of Myst or Fighting Fantasy. The player is dropped into a strange location and they must explore the world, solving puzzles and uncovering the plot as they go. It’s big with 200 locations to visit and 100 items to interact with and an exciting plot based on a Celtic murder mystery story.

While we’ve had loads of positive reviews there has also been negative feedback - people have got lost in the game wandering around the world finding nothing to do or the puzzles are too difficult and they’ve given up after a few attempts.

Otherworld also has features missing, there are no achievements, no scoring, no leader-boards or challenges and little social interaction.

This means there is plenty of scope for Live Ops to bring value, making the game easier, providing hints and tips and keeping the player engaged for longer to maximize enjoyment.

Otherworld uses photography rather than computer graphics to represent the world.

Otherworld currently has a paid version and a free trial version. It is implemented in Microsoft Xamarin using C# which means there is one code base for all platforms. It is released on the Apple, Google and Amazon app stores.

Find out more on my website and you can play the free version to experience it for yourself. The free version is available on the Apple App Store, Google Play or the Amazon App Store.

Diving into the Detail

Today’s Diving into the Detail will focus on the high-level requirements engineering for the project with the first job being to write down exactly what we are trying to achieve and what value we want to get out of it:

We want to keep the player engaged with our game by adapting it to their level of skill so to maximize enjoyment, generate positive reviews and influence them to purchase our other products.

This covers who this is for, what it must do and why we want it.

However, it needs to be a bit more specific so I’ve broken it down into areas I think that need to be done, each of which should be independent and represent value. We want Live Ops to do the following:

Keep players engaged by providing hints and tips on what to do next.
Make the game easier or more difficult by changing game parameters during play.
Maximize our revenue by suggesting appropriate in-app purchases that will help at the right time.
Maximize player enjoyment by awarding achievements.
Increase player interaction through leader boards and our social media sites.

In agile terminology what we’ve done is to create an ‘Epic’ with a series of ‘Features’. These features are our ‘road-map’, each of which can be released separately as updates to the games.

Constraints

In developing this project several constraints must be considered. These are:

There is no budget so no expensive tools or existing online AI services, (I’m sure many indie developers will be in the same boat).
There must be a minimal, measurable impact on the current codebase. The game is stable having gone through a lot of testing by our community and a full regression test pass will be expensive in time and money.
There must be minimal impact on the performance of the game - we don’t want to make the experience worse for the player.

Prioritization

Bearing in mind the DevOps principle of ‘maximum value for minimum effort’ we should re-order the list of Features in terms of both the value they will deliver and the risk or complexity involved. If we can deliver the most valuable Feature first and measure the impact it has then this will drive better decisions about whether to continue and develop the second one, make changes based on the feedback or potentially even abandon the project.

To help prioritize the Features, I’ve scored them using a simple 1 – 5 scale against ‘simplicity’ and ‘value’. For Simplicity a 5 means that is easy to implement but 1 means that its complex or carries particular risk and a 5 for value means it’s the most valuable. Multiplying these scores together gives a measurement for the priority:

So here now is our prioritized road-map:

Hints and Tips
Change Parameters
Social Media
Achievements
In-App Purchases

Before finishing with the high-level requirements, it is important to consider how to measure the value we want to get.

All this information can be automatically collected from the game and it can be backed up further by feedback surveys from beta testers as well as reviews once the game is released.

To round out this section, I want to mention tooling. Otherworld has been built using Microsoft technologies and aside from the coding we’ve used Microsoft App Center for the build and Azure DevOps for the project management. These tools are free for small teams and Indie developers and if you want to find out more please check out this article.

Azure DevOps contains Azure Boards for requirements and project management and I’ve placed all the information above into it. Here is the set of prioritized features in the Kanban board:

Summary

We’ve set the foundations for the project and carefully considered the value we want to get out of it and how it will be measured. We’ve also created a prioritized road-map and we are now ready to consider ‘how’ this system will work both from an end to end business flow but also the structure of the AI brain within the system.

This is exactly the subject of the next article where we’ll also think about how everything will be tested and look at the tooling available especially for capturing the data and measuring the value.

I hope that you have enjoyed this article and potentially even found it useful for your own projects. Please do leave any comments or feedback and watch out for our next instalment.

Stay safe!