Artificial Intelligence (AI) – Part one

Graph showing Cumulative Reward

A demo for Chess Battle is planed for the end of September.

At first this demo would have been a two player demo only, but quickly I realised that this won’t make much sense for most of the players because right now there is no network support, nor enough players.

So if you want to play the demo you’d have to be two in the same room, playing turn by turn (something that is intended when the game will be done but probably not ideal for a demo where I want quick iteration and feedback loop).

In an other hand, I alway thought basic AI would be a pain to code and not fun to play with (because it’s based on a set of rules, the player can understand and predict them quickly).

So what was the solution?

Fortunately we are at a time were you can use “real” AI in your games now. Real like the one in automated cars, or the one which won at the Go game. That kind of real. The one that you can train yourself giving reward to get a neural network in return. The one that is mostly unpredictable, creative and fun to interact with.

I mean, that’s the theory.

That being said, it’s still a hard topic. AI development is fun to play with but hard to get right. And to be honest, I’m a total noob in this area. I understand the basics and how it works as a whole but implementing it is something else.

Fortunately Unity has some good pieces in place to help you start, they included a good toolkit (API) and some tutorials too. I thought it will be easy to apply their example to my specific problem but OMG that was way harder than I thought.

I had a first very naive approche, using what I’ve just learnt in a good tutorial and thinking that it will be quite easy to apply to my own problem. Not true. I had to refactor all the code first to make it work with multiple environment (but that’s a detail), I’ve also had to think hard to get a good rewarding system and implement it. Find how to express AI objective and translate that to code.

When this was done, I had some AI training going on and to be honest it looked like it could yield some result. But I found an other problem: computational power. My old Macbook Pro is, well, old and does not have the needed CPU power to train an AI model in reasonable time. After a lot of internet searching, I found out that my objective are too complex for my AI model anyway (no mater the power of my computer).

Note on the hardware: at some point I was looking to pimp my macbook with external GPU thinking that it would help. I discovered that it won’t. Tensorflow the software used behind the scene use Nvidia GPU only (and fallback to CPU otherwise). Unfortunately Nvidia and Apple are at war (and thus not compatible). So it won’t help.

Getting ready for part two.

Today I designed a new way of getting an AI to work. After my search I found out that people split their objectives in small chunk and train multiple brains. Then they add some code to switch those brain during the gameplay. I’m hoping that way it will work.

Also Unity contacted me because they have some AI Training Cloud in their roadmap and they may provide that service in the futur. Hopefully they will let me try it soon.


A demo for Chess Battle is planed for the end of September.
Join the beta ⤵️

Doubts

When I spend too many hours on Chess Battle trying to solve a problem or even iterating, sometime I fall into periods of doubts.

I play my own game and I don’t see what I’m looking for. It’s not fun, not pretty, not well balanced. Full of bugs. In a word: it’s not good. From here it often escalates to the point where I realise the amount of work left. I feel overwhelm. I don’t know where I’m heading to.

Mentally it’s hard to handle. The only solution I found for those moments is to step back a few hours, or even days. And hopefully when I’m back to work it’s gone and I’m full of faith again (so far it worked like that).

I guess looking back at the accomplished work help too, hence my previous post about current progress.

I thought it’s important to share those bad feelings too, because as indie developers we face many challenges, but self doubting seems to be one of the worst (at least for me).

Do not hesitate to take a break!

On that note, it’s holiday time for me, see you in a couple of weeks.

🏖

First months progress

From the idea, through prototypes, all the way to a playable demo!
Let’s see how far we are after 4 months.

A little bit of history: Chess Battle started in January, I mean, it’s been in my head for a long time but I started to write down some stuff in January 2020 and I decided in May to give it a go by working on it full time.

Also, because I know projects work better with a scope, I arbitrarily decided to fix a deadline for the first playable demo to September 2020.

May 2020

In may I was playing with Unity own Physics engine and thought it would be easy. I also used an asset that allows to get destructible sprite very easily but, rest assured, all this will be soon discarded.

I also had a first prototype of map generator based on bitmap at the time. See details here.

June 2020

If I remember well, in June I had my first game over the Internet with a friend. It was laggy as hell and I did not see how it could improve with my technical choices at the time. So I discarded all the networking part too. What a progress.

I still was trying to get Unity Physics engine work the way I wanted, and it was quite convincing. I built specifics scene to test all the parameters and stuff.

This is when I decided to implement the distance limit, here with a halo that prevents you to move more than a specific distance. After testing it for a while, I’m pretty sure it won’t end up in the game in that form.

I also iterated on the map generator, positioning destructibles objects and ammo/health bonus boxes.

July 2020

What an exciting month! In parallel to coding the game, I was also looking for a designer to help me work on the game. I found someone that has the exact style I wanted and he accepted to work for me.

We can see on those video some of his concept art. Except that I started to tacle the hard problem: implementing my own Physics engine.

August 2020

With Jean-Baptiste we settle down on Anima2D for the character animation and it’s pretty cool because I had sometime to test some sort of ragdoll animations — something I always wanted to have — on this video it looks stupid and full of bug but the final implementation will be great. I also worked on my own Character movement controller.

On the last video we can see that I started to integrate the final art from Jean-Baptiste. The map generator has to be tweaked a bit more too.

To be honest with myself I’m not even half way to have something ready but I hope that in September I’ll get some sort of demo.

Fingers crossed

🤞

Character Movement

Today I spent way too much time on my character movement controller. It turns out, this part is more complicated than I expected. But it’s so important to get it right, that I took the time, and spent a bunch of days working on it.

At first I was a little bit disappointed that something so basic was not included into the game engine. So I browsed the asset store, and tried a few assets with no success.

The problem, kin of “as usual” is that I want something very specific with a certain feel to it, and even if most of the assets were configurable I never found the right combination. I decided to give it a try myself.

I’m a little torn, in a way it was not so hard to do, but on the other, I had to deal with so many cases. As you may now from my article on my technological choices I decided to handle most of the physics myself. So that was some work to get the character collide with stuff and bounce when projected.

But it’s done.

  • I implemented left / right move
  • Jump (and double jump) in player physics controller
  • Handled pretty much all collision cases, including when hitting multiple walls at the same time (or when falling, jumping)
  • Implemented distance limits (because in Chess Battle, a character can move a certain distance regarding his class. Not sure that mechanic will make it up to the final version).

Prototyping with a designer

Image with test for different sizes

These days I’m lucky enough to spent time with a great artist: Jean-Baptiste Dessaux (Jb for short). He is going to work on the graphic side of Chess Battle.

I’m very happy that this part of the project is moving forward!
We are going to try to answer some critical gameplay questions ; for example the proportion of the character versus the map or the style of the game.

Size IS IMPORTANT

In classic artillery games, players often move military tanks (or in the particular case of the Worms series: worms). These characters are slow, which gives artillery all its meaning.

In Chess Battle, the characters are not intended to move slowly, they are humanoids. This could be a gameplay problem. Indeed if the player can quickly move his characters close to those of the other player, why would he use artillery rather than nearby weapons?

That’s partly why we have an other gameplay mechanism: distance limits per character. For example the bishop can move a certain distance, the knight a bit more etc (it’s because the game has some chess board game roots). But even for me it seems a little bit odd.

We will see how it goes!

Image with test for different sizes
Size tests. Concept art by Jean-Baptiste Dessaux
Map

By working with Jb I came to realise that doing a map generator is probably too early for the game. I’ll go for a pre-built map so the gameplay can be tested in advance. It’s always sad to remove features from the codebase but that’s how programs/projects dev work.

Learn more about the map generator here.

First results

Jb is now iterating on concept arts, some for the map and some for the main character: the queen.

Image with 9 objects
Concept art for map objects by Jean-Baptiste Dessaux
Image with 4 tests for the Queen character
Concept art for the Queen character by Jean-Baptiste Dessaux

I paused a bit some dev things to focus on helping him deliver. And then I could integrate his work into the game to see everything came to life.

Exciting times!

Technologies

This article will be updated as I add parts to the game.
Last update was on the 10th of September 2020

In this blog post I will talk about the technological choices I made and go deeper in some technical details about the game.

Unity

The game is based on the Unity engine which allows you to export on all platforms, from PC/Mac to consoles via mobile platforms.
I made that choice because I know Unity quite well and I like coding in C#. But to be honest, everything is not perfect in the Unity world.

Love / hate relationship

I love Unity because it’s very easy to get started with, there are plenty of online tutorials and examples, and the assets store has some good gems. All this gets you pass the prototype phase pretty quickly.

I hate Unity because they have different ways to do the same thing (usually they buy some popular asset, integrate it in the software and that’s it, they do not remove the part it replace). They also sometime remove feature without giving anything in replacement (last example with the networking part).

Physics 2D

When I started the game, I thought “it’s going to be easy because Unity has all the needed tools including a good 2D physics engine”. But after a while playing with it, I found a bunch of blocking limitations.

First of all it’s very hard to customise, you can play with physics materials and change the mass, friction and all those variable, even the gravity scale itself. But still, in the end it’s a bunch of variable that you’ve changed here and there. You get easily confused and it’s not even practical to test.

Second, and that was the blocker, the Physics engine is non deterministic. It means that given a set of inputs (ie: force, mass and start position), if you play it two times, you will probably not have the same output. Unfortunately this is not compatible with Chess Battle Gameplay. If a player at some point has a good aims, nows the right force and play the same move again, they should get their bullet at the very same spot.

You will see that the deterministic part is even more important because of the network implementation.

So I took some time to re-implement basic physic equations but kept some of Unity existing pieces like colliders and collision resolutions.

About the destructible map

I found a great asset on the store that allows you to take any Sprite and make it destructible. I bought it without even thinking and at first I was in love.

But after some prototyping, I found out that because the asset was working on pixels and not shapes it would never render the way I wanted.

So I made my own destructible map which is based on Sprite Mask and custom polygon colliders, all of this is easily done with Unity and a bit of shape maths.

Map generation

See detailed article here: Map generator

Network

My idea was to implement the network part from day one, because that way I could play with beta testers right away.

I started with my own implementation using Firebase and found out that it was pretty hard to get everything working. Then I benchmarked a bunch of solutions and settled down on Photon Unity Network (PUN).

It was great, the code was not that hard and it seemed to work. Until I had the occasion to test an early version with a friend in real condition (meaning over the internet and not on a local machine). The result was too laggy for me. I’m pretty sure I could improve some details but I didn’t wanted to fight against the code.

I decided to stop developing the network part right away, but thanks to this first step I’m very aware of how to structure the code.

Custom solution

I made some new prototype with a new solution of my own, tailored for that particular game. Indeed being a turn based game, I will go for a “turn replay” mechanism: the idea is to record the turn of the player (with a specific optimised stream format) and broadcast it to the other player in near realtime. This will also allow to keep a record of any game for later replays.

You can now see how important it is to have deterministic physics, so I don’t need to record every movement in the replay stream.

Artificial intelligence

Learn about AI in this detailed blog post (part one of multiple coming up)