We are thrilled, exhilarated and ecstatic to announce that Okhlos has been selected to be part of the Leftfield Collection 2015, and as such will be at the EGX Rezzed event in London, next month. One of the biggest events in Europe! Handpicked to part of a prestigious collection! Wow! It’s such an honor not only to be part of the collection, but also to do it among such amazing games as the ones chosen this year. You can see the full list here and check for yourself how awesome the games are looking!

As for our part, we are working right now on a exclusive new version that will be playable at the event. It will have tons of new content and we will try to have as polished as possible. We are adding new enemies, new hazards, new hud and even new mechanics we have trying out. We aim to have to best version so far, in order to give everyone at the EGX the chance to experience Okhlos at its best.

So remember, if you are in London from March 12 to 14, go and play Okhlos at the Leftfield Collection!

Read More

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.

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.

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.

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!

Read More

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!

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!

Read More

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.

 

 

 

 

 

 

 

 

 

 

 

 

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.

 

 

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.

 

 

 

 

 

 

 

 

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:

 

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

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.

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      Speed: High
DEFENDER               Attack: Med           Def: High       HP: High     Morale: Med      Speed: Low
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!

 

Read More