This post is a follow up of the libgdx and Kotlin post.
I have decided to prototype a simple 2D platformer (along the lines of Star Assault from my early posts), but instead of Java, I am using and learning Kotlin along the way.
For this tutorial, the project should be in its initial state from the previous post. A bare-bone libGdx Java project turned into a Kotlin project. We’ll be jamming away in our main Game.kt file, formerly Nemo.kt.
The project source for the initial state can be found here.
Kotlin doesn’t require the file name to be the same as the class name, or even to be in the directory structure equivalent to the declared package.
Without further ado, here’s is the first change to the code.
I’ve been reading lately about different languages and what they can bring to the already crowded table of software developers, and one language stood out for me: Kotlin. (https://kotlinlang.org/)
It’s a relatively new language (est. 2011) and these are just a few reasons why I picked it over the multitude of other more mature languages:
Game AI is a very broad subject and while there is a lot of material out there, I didn’t find something that introduces the concepts gently and at a slower, more understandable pace. This article will try to explain how to design a very simple but extendable AI system loosely based on the concept of Behaviour Trees.
Artificial Intelligence is the human-like behaviour exhibited by the entities participating in the game. It’s more the illusion of intelligence and thoughtful action performed by the entities than an actual intelligent reasoning driven behaviour. The goal is to try to fool the player into thinking that the other “intelligent” entities are controlled by humans and not by a machine. It’s easier said than done, but we can use a lot of tricks to achieve some really good, seemingly random and “intelligent” behaviours.
One useful architecture pattern in game development is the MVC (model-view-controller) pattern.
It helps separate the input logic, the game logic and the UI (rendering). The usefulness is quickly noticeable in the early stages of any game development project because it allows to change things quickly without too much rework of code in all layers of the application.
Adding depth to our games, then we have to get ready to go 3D. 3D is not complicated at all and rendering 3D graphics is quite easy using OpenGL ES.
I will break the concepts down to the basics. In a 3D game, as in the real world, everything happens in space. If we were watching a football match from the tribunes, looking down onto the pitch, we would be observing the unfolding action from a perspective. What we would see is defined by the field of view and the players that we “catch” with our eye. We would look at a 3D scene.
In this part I will try to explain how to design easily extensible and maintainable game elements that control their own internal state and behaviours.
An internal state is best described as being the soul and mind of the entity. In the [first part][1] I described why composition is better than inheritance. In a nutshell composition provides the means to interchange the algorithms associated with their behaviours. State on the other hand helps objects to control their own behaviours.
In this part I will try to explain what I understand on good game design elements.
I will use droids in the examples and I will script a basic fight simulator to see how they behave.
I command a single robot and I want to obliterate my enemies. To face the same type of enemy all over again is boring. I need new challenges and this means new types of enemies. For example in the first level I want only to practice my target. So I need a pretty dumb enemy that does not do much but takes the shots. After I mastered that skill (shooting a helpless droid), I need a bit of a challenge and I want the enemy droid to fight back, but because I am still a beginner I don’t want to die quickly so I need weak droids. After I am over with them I want a tougher challenge. I need better and stronger droids. Not just stronger, but different in behaviour as well as it can get boring killing the same type of enemy over and over again.
Create 3 classes for the 3 types of enemy droids. To keep it simple, each droid has 2 abilities: move and attack. It makes sense to create a Droid interface with these two methods and have each droid implement them.