Monday 28 September 2015
Going Places!
In an effort to make things simpler for ourselves, we've wanted to move over to tumblr for a long time, but now we've finally done it!
All our future progress will be posted over there & on our Twitter too. So if you're interested in keeping up, feel free to follow us at odonatagame.tumblr.com - hope to see you there!
Wednesday 12 August 2015
We did it!
We're in EGX Leftfield Collection! This will be the first time showing Odonata ever! Expect a lot of visual changes when we hit the show deadline, and a proper look at Odonata's gameplay.
If you're interested in trying Odonata first hand, come and check it out at EGX!!
If you're interested in trying Odonata first hand, come and check it out at EGX!!
Friday 31 July 2015
Oh that's right, we're not dead.
After a looong venture with other experimental projects, we decided to breathe life back into Odonata again.
In the last 20 days we've been frantically working on a submission for this year's EGX Leftfield Collection. Here are some screenshots of the submission, we hope to catch a nice break for a bit, then we're back to solidifying a decent build and fixing a crap ton of bugs we generated in the frenzy.
In the last 20 days we've been frantically working on a submission for this year's EGX Leftfield Collection. Here are some screenshots of the submission, we hope to catch a nice break for a bit, then we're back to solidifying a decent build and fixing a crap ton of bugs we generated in the frenzy.
Tuesday 15 October 2013
Bug Troubles!
Some updates! This past couple of weeks we have been working on our primary building system for Odonata. Building is going to be a significant part of the game and we have to take our time so that we get it feeling solid and, more importantly, comfortable.
However the plan to get this up and running for a development video today has been a bit of a mess quite frankly. Just as soon as we're getting ready to post some new stuff, all the most annoying bugs and problems come crawling out of the woodwork. We've had to cut off some of our systems like a diseased arm and take a step back to figure out what is going on and what we need to do.
So for now we'll have to make do and show what we have that isn't broken I suppose, screenshots anyone?
Our plan from now is to get the building working then push on the AI so that it can give purpose to the building and the traps we have planned.
However the plan to get this up and running for a development video today has been a bit of a mess quite frankly. Just as soon as we're getting ready to post some new stuff, all the most annoying bugs and problems come crawling out of the woodwork. We've had to cut off some of our systems like a diseased arm and take a step back to figure out what is going on and what we need to do.
So for now we'll have to make do and show what we have that isn't broken I suppose, screenshots anyone?
Our plan from now is to get the building working then push on the AI so that it can give purpose to the building and the traps we have planned.
Saturday 14 September 2013
Still Pluggin' Away
As I'm sure many of you know, game development is difficult, and entails a multitude of problems and headache. This last year we have been refining and refactoring the engine that Odonata is running in, and we've also been falling into pitfalls and climbing back out. This is our full-time job and we've solely been contributing daily to Odonata as best as we can.
"Can you show us what you've been working on since?" Not really no. Well, not without boring you at least; we've been doing things like GUI, collision, pathfinding, re-factoring the code architecture, etc, mostly the game's framework. When working on elements in an engine the only way to show it off is by using it, so 'using it' in this context would just be the game content, which is where we are right now, and the reason why I'm posting!
With Odonata, our ultimate plan to tackle it was in this order: design, plan, engine, gameplay then art. The engine is finally complete, so much so, we wouldn't want to change anything about it. We're just clear of systems and pretty much past most of the technical challenge (programming). This is the point where we work on the gameplay content, making it fun, making it a playable game!
It won't be long before we're posting regular gameplay videos, showing you an insight into what Odonata is going to be. So I'm going to stick my neck out and promise we'll start posting gameplay videos within a month! So keep posted! If you don't follow the blog you can follow the Odonata Twitter to know when we post.
Monday 3 September 2012
Knowledge is Power!
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!
Friday 11 May 2012
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!
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.
Thursday 26 April 2012
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!
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!
Tuesday 10 April 2012
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.
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.
Tuesday 3 April 2012
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!
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!
Subscribe to:
Posts (Atom)