We are working hard to get a prototype ready before the IGF deadline. This is taking up most of our time, leaving us with little time to write new amazing and exciting updates. But, at the same time, we don’t want to stop posting updates. It’s fun, it keeps us motivated and getting some feedback is an important part of the development cycle. So we decided to resort to this: posting a bunch of pseudo random screenshots, along with some even more pseudo random comments.

This particular set of pseudo random screenshots are the result of some tests I’ve been carrying out, using different shaders, and also some  good old fashioned fooling around with Unity’s camera effects. Most of the stuff you see here will not be in the game’s final version. They are tests, weird stuff. So posting them here is also a way to put them to rest. Of saying goodbye to them. Farewell, random test!

So, without further ado, here they are. Pseudo random screenshots.

 

Smoke in the Stone

Basically playing around with fog here. The grey tint gives it a smokish look. Perhaps we can use something like this if a whole city or area is burning. Or maybe the ancient Greeks had smog too.

 

Ye Olde Delphi, or the unavoidable need to try a sepia filter

It just had to be done.

Extremely Loud and Incredibly Close

Okay, maybe not so loud since it is a screenshot with no sound whatsoever, but it is indeed a closer look at some of our favorite Greek mobsters. Plus, check out the pecs on that warrior. Someone has been working out!

 

The Snake Mode

Or the mob’s conga line if you prefer.

 

Fisheye Mob 

Testing some more camera effects. Here another of the classic ones. I don’t think this will make it to the final cut, though.

 

A Lighting Test

Just a single philosopher, in the middle of nowhere. Plus Unity’s editor thingy up there in the corner (that’s the technical term for it, don’t let anyone fool you).

 

The Shadow Mob

Booo! They are dark and evil… You know, I kind of like how they look. I am thinking we could keep one of these guys as a hidden character and name him Niatsabes Euqor…

 

Under Medusa’s Shadow

Testing an overlay effect with a frame from Medusa’s death animation.

Medusa’s Mist

More crazy medusa-induced effects.

 

Conga Line, Part II: Someone shouts “B”

And as a bonus a merry group of Carmenmirandesque medusas of different sizes try to join the party.

 

The Brightest Day 

And still quite some time until someone invents the sunglasses.

 

A Poor Old Man in the Snow

Life can be tough sometimes. This was a test using a snow shader  (something that would have allowed to create a snow level without changing a whole lot of textures) but it didn’t work out very well. Okhlo’s style (low poly, sprites, pixel art) doesn’t lend itself very well to something like this.

 

Dusk At Delphi 

Both Roque and I agree that this was the best of the lot. It was the result of testing different shaders and playing around a little bit with the scene’s lights. If everything works out the way we plan, be prepared for more dynamically lightning in Okhlos!

Read More

 

So, enjoy the video and let us know what you think!

Read More

This week, we will review what kind of units will join your angry mob! In character sheet form!

 

Read More

I’ll be incredibly frank today. I hate writing in English. I’m a lot more comfortable now than before I started the dev blog, having the obligation of writing each week an update helps a lot, but each update that I write, goes trough Sebastian, for some quick spell check, and to make sure that the sentences are understandable. This same text is then reproduced in our page, our IndieDB page, and our TIG post. If you know other cool sites to post our dev blog, let me know!

This whole process isn’t helping us reach our new goal, which is the IGF. So I thought that this week, which was quite busy, I could post only some images, to show how the integration between the mesh and pixel art sprites is coming.

 

I had a few questions about the technique I use. I really want to give a full detailed description of the process, but unfortunately, it takes a lot of time. So, maybe in a few weeks, I can post something about this.

 

Just to give you a sneak peek of the explanation, the technique is:

-Make the structure in your favorite 3d software.

-Add some sprites in Unity.

This text is added only to make the post look cool.

Putting two images together and no text in between is wrong! “(Click in the picture to enlarge it!)” Doesn’t count

I know you are reading these texts. Please Stop. Just focus on the nice pictures

This text has been read 18 times.

Thankfully, this is the last filler text I have to do. I ran out of ideas.

Well, that’s pretty much meshes + sprites.  Thanks for not reading the in-between texts!

 

 

Read More

I’ve been, for the last few weeks, trying to decide how we will be doing the environments of Okhlos.

This process was not pleasant, to say the least. It would normally be a cool process, prototyping, trying to decide aesthetics, profiling, etc. But with the IGF around the corner, every method I discarded, made me feel more pressured to have something definitive, and less time I had to have something nice to show.

We are planning on having two “playable” levels for the IGF, where you can have an idea of what will be the overall aesthetic, plus the core mechanic.

 

It all started with the buildings (I will do an update on how I managed to get the pixel art in the textures, soon).

We had  some nice buildings. The main problem was that they were too historically accurate. They were damaged, filled with imperfections, and mainly made of stone. The rock texture gave the impression of something old and neglected.

Later, Sebastian pointed out that they were no fit for Delphi, as Apollo represents order, thus Delphi should have been spotless, and showing that everything is in order. I thought that changing the textures should suffice, unfortunately, it required some uv mapping changes, also removing the sprites objects in order to make everything more marble-like, and some geometry changes were in order.

Previous house model vs new one. We may utilize the old one for some other levels.

Later, when we had what would be the main buildings of the levels (we could add more variation later) it was time to figure out how to put these buildings into this:

We use 2dToolkit. It’s extremely cool, fast, intuitive, yadda yadda yadda. We use it mainly for the characters and ornaments It has some tilemap functionality, but it’s not its core.

First of all, setting the map was not very intuitive, we had to upgrade the plugin, which was not that painful, but it took some time, in order to be able to have the new features specially for the tilemap editor. Finally, we figured out how to set a scale congruent with our current one.

Later, we found out that the meshes didn’t have normals, so we must generated them by code. (without normals, we wouldn’t have shadows!)

We could have discarded the Y, and made all the levels flat, but there was one more main problem, and that was the materials we use for the bump mapping. There was no easy way of setting the normal maps in the atlas we used for the tilemaps. And that is one of the main things I use to take some work form the textures :P

Unfortunately, there is no picture, as I deleted it accidentally, and it’s a long process to do it again, just for the sake of the screenshot.

And some tiles that could eventually end up in the final version (not in the same way probably)

 

The first problem, as always, was setting parameters that would be consistent with our scale. It was not easy, and the values were extremely different.

From the aesthetic side was not good either.

(Click in the picture to enlarge it!)

The terrains in unity, are definitively nasty. The vertex painting part is incredible cool, but otherwise, there are just a headache, or just something quick for prototyping (if you are working in the same scale).

Eventually, it hit me. We are making low poly buildings, for pixel art characters. The environment it has to be all low poly. And as it would be a stupid amount of work making an entire city unique, the best approach was to made it modular.

In this train of thought, I arrived to my second error. The concept (which all of you can see here!) was very vague in some areas. I didn’t figure out how all parts would fit together, and the blank spaces in which “I’ll put a mountain or something later” were really not helping to gain a big picture.

So I sat, tok the map, and did it again, now having in mind a tile size, and that each square had to be declared.

As for the side of the amount of meshes, eventually, I realized what Sebastian was trying to say for a week now. It’s not time for optimization. We will have that time, but for now, we can take a few liberties. Also, the performance problems are coming from the physics side, not the rendering one.

 

 

Read More

When we first started discussing the game’s idea with Roque, and the word mob was mentioned, another word come into mind: “empanadas” (because we were hungry, and we always eat some delicious emapanadas on Fridays). But immediately after lunch yet another word come into my mind: flocking. The algorithm that mimics the coordinated movement of bird flocks or fish schools (http://www.red3d.com/cwr/boids/) seemed like the way to go. Sure, people were not going to behave exactly like fish or albatrosses, but the three rules that govern the flocking algorithm, separation, alignment and cohesion, were going to be more than useful to determine how the people in the mob behave.

Being the lazy programmer that I am … errr … I mean, the efficient programmer that I am, and trying to avoid reinventing the wheel, I set out to seek flocking algorithms implementations on Unity. Soon I came across this neat little set of scripts on the Unity Wiki: http://wiki.unity3d.com/index.php?title=Flocking. It was very simple to implement and the use of a centralized controller made it very efficient as well. It allowed to create a mob of several hundred boids at a very low performance cost. So I used this as the mobster’s behaviors’ foundation stone. Our early prototypes were all done using a modified version this algorithm.

And so everything was peace and quiet, months went by and the game grew until one day the algorithm was not enough. The game’s needs had changed and it was time to write a new super efficient yet flexible and versatile flocking algorithm … or search the web again. So I did the latter and this time met Unity Steer: http://arges-systems.com/blog/category/unitysteer/

 

Unity Steer proved to be very flexible, you can add or remove different steering behaviour to get different results easily. It seemed just what we needed. But this came at a performance cost. My good old MacBook started to suffer when a couple hundred boids were added.

What I did then was a fiddle around for a while with the different behaviours, to see which combination worked best (and because it was fun to do so, wiiiii, flocking!!!) until I found something I liked and then merged the behaviours together. The next step was doing some more optimization, taking advantage of the mob’s specific characteristics, removing a little bit of this, merging some of that, profiling, adding a little bit of that, profiling again, checking imdb to settle some arguments about Willem Dafoe’s career, removing some more stuff and profiling once more. You know, the usual mob optimization process.

 

When it was all over, several hundred boids were moving smoothly around the computer’s screen, doing their boiddy things, aligned, separated yet cohesive. The boids were ready to be integrated into the game, to spark some life into those pixelated and angry Greeks. Pure beauty.

 

Read More