It was described by the creator of this game, who is pursuing a master’s degree in machine learning at the University of Helsinki, for his dissertation. Name unknown.
Well suited for those who create games or are simply interested in the above. Let’s get started.

______________________________________________________________________________

1. Selecting a Machine Learning System
My programming language is C#, I have started exploring the machine learning platforms available for .NET. Considered several options such as Numl, Encog, Sharpkit, but the one that stood out to me as the most versatile and comprehensive was the Accord base.Net.
I took the skeleton of a previous project to create a prototype that would generate data approximating what I expected from my game. Specifically, the prototype randomly places one to ten defensive structures on the screen, then spawns five to twenty enemies that move from the left side of the screen and then try to get to the right side while the towers shoot at them.

2. Define all inputs
The input data to the model is very important because you need to capture everything that will affect the output, but exclude what is not related and will only add “noise” to the results. For my prototype, I recorded the maximum health, speed, location and movement form (walking/jumping/flying) of each enemy and then combined this with the range, damage, fire rate, location and area of ​​effect of each of the structures. If the enemy/tower was not used, I replaced the values ​​with zeros. *Note. Depending on the model you use, you may need to normalize your data; that is, process it so that all values ​​are in the range from zero to one by dividing the actual value by the maximum possible value.

3. Define your output
The output https://fruity-vegas-casino.co.uk/ of your model is the information you are trying to
train models – predict. For my game, what I was trying to predict was how effective a group of opponents would be given the defenses and obstacles they faced. At the end of the wave I recorded the distance reached by each enemy and noted which one managed to reach the other side of the screen, these values ​​​​will be considered the result obtained from the wave input. I saved the input and output data in CSV (Text format designed to represent tabular data) which was sample data for my model.

4. C generate sufficient sample data.
I gave the opportunity to do a test run non-stop for a couple of days to create a lot of sample data. I then wrote a class to read the CSV-data and then used it as a collection of different Accord models.Net, including identical models with different initialization parameters, to see which model had the most accurate predictions and at what level of data their predictions became reliable. This model refinement process took several days due to different training methods (unsupervised), possible model parameters and hyperparameters. I tested one model with different parameters, chose the reasonably best combination for that model based on the time required to train it and the accuracy obtained, and then moved on to the next model.

5. Model selection
At the end of my testing, the model with the most promising results for my particular scenario was the deep belief network, a form of neural network that was highlighted when features were detected. Using a combination of supervised and unsupervised learning, I found that the predictions became reliable after about a hundred data samples with an accuracy of 90%, and they continued to improve with increasing data access to the point that it reached a root mean squared error of 0.045 after 1.500 samples or 95.5% accuracy. In addition to high accuracy, training time was acceptable, with an upper range of thirty seconds.

6. Implementation of your model
At this point you should already have a sample working code for your selection model, so implementing it in your real game should be as trivial as changing the dummy data to real data and applying the predictions it makes to your game logic. The key thing you need to do is reduce the time it takes when you train your model, as it usually takes longer as the amount of data increases. What I did when new data needs to be input is I copied the existing model and then assigned a low priority thread to train the copy. When the training was over, I replaced the existing model with an updated copy. Closed access to the live model using a mutex (analogous to a single semaphore, used in programming to synchronize simultaneously executing threads) to prevent concurrency problems.

7. Make your own game
So now you’ve chosen your machine learning model, the data it should identify, and you know how you’re going to use the output to continue playing. You may decide to use more than one model for different aspects of gameplay, or use other aspects of your chosen framework, since you will be implementing a framework into your project to implement your chosen model anyway. There are many applications of machine learning, such as dynamically changing game events to maintain tension, using genetic algorithms as the basis for creating game content, or analyzing game patterns to maximize ongoing player engagement.

8. Decide whether static or dynamic model?
Once you’ve finished your game, you can use it to generate enough data to train the model, export it at your current performance level, and then ship the exported model with the game for use without further preparation. This will eliminate the computational requirements needed for continuous learning, an important consideration for a mobile game. However, this may affect the game’s difficulty level if players understand the game’s blind spots and vulnerabilities. Instead, you might decide to partially train the model as best you can, and then let that model be constantly updated with live player-generated data.
This latest hybrid approach captures the best of both worlds because you start with a good enough model that will continue to improve based on the players’ own actions. For my own game, I decided to send the model with zero data and let it learn as the player learns, so errors and misses will be part of the narrative. In other games this can be a dangerous decision, depending on what the model is responsible for in a particular variant, but in my case it is simply a decision about which enemies to send to the location. So in the worst case, the model will simply send out enemies that are not well equipped to deal with the defense(towers) they are facing.

9. Consider other apps
While testing the models, I carefully studied the structure of the Accord.Net and decided to make the enemies more dynamic than they were in my prototype, using an available implementation of genetic algorithms. I knew this wouldn’t have much of an impact on actual gameplay, but I thought it would be useful to provide each enemy with unique attributes to make the data generated a little more "alive" and hopefully improve enemy performance over the course of the game in combination with model performance.
When creating a new save file, I generate a random pool of genetics for each enemy type, consisting of eight chromosomes that change the maximum health speed, walking speed, and more, so that increasing one reduces the other. The machine learning model then compares the base enemy’s prediction to the enemy, using the specific genetics to determine the relative fitness of that genetics, and those genetics with the highest fitness are most likely to be passed on to the next generation.
______________________________________________________________________________

The game was created primarily for a dissertation, where the goal is to see how good the created model of a scientist, namely a network of deep beliefs, is, how it works against players and with zero preliminary training. This means that when you first start playing the game, it also knows nothing and learns to play just like you. As you play, input and output data is sent anonymously to Keen.io for analysis of a person’s dissertation, so the more people play, the more confident the statements and results will be.

His friend designed enemies, towers, attributes and terrain objects. He took his designs and animated them using Spriter Pro, scripted the branching dialogue using Articy: Draft, and then combined all the results using the FlatRedBall engine and the MonoGame framework.

In total there are 15 enemy types, six tower types, ten maps and about 2.500 pieces of dialogue, four game endings, and it takes about an hour to complete one run.