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

Week 3

So, week three will be about creating the boss A.I tree and how it will react to the player.

Naar’s boss was designed by the lead designer and his behavior tree designed by the lead programmer. He is meant to serve as a lord of the level (region) Mokhtar is traversing. When the player get to the throne room the boss is presiding, the boss is suppose to find Mokhtar (lock in), move a few metres forward, trash talk Mokhtar then start wailing spells at him. Now, Mokhtar has to dodge his spells or destroy them with him own while trying to damage the boss.

The boss has ten hit points, when he equals or goes below seven he switched his state, moves to another position and start wailing new spells but quicker, same sequence happens when he reaches four points or below.

Another sequence that was not mentioned earlier was that the boss has an animation when he is between the transitions of these phases. This animation plays out as he falls unto his stomach and farts a dangerous smoke effect. If Mokhtar is able, the player will be able to throw a fireball, igniting the gas and explode the boss, damaging him a bit before the next phase.

So that is the design of the boss, there will be an array of different spells the boss will be switching to and depending on the phase, the projectile speed and attack speed will be different. At the moment, there only one spell.

I have succeeded in creating all the three phases with all the values and animation spots we need but we still need the spells, the balancing design and a few minor changes in order to have a final product.

So the design was given to the lead programmer which discussed with the lead designer and created a short behavior tree which I created. The behavior tree:

At the moment I changed this behavior tree as the three attack phases and never implemented the phase 1 but a small melee range where the player is slowly killed if he ever comes close. I will change this and implement this feature. The spells has not been implemented, only a debugged version of the blast attack.

My behavior Tree:

My behavior tree always keeps track of the boss’s hit points, measures the distance between his target on every iteration. He then goes through which phase he is in by measuring his current hit points then rotates to Mokhtar, moves to his position (skips this one if he is already there) then looks at his attack range, which is just as large as the throne room and finally attacks Mokhtar. The only differences between the phases at the moment are the casting speed and his movement speed when he traverses between his phases. What is missing is the fart sequence which will be between the phases. I will implement those in the future, with the boss counter if Mokhtar ever comes at a melee range.

This is pretty special for me, this was the first time this project that I followed orders from the lead designer, discussed it with the lead programmer and designed this without any help (outside and inside). I have a new understanding of A.I design such as connecting blackboard variables with variables by setting values as objects, able to be used in other blueprints. One mistake I always did was making sure variables were public hehe, easy mistake but nevertheless, a mistake. Another thing I designed was the A.I and the players collision boxes. Hard at first, I quickly found out how to create custom collision boxes that are able to collide with only spells.

I also changed the level, fixed a few variables and started writing my dissertation! I will talk more about these changes and how I will start collecting data for my dissertation next week, stay tuned!