male hair loss treatment

content top

Atlantian Problems part II

 

Happy New Year and welcome back! This is our first update of 2015 and we hope you’ve all had a great start to your year! Here at CoffeePoweredMachine the work never stops, and we’re still chugging away on the Atlantis levels, which we first showed you in our last update.

Back then, when we introduced Atlantis to you, we also talked about its ornaments and it’s foliage, and you guys gave us a lot of great feedback! Thank you very much for all your thoughts, we’re going to keep working hard on those details to make sure it look just right!

Okhlos’ water

The composition of the water in Okhlos is quite simple: it’s a plane.

waterPlane

The water is above the actual ground of the game… duh.

It’s a plane above the actual ground of the level, so the units, buildings, and enemies never interact with it. The ground is the one that posseses all the physics components, so it still handles all the collisions itself. The water is just a mesh child of the ground.

The water has a transpartent/diffuse material, and there isn’t much more to it than that. We don’t reduce the opacity of the texture, we just change it in the materials settings. This gives us much more control, and, since we’re working directly on the final look as we make changes, we can just do it all within Unity instead of having to export out a texture for every tweak we want to make.

matProp

“Agua” in spanish means water :P

As far as water within other objects goes, all the water in streams and containers was made in 2DToolkit, which makes animating it so much easier and gives us far more versatility.

agua

 

As you can see from the picture above, almost all the water streams for the objects are made using sprites. We animate them frame by frame. 2DToolkit has an incredibly useful pipeline for this kind of work. We still need to export the sprites, but we change their sizes, shapes, and orientations very quickly, and we can see the results almost immediately.

barrilbebedero

 

waterFountain2

This fountain has 8 different sprite animations, just to illustrate the versatility of our system.

fuente

The only real problem we had with this approach was that we had to change the material of the water within the objects to differentiate it from the water plane. The water has an Additive Vertex color material, which is why it almost seems to glow.

 

 

The cascading water, as we mentioned before, is a sprite animation, but the ripples are produced using Unity’s particle system.

waterFlow

It’s actually a pretty simple effect, it’s just a looping particle that throws instances every now and then.

Captura de pantalla 2015-01-07 11.07.37

With just a few tweaks we can apply the effect to a character. We just need to change the Emission from Time to Distance, and the simulation space to local.

waterRipplesCharacter

The buildings

The buildings, fortunately, were pretty straight forward to make. We added some moss and a strange glowing pattern that we thought exuded a certain Atlantean look.

buildings

 

We added the obligatory moss, following in a looooong tradition of water levels.

As for the edges of the level, we got rid of those old fashioned mountain bases and we replaced them with water walls that have ancient Atlantean runes! So cool!

water

 

Oops… this update ended up being a little long, didn’t it? We still have at least another update to write about Atlantis, talking about enemies and hazards, but there’s also so many other things we want to talk about! We’re still not quite sure what we’ll focus on for next week, but stay tuned, it’ll definitely be exciting!

See you all next time, and happy new year!

As always, this article was proofread and edited by @pfque_!

Read More

Okhlos: A year in review (2014)

Hey! How’s that we are not writing about Atlantis? That will have to wait a little longer (as it happens with almost all things this time of the year). Instead, we wanted to share what we thought were the coolest moments of this year.

A huge thanks!

First of all, this year we were overwhelmed by the amount of support we received. By our supporters (fans is a such a strong word!) and our colleagues. We usually post all this stuff in three different places: our blog. TIG, which is an amazing forum for developers, and IndieDB. We got so many wonderful comments, helpful feedback and lots of cheers from these communities.

Also, lots of tweets, shares and a plethora of nice words from our friends. We really got the chance to see the best part of the industry this year.

2014-2

 

Best of 2014

-We started our year with a full press coverage in RPS and Kotaku

-We had major HUD changes (and we are still making more!)

-We had our own take on prefab inception

-We had a good amount of Lets Play

-Gordon joined the team as our musician/sfx guy/Canadian friend

-We made things harder

-We now have a cool Trailer

 

-The trailer’s making of was featured in Gamasutra

- We turned down three different publishers offers! All of them included upfront money, so it was very difficult to say no! (and we didn’t  write an update about it)

- We received private funding! And now we can eat! (and we didn’t write an update either)

-We added Sparta, Ephesos and Atlantis to Okhlos’ world roster!

-We went to a lot of events!

-The last part of the year, we worked very hard on improving the gameplay! (We are preparing an update about it!)

-We met and chat with Adam Saltsman and Rami Ismail (and they played Okhlos!)

 

So, in short, it was an amazing year for us, and we hope that 2015 will be even better. It will definitely be the year we release Okhlos, so at least, we can expect that we will live interesting times.

 

Thanks again for reading, and liking, and tweeting, and sharing the love!

 

Read More

Atlantian Problems Part I

Hey gang!

We’ve been doing a lot of work on the core mechanics of Okhlos and we’re experimenting with quite a few things, some of them a little weird. It’s quite intensive, and coding for all these tweaks and new ideas has been taking up a lot of Sebastian’s time, so in the meanwhile I’ve been designing Atlantis, one of our new game worlds.

We know three basic things about Atlantis: It was circular, it was fictional[citation needed], and it was somewhere in the middle of the Atlantic Ocean.

People tend to imagine Atlantis as an underwater city, since it sank into the Ocean, and we’re running with similar imagery. We’ve ditched the circular part, and are working with the idea that people kept living on it, despite the humidity.

Decorations and ornaments

As we’re running with a water theme I did a few quick google image searches to help me set the mood. I think we ended up with some good design constants for the city:

stock-vector-illustration-featuring-elements-commonly-associated-with-underwater-scenes-194520425

I still regreat not using the dolphin

We’ll have a lot of coral and ferns around the buildings, and tridents as ornaments on the roofs and higher floors.

Ornaments

Foliage

We’re having an ongoing problem designing the foliage and we still haven’t decided how to address it.

These are our current options (any and all feedback is welcome!):

  • No foliage.

As a soaked, inundated city, there should be no foliage. This is a simple approach, and although it makes sense it’s a bit boring. It definitely lacks something.

fol1

 

  • Rocks, Ferns, and Coral Everywhere.

This option adds quite a bit to the visuals but is rather messy, to the point where it’s not pleasant to the eyes. (Keep in mind, the bamboo is a separate element, and not part of the foliage we’re discussing here.)

fol03

 

  • Ferns and Coral only

This last option still adds some flair, like the option B, but we took the rocks out of the equation. It looks better and a bit less cluttered, but it still doesn’t feel quite right.

fol2

We’re going to try a few other things for the foliage and we’ll come up with some more options, but we welcome your opinion on the matter. If you want to see Atlantis within the context of the game, there’s a few screenshots below!

 

screen1

screen2

These screenshots were taken from the No Foliage Option

 

This is it for this week, but there’s still a ton of things about Atlantis that I’d like to talk about in the near future! We’d love to hear your feedback about this new game world, so please let us know what you think!

This article was proofread and edited by @pfque_!

Read More

Regaining Control – Aftermath

Hey guys! These last few weeks have been very busy for us here at Coffee Powered Machine.

We’ve shown our game at three (3!) different exhibits in just as many weeks, and let us tell you – after almost a whole month without weekends, we’re exhausted! We’ve been so busy we didn’t even get a chance to put up an update last week.

The events were great though, and we got a lot of great feedback from the people who tried out Okhlos at the various shows. We now have a ton of data to work with as we head back into development. Thanks to any of you who came out and gave our game a shot! Seeing you guys play the game and talking to you has been incredibly helpful.

As you might remember from our last update, we had been talking about implementing a new control scheme for Okhlos. We had proposed three different schemes: the non-zero option, the alternate keyboard option, and the mouse option.

 

EsquemaTodos

 

We got a chance to test out these different control schemes at the various exhibits and have learned a lot from our experiments. Below you’ll find a short break-down of each of these exhibits and what we managed to learn.

The Events

These were the events in where we showed Okhlos.

EVA

EVA is short for Exposición de Videojuegos Argentinos, or Argentine Videogames Expo. It is the principal videogames event in Argentina, and it’s mainly oriented towards developers.

We exhibited Okhlos 0.4.1 during EVA, the same build we sent off to the IGF, and used our original control scheme.

The biggest problem with this build was that the players didn’t realize they had to keep holding the second analog stick in position in order to attack. The QTEs also proved problematic as it’s hard to push the face buttons when you’re supposed to be holding the second analog stick at the same time.

MEET THE GAME 2

Unlike EVA, Meet the Game is more of a public event where people get a chance to meet developers and try out their games. One of its goals is to facilitate one-on-one interaction between developers and players. It’s still a small event but there’s a lot of potential in the format and we hope it’ll grow.

We showed two different versions of Okhlos at Meet the Game, each one sporting a different control scheme. We showed one with the non-zero joystick layout (scheme 1 in the chart above) and a second one with the mouse layout (scheme 3). We were particularly interested to see how people would feel about controlling the game with a mouse. We had only tested the mouse internally up until that point and hadn’t had a lot of time to tweak its controls.

 

notebooks

Thanks to Marisol Estevez for the picture!

We found out some very interesting things.

Players had an easy time with the non-zero joystick scheme, and had no problems attacking enemies throughout the demo. They used the second analog stick to adjust the position of the mob whenever necessary and had no trouble hitting the face buttons during the QTEs. It’s still far from perfect though and we’re still very tempted to eliminate the QTEs altogether.

What really amazed us though was how positive the reaction to the mouse scheme was. People really liked it a lot! We were told it felt quite intuitive, which is great! The only problem was that we didn’t map an action to the left mouse button, which, as it turns out, is what players naturally tried first and wanted to use. I guess using the mouse just makes people feel like they’re playing an RTS!

TRIC VI

I still don’t know what this event was about. It was some kind of scientific or academic tournament endorsed by the IEEE? Maybe it’s just because I’m the graphics guy but I really didn’t get it.  It wasn’t as cool or as crowded as the other events but we managed to test out the keyboard scheme nonetheless.

Seeing how the attendees (all two of them!) reacted to the keyboard controls we concluded it was a very good control scheme for the game. We changed it a bit from how it’s shown in the graph above – instead of using the Del, End, and Page Down buttons for items we went with the 1, 2, and 3 keys which are much closer to WASD. We realized not all keyboards have Del, End, and Page Down buttons close to the arrow keys.

10626422_1962326810572963_7462021763699652972_o

Thanks Yiyo Flauros for the picture!

 

Overall, we gained a lot of data from each of these events. I think we almost nailed the keyboard control scheme, but it seems Okhlos still has some game-mechanic issues that we have to resolve before we can perfect it

To the drawing table, again

We had a long session with Daniel Benmergui on Friday in which he helped us test out and think through some of our base mechanics. We tried some quick changes, analyzed the flow of the mob, ran through our challenges, and at the end of the day we asked ourselves whether our game is robust enough as it stands right now or whether we have to keep working and tweaking its mechanics.

The conclusion we came to was that that we need to keep exploring our base mechanics. We have a cool concept but it’s just not enough. As Daniel said, we need to start thinking in verbs. In the current build you gather, you run, you attack, you solve QTES and you use items. We need to add more verbs to that. And as for removing QTEs, that would make our gameplay even simpler than it already is, so we can’t really afford to just yet. Not until we’ve built something more robust.

It was a great experience talking with Daniel and we came out of it with a huge list of changes we want to make. We’re thinking of removing any unnecessary numbers, changing a great part of the HUD, axing the bureaucrats, reducing the options available in the market, and changing the dash. That may seem daunting, but I think one of the things that Daniel helped us corroborate is that doing something original, something that hasn’t been seen in any another game, is very difficult, and we’re on good track to making it happen.

We also had an interesting experience with our sound designer, Gordon, @jouste  and @Nelsormensch. We had a video chat with them while they played Okhlos, which was a little weird but very cool! We weren’t sure if we should be looking at them or at the screen – they had to turn the laptop around for that – but once it started we were able have a good conversation, even in my rusty English.

Their suggestions were very similar to Daniel’s on most things, but they were nonetheless very helpful. Talking about your game always is! We’re very thankful for their feedback and now have plenty of work to keep us busy for quite a while!

That’s more or less it! I will continue to work on new worlds for Okhlos and Sebastian has already started conducting weird experiments with the mechanics. We’ll see what come out of all that and we’ll let you know!

This article was proofread and edited by our new collaborator, @pfque_!

Read More

Regaining Control

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.

hazardNEW

Testing can be so much fun if you are not the one following the flag

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.

EsquemaNuevo_00

Current control scheme

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.

Isaac sure could've used the help of an angry mob down there

The control scheme of the original The Binding of Isaac

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!

bannerMeet

Read More

Introducing Ephesos [Part 2]

Last week, we started talking about Ephesos, Okhlos’ new world, and we left a few things out. This week, we are gonna solve that.

ENEMIES

We have some new enemies for Ephesos. Mainly the Centaurus and the Forest Giants. Granted, Forest Giant is a silly name, but they are powerful enemies, we promise!

gigante

This is the second Gigante (Giant) we introduce! The first one was the shield bearer. And we still have a few more to show!

The Centaurs, on the other hand, they are a very different enemy.

CentaurA

For starters, Centaurs will search for you, and try to trample you. So, their attacks are continuous and in line.  You’d better try to dodge them, because they will not stop even if they hit a unit.

Another thing that they have, is that they can crash with the buildings, and this hurts them. This was something that came from the early prototypes, and we don’t know if it’s a good fit for the current state of Okhlos (having changed so much since then).

HAZARDS

In the subject of hazards, the new ones in Ephesos are these kind of bear traps. These traps will hurt any unit that walks on top of it.

ArtemisTrap

Also, there is a new variation of the exploding barrel hazard, but they involve only graphical changes.

ARTEMIS

Artemis is Apollo’s sister, so in character design terms, it was pretty easy to develop her.

You can see that she has lots of things reminiscent of Apollo. And we translated some of the yellow elements to green ones, in order to push the nature theme a bit further.

ArtemisApollo

Artemis also has a few special attacks, like filling the stage with traps, and shooting arrows like his brother. It’s very likely that she’ll have a third attack, but we haven’t done it yet.

As for the stage where she is, we are currently using a placeholder, but she’ll definitely have a version of the Temple of Artemis, and a huge open area for the battle. As one of the cool things about her is that she places traps, having terrain covered by buildings, thus not being able to place traps there, can nerf that. As with Ares, this boss is much more enjoyable with an open terrain where you can fight her. Obviously, we can’t just put a blank chunk, we have to decorate it!

ArtemisChunk

Well, that’s pretty much Ephesos. We still have a lot of work to do here, but with all this, you can get a grasp of how it will feel like!

 

Read More

Introducing Ephesos [part 1]

In the huge 0.4.0 version, we added a big feature that we barely mentioned before. That’s Ephesos.

Ephesos is a new world in Okhlos, and the hometown of Artemis. We still need to work a lot in Ephesos, but we could put enough to have a stable version for the IGF.

 

This makes Ephesos our third world! And right now, we are making a few more! We hope to have quite a few more by the end of the year.

 

So, what’s going on with Ephesos?

THE NAME

We decided to start working with Artemis, and we needed a place. We started with Brauron, which was a good fit for Artemis because it held The Sanctuary of Artemis, and also because of the green. We wanted the Artemis’ world to have lots of green. We wanted some kind of city invaded by plants, and Brauron seemed just right. We even started making most of the world’s assets with that name. However, we weren’t 100% convinced that placing the action in Brauron was a good idea, mainly because of the name. It’s not very likely that you’ll associate “Brauron” with something Greek. Brauron seems more like British.

We knew that the name was not perfect, so we kept searching for a better fit. Finally, we found Ephesos, which had everything we wanted.For starters, Ephesos was famed for having The Temple of Artemis. It’s also very green.  Also, it sounds sooo Greek. Anyway, we are extremely happy with the new name. It was a perfect fit, so we gladly went on to change the names of the assets.

Ephesos

Keep in mind that still is a work in progress.

BUILDINGS

So, apart from the stupid amount of trees, Ephesos has simple buildings because it’s a rural area. It doesn’t have too many shops, and there are lots of farms.

Edificio1

Edificio2

Also, we had to put lots of fences, and we started using special transitions. In Delphi and Sparta, the transitions between a level and the next one were almost identical, with just a texture swap. For Ephesos, we started making these new transitions, and it’s very likely that in future  worlds we  will make many more new transitions, and not just  texture swaps.

Also, a new feature in 0.4.0 is that when entering the boss level, the transition will be slightly different, in order to let the player know that he is about to fight a boss.

transicion1 transicion2

FOUNTAINS & ROADS

Another thing we did was adding some grass and foliage to the fountains and statues. That really made them stand out.

fountain

The roads were a pain. Really don’t know why, but it took us some time to get them right (also, we feel that we might be revisiting them in some time).

roads

 

Next week we will continue discussing the new things in Ephesos!

Read More

Road to IGF 2015 [Part V of V] The Changelog

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!

changelog040

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!

0001 0000 02 03

Read More

Road to IGF 2015 [Part IV of V] Effects for the Gods

Hey there!

Just one week to the IGF! And we still have a lot to do!

 

For starters, besides the IGF we have to give a talk at Tecnopolis on Saturday, so that will take some of our time.

Because we have to be there on Friday too, we must have the build almost ready by Thursday. After that day, we decided that we wouldn’t add anything new to the build (so you can imagine how hurried we are).

logo

As I said before, on Saturday 18 we will be giving a talk, so we can’t work on Friday or Saturday. The next Wednesday we will have to  submit it to the IGF, so we have Monday and Tuesday to fix any issues that we may find in Okhlos’ new version.

oradores

All of this is stressing us a lot, but we are glad that it’s almost over!

 

Anyway, as we have so little time, I think it’s a good idea to brag about some new effects we are working on! The game still needs a lot of “Juicy“, so adding fx is a good way to give feedback to the player, letting them have a good idea of what’s happening . We still need to push a little further the audio in that part, but Gordon is working on it.

 

When you have done 3 different gods for Okhlos, you start learning things you will use for the remaining ones:

1.- Be consistent

2.- K.I.S.S. (Keep It Simple, Stupid)

Following these rules, one thing we decided last week, is that every god will fly. I was finishing Artemis walking loop, when I stumble upon these rules. We already had two flying gods (1), and is much easier to do a flying animation than a walking one (2). So I threw away the ongoing animation, made a new one, added a wind blowing fx below the gods, and voilá! They are flying.

Apollo Flying

There it is! (WIP!)

 

Another thing we changed was the death animation. Ares was the first God I drew, so he had a lot of issues, and I learned a lot since I made him. For Apollo and Artemis I made a much more cool / powerful death animation,  so, following these two simple rules, I changed Ares’ death animation.

aresmuereViejo

This was the old death animation.

 

AresMuerte2

This is the new one.

As you can see, there is a big difference between the animations. The second one is more “epic”.  Also, it’s just a little bit easier to animate. And finally, it’s consistent with the rest of the gods.

 

We learned a lot after working a few gods, and that gave us a better understanding of what we are doing.  The best advice we can give in this matter, is that if you have to make 12 Olympian gods in your game, make 3 or 4 together and that will give you a better idea of what you are up to.

 

Next week, we will be writing the final post of ROAD TO IGF series!

 

Read More

Road to IGF 2015 [Part III of V] Inheritance 101

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.

 

Elviros_800x700

A chunk of Elviros’s code … which you can see was oddly similar to Orpheus’ code

Orpheus_800x700

A chunk of Orpheus’ code

 

 

 

 

 

 

 

 

 

 

 

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.

 

HeroMusician_800x700

One script to rule them all (or at least those two)

 

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.

 

NewElviros_600x300

Brand new Elviros’ code

NewOrpheus_600x300

Sparkly and shiny Orpheus’ code

 

 

 

 

 

 

 

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:

Units_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
content top