chia seeds weight loss

content top

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

Sparta, Take Two

Last week, we talked about our “outside the box” solution to a particular problem with the Y displacement.  It wasn’t perfect, but we are almost proud of it (we don’t actually know what being proud is, but we read about it).

Before that, we had started talking about Sparta,  the new world we are working on. We showed a few bits of Sparta, and this week we will continue presenting new stuff!

CartelSparta

 

Another one of the new enemies introduced in Sparta is the Rock Thrower Cyclops. He will throw rocks at you (I bet you didn’t see that coming). He may not be as tough as the armored cyclops or giants, but his rocks can do a lot of damage to the units.

RockThrower

Here he is, grabbing a rock to throw. Ah, the Rock Thrower.

 

Besides adding more enemies, there were a few things we tweaked in Sparta.

In the previous world, Delphi, you could find a lot of shops in the city, like a meat shop, a fruit shop, and so on. In Sparta, being a much more “war friendly” zone, you will be more likely to find war-related stuff . Which meant that, in addition to a change of materials and textures, there were lots of structural changes in the buildings.

For instance, instead of a meat shop, you will have an Archery Range.

Archer

Needs an awful amount of work, but you get the idea.

And the buildings were just a small part in the process. You can push a little further the idea of a heavy armed city with props.  For instance, having some training dummies around. It really suggests that the people there are constantly training.

dummys

Breakable dummies everywhere!

 

Also, to have a heavily armed city, you need lots of weapons.

montonDeArmas

You can feel like Neo here.

 

And finally, we used the directional light to change a little the mood and the time of day.

luces

Well, that’s pretty much it for this week, and probably for Sparta. Next week we’ll be introducing a new world! (maybe)

Read More

Cameras, Pythagoras and faking it

A decision every game developer must face at one point or another is which camera angle to use in their game. Even in the case of 2D games, developers will have to choose between different perspectives (top-down,  side-scrolling, isometric, etc.), but this is particularly true for 3D games. Since Okhlos takes place in a 3D environment our case was not different. We started with the camera at a somewhat arbitrary position and rotation. Then, as time went by, we tried different angles and positions until we found something we liked. It wasn’t as easy as it may sound since we had two competing factors: on one hand we wanted you to be able to accurately see the mob and its immediate surrounding  as easily as possible, on the other hand we wanted to showcase the game’s art, the units, the enemies, buildings, the landscape etc. Gameplay wise the best perspective seemed to be top-down, clear and simple, but the top down perspective meant that you would be looking at roofs most of the time, and let’s not speak of how horribly incompatible it was with the billboard characters we had planned. The solution we found was the camera you can see in Okhlos’ current build: it lets you appreciate the art as well you give you a decent chance to spot those pesky Cyclops before they crush you.

 

A screenshot with the current camera position and rotation

Best camera ever

 

Happy ending, then? Not quite. There were a couple of issues. The first one was immediately evident. With the current camera perspective, people and enemies, could get blocked from the line of sight by buildings in front of them. It was a problem the top-down camera would have avoided but we now had to deal with. Luckily we were not the first ones to venture into the dangerous seas of isometric perspectives so we resorted to a solution many others have used in the past when faced with the same conundrum: making the objects that block the view transparent while there is something you need to see behind them.

 

A gif showing a building fading out when the leader goes behing it

Magic!

 

So now everything is settled and we can all move to happy land, no? Wrong again. Even though the view-blocking-buildings crisis was averted there was a new problem in the horizon. And this time, the problem at hand was not so evident. In fact we spent months without even noticing it. Throughout many version we played the game with the feeling that there was something odd about the way the mob moved, but not quite able to pinpoint which was the problem. Finally, during one playtesting session we came to the realization that the mob seemed to be moving more slowly when moving upwards or downwards than when moving to the sides. Once again this was due to the camera angle we had chosen. The mob did move in every direction at the same speed but the camera angle gave the illusion that it was the mob was moving at different speeds. Our solution here was to do something that would seem to be the problem in the first place, make the mob move at different speeds depending on the axis you are traversing.

So now, the mob and its leader now move 40% faster when they are going towards the bottom or the top the screen, than when they are moving to the sides. Why 40%? That’s when our good old and soon-to-be-in-the-mob Pythagoras comes to the rescue. The main camera in Okhlos is tilted 24°, and we know, thanks to Pythagoras, that by calculating the sine of that angle how much the view is distorted by the camera, and therefore how much we need to compensate. Hooray Pythagoras!

 

A screenshot showing the camera's angle and position in the editor

Here you can not only see the camera’s position, you can see the frustrum too! Delight in the wonders of the frustrum!

 

If we learned something from all this (and I hope we did), it was that dealing with the camera is an important issue. But we kind of knew that already. What we didn’t know was that sometimes the solution to a problem may be something completely counterintuitive. We ended up with a mob that moves at a one speed in an axis and at a different speed in another, which seemed to be the problem itself. However, it feels much better now, so this largely compensates the fact that you can traverse the levels faster by moving vertically (and by the way, now that know this, don’t exploit it!).

And so we come to the end of this week’s update.  This was not the last time we had to do something apparently counterintuitive to solve a problem, nor it was the only problem we had with the camera, but we will leave those stories for another time. Until next next week!

Read More
content top