A Summer Tale

It has been a while, thanks, no you too.

The summer gave us the a nudge, making us want to tell you guys so much about our game so far!

We are still finishing up on our art, I don’t want to give anything away of course (http://puu.sh/j5sjf/a8ed655175.png), it would not go well with the lead artist (http://puu.sh/j5spa/36536faf01.png) so that’s that.

We are currently on our way to implement our unique new system !
Combos.

Combos will provide the solution of not having a button mashing beat’em up. We’ll talk about it when the time is right.

So far, our enemies have been painted, most of their animations are done, behaviors are available and we are currently 66% done with two A.I enemies.

Now usually, when it is so close to the beginning of this development, developers are very careful not to spread ideas this big around (http://puu.sh/j5sMq/79a0c38036.png). Therefore, I will not be able to show the next enemy.

There is a lot explained on the systems available on the groups own work during development (or just their thoughts). You can find them here: http://www.asnailtale.com.

A Snail Tale Update

This week has been fruitful for the snail gods.

Our lead programmer Frederick has been working on getting the mechanics on the running done, we were searching for a character that accelerates quickly and decelerates when switching sides. I believe we’ve achieved it, unfortunately, we don’t have footage yet but we will soon enough!

Our lead designer Topi has finally created the three most important pages on our concept document and it is getting sharp!

A snippet for your imagination!

“A Snail Tale is a 2.5D beat ‘em up game for the PC that will utilize everything that made the old arcade beat ‘em ups so memorable. It will be featured with controller and keyboard support.

A Snail Tale features both singleplayer and multiplayer campaign modes with cooperative play.

The world of Skingdom is at peril, warlords from the Bruti faction has started an invasion upon the land and the crown is in jeopardy. It is up to the Skindi Order of Knights to repel the invaders and bring peace upon the land.
The Order provides the player(s) with seven different classes, all with their own melee, ranged or magical weapons and skills, to provide a personalized experience. Each knight defeats its foes differently, making sure everybody will have their own favorite knight to do battle.”

Very straight forward with awesome player controls is what I would call it.

We are currently deciding what type of sound we will proceed with, there is a discussion going whether or not we are producing chip tunes or not. Our sound engineer Zachary has created a sample for you to enjoy at his blog [http://zvankleeck.wix.com/emitter]. Tell me what you think in the comments =).

That’s all for now =)

Keep looking for updates each week!

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!

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

This weeks production on the helium engine

Working with the states gave me a better understanding on something I’ve worked with for some time. I’ve been looking at each feature we’re putting in such as 3rd person camera, a cube, a goal, a button(GUI), a HUD and been thinking how each class should be structured.

Its pretty simple if you think about it. You have a function that constructs the feature, another that update it if it needs to and one that draws it.

The problem we are looking at on every corner is how to construct the damn thing. Most issues have been very generic like sending 16 bits instead of 32 bits integers around the engine.

I was working this week mainly on implementing the HUD and co-operating with my partner implementing his heightmap. We actually had the same problems but I couldn’t understand how we didn’t see it before. We need to watch ourselves for more legacy code that’s obsolete.

Next week will be a hard one, I have to implement a working button on another state, put in working numbers(font) on the HUD, establish a goal class that knows when our racing car is on that specific location so it can quit the game.

All of this on one week while this week was hard just to implement a non-working HUD. We’ll see how it goes on the next turn.

Implementation in Helium!

I’ll give you guys a rerun on whats happened so far.
The class was given a 3D engine from the teacher to create a 3D game.

Most of the engine is already written such as the camera, scene management and all of their functions capable of creating a passing grade result.

The lectures we’ve been having before this was working on a shell of the engine just implementing the camera, scene, background, triangles, squares, 3D objects, height maps and HUD.

Thing is, with this new version nothing looks the same and now we have to connect it all and make sure it looks professional.

And if somebody haven’t been reading I am the average Joe. It feels like a chimpanzee understanding how to work a Swiss knife.

So my first challenge was to concentrate on getting a state up and running from where I can place the objects in. From here I can declare,  initialize, draw and update my objects.

My first problem was to understand that all the states inherit from the abstract_game class which basically is the engine. The engine class is just like any class, it initialize everything and connect most of the engine classes to the game specific classes.

So problem one solved.

After that I had to make sure the state manager has my state, attaches it and then use it as the first one.

We now have everything up and running!

Now we need to initialize all the objects and the engine systems in order to construct, draw and update the stuff we create !

I’ll leave you guys here I am afraid. Most of the time have been spent looking at the mountain of information, observing and planning my approach. I am not going to even talk about the amount of help I got(shout out for my class mates <3).

Good night all and I’ll see you guys after Christmas. Cheers.

 

Icing

So web servers have to wait a while. I’ve been making more progress on another assignment.

This time around we have been fortunate enough to work on a 3D engine. My assignment is to make a 3D game with a partner.
The genre we picked was racing. This time around the game is not the focus instead we will be focusing more on the systems built around it.

To be honest, most of the code has already been written before in different versions and most of the underlying systems have been pre-written before we even touched this assignment which made this assignment so much easier.

So what I am going to talk about is the systems. This is to make sure I myself understand them correctly so if you guys find anything badly written please comment below =)

So this is the way we are writing our engine.

The renderer systems is all but done and given to us before the assignment. Same goes for most of the resources. The Front-End was taught and the scene as well. A state management system was also beautifully written and given to us. Most of them haven’t been connected properly though. Some are just created and not even implemented correctly though and the funny thing is we got some of the code rewritten(parameters were changed order) in order for us to NOT copy code.

A super villain couldn’t have done it better.

So, most of our lectures have been about creating a camera, a texture, shader, buffer, a triangle, square, box, height map, moving the camera(or the world!) and understanding the fundamental part of how to construct a 3D world.

Its beautifully thought out in my opinion. As I see it you create a system that’s connected to each other more advanced for my mouse brain at the moment. You start by creating a window, like opening your eyes. Then you provide them with color by giving the world a background. You then create a parameter for your eyes, now you are allowed to move your head but there is an underlying fact here. You aren’t moving the camera throughout the world you just created, you are simply moving the world while the camera is still, neat huh?

After this mind blowing fact you start by creating the easiest geometric form possible with dots or vertexes(vertices), the triangle. By combining different triangles you can create the geometric shape you need from there on out. Connecting the vertexes together to minimize the amount of dots used and now you have a beautiful three dimensional box. Add some textures, shaders and buffers and boom, its a box!

Now lets say you create tons of boxes all around your camera. What would be the easiest and most efficient way to make sure the computer isn’t working its ass off to make sure these boxes are being rendered and updated all the time? You create a scene! much like a theater a scene is everything your looking at or what the camera perspective is looking at. Most of the hidden materials are already around you, you just aren’t looking there. So when you move your scene to the left some boxes stop rendering and the others takes their on the scene!

Beautifully thought out and most efficient when you got a 2 square km area filled with objects and your in the middle of it. This is called culling and scene management.

Now I will write the rest later today on another post as I am obliged by the course to do so.
Not really much code here because I haven’t really written anything. I’ll be talking more about the other implementations at the next post and the week after will be more about my own code =)

 

Cheers.