content top

Regaining Control

Even though we are currently making lots of progress with the game, adding content as if there was no tomorrow, there are still a few key issues we need to address. One of them is controls. And digging a bit deeper, we can also divide the issue into two problems we have to deal with: Teaching players how you should handle the leader and mob’s movement, and finding an alternative control method.

hazardNEW

Testing can be so much fun if you are not the one following the flag

Our idea is that the game should play kind of like a twin stick shooter. You control the leader with one stick and the mob the other. However, this is not so easy to convey to new players. It takes some time to get the hang of it, some players even play for quite long without nailing it. We tried different ways to transmit this to the players, through tutorials and the like, but now we are going to test if we can solve this by changing the control scheme a little bit.

EsquemaNuevo_00

Current control scheme

The second issue is that, until now, the only way to properly play the game is with a controller. You can play it using the keyboard (that is what we do most of the time while testing it) but it is not the most comfortable thing in the world. You may end up having to press five or six keys at a time. Our plan is then to give players more options, but we don’t even know if it is possible to have the same experience as using the controller with the keyboard (or another device). To find out if it is, we are going to carry out a series playtesting sessions with different control schemes.

So far, I’ve mentioned these control schemes a few times, but what exactly are them, you may wonder. Well, here they are:

  • Scheme N°1

Nowadays, you control the mob with the controller’s right stick. If you move the stick, the mob will move in that direction and destroy anything nearby. If you release the stick, the mob returns to its original position, around the leader. With this control scheme we change that. If you move the mob to the right and then release the stick, the mob will move to the right and remain there until you move it elsewhere. Granted, this may not be so much a different control scheme as a change in the mechanics but we have the hypothesis that this may affect the way people use the controller, making it easier to master. We will see if that is the case.

  • Scheme N° 2

We wanted the controls to feel like those of a twin stick shooter, so instead of reinventing the wheel, the first thing we did was looking into what other PC twin stick shooter had done. It wasn’t long before we ended up going back to The Binding of Isaac. It’s controls are basically those of dual stick shooter using the keyboard, and it plays and feels great, so we set out to test a control scheme very similar to the one The Binding of Isaac uses.

Isaac sure could've used the help of an angry mob down there

The control scheme of the original The Binding of Isaac

You move the leader using “ASDW”, the mob using the arrows and dash with the “Space” key. The only difference in our control scheme ended up being the keys bindings for the items. While Isaac has only two items (the bombs which you use pressing”E ” or “Shift” and the cards with the “Q”), we have three different items, so we decided to go with “Delete”, “End” and “Page Down” instead of “E” and “Q”. Those three keys are usually placed together, and they should be right next to your right hand (which will be most of the time over the arrows), that’s why we thought they would be a good choice.

As a side note/disclaimer, I feel inclined to point out that the game will have the option to set the key bindings in any way the player wants (you can already do that in the current build). But we want the default key setting to be best it can possibly be, that is why we are devoting time to find the perfect key setting.

  • Scheme N°3

Last but not least, scheme number 3 once again turns to the wisdom of PC twin stick shooters. Which is the control scheme of choice in 99% of those games? Mouse + keyboard! So we are giving that a shot. You move the leader with the keyboard (either ASDW or the arrow keys)  and the mob using the mouse. You use items with the mouse buttons (left, right and middle mouse buttons), but you could easily swap the buttons for the keys from scheme 2 if you don’t believe in multiple mouse buttons.

It may be worth mentioning that this is not the first time we have tried using a mouse and keyboard combination. However, we never playtested it (I played for a little while and then dropped it because it felt odd), so now we are going to have a bunch of people play it and let them know how they felt, before making any decisions.

 

Now you know what we are going to be playtesting, but when? Who?  How? Well, in a few days there will be a local games event called Meet the Game, where, as the name suggests, there will be people, there will be games, and they will meet. We are going to take that opportunity to use those people as guinea pigs and playtest the different control schemes. So, join us next time, when we will let you know how the playtesting session went out and which conclusions we reached!

bannerMeet

Read More

Introducing Ephesos [Part 2]

Last week, we started talking about Ephesos, Okhlos’ new world, and we left a few things out. This week, we are gonna solve that.

ENEMIES

We have some new enemies for Ephesos. Mainly the Centaurus and the Forest Giants. Granted, Forest Giant is a silly name, but they are powerful enemies, we promise!

gigante

This is the second Gigante (Giant) we introduce! The first one was the shield bearer. And we still have a few more to show!

The Centaurs, on the other hand, they are a very different enemy.

CentaurA

For starters, Centaurs will search for you, and try to trample you. So, their attacks are continuous and in line.  You’d better try to dodge them, because they will not stop even if they hit a unit.

Another thing that they have, is that they can crash with the buildings, and this hurts them. This was something that came from the early prototypes, and we don’t know if it’s a good fit for the current state of Okhlos (having changed so much since then).

HAZARDS

In the subject of hazards, the new ones in Ephesos are these kind of bear traps. These traps will hurt any unit that walks on top of it.

ArtemisTrap

Also, there is a new variation of the exploding barrel hazard, but they involve only graphical changes.

ARTEMIS

Artemis is Apollo’s sister, so in character design terms, it was pretty easy to develop her.

You can see that she has lots of things reminiscent of Apollo. And we translated some of the yellow elements to green ones, in order to push the nature theme a bit further.

ArtemisApollo

Artemis also has a few special attacks, like filling the stage with traps, and shooting arrows like his brother. It’s very likely that she’ll have a third attack, but we haven’t done it yet.

As for the stage where she is, we are currently using a placeholder, but she’ll definitely have a version of the Temple of Artemis, and a huge open area for the battle. As one of the cool things about her is that she places traps, having terrain covered by buildings, thus not being able to place traps there, can nerf that. As with Ares, this boss is much more enjoyable with an open terrain where you can fight her. Obviously, we can’t just put a blank chunk, we have to decorate it!

ArtemisChunk

Well, that’s pretty much Ephesos. We still have a lot of work to do here, but with all this, you can get a grasp of how it will feel like!

 

Read More

Introducing Ephesos [part 1]

In the huge 0.4.0 version, we added a big feature that we barely mentioned before. That’s Ephesos.

Ephesos is a new world in Okhlos, and the hometown of Artemis. We still need to work a lot in Ephesos, but we could put enough to have a stable version for the IGF.

 

This makes Ephesos our third world! And right now, we are making a few more! We hope to have quite a few more by the end of the year.

 

So, what’s going on with Ephesos?

THE NAME

We decided to start working with Artemis, and we needed a place. We started with Brauron, which was a good fit for Artemis because it held The Sanctuary of Artemis, and also because of the green. We wanted the Artemis’ world to have lots of green. We wanted some kind of city invaded by plants, and Brauron seemed just right. We even started making most of the world’s assets with that name. However, we weren’t 100% convinced that placing the action in Brauron was a good idea, mainly because of the name. It’s not very likely that you’ll associate “Brauron” with something Greek. Brauron seems more like British.

We knew that the name was not perfect, so we kept searching for a better fit. Finally, we found Ephesos, which had everything we wanted.For starters, Ephesos was famed for having The Temple of Artemis. It’s also very green.  Also, it sounds sooo Greek. Anyway, we are extremely happy with the new name. It was a perfect fit, so we gladly went on to change the names of the assets.

Ephesos

Keep in mind that still is a work in progress.

BUILDINGS

So, apart from the stupid amount of trees, Ephesos has simple buildings because it’s a rural area. It doesn’t have too many shops, and there are lots of farms.

Edificio1

Edificio2

Also, we had to put lots of fences, and we started using special transitions. In Delphi and Sparta, the transitions between a level and the next one were almost identical, with just a texture swap. For Ephesos, we started making these new transitions, and it’s very likely that in future  worlds we  will make many more new transitions, and not just  texture swaps.

Also, a new feature in 0.4.0 is that when entering the boss level, the transition will be slightly different, in order to let the player know that he is about to fight a boss.

transicion1 transicion2

FOUNTAINS & ROADS

Another thing we did was adding some grass and foliage to the fountains and statues. That really made them stand out.

fountain

The roads were a pain. Really don’t know why, but it took us some time to get them right (also, we feel that we might be revisiting them in some time).

roads

 

Next week we will continue discussing the new things in Ephesos!

Read More

Road to IGF 2015 [Part V of V] The Changelog

And so we come to the end of our five-part series, Road to IGF 2015. Just a few minutes ago we submitted a build to the IGF. The last few weeks were a bit hectic but they have also proven to be fruitful. There mere fact of setting the submission date as a deadline to have a new juicy version was a good idea, and it helped us make a lot progress. Plus, we are very excited to have a chance to show the game to the IGF judges. But, enough of that, to the changelog!

changelog040

It has been a long time since last posted a changelog. We’ve actually had three small versions since the last post (0.3.3, 0.3.4 and 0.3.5), which were too small to deserve their own post, so we will be including them here along with the latest one: version 0.4.0. Here are the changes (in pseudo chronological order):

—————-VERSION 033

  • New Heroes: Theseus, Elviros, Jason and Achilles
  • Units in the mob don’t have back animations any more
  • Zoom effect when the last philosopher dies
  • Several graphical fx added

—————-VERSION 034

  • New heroes: Drakularos, Pirithous and Pandora
  • Camera adjustments
  • Tutorial level implemented

—————-VERSION 035

  • New heroes: Pericles, Paris, Atalanta, Antigone, Andromeda, Helen, Castor & Pollux and Electra
  • A new way to generate the levels was implemented, which adds much more variety (and will save us a lot of work)
  • New defeat condition: You lose when the mob meter reaches zero and you have no more people in the mob

—————-VERSION 040

  • New worlds: Sparta and Ephesos
  • New enemies: Shield Bearer and Centaurs
  • Alpha transition for buildings
  • New hazards: Fire, Spikes, Giant Bear Trap and Cart with explosives
  • New bosses: Ares, Phobos, Deimos and Artemis
  • The finish moves system is now less lenient and has better feedback
  • HUD elements now fade out instead of disappear bluntly
  • Adjustments to tutorial level: we playtested it and made several changes based on that
  • Healers now regenerate other units health slowly over time and healing items (pork leg) heal a lot health at once
  • Heroes in the market are no longer random, they now follow a set of rules
  • A new unit’s stat system implemented (as seen in this post)
  • New life bars for the bosses
  • Heroes that you can/can’t buy are now highlighted in the heroes market
  • Random skill generator added
  • Difficulty adjusted in Delphi and Sparta adjusted (so as to have a difficulty progression throughout the three world)
  • New Sounds straight from Gordon, including but not limited to,  footsteps, attack/victory/death unit shouts, and sfx for all the enemies in Delphi (including Apollo)
  • More chunks (our level generator’s main component) to add more variety in the levels
  • FMOD sound engine implemented
  • Hero markets now show up only between levels: Markets used to spawn randomly somewhere inside the levels, now there will always be a market at the end of each level
  • Minor performance optimizations (you can now get a larger mob without your cpu dying in the process!)
  • Brand new displacement marker sprites, as seen in part I of this series
  • New Heroes: Cadmus, Daedalus, Hippolyta, Medea, Meleager, Narcissus, Patroclus, Penelope, Gaspode and Midas
  • Poppy, catchy and flashy introductory animation added (with corresponding sound and music)
  • New fx for the bureaucrats, so that the unit they affect is easily recognized
  • New artwork for the gates that lead to boss levels
  • More fx added to all the gods (now a 76% more imposing!)

… and lots of minor changes, bug fixing, bug adding and polishing.

 

As you can see, we have been pretty busy, but we still have a long way to go so we will keep on working. And hopefully, it won’t be so long until we can show you a new changelog!

And because you are worth it, spoil yourself with a few screens of the new version!

0001 0000 02 03

Read More

Road to IGF 2015 [Part IV of V] Effects for the Gods

Hey there!

Just one week to the IGF! And we still have a lot to do!

 

For starters, besides the IGF we have to give a talk at Tecnopolis on Saturday, so that will take some of our time.

Because we have to be there on Friday too, we must have the build almost ready by Thursday. After that day, we decided that we wouldn’t add anything new to the build (so you can imagine how hurried we are).

logo

As I said before, on Saturday 18 we will be giving a talk, so we can’t work on Friday or Saturday. The next Wednesday we will have to  submit it to the IGF, so we have Monday and Tuesday to fix any issues that we may find in Okhlos’ new version.

oradores

All of this is stressing us a lot, but we are glad that it’s almost over!

 

Anyway, as we have so little time, I think it’s a good idea to brag about some new effects we are working on! The game still needs a lot of “Juicy“, so adding fx is a good way to give feedback to the player, letting them have a good idea of what’s happening . We still need to push a little further the audio in that part, but Gordon is working on it.

 

When you have done 3 different gods for Okhlos, you start learning things you will use for the remaining ones:

1.- Be consistent

2.- K.I.S.S. (Keep It Simple, Stupid)

Following these rules, one thing we decided last week, is that every god will fly. I was finishing Artemis walking loop, when I stumble upon these rules. We already had two flying gods (1), and is much easier to do a flying animation than a walking one (2). So I threw away the ongoing animation, made a new one, added a wind blowing fx below the gods, and voilá! They are flying.

Apollo Flying

There it is! (WIP!)

 

Another thing we changed was the death animation. Ares was the first God I drew, so he had a lot of issues, and I learned a lot since I made him. For Apollo and Artemis I made a much more cool / powerful death animation,  so, following these two simple rules, I changed Ares’ death animation.

aresmuereViejo

This was the old death animation.

 

AresMuerte2

This is the new one.

As you can see, there is a big difference between the animations. The second one is more “epic”.  Also, it’s just a little bit easier to animate. And finally, it’s consistent with the rest of the gods.

 

We learned a lot after working a few gods, and that gave us a better understanding of what we are doing.  The best advice we can give in this matter, is that if you have to make 12 Olympian gods in your game, make 3 or 4 together and that will give you a better idea of what you are up to.

 

Next week, we will be writing the final post of ROAD TO IGF series!

 

Read More

Road to IGF 2015 [Part III of V] Inheritance 101

Last week, while working on some the heroes, we ran into an almost a textbook example of the use of inheritance and we thought of sharing it. If you are programmer this will post will most likely be too basic, but perhaps you are just taking your fist steps at coding, or it is something you just dabble a bit in. In that case this may be useful, and also it is a chance to show you a bit of the game’s code and structure.

It all started with Orpheus. Quite a while ago we decided to add Orpheus as one of the heroes in the game, and that giving a boost the units nearby (the units that were close enough to hear him sing) would be a suitable ability for him.  And so we did. Roque drew him, animated him, we added some code and voilà. Orpheus was in the mob, all was right with the world. However, some time later we thought about adding more musicians to the mob, and giving them the same ability as Orpheus. It seemed like a good idea, half the work was already done and it made sense that musicians would have similar abilities, so we created Elviros.  You can see below a bit of the code for them.

 

Elviros_800x700

A chunk of Elviros’s code … which you can see was oddly similar to Orpheus’ code

Orpheus_800x700

A chunk of Orpheus’ code

 

 

 

 

 

 

 

 

 

 

 

Unsurprisingly, since they both do pretty much the same, the only difference in the code were a couple of values (Orpheus is better at what he does, sorry Elviros). Not only this, our plan was to add a few other musicians as well, so we were probably going to have to copy that code a few more times too. Here is when inheritance comes to the rescue. We created a new class called HeroMusician, which contained all the code for the special abilities, and made Elviros and Orpheus inherit from that class.

 

HeroMusician_800x700

One script to rule them all (or at least those two)

 

Now if we have to make any changes the musicians abilities we only have to change the code in the HeroMusician class instead of doing it throughout several classes. And Orpheus and Elviros’ code is now much smaller, pretty much nothing but setting their stats and modifiers. The magic of inheritance.

 

NewElviros_600x300

Brand new Elviros’ code

NewOrpheus_600x300

Sparkly and shiny Orpheus’ code

 

 

 

 

 

 

 

The real trick while dealing with inheritance, however, is not learning how to use it, but learning how not to overuse it. Your code can soon become flooded with tons of classes that do almost nothing but look neat in a hierarchy tree. It is very tempting to start adding classes because it makes sense object-wise, to scrape a couple of lines of code from some method, or because you may need them in the future, but you should think carefully before doing so. Having a thousands little classes can make your code as unreadable as having classes with thousands of lines of code.

This is why our policy has from day one adding classes only when needed, like in the example above. And based on that philosophy that we ended up with our current class hierarchy:

Units_Hierarchy

 

You can see the new class HeroMusician in the lower level, which means that Orpheus and Elviros not only inherit from Hero Musician but also from Hero, Unit and Destroyable. Is this the best way to do it? I can’t tell for sure. The hierarchy may change in the future, but we will try to keep on working with the same strategy, without abusing the wondrous inheritance.

 

Edit: There have been some very interesting and accurate comments on reddit, mostly about the subject of composition vs inheritance, which point out a couple of things that are worth mentioning here as well. Several people pointed out that the problem of the musician heroes could have been solved using composition, for example making the musicians ability a component and adding that component to the appropriate heroes. It’s true. I never mention composition in the post but as is it also pointed out in the comments, favoring composition over inheritance is a more scalable approach, and can be an effective method to avoid ending up with a cluttered class hierarchy.

 

Read More

Road to IGF 2015 [Part II of V] Stats that Matter

Let’s talk about stats. Every creature in Okhlos, from the Gods to the bureaucrats, has a series of stats that describe how hard the creature hits, how fast it moves, and so on. We didn’t want the game to revolve around micromanagement so these stats are mostly hidden from the player. They are there, and we are doing all kinds of jazzy things with them, but for the most part you don’t have to worry about stats. However, if you do want to get a sneak peek of what goes on behind the curtains you can do so at the pause menu.

Attack 22, Defense 8, Speed 12, Morale 10, Poetry 10. I guess he writes pretty bland verses.

The mighty pause menu, featuring the stats of Eudokos, the warrior.

There, you will be able to see the stats for all the units in the mob.  Most of them are self explanatory: strength determines how much damage that unit will deal, morale determines how prone the unit is to leave the mob when things get too nasty (we’ll see more about that later),  defense reduces the damage taken, etc. However, you may wonder about the values. Where do they come from? Is a twelve good or bad? How about that eight?

Well, to start, each type of unit will be better or worse at certain skills. The table below will show you:

CITIZEN                     Attack: Med           Def: Med        HP: Med     Morale: Med       Speed: Med
WARRIOR                 Attack: High           Def: Med       HP: Med      Morale: Med      SpeedHigh
DEFENDER               Attack: Med           Def: High       HP: High     Morale: Med      SpeedLow
PHILOSOPHER      Attack: Low            Def: Med      HP: High      Morale: High      Speed: Low
SLAVE                          Attack: Med            Def: Med      HP: Med      Morale: Low       Speed: Med
LARGE ANIMAL     Attack: Med            Def: Med      HP: Med      Morale: Med       Speed: High
SMALL ANIMAL     Attack: Null            Def: Low       HP: Low      Morale: Med       Speed: Med
BUREAUCRAT        Attack: Null            Def: Med       HP: High      Morale: High     Speed: Med

Then to translate these low/med/high values into numbers we use this table, selecting random values from these ranges.

LOW          0-8
MED          8-14
HIGH        14-20
HEROIC   20-30

You can see that there is an extra tier, heroic, and you can guess what we use it for. That’s right, heroes. Heroes can have stat values that go beyond that of regular men and women (and oxen), that is why they have their own tier in the stats table. Enemies also have stats that go beyond this table (specially gods, you don’t even want to know the attack value a god can have). And then there is also the subject of multipliers and bonuses but we’ll stick to regular stats for now.

Finally, the last step to generate the stats is to add a little extra deviation to make each unit unique. There is always a little chance that any unit may be particularly good at something they are not supposed to, or even better at what they are supposed to be good. So, this is how the mighty warrior Eudokos, ended up with an impressive 22 in strength (way above average). I hope I could say the same about the rest of his stats, but they are not so impressive. Low defense and hit points, he may not last very long…

And so we come to the end of this little tale of stats. I hope by now you can get a better idea of how the units in Okhlos work, and also that you can appreciate how messed up the image below is. Until next update!

Strength of 1428, this is a seriously beefed up slave

Keep in mind that we do not approve the use of steroids

 

Read More

Road to IGF 2015 [Part I of V] The displacement marker

Last year, we wrote about how we almost submitted Okhlos to the IGF. We were about to do it, but we decided to back off because we thought that Okhlos wasn’t in proper shape for something like the IGF.

This year, we are much more confident. Okhlos is far from complete, but in its current state, it has lots of crazy things happening that we think are cool. Also, the visuals are on more solid ground. And that’s without mentioning that the game has changed a lot from those days, when things weren’t procedural, and we didn’t even have a roguelike foundation.

That’s why, this week, we are starting the “ROAD TO IGF” updates. They will all be very brief and straight forward, in order to make the most of our time from now on until the 22nd of October. The final update in this saga will be just two days before the deadline, and that will include a changelog from this version to whatever we have in a month.

Now, for this week:

The Displacement marker

There are certain GUI elements that are crucial in a game. In Okhlos, one of the most important elements is what we call the displacement marker, that little flag that shows you where are you directing your mob.

At first, this was a very difficult concept to explain. People didn’t seem to grasp the idea of moving the mob alongside their character, or using the stick in order to attack.

displacementMarker_Viejo2

Ye olde displacement marker. So long buddy…

So we solved this (at least for now) by changing the graphics according to the context.

mueve

So, if you need to move the mob, your displacement marker will show you where they  will move (approximately). But if you are near an attackable thing, the displacement marker will change. We think this will help tell what’s interactive and what’s not.

ataca

Right now, we drafted some ideas about how it should look, but we aren’t quite sure about which direction should we go. They are very showy, that’s for sure, but when you have 50+ people around, maybe you need showy. We still have to try something more subtle though.

displacement_Contexto

Here, you can see the displacemen marker in context

Also, we prepared an alternative, which is the arrows rotating, and the swords pointing and scaling. Exactly the opposite of the previous one.

Mueve_Alternativo

Here you can see the arrows rotating around the marker.

Ataca_Alternativo

And the swords scaling down

We’ve just arrived at these options, so any comment or feedback about this is super welcome!

Finally, another thing we had to decide is to make the displacement marker a billboard or not. All the units in Okhlos are billboards, which means they always face the camera. Opposed to that, not being billboards means that they will be just stand there, and that they will not rotate according to the camera’s position.

I think, in this case, the best solution is to not use a billboard. This will give the player a better sense of depth, and a better idea of the position of the marker.

comparision

It’s veeery subtle, but it’s there!

 

Anyway, that’s it for this week! We will be working hard in order to have a cool build for the IGF. Wish us luck!

 

Read More

Iterating like a BOSS

I’m a big fan of iteration. I love letting some time pass and then revisiting something. The problem with iterating, is that takes too much time. Sometimes you have to do the same thing two or three times.

In this sense,  ideally you want to do it right the first time. Of course, you can’t plan on doing it right the first time. You can try, but it’s very unlikely that you will have it right at first.

Time is another huge factor. Sometimes, you just want to see your work in game. Seeing things implemented, even when it’s a draft, can help a lot to give you an idea of how it will look and feel in the game. Context is important.

This week, I will show you the difference between the first and second versions of a character. I think that a few of these tips are useful not just in pixel art, but in almost every creative field.

The important part: If you are not extremely happy with your result, do it again!

 

Now, the example:

The last weeks, we’ve been showing you the Shield Bearer, an Ares warrior who takes cover behind a giant shield.

ShieldBearer

This is the original enemy design. If the character is looking forward, the only way to attack him is from behind, and vice versa if he is looking back. He always moves and attacks behind the shield, so you have to sneak from behind. We can start from here.

 

Idle Animation:

shieldBearer_idle1

IDLE – Old Version

 

shieldBearer_idle2

IDLE – New Version

As you can see, the base gesture is not horrible, but it doesn’t suggest action, and the stance is kind of boring because he is just standing there. The new version is much more dynamic. It has the same number of frames, but you can see that he is waiting for action! Also, you can see some shoulder deformation, almost like a hunchback. This was unintentional, but I thought that it added personality, so I left it.

 

Attacking Animation:

shieldBearer_ataca1

ATTACK – Old Version

shieldBearer_ataca2

ATTACK – New Version

The new Attacking Animation preserves the same stance from the new idle animation. This version adds an extra frame, and that gives a little more momentum prior to the attack. Also, I reworked the cape, because the previous one was awful.

 

Running Animation:

shieldBearer_corre1

RUNNING – Old

shieldBearer_corre2

RUNNING – New

This animation also derives from the idle stance.  Like in the other cases, there wasn’t much I could use from the former animation, and I had to redraw a lot.

 

Turn Animation:

shieldBearer_daVuelta1

TURN – Old

shieldBearer_daVuelta2

TURN – New

The turn animation had the same problem as the idle one. It lacked action. Using the idle animation as a base, we could do something much more dynamic. Also, we added a subtle movement in the foots, that helped.

 

Back Animations:

__comparativaAtrasVieja

RUN / ATTACK – Old

__comparativaAtrasNueva

RUN / ATTACK – New

Back animations are a pain. A real pain. They are awful to do. They don’t look good, and that was a perfect excuse to stop doing them for the mob units.

In some enemies, we still have to do it. This was the case of the Shield Bearer. The back animations are as important as the front ones, so we had to add some love to them. Also, with the new animations, it’s much easier to read where he is facing at.

 

Animating these enemies is a completely different task than animating the mob units. I’ve learned a thing or two animating these giants: It really helps drawing some guidelines on top of your character, and not to think so much about reusing every part. You might need to redraw an arm, or the torso for a particular pose, but that will give some life to your animations.

DraftAnimation

 

The little blue cross you see below the character is a small mark I do to know the absolute position the frame must have in the .psd file, since each frame will be automatically exported into .png.

The blue / red thing is to have a better reading of what’s happening. You might need that when you are trying to understand a couple of strokes in a 50px canvas.

 

So that’s pretty much it for this week. It’s a bummer to have to redo some things but, in the end, it’s usually worth it.

 

Also, this week makes the debut of our new comment system with Disqus. Feel free to leave a comment to test it!

 

 

Read More

Shooting like an Amateur

This week we are going to take the opportunity to show you the dirty secrets behind some of the mob’s favorite enemies. We are going to make a little trip inside the minds of the Hosioi, the Shield Bearers and Phobos to tell you about a couple of little twitches we have used to improve their behavior.

It is much easier to make an AI with perfect accuracy than make it have a realistic chance to miss.  This is why I hate when robots and androids in movies miss their shots as if they were space cadets. Specially when shooting laser weapons, they don’t even have to compensate for wind speed, direction and things like that! Who makes these purposely faulty robots!? Do they do this to give the humans a fighting chance in case they rebel? Okey, that could be a good argument, because they end up revolting against living beings a lot… But I digress. The point is that is easier, more even so in the case of a simulation where you control all the environmental factors too.

A Hosioi hitting people with his fireball attacks

A lean, mean, fireballing machine

Back to Okhlos. Do you remember the Hosioi? Apollo’s acolytes that shoot fireballs? Well, the Hosioi’s first prototype had perfect accuracy, because they were put together very hastily. The code simply said, the target is at that point, shoot to that point. And since the fireballs were pretty fast there was little chance to avoid them. Our next step then was to make the Hosioi fallible. To do achieve this we did two things: first we added a little randomness to the shots. Not much, but just a chance that when the Hosioi shoots the fireball it comes a bit skew. The second thing we did was making the Hosioi track its target’s position with a little delay. This way the Hosioi will have less chances to hit a moving target but will be more accurate against still targets. And so, with two little changes Apollo’s acolytes went from relentless machines that never miss a shot to being fallible creatures just like you and me, having to aim their shots and sometimes experiencing the bitter feeling of wasting a perfectly good fireball.

A Hosioi missing a shot

Too fast for you, Mr. Hosioi!

 

Something quite similar happened with the Shield Bearers. You remember them, don’t you? From Sparta, big shields, not bears? Well, they don’t shoot anything (they trust their nasty shield bash to punish people) so the attack wasn’t the problem here. The problem here was their movement. Shield Bearers hide behind their towering shields, making the only way to beat them to attack them from their backs, and if they see the enemies are moving to flank them they will turn and face their shields towards them. So if they can follow the enemies’ movements accurately and respond immediately to them,  it becomes nearly impossible to hit them.

ShieldBearer

Yeah, you remember him!

We knew this from the start, so the Shield Bearers are one of the few characters in the game that have a “turning” animation. Everything happens so fast in the game, people are running from here to there all the time, that simply flipping or switching sprites is all that is needed most of the times, but in this case we wanted the Shield Bearer to take some time to turn around, hence the animation. But it wasn’t enough. It takes time to maneuver the mob so the few moments the animation gave you were not enough. This is when we turned to one of the tricks we had learned with the Hosioi, tracking the enemies position with a little delay. This way you may get enough to get them before they face you again, and the idea of these giants hiding behind their massive shields being a little slow makes perfect sense too.

 

The Shield Bearer making his signature turning move

Shield me up, Scotty!

 

Last comes the story of Phobos. Not long ago we decided that Phobos would move around by leaping from place to place, kind of in a hulk-esque way. He is a big guy, bulky and mean, so it is pretty cool to see him land next to you and take a swing with his mighty axe. But, as you may have guessed, not everything was perfect at first. Deciding where to jump was the issue here. The easiest thing to do was just get the mob’s position, either the center of the mob or the leader’s position, and jump there. But that didn’t feel good so we had to resort to some of our old tricks.

 

Look at him go!

White gods can’t jump

 

In this case we used randomness again. Adding some randomness to the jumping target position meant that sometimes Phobos would end up just ahead of the mob, seemingly anticipating the mob’s movements, or a little behind them, giving them a chance to escape or head back and engage. The result was something much more interesting than having him always jump into the middle of the mob and attack everyone there.

 

Is there are morale to this story? Of course there is, thousands of hours of watching pre-Seinfeld sitcoms taught me there is always a morale at the end. It may be that little changes can make a big difference. Or it can be that one of the keys to making an AI more real is to make it fallible. Or that random numbers are awesome. But there is definitely a morale in there somewhere.

Read More
content top