Yes, I know, inception is putting an idea in the head of someone and not precisely recursion, but nowadays is a recursion synonym. And the other option was naming this post “Yo dawg, I heard you like prefabs”.

(All THE IMAGES ARE SCALED DOWN. CLICK THEM TO OPEN THEM IN A NEW WINDOW)

Well, this week we are going to talk about a problem that, although we finally managed to solve,  had us trying lots of different solutions and has given us many head aches, a problem named Nested Prefabs.

Unity’s prefabs are instantiable objects. The problem is that these objects can’t be placed inside other objects, without losing the reference to the original object. It would be like a Flash MovieClip, but the main difference is that the MovieClip allows children to maintain their original reference.

Why did this bother us so much? Well, each stage in Okhlos, is composed by four chunks. Each chunk is, in turn, composed of different buildings. And each building is composed of different props and structures.

CHUNKS

This is a chunk. The main component of the chunks are buildings, but they can also have other elements like hazards, enemies, props, etc., and some of these can be completely randomized.

BUILDINGS

The buildings are composed of a main structure and different props, also some other decorations which may be sprites or the like.

PROPS

Props are the weakest destructible elements. They usually have a small structure and some sprites.

 

The following image will perhaps better illustrate how these things, chunks, buildings and props, fit together.

As you can image by now, when we add this hierarchy to the prefab’s problem you end up with three o four levels of lost references for each chunk or building. At first we simply tried to deal with this without resorting to any kind of nesting of prefabs, but it came at a high price. Basically, we had to redo every chunk and building a couple of times.

What we do now, is use a script we named Building Holder. That script holds a reference to a prefab, and instantiates it on runtime.

This reference points to an object of GameObject type, thus it can be either a GameObject in the scene or a prefab. What we found out when we started using this was that if the reference pointed to itself, when we hit apply, it stored a reference to the Game Object in the scene, not to the actual prefab.

You can see it (kinda) more clearly here:

The green line shows how the reference points to the Project view (to the actual prefab). The red line shows the object in the Hierarchy view (which is the scene view, what we don’t want to happen). And the blue lines show the objects’ structure (chunk, building, prop).

To set the reference point to actual prefab and not  the instance is fundamental to be able to modify a building without having to modify its instance in each chunk (or to put it in other words, to be able to modify a building once instead of gazillion times) but luckily we now how to do it.

 

Finally, a few screenshots showing some chunks together:

 

And closing up this week, a tree destruction .gif!

 

Read More

These past few weeks, we’ve been working on having cool ruins to replace the buildings when they are destroyed.

This was not easy. In the first place, we don’t want to have stupid amounts of geometry going directly to your video card. In order to maintain the low poly look, we have to be resourceful in how we show the destruction.

While doing this we had to resort to nested prefabs (which we will cover next week. Spoilers!), deal with a lot of trouble we had with the .FBX and with the project order in almost every fracking level of it.

Well, here is the thing:

First, we had these nice little buildings, each one in its own file.

That was cool, except for the fact that when we decided to add the ruins, some of the buildings shared the destroyed version. So, duplicating the ruins in each file would have added useless geometry, and not doing it would have been messy (and my little OCD bug would have killed me).

We didn’t have an satisfactory way of doing it. So we decided to put the meshes in a few .FBXs. Doing this would mean less file access, and putting the same ruins to share models would save us a lot of polys. And everything would be tidy.

In our organized wall society, we do not tolerate new ideas.

So we ended up with only two or three files in this fashion, using only two or three textures per file. I think it is pretty optimized, but not perfect. I really wanted to optimize everything. I… have… to optimize… more…

 

I’m implementing all the solutions in the city of Delphi and when everything is working, I will do the same on the other cities.

As almost every modeler using Unity knows, I have to work with both the modelling tool and Unity to really know how it’s going to look. So, here is how it looks in Unity!

(Click to enlarge!)

Well, next week we will talk about a really bummer, which is… NESTED PREFABS!

Read More

I have to stop using so many music references for the titles. But they are an easy way out, and I’m lazy!

Anyway, very briefly, these past weeks we’ve been finishing up the design of most of Okhlos’ HUD and windows. We had to make a lot of hard choices, and we are still changing a lot of things that aren’t closed yet.

(Our previous HUD vs. the new one. Click to enlarge!)

It’s hard, because you have to anticipate how the player will interact with the given information, so you have to guess a lot.

The most significant change was adapting everything to a 1 on 1 pixel aspect. Every element was 2x in the original pixel art work. We decided (actually, I didn’t consult Sebastian and went on with it without telling him until it was finished) to make everything 1x, meaning to respect the pixel art as is.

This is the Items Thing (technical terminology). It’s function is to show you the keys assigned to each item and tell you if anyone in your mob is carrying one of those items.If you don’t have an item, it will be shown in gray.  The image you see is here is the one that will be shown if you are using a joystick, we didn’t do the keyboard graphic yet. And as you can see, it’s much prettier if you treat each pixel as a pixel, instead of scaling them.

This is the story of the basic buttons. At first, we used to use the Dalek font (don’t know the relation between a Greek font and Dr. Who) and the sprites at 2x. Later, we switched to a more pixel-friendly font. Finally, last week, we took them to the actual size.

Here you can see the mob count tab, that shows the number of people you have in your mob , how it was and how it currently is .

The “1P” in the first  image is a sign of how much more we were focused on multiplayer during the early stages of development. The second attempt added the mob’s rage bar. This bar basically shows how rampageous your mob is,  increasing when the mob smashes things or tramples enemies, and decreasing over time. Finally, I made the third option last week, it’s not final yet, but we decided to show a mob icon/graphic, and separate the bar from the mob count.

(click to enlarge!)

This is the pause menu. This may be the most important window of all. Here, you will see all of your units, heroes, and the mob modifiers. If you have a hero that gives you +10% attack bonus, you will see it here. It’s faaar from finished yet but we think that is important to keep it as simple as possible. Too much information will ruin the window completely, it will frustrate the player when navigating it. So we will try a lot of mockups to see how we can best convey all the information.

And keep in mind that things can get a little crowded.

Yeah, that’s too much information. Feel free to feel overwhelmed by clicking the picture and pressing F11 (In chrome and in PC, don’t know in other systems).

As always, we love your comments! You can reach us in Facebook, Twitter or right down here! We try to answer all of them! (Please stop sending us nude pictures)

Well, as John Green says, Don’t forget to be awesome!

Roque

(Yeah, I know, I never sign the posts, I suppose that I’m very hipster lately)

 

Read More

Ahoy! So much time has passed since the last update. These past weeks have been a rollercoaster. Some good things happened, some not so good also… Whatever. Today I will talk, among other things, about cholulaje. Cholulaje is an Argentinian lunfardo (or colloquialism) word that means something like celebrity junkieness, or screen personality fandom.

It all started quite suddenly one day. I woke up, made some coffee and started my morning routine, which involves checking mails and checking Facebook for like half an hour. I had two mails and Facebook messages stating the same thing: we had appeared in Rock Paper Shotgun! That was incredible, we couldn’t believe it. We had never sent anything to any media outlet, but there it was, a beautiful article about Okhlos! (Here is the article)

 

It was amazing. Suddenly, we had a lot of tweets. People following our twitter account (here :))! And our owns accounts also. Lots of people retweeted the article.  Also, we had a few comments on the article, and I could argue with the public for the first time!

A few hours later. Mail from Kotaku. Chris Person wanted to do a Let’s Play of Okhlos. We were beyond words. We worked a lot in order to have a semi stable version for Chris. Setting a deadline always helps to keep the rhythm and prevents from getting too relaxed, so the pressure of having to send them something quickly ended up being a good thing .

Some days later, when everything was sort of OK, we sent him the version. What a thrill! (sounding like a little school girl). A week after that, during my morning routine, I noticed that we had a lot of musician offers, some mails and lots of tweets. The reason was obvious, Kotaku had published the article. 

Finally, IndieGames on Twitter asked developers for .GIFs of their games. After a few technical details, I prepared some GIFs and sent them. Thus we also made it into in the article for #GIFriday!

After that, I talked to John from IndieGames and he told me that he wanted to do a series of GIFs explaining the game, we were thrilled, and we started to work on more GIFs. If anything can go wrong, it will go wrong when you are talking with the press. My PC started to freeze when I tried to convert the video into gif, the hardware acceleration in photoshop suddenly decided to stop working, and our first 480px gifs ended up with a size of 20mb (which is not a good thing). Fortunately, we managed to make the gifs, and of a reasonable size. I will not post them here, because the article hasn’t came out yet, and I don’t want to spoil their exclusivity. But I will post them on future updates.

Here is the first post of IndieGames showing Okhlos!

Also, to add more to this media coverage / cholulaje account, a cambridge P.h.D. specialized in ancient philosophy wrote about Okhlos in his blog.  Which is as terribly cool, as completely off topic.

PS: In order to have more images (c’mon, we know you just look at the pictures), here in the bottom is a sneak peak of the changes we are making to the HUD

So, that’s all for this week! As always feel free to send us your feedback about anything you want!

 

Read More

This week we will start with an ongoing series about heroes in Okhlos.

 

What are the heroes?

The heroes are special unit, that are going to be scattered all over the game but that you will also be able to buy with different units.

Originally, the heroes were only going to be available for purchase with slaves. The goal was to use slaves as coins, a kind of critic to the class system in ancient Greece, and the slaves would also have another function, to carry items. We realized that those two functionalities were too important in the game, and that putting that much into a single unit type would make the others less relevant. If the players wanted to buy items, they couldn´t buy heroes. And when they bought heroes, they lost all items they were carrying.

The system was unbalanced, giving too much importance to the slaves. The best strategy was simply to gather as much slaves as possible, forgetting about the rest of the units. That is why we decided that is was best for the slaves to keep the item-carrying functionality, but that the hero-buying part would be something that could be done with any kind on unit. Now each hero costs a certain amount of units, depending on what it does. For instance, Leonidas, king of the Spartans, is going to be able to be purchased with warrior units.

Each hero is going to have special stats and characteristics.

OEDIPUS

Oedipus  is based on the hero of the same name, but we took some liberties translating him into the game. Basically he is the king that blinded himself after he realized  the great sin he had committed, which made family dinners really awkward, and made Freud rich. However, in Okhlos, his power doesn’t come from the myth, Oedipus doubles the number of people that are added to the mob. If you add a slave, you will get two slaves instead.

This is pretty useful, but is also makes it very easy to reach the mob limit fast.

Even though this seems like a non-sequitur between the myth and the in-game ability, we justify it with a Borges quote: “Mirrors and paternity are abominable because they multiply and affirm it” (“Los espejos y la paternidad son abominables, porque multiplican al hombre al infinito“).

HERACLES

In Okhlos we are constantly lobbying to get this hero called like he should be. It’s Heracles, not Hercules.

He is the son of a god and a mortal (remember that if something moved, it was very likely that Zeus would want to bang it). Heracles possess and incredible strength and can resist almost any impact. He would the archetypical tank unit, if not for the fact that each of his blows deals more than the rest of the mob combined (not true).

 

SPARTACUS

The Roman slave, turned leader of a popular uprising. Kind of a classical Che Guevara. Spartacus role is basically to make the slaves stronger.  Each slave will be stronger and tougher if Spartacus is in the mob.

Spartacus is like getting all your slaves on steroids. However, we condemn the use of non-virtual steroids.

ASCLEPIUS

Asclepius heals units. He is also Apollo’s son, which makes him a demigod. It’s always useful to have a healer in the mob. We still have some fine tuning to do, to see how much he will heal, and how close the other units need to be to be healed. As it is now, he is terribly unbalanced, but it’s a matter of fiddling a little until it’s right.

 

Read More