Watch out! Ancient Greece has been taken by the dead! Hordes of zombies are lurking in Okhlos!

Starting today, and until November the 4th, the Greeks rampaging against the Gods will be infested with the Zombie plague.

Also, a few shadowy figures had been spotted! Pay close attention to some Philosophers…

The Okhlos: Zombie Edition update is totally free, so check it out now! And if you don’t already have the game, you can get it as part of Steam’s Halloween sale with a 40% discount!

 

Read More

Okhlos’ new version is here!

We’ve migrated from Unity 4 to Unity 5. And a lot of improvements were made. The most important ones are that now the game supports cursor lock on multi monitor displays, and an overall improvement in graphics, shadows and shaders. We’ve also changed the pieces left by a building when it’s destroyed, and a done lot of bug fixing.

Bug Fixes:
– The resolution issues which made you unable to play the game on some AMD configurations (mostly on some MacBook Pro) are now fixed
– Beating the game with Einstenos in the mob, no longer makes that if you start a new run at that moment it crashes upon finishing an area
– Fixed a loading freeze when trying to spawn a hero that was already in mob (inside one of the special  buildings)
– Fixed a crash after killing Hades (with Thucydides in the mob, and another hero affected by his ability also in the mob but dead)
– Gryphons can no longer get stuck flying away from the mob after killing a unit
– Flipped screen on Lemnos in some configurations when the anti-aliasing is activated
– Dying at the same as defeating a boss no longer makes you respawn at the next world but without a mob
– Pyrrho will now not kill any heroes, as part of his ability
– Stats are not stored any more during Crypto runs (as are persistent heroes)
– Panacea will no longer try to bring back to life disbanded units (which resulted in a mess)

Plus several other minor issues.

 

And lastly, here is a screen showing some of the new illumination and shaders.

Read More

We have amazing news! After almost 4 years of Development, Okhlos is out now!

 

These past few weeks we’ve been working on Okhlos a lot, and probably neglected a little bit the dev blog. We are still planning on doing some more articles about Okhlos, so stay tuned!

If you want to buy the game, use these links!

 

These four years had been an amazing experience. An experience which hasn’t finished yet. Today is launch day, and we don’t have any idea what we will be facing! Wish us luck!

Also, if you had been reading our ramblings all this time, thank you so much! We really appreciate your support!

 

What is Okhlos?

Squeeze into your toga and slide on your sandals to rally the angry mobs of Okhlos and bring down the oppressive god of mythological Greece! Your beloved people will not longer stand for the abuse from their deities and take up arms against them and taking down anything and everything in their path. Topple the beastly minotaur, bring down sacred temples, and confront the almighty Olympians themselves while recruiting and balancing your unruly mob with warriors, peasants, slaves and even livestock in their quest for freedom from Mount Olympus! It’s total anarchy in the birthplace of democracy!

The people are angry and have united behind the noble philosophers to do their bidding to take down the soldiers, mythical beasts and temples under the control of the twelve vile gods.

Carefully recruit your followers from warriors, peasants, slaves and beasts of burden and unlock special units or swap units for one of 100 legendary heroes to upgrade the mob and increase their savagery. Wield the power of Heracles, Leonidas, Pandora, and Socrates to turn your mischievous gang into a formidable army!

Every campaign against the gods is different with changes to heroes, monsters, and bosses – and even the mob itself – each time you and your followers set out for battle. Traverse eight procedurally generated Greek cities and never fight through the same world twice!

Make your way through all manner of beasts, warriors, and demi-gods to arrive at the feet of the maleficent Olympians and unleash the power of the people in epic boss battles set against ancient ruins before they were ancient!

Read More

Hey All!

This week we will talk about something very cool we’ve been doing. PLAYTESTING!

This is by no means an comprehensive guide on how to do Playtesting, it’s all very much focused on Okhlos, but I think we ran into some interesting bits, that might help on different projects, so we wanted to share them.

Let’s begin!

What is Playtesting?

When  we started asking people to take part in the Playtesting, we found that most of the people didn’t know what “they had to do”, or even if they were prepared to do it. A huge amount of people believe that Playtesting and QA Testing (or Functional Testing) are the same thing. And, of course, they are not.

Playtesting is a kind of usability test, where you can see how players read and react to the game in an (ideally) relaxed context. The idea is to see the player interacting in the way she/he would normally play the game. But with us breathing over their shoulders and taking silly incomprensible notes.

This is particularly useful to, for example, polish a tutorial. We always try to get people that have never played the game, so that we can see if the tutorial is really effective at communicating the mechanics, or if we have to be more clear in some areas. Also it’s really useful to help set up a good difficulty curve, and to check how good the feedback the game gives to the players is .

We’ve showed the game at lots of events. And seeing new people play the game is always useful, but when you are at an expo, the players don’t usually pay too much attention to it, they just want to try it. While playtesting the game at expos can point out some design flaws, you really need to sit down and analize what’s going on, and what would happen if they played the game at home, instead of in a loud and flashy (and sometimes smelly) environment.

Why we do it

We did very small amounts of playtesting during the development of Okhlos. Mostly at events. Sometime we’d invite someone to try it, or send a build to a friend and ask for notes. We never did a huge playtesting session before.

We were getting close to the launch (and we still are!) and we were having some discussions  (friendly, of course) with Devolver regarding the difficulty of the game.

We had been playing the game for so long, that it was almost impossible for us to judge the difficulty of the game by ourselves. For us, it was always was too easy. Devolver pointed out that the difficulty curve at the first levels was too high. And it seemed that there was a large group of players having difficulties with the game.

Sending a game and asking for feedback is not very useful because games are difficult to put in words. When you see the playthrough is when you realize that someone is not getting the idea correctly, or even that you might be asking the wrong questions. You should pay attention to the user session, what you discuss with them afterwards is just for ratification, but you are the one that has to identify problems and solutions. If someone says “I don’t like this, maybe you should…” you can stop listening there. You know your game better and your playtester should only communicate the problems they had, not the solutions (also, this depends on your group. We had very few designers for this playtesting intentionally).

We decided to do a Playtesting session in order to see what was going on regarding difficulty. Any additional information we could gather (tutorial, mechanics and feedback) would not be the focus, but a very welcome bonus.

How we did the setup

We started by reaching out on Facebook to any people interested in trying out the game (through our personal Facebook, not the Studio page just to be sure that at least we knew the people coming to our offices).

Because of this misconception regarding playtesting and functional testing, we had to stress a few times that no knowledge was needed in order to take part in the Playtesting sessions. We looked for acquaintances that had  never tried the game before and could drop by our offices to play a little.

The playtesting sessions went out of hands pretty quickly, Too many people wanted to try the game and give us feedback, so we had to narrow the list to twenty something people.

The session took us literally all week and because of their jobs people, lots of them wanted to come on the weekend.

A cool thing we did from the start, was trying to set every session pretty far from each other. At first, we didn’t know how much each session would take, so we assumed a two-hour slot for each participant. We thought that each user would play around an hour, so rounding it to two hours would give us plenty of time to get everything ready for the next playtester.

As you will found out later, we were clearly wrong.

Another cool thing we did was to add each playtester to our calendar. This would help us a lot when we had to rearrange the timetable. We have a gmail account for the studio that we use only for this kind of things, we shared the calendar with our personal calendars and started adding events. Pretty handy and stupidly quick.

The only problem with this was that for some random reason the timezone configuration was broken, so all our appointments were off by an hour when viewing from our personal calendars, and that created some awkward overlapping.

The sessions

For starters, we set up OBS to capture the player’s footage. Players would be sitting in front of the computer, and we would ask them how they usually played games at their homes, if they used a joystick or a keyboard and mouse configuration, and we would duplicate the screen to see the play session from another monitor. The videos recorded were at a very low resolution. Just enough to see what was going on. There is no need to have 20gb videos of hours of playtesting.

We also asked what language they usually play games in, and if they used headphones. We didn’t want to impose anything, and we wanted players to feel like at home. We even threw some snacks to improve the experience. If you have to play an incomplete and broken game, at least have some free food.

A little side note, we were surprised the amount of people that play games in English in Argentina. Probably half of the users wanted to have the game in English. This might be due to past experiences dealing with shitty translations, and trying to have the real deal, the true experience of the game. For me at least, even if Okhlos supports like 8 languages, and this blog entry is in English, the game’s main language is Spanish. There are some jokes that wouldn’t simply work in any other language. And we literally did whatever we wanted in the Spanish version. 99% of the game is the same in all languages, and the game should detect your system settings for language.

We had planned each session to last about an hour. In reality, most sessions took about two hours. And sometimes more. This is very positive from a game design standpoint. People just wanted to keep playing the game, but from a schedule point of view it was a problem. We tried never to say “Well, that’s enough, go home” but we had to a few times.

Because of the previous mentioned calendar bug, and the organic and always changing nature of people, we started to have people’s time slots overlapping. When this happened we had resort to setting up another computer with the game running, where we didn’t have the chance duplicate the screen.

When the playtester were playing, we tried not to talk to them to avoid distracting them. We also told them not to ask us questions. If there was something that they couldn’t figure out, we would jump in only if it was absolutely necessary.

At the end of each session, we would ask the player how they felt the game, if it was too hard, too easy, what they loved and what they hated, and if there was something that they hadn’t understood. Most of the questions were pretty redundant, because when you know your game you can get most of this stuff by simply watching them, but very interesting stuff came up from these five minute interviews.

In the middle of the week, we did some A/B testing with basic stuff (I will get on details about that later), and it was really useful. Because we knew that there would be no further playtesting after this, if there was something controversial that we wanted to test, at the beginning of each day we would discuss it and make a new version.

Saturday was chaos, with probably six or seven people at any time in our offices. They atmosphere was really relaxed and cool, but we couldn’t pay so much attention to each individual session like we did during the rest of the week.

The videos were incredible useful. When the week was over we started discussing what we saw and what we should change. Having the videos was a very quick reference to see what we were discussing. And my memory is pretty visual, so seeing the same thing might trigger what you were thinking when you saw the live performance.

If I have to draw a conclusion, is that doing playtesting is really important, is incredibly useful and even when you don’t want to burn off all your friends too often, you have to do it at least two or three times for project (obviously, this depends on the scope of the project).

It’s also a huge morale boost. We were very tired for the long and uninterrupted development cycle, and a little worried about Okhlos being too easy/hard/bad, but when we finished the sessions, the results were so good that it really injected us with the energies to keep working as hard as we were before. From a psychological point of view, it sounds very healthy for medium size projects. As long as you know very consciously not to go trigger happy with the changes.

That was pretty much our playtesting week, which was incredibly tiresome, but amazingly fruitful. If you came here to read only about Playtesting, good job! You are done here. Below, I will start talking about Okhlos particular results.

Okhlos Results

The response was overwhelmingly positive. Most of the people that came for the platytesting were even not acquaintances of us, who had found out about the playtesting through someone that shared our original post (which was not exactly what we planned, but we enjoyed the enthusiasm).

This made the tester brutally honest, but in fact, nobody said that they didn’t enjoy the game. However, we have the idea that one of the testers really didn’t like the game, he played a little less than an hour and didn’t want to keep playing. But statistically, it’s still a pretty cool outcome.

As we said, we thought that the game might have been be too hard. While balancing, tweaking the difficulty curve and through other changes, we think we found a sweet spot. Some players still found it kinda easy, so we are increasing the difficulty in some areas.

Some players pointed out something very interesting. They didn’t get enough feedback from the attack. When you press Defense, you immediately know that your mob is defending. They all stay still and defend. When you run or collapse the mob, you don’t have to focus your attention in any particular element, you simply see the mob and how it behaves even with your peripheral vision. When you are attacking, though, there is not much change visually. Yes, the mob moves slower, but not so much to be noticeable. The first tester who pointed this was our friend Juan from Heavy Boat.

This was one of the first changes we did during playtesting. We used the sprint sound in the attack, permanently. It was rough, but tremendously effective. Gord almost kill us for that. Players realized much more quick when they were attacking.

Besides this, we had another related issue with attack. Players that used Joystick where more inclined to understand to hold the attack trigger (maybe because it’s a trigger), but players that used the mouse,  would constantly smash the mouse button. That was something that we knew sometimes happened, but we were not sure how to approach it.

We did small animations in the tutorial boards, just to clearly state that you should hold the mouse button down. But maybe more interestingly, we decided that if players really want to smash their mouses, well, we should just let them! So Seba added a small delay when pressing the mouse, so if you let the mouse button off for a second, the mob will continue to attack. This helps in two ways, for starters, players realize that you can maintain the button pressed, but even if they keep doing it, there are more chances that the mob will attack. Before this, if you didn’t hold down the button, there were big chances that the mob wouldn’t start to attack, because they have to get near the target and there is some anticipation in the attack animation. So now it feels much better, and its still pretty responsive if you want to stop attacking immediately.

 

A small narrative change we did was regarding the procedural phrases Homer tells you each time the mob moves to a new city. They were generic and interchangeable. But @DavTMar suggested that in order to help the narrative, we should address specifically which city the mob was going. So we added the name to the city to the phrase (and we tweaked them a little), and now we maintain these procedurally generated, phrases but having the name of the city makes them more custom, and clear to the user.

There were tons of other stuff. We changed the items in the hud and we placed them directly on the mob, which is really cool and organic, and having less UI feels very good. We added tutorial texts, we revisited them, we scaled up buttons, we got ourselves very busy for the week following the playtesting. And that was pretty rad. We were able to address most of the changes in less than a week, which was very cool as well, as we weren’t hoping to finish so quickly with all the changes.

So, there you have it! Playtesting often is healthy, cool, incredibly useful and cheap. You don’t have many excuses for not doing it!

We wanted to close the entry with a HUGE THANKS to all the people who made the time to pass by our offices and helped making Okhlos better!

Drinking game: If you finished reading the article, then read it again but every time I said the word “playtesting” take a shot.

Read More

Hey all! It’s been a while!

Even while we are in the midst of going crazy with all the stuff we have to do in order to get Okhlos ready for release (and we still have some work to do in that regard!), we wanted to let you all know that Okhlos will be available to try in two huge expos!

We’ve disregarded the dev blog a little bit these last months because we had so much work that we really needed to focus all our energies into the game. Next week, however, we will be retaking our good old misadventures about development that you all hate to read, but you probably know us and had to anyway.

 

Weird introduction to subject matter, let’s now delve into what’s important!

Do you want to try Okhlos? It will be showcased at two different venues!

 

Kyoto BitSummit

The 4th installment of the Indie festival! So, if you are in Kyoto this weekend, you will be able to try the game! Note that the expo just lasts two days!

Also, players will be able to play the game in Japanese! Which was an interesting task (expect more about localization in future posts!).

#Okhlos now supports Japanese!
Sugoiiii!! Had to remove all unused glyphs from font in order to work#noticemesenpai pic.twitter.com/0N0BZYRcLY

— Okhlos (@Okhlos) June 7, 2016

For more info about the venue, check this!

 

 

Tecnopolis 2016

Tecnopolis is probably the biggest event in Argentina regarding science, technology, art and culture (culture basically encompasses the other three, but I wasn’t the one who came up with the slogan).

From what we know, Tecnopolis will be open from July 14 till October 15, so you have LOTS of time to try Okhlos! The game, obviously, will be in Spanish! :D

 

Tecnopolis will take place in Buenos Aires, Argentina. More info here

 

Well, that’s all for now! We promise to come back with mildly interesting bits of information about game development and whatnot.

Because you happen to reach the end of the article, here is a gratuitous gif! <3

Read More

Another week passes by in our endless Okhlos development cycle, and that means another devblog update with a few insights into our process. Mostly with examples about how NOT to do something.

This week, we bring you a subject that is still changing a lot. That is Persistent Heroes.

Types of persistent heroes

In Okhlos, you have two types of persistent heroes: Philosopher heroes and Basic persistent heroes. The basic persistent heroes will behave as regular heroes (that means that if they die, they will revive at the next world), except that, once you’ve unlocked them, you can choose to start each session with them.  The philosopher heroes are the ones you control directly, and they replace your current mob leader.

Why we put them?

Okhlos is a roguelike-like game, so each time you lose, you have to start over from the first world. We liked that feeling, but we wanted also to have a feeling of progress, besides how good you get with any particular mechanics. In this fashion, we wanted to have some bonuses you can get at the start of each run. Persistent heroes accomplish this, but they are also proving to be very difficult to balance.

Also, we wanted some type of mob management. We always felt that adding too much management to the mob would be counterintuitive, because the mob should be more of an organic thing. The good thing about this, is that you only have to do it when you start the game, not in-game.

This is the main reason we created the Agora, which is a hub where you select these heroes (and also where you can do a few more things ;P).

The Agora always felt right as a pre-game phase. The camera is zoomed in during this part because we wanted to make a clear distinction between the action phase and this section. (Also, I wanted to show off the character sprites). Additionally, we had to remove some hud elements that had no use at that moment.

The Agora is a very small section, and that’s intentional, because we felt the movement between options should be as quick as possible!

 

Why add persistent philosophers?

That’s a good question! Thanks!

Originally, we had lots of cool philosophers in the game. That was always the idea. You start playing, and suddenly find Aristotle. So, Aristotle will join your mob, and he will give you a particular bonus. If the philosopher you were using is killed, you will start using Aristotle. Because of that, we had to make tons of new animations for all of this special philosopher heroes.

Each unit has a common set of animations, but the units you control, have a lot more, like running AND commanding to attack. Or commanding to disperse. So each philosopher we add to the game, turns out to be very time consuming.

Lets continue with the previous example. Suppose you are still controlling Aristotle, and you find/buy Plato. Now you have two philosopher heroes in your mob, each one with their particular bonus. And if Aristotle dies, you will start controlling Plato, but Aristotle will revive in the next world. So you can have a lot of philosopher heroes in your mob.

We changed all of that, and we made that you can only have one philosopher hero on your mob. And you select it at the start. I particularly liked the idea of choosing your avatar in the game (a decision that can last seconds). It made sense that you could choose which type of bonuses (sometimes with a trade off) you’d want to start with.

We are still tweaking lots of things in order to achieve that each philosopher encourages a different play style. We currently have 20 philosophers in game.

 

How many can you take to a new run?

For starters, we wanted to have a lot of persistent heroes, so we set up like fifteen of them. The cool thing about having a bunch of them is that it adds lots of replayability to the game. Each hero has a unique unlock condition, so unlocking them all is a huge achievement.

The problem that comes with that is that if you’ve unlocked every persistent hero, and you take all of them to a new run, the game will be stupidly easy. Also, because of the management side of things, why wouldn’t you grab all the heroes you have at your disposal? If you’ve unlocked ten, you would want to take the ten of them to the game.

So we designed a few rules for the persistent heroes window. When you start the game, you will have no persistent heroes. Once you start unlocking them you will be able to take up to three to a new run.

The more persistent heroes you unlocked, the amount of heroes you will be able to take to a new run will increase. Currently, we have seventeen heroes and if you unlocked them all, you will be able to take up to five to a new run.

 

 

Unlock conditions

We set up the unlock conditions so that the player would spend some time unlocking the characters. We think that we might’ve put things a little to easy. We find that we unlock a lot of them in the testing runs, so we might tweak the numbers a little more.

We have weird conditions, like finishing the game without Socrates dying once (you may guess what are you unlocking with that) and more traditional unlocks, like defeating a certain amount of gods.

We found that it was difficult to communicate the player that they had unlocked something. Should we interrupt the gameplay session to let them know? Wait till the end of the session? We decided to communicate it via an unlock window that shows up after you died or won the game. It would not interrupt the session, but it had some problems.

Suppose you meet the unlock criteria, but you quit the game before losing or wining? When will you be notified of the unlock? If you continue your run, no problem, because it will show up when you lose or win, but if you select New Game, you will lose your last session’s progress.

We decided that we would just unlock the heroes when the unlock condition is met, and we would notify the unlock next time the user loses. If players do something weird like quitting the current game and starting a new one, they will miss the screen, but they will have the heroes unlocked nonetheless.

Also, we decided that instead of placing the unlocks in the win/lose screen, we would just place a new window on top of that.

Balance

We are still working the balance issues. Like getting too powerful too soon, or some of the unlock conditions being too easy. We ran a test with a company that works with Devolver for playtesting, and we were able to secure some ideas, but it’s clear that we still have a lot of work to do. However, all of these issues might be connected to some overall and ability changes we are planning for all heroes, not just persistent ones, so it might be more complicated than just adjusting the unlock conditions.

Interesting times…

Read More