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!