Week 5

This week has been hectic to say the least, we’ve been working on a lot. In order to show the massive improvements we’ve made all together, I made a video.

For the A.I part.

I made minor changes for the first A.I by taking away the hear function and the guard target. The first enemy A.I now only sits in the shadow, waiting for you to appear in their view range and then moving into position to start attacking.

Relatively simple. There are plans for the first enemy, “Hashara”, to have their own spell in order to code better collision code so their spells wont ever hurt them nor will they collide. By implementing that, and their textures and animations, the enemy will be done.

For the second A.I, most of the design of the original behavior tree with some changes done to the public variables such as movement speed, attack speed, attack damage, and attack range.

The boss is most likely finished except for the animations and the diversity of spells. What will be different is the fight itself, I cannot go into detail because I am having my meeting with the lead designer and lead programmer next week.

This meeting, and the one I am having afterwards with my mentor, is a crucial method I am using to talk about the original design, how the design looks so far, what I need to do later on.

The meetings uses the method qualitative forms with these questions so far;

First meeting

1. Give me a general description of the character and its purpose in the game world (be as detailed as possible about its behavior).
2. Where is it situated? In what environment?
3. What do you want to alter when you balance the game?
4. What are the long term plans for this A.I?

Mid meeting

1. Are the required actions for the enemy A.I sufficient?
2. (Programmer) How much am I able to import to the next enemy A.I?
3. Are there any details you would like to add to the character?
4. Are the public variables available good enough?

These questions are not even researched before, I have to find sources on A.I design in general and specifically on third person adventure games in order to actually make my dissertation well made. I will next week to look for sources and try to get some.

It will be interesting to see how far this will go =).

I’ll be blogging next week about how the meeting went and what the plan will be until the last week before GGC.

Week 4

Hello everybody, this week wont be much about my position as A.I but as a small update on my course in general and what I’ve been up to otherwise.

So, the reason why I am making these weekly posts is because of a course as an A.I programmer for a demo of a game, but I am also writing a dissertation on my time as well.
My relevant questions and reason for my dissertation is to understand how I need to create the first A.I enemy and how much of it can I later import to the next A.I.

I struggled at first, not knowing how I needed to gather data, ask the right questions and simply not understanding the guidelines in general. I needed to rework my synopsis and try to understand what I wanted to learn, why I wanted to learn it and how I can learn it. When that is all and done I could finally start writing on the dissertation which will introduce the project and what I will do, list all the tools I used to answer my questions, show how it turned out, discuss what could I have done differently to make the job more effective and finally what I learned.

Pretty straight forward, I started with my questions from above but I tried to get the information by measuring immersion from players as well as other developers and mentors. By getting guidelines to be more scientific and more precise, I took away the part with immersion and focused more on dividing the questions I had into more questions and setting up times where I can talk to my lead developers to understand what they needed, how they wanted it to be constructed then work on the detailing myself. So I created meetings to have with my leads, discussing with them the questions I have with qualitative surveys on each tier. I present these tiers to my leads at the beginning of developing the A.I, when they have their first iteration and finally their final form.
I will also have to do another survey with my mentors when they evaluate the game to measure their feedback as well. By looking at literature on designing A.I and measuring the feedback from my leads and mentors, I will be able to see how different the literature and the feedback is and how successful they are.

The goal or the teachings I want out of this project and the course is to understand how the spectrum of A.I development goes and how my first time went, simply to get a better hang on developing A.I in general but more importantly for third person adventure games.

Other than that, I have great news from my other project, A Snail Tale [www.ASnailTale.com]

For a few months now, I have been working on a beat’em up game as a programmer and producer with an international team.
The game, A Snail Tale, is a 2.5D fantasy beat’em up game with more focus on narrative. There are no real unique feature in the game but we focus on delivering more of the nostalgic games of old such as Streets of Rage, Battle Toads, Turtles in Time, Knight’s of the Round (new addition by a class mate!) and many more. We take direct inspiration from castle crashers and other great beat’em ups that were able to generate new additions to the genres with minor changes such as multi player.

A Snail Tale will incorporate a medieval tale about a snail, destined for greatness that needs to rebuff evil warlords besieging the land. It will feature kick ass button mashing mechanics, strong heavy handed combos, different weapons, magical spells that destroys your foes and different classes to play from for a personalized experience.

The graphical art style in A Snail Tale will be pixelated and with all the splendid effects you can nowadays add on the camera to generate a tiny adventure of massive scale.

The team was generated by people that saw the concept picture above and was inspired to create something totally immerse. After a few months of planning, testing and playing around, we found ourselves working towards a demo which will be available in 6th of September. We want every fan of beat’em ups to enjoy the full control of a player, throw awesome combos with dual wielding axes as a berserker and take down enemies like this:

Keep in mind, this is simply a concept picture. Most of the art displayed might never be implemented into the final product, we want players to understand the direction we are going with and how the game feels when you play it.

If you guys are interested in looking further, keep a lookout on each developer blog we have at the moment and of course, check this blog out for more information about development in general!

 

Topi – Lead Designer – https://aarniodesign.wordpress.com/

Alexander Vincent – Lead Artist – http://www.twitch.tv/dino__sawr

Frederick Tejner Witte – Lead Programmer – http://www.wituz.com/blog

Much love,

Ladbon

Second week, a new base and completion

So, much to talk about and a lot to take in!

So this week I redesigned the A.I behavioral tree from the ground up accordingly to my lead programmer and lead designer, and added the attack action!

So lets start, my enemy A.I needed to be faster in reactions, better in its rotations and have more actions. The A.I had to patrol, guard an area, look for enemies and listen for disturbances. Whenever it found an enemy by seeing it, it would move to the player and when it was within attack range, shoot spells at him.

I found a great, tutorial that helped me achieve these designs.

So now

The behavior tree looks like this.

http://imgur.com/i0BkmnJ

Here you can see that I have a script that checks the distance to object, this specific blueprint finds a specific target point in a and gets the two dimensional space between them (as I don’t want my A.I to jump) and goes there. From there, the A.I will collide with a trigger box and be told to move to another target point (somewhere else) to always keep patrolling when idle.

So the first action he makes is moving to the target point of my choice then to the other. I also added a variable here which the A.I always checks to see if he ever moves beyond the first target point. If this happens, he resets and moves back to the target point, effectively enabling a guard area which is top priority in all the actions.

The second action is if he ever sees an enemy (the player), the A.I’s perspective is 180 degrees at the moment but can be changed depending if we want to implement some sneaking into the gameplay design. When he sees an enemy, he moves until a specific attack range and starts attacking. The attacking blueprint is made by a tutorial from an asset bought on the store. A very cool spell casting asset where you can create spells and some more as you can see from this blueprint.

http://imgur.com/rZmhH9S

Third action, has the enemy A.I heard something (public variable for hearing range), he will move to that place to look around, wait one second then move back. Something not told since the second action is that the guard area is the highest priority, if the enemy A.I ever moves beyond that point, he will move back.

The interesting part with this behavior tree is that the public variables available are so great that we will be able to generate some interesting enemy A.I’s from them.

Conjure speed =
Spell projectile speed =
Cooldown speed =
HP =
Guard Range (in meters) =
Aggro Range (in meters) =
Listening Range (in meters) =
Attack Range (in meters) =
Move speed (1 – slow | 10 – sonic) =
Does it patrol or stationary =

and that’s about it. It looks very fun to sneak behind the enemy A.I at the moment, just making him run around looking for me or just dodging his spells. Next week, I will start working on the boss A.I! Stay tuned.

A New Project

So I am renewing my blogging with some post these coming eight weeks on my experience as a AI programmer on Giraffic Art. This lovely bunch are my co-workers for a course named Big Game Project.

We are developing a game named Naar, an adventure plat former with a unique spell casting system and is set in a genie world.

My primary objectives during this project will be to design behavior trees for the two enemies in the game and the main boss. My goal is to create a base tree for both enemies then alter their attack and movement speeds to make them feel different when Mokhtar, Naar’s protagonist approach them.

The engine I am using is Unreal 4.7.1, a heavy engine with powerful and remarkably easy tools to achieve my goals.

My first step was to create two characters, one a player can control and an AI. This AI or pawn as unreal like to call them, will be interested to you when you come within a distance to it and follow you until it reaches the designated attack range.

Easy enough, there was already a tutorial with a 3rd person view that spawns a character, making me jump start my work without any hassle. As I had my sky box, level and character, I only needed to write the behavior tree for the enemy.

There is a tutorial on Epic’s website that teaches you how to use behavior trees and the results is a pawn that follows you as soon as you come close.

Unreal has the notion to always use nav mesh’s nowadays so the first step was to create one. Nav mesh bounds volume is a feature that you place unto platforms like a collider, explaining where the pawn is allowed to walk/run.

Following the tutorial, you start by creating an AI character, notifying the developer that the parent class needs to be a character rather than a pawn (I am still not sure why). You then create a blackboard, a blueprint and finally a behavior tree. A blackboard is, well, I am not really sure but it seems to be able to create global variables to use for the behavior trees. Blueprints is a new, effective tool used in the unreal engine to program without having to write one line of code. It’s an effective way to actually show code and learn the inner workings of code in general but I personally prefer writing code though I am starting to enjoy their capabilities.

By following the tutorial you start writing a blueprint for the movement, making the pawn move without any controller input. For movement there is a need to start the blueprint with a event begin play to indicate that when the print is called, this is where it starts. From there it remembers it’s home location and start running to the player.

After enabling the pawn to move, there is a need to create a task as to why it runs and the rules. In this case it was to have the enemy follow the player until it’s within range then start attacking. For this reason you create a task inside the behavior tree with the pawn’s location and the players. There you connect it to a tick, counting each frame and make it follow it when it’s within the pawn’s aggro range. The aggro range is the pawn’s reaction radius to run towards the character. There is a lot here that I do not understand such as the break hit result instance and the line trace by channel, making sure that I wont be able to tell you in detail how it works. My best guess is that it creates a path within the nav mesh to find the fasted path to the player and follows in with ticks counting when the pawn can move and stops itself within attack range.

When all of these massive blueprints and tasks are done, you are transported to the behavior tree to create the sequences and selectors, making sure the AI follows a predicted train of thought you create.

For this instance I followed the tutorial and made one by checking aggro every 0.5 seconds and if the pawn sees the player it creates the fastest path available and moves towards until it is close enough. If the pawn is not available to follow it waits 2.5 seconds before going back to it’s home location.

And that’s it! I haven’t been able to implement the attack state of our AI nor will I include tidbits of that exploration in this blog post because I need something to write next week!

Stay true,

Ladbon