Knowledge is Power!

Long time no see! Amidst the deep silence, there has actually been a ton going on here. We've been bashing our heads together trying to come up with the best way to go forward with Odonata.

We heard what you were saying about the 2D format and we questioned why we made the decision to change in the first place. The thought of a 2D aspect took a huge weight off our shoulders but we wrongly presumed that it would be much easier and would satisfy the gameplay mechanic we had planned.

One month into a 2D prototype we realised that while the physics and collision was easier to work with we felt that it would have too much of a knock-on effect concerning the gameplay (like many of you had said!). With the problems happening first hand, we came to terms with switching back to 3D and facing our main problem, implementing a custom 3D collision and physics engine.

In the older builds (the ones you’ve seen in the videos) we were using Unity’s PhysX implementation but it was largely limited and required a lot of hacky workarounds to get what we wanted out of it. Rigidbodies are crazy unpredictable and with a bit of speed, objects can also easily penetrate walls and floors, which is just terrible!

Due to these issues with built-in features, we went back to the drawing board and learnt how to write physics and collision ourselves from scratch, which has a huge amount of background work and prerequisites, none of which you can even see, so we can’t even show it off!

It was devastatingly difficult with the general lack of online resource and while the learning process had really set us back, it is finally done with so we can get back to where we had left off.

So this comes to where we are now and what we are doing. We are done with the item and inventory system, physics and collision. Which leaves AI behaviors and pathfinding, “random” levels and the gameplay content...which is where all the fun is!

From now on, hopefully we’ll be able to deliver some interesting videos and previews, so stay tuned!

Aethena now has shorts! Yay!

Conversion to 2.5D! *Not anymore

In the past few weeks Odonata has really been going through some drastic changes, namely with us deciding a definitive format for Odonata to really flourish, aesthetically and gameplay-wise.

Up to this point, we've made sure that no element in Odonata is ever safe from questioning and revision, and with that in mind we questioned Odonata's 3D top down aspect. Here is a quick prototype mock up of the new format we have planned for Odonata.

While this new format may seem like it will have a substantial knock-on effect we can assure you that the gameplay will still remain true to our original plan.

We'd love to hear what you think!

Loot problems!

Hey folks! Sorry it's been a bit quiet here, we've been having a few issues with various core gameplay knick knacks, discussions about the way forward as well as converting our code base from javascript to C#. However we're going to try our best to keep this blog updated more regularly!

Here's a write up of an issue we've been having:

Loot collection!

One ongoing gameplay problem has been about the method for getting items and metal to the player, which is a very significant element in the game.

There are two important primary contexts in which the player will be killing enemies and getting loot: directly (being there in person) or indirectly (not being there in person). While there might be an easy solution for getting the items over to you (giving it directly to the player), it's just too easy and not necessarily the most fun. We want a nice raw physical method, in chime with the way the player deploys items by crudely lobbing crates.

So, for the economy to fully circle remotely away from the player, they must have a definitive solution for retrieving loot from any location. Otherwise, if one of the player's turrets out in the desert kills an enemy, the enemy will drop their loot in an arbitrary location that your system simply will not know about or have any capacity to predict, and more unfortunately, neither will you. The orphaned loot pick-ups will just time out and die, which is just lost income to the player, given that they spent money to kill the enemies in the first place. So we came up with several possible solutions to cover this economy gap.

At first we thought about an environmental method, how the player could use walls to funnel the enemies into a specific area so that when they die they will drop their loot around that choke point. However, we figured that it would be too situational and limit the system to a certain structure, which is just no fun. We want to give the player as much control as possible while keeping the requirements of a "system" to be as minimal as possible.

After that, we tried a various selection of radius checking magnets that pull loot towards your system by force, but these had to have a rather small radius as large area checks are significantly expensive for the CPU. Due to this restriction it required a lot of them to cover a sizeable area which is just as bad computationally, not to mention them conflicting amongst themselves and with over movers.

By this point we came up with a way to define what we are trying to do and why: we figured that for the movers, we can refer them as being either "specific" when you know exactly where the item is coming in from and where its going to go (conveyor belt) or "unspecific" when you have no idea where it's coming from but you do know where it's going.

From that, the "item collector" deployable came about, which seems to have nicely solved the issue. Item collectors are tower-like buildings that will pluck loot from an enemy death triggered by the player, from anywhere in the world within a distance, transporting the items from where they are to a single nearby point specified by the player. From that point, the player will be able to ferry the loot to their movers now that they know where it's all going to go. The item collector is going to be the rudimentary catalyst for all trapping systems.

Q & A time!

“What about the camera? Will it be 1/4 views, free view or static?”
We've experimented with different cameras but we're planning to implement a direction focus camera similar to a lot of 3rd person console games, perhaps with an additional automatic alignment based on the player's relative move direction.

“Will there be a friendly fire mode? aka will your own traps harm you?”
We are currently playing around with friendly fire and damage masks. However, in terms of traps and the player, being able to fully interact with your traps will help you test it properly but that is just the general idea so far.

“I'm guessing that the lever can only be used by the player, but is there a way to set the proximity and pressure triggers, to be activated by the player only/enemies or both?"
The lever can be used by anyone but at the moment there's no way of filtering usage. That would be a nice idea though, we'll add that, thanks!

Signals, Triggers and Logic

Just while we’re busy developing new content for the game, here’s a quick insight of how the trigger, signal and logic system works!

Triggers

Right at the root of the system are the Triggers. When set off, they send a signal to any connected deployables, triggering a network of traps or whatever nice surprise you might have in store for your enemies. Here is the line-up of the triggers we have so far:


· Lever - emits a signal when set to the on position.

Gameplay Overview

We thought we would make a follow-up post to explain some of the gameplay as a whole and some of the specific deployables in the previous videos!

Having known and worked with deployables for the last couple months we forgot to explain what was going on to you guys, so hopefully this will give it all a bit of context.

We'd like to note that this is an explanation of the deployable buildings in specific but using the deployables in Odonata will actually be entirely optional, it would be up to you if you want to use them based on your personal preference and play style. Nothing wrong with going at it one-man-army!

Let's first explain how the resource system works in Odonata.



The main currency in Odonata is scrap metal, everything in the game is worth an amount of metal. Shooting a gun, throwing a knife or deploying a turret would cost a certain amount of metal directly proportional to its practicality and purpose. For example, the cost of throwing a grenade is relative to the size of the explosion or the amount of damage it does.




A notable resource building would be the crusher deployable as it is the main method to "liquidise" your assets. Tossing a gun with a value of 200 metal into a crusher would result in 200 metal being dispensed out of it. This would also apply to any pickup item, essentially serving as an efficient 'quick sell' to be immediately used as currency.




In terms of deployables, deploying a spike plate at a cost of 200 metal per deployment would mean it would be worth that exact amount if it were to be disassembled (at full HP) and at a heavily discounted return if it was destroyed instead.

In the future, not only will scrap metal be used to pay for general battle and upkeep costs but it will also be used to upgrade your weapons and items, allowing you to improve something you already own or to be used to obtain an entirely new item.


Economy system and the importance of mover buildings.



Mover buildings are simply used to move scrap and item pickups from one place to another. This is important because in order for you to obtain scrap metal and items you must either collect it manually or ferry it from where it was to where you are, in a similiar fashion to resource harvesters in an RTS.

Killing an enemy will cause them to drop metal and any items in their inventory. However, if you were to kill an enemy at a remote location, say with a turret or a trap, you won't be able to benefit unless you collect it or move it.

This concept raises the necessity of mover buildings as it would enable you to make an automatic system that could essentially pay for itself, allowing you to efficiently project your battle advantage across the field.

That's it for now, we'll discuss more about the triggers and logic buildings in the next post!

Odonata Dev Launch!

Huzzah! It is finally here, our new development blog is aliiive!

We're really excited to finally show you what we've been up to, it's been one tough month. We've been busy plugging away, trying to pull together some sort of early launch to preview what Odonata is and what it's all about.

So far we're about 3 months into development so, of course, it's very early days yet. Despite our first intention, Odonata is a pretty large game and will require a great deal of undertaking, especially just for us two little people in a room. However, so far we have managed to lay down the major foundations of the code and some very early (experimental) gameplay/content.

The process during this last couple months has been quite a surprise to say the least, given that we've never worked on a game before! However, it's all been going well...so far!

We'd like to strongly express that Odonata is in a kind of super-baby-foetus-alpha at the moment, so everything is either temporary, a bug, broken, a joke, unfinished or a placeholder for now, haha. The visuals are very much at the dusty bottom of our list, so the next 4-6 months will be about features, function and gameplay!

Anyway, here are a few videos and screenshots demonstrating some of the features we have. We've just finished up on the deployables and signal logic system in our game so here's some of them in action.











We've put up quite a bit of info about the game and FAQ in the "About The Game" section at the top, so if there are some things that might be eluding you, it may help answer some of your questions!

Expect more very soon, we'll do our best to keep you posted with the new features and nerdy development stuff as regularly as we can :)