The ships and stations of Twelve

Since our submission of Twelve on Steam Greenlight we've been continuously working on adding content. If you looked closely at our release trailer and gameplay trailer you'll notice there isn't more than 4 ships in the hangar. Since then we've gone over each one and have implemented 10 ships in total, removing or changing some that we weren't happy with. Aswell as adding in 11 more stations, for a total of 12.

With a total of 12 stations, each faction will have now a unique station. That is, until you capture it and make that station yours.

Each station sprite will have a hitbox which matches that sprite exactly, so as long as the ship is not touching the station there will be no collision registered.

As you can see, a smaller ship can actually be inside the center of this station because of their accurate hitboxes.

We've also added in more ships, for a total of 10 ships as of now.

Since we've added this many ships, we thought it would be a good idea to elaborate on the differences between ships, how they'll vary in-game, and how many we plan on having.

Each ship will have different stats, for example, some will be quicker and smaller but have lower hull. Some will be slower, but have high damage and hull. Each catering to different playstyles any player might have. The ships won't all be equals, some more expensive than others depending on their stats and other factors.

The hitbox on each ship matches their sprites, so a smaller ship will have a smaller hitbox and therefore be able to dodge lasers more easily. However, crashing into another ship at full speed deals damage to both the player and the AI. Since the player has more hull, most of the time the AI will be killed and the player will survive, making ramming a viable strategy for offense. The drawback being that the player sustains damage aswell the player being able to ram both enemies and allies, so it's an offensive strategy that's to be used carefully. Of course bigger ships will have an easier time doing this due to their larger hitboxes.

The total amount of ships we plan on having is unclear, but each ship will have their own unique special ability called "Overclock" which gives them a temporary but powerful advantage on the battlefield. We'll be talking about those soon as we implement them one by one, stay tuned for more info and details on these abilities.

-Brendan

Twelve is now officially on greenlight!

Twelve is now officially on Steam Greenlight! If you enjoyed any of the content in this blog, consider voting "yes" to make our game a reality and have it approved on Steam.

Here's a brand new gameplay trailer with a more in-depth exposition of Twelve's gameplay:

Thanks for taking the time to read through our blog, and we hope to keep updates coming about the greenlight and more development.

Drawing: The Falcon

Hey everyone, Brendan here. I'm the artist for our game called Twelve and today I want to share the process of creation for some of the HD art involved with the game. I thought, since I am the artist and since my work is essentially completely visual, that instead of telling you how I did it I would simply show you in a sped up process video.

I plan on going more in-depth about the artistic process if anyone is interested and/or wants to know more details about it. Feel free to ask any questions and stay tuned for more updates.

-Brendan

Twelve: Official Trailer

The official trailer for Twelve is finally here! Don't forget to sign up to our mailing list to be notified when Twelve releases. 

Subscribe to our youtube channel for the latest videos and send us a tweet for any questions or comments

Projectile Interception

Warning: this post is math intensive so if you’re not interested in math and/or programming you might not enjoy this.

In an earlier post Brendan had mentioned how the AI utilize an advanced algorithm for shooting targets. This post will explain how AI in Twelve are able to consistently land shots when the lasers they shoot have a significant travel-time. It describes the interception algorithm used to determine where the AI should shoot. This is intended to benefit other developers trying to program a similar algorithm for their games.

The math used in this post does not exceed a high school level education (at least that’s the level of education I’m at). It's linear algebra that should be simple enough for most programmers to follow.

When designing an algorithm it usually helps to explicitly state the problem being solved. In this case, we're trying to make AI that can shoot a moving target. This is hard because the shots the AI takes do not travel instantly. For a shot to hit a target it has to be fired towards the target’s future position rather than their current position.

A simple example is the rocket launcher in most first person shooters. Unlike bullets, rockets take time to travel distances. To hit a target the player must lead their shot by a certain distance to compensate for the speed of the rocket. The purpose of this algorithm is to precisely determine the direction a shooter needs to shoot for the projectile to intercept the target.

Given the position of the shooter, the position and velocity of the target, and the speed at which a shot travels, we want to find a unit vector that is the direction the shooter needs to shoot to hit its target.

Here’s a diagram representing an example scenario:

For simplicity we'll assume that the unit of distance is meters and the unit of time is seconds. The blue spacecraft is the shooter and the red spacecraft is the target. The green vector is the velocity of the target. The unit for velocity is meters / second so its magnitude represents how many meters the target will move in 1 second. The dotted line represents all the future positions of the target (this assumes it travels at a constant velocity). We can predict exactly where the target will be after any amount of time using the following relation:

The shooter’s projectile travels at a specific speed, which means the time it takes for the projectile to travel between where the shooter shot from and the target will depend on the distance between the two. In short, the travel time of the projectile depends on the distance it needs to travel. If we know this travel time, we can predict where the target will be after that amount of time, and we can come up with a vector pointing from the shooter to the future position of the target. Here’s a diagram to better illustrate the problem:

Each purple line represents a possible path for the projectile to take. A projectile that travels instantaneously would take the path on the very left. A projectile that travels slower would need to take a path more towards the right to compensate for its slower speed. It’s easy to see that for a projectile of speed x, there's only one possible path that it could take ensuring it will hit the target. Each of these paths has a different length, which means a projectile of the same speed will have a different travel time along each one.

Now we have simplified the problem. We know that we’re looking for the travel time of the projectile so that we can know where the target will be and determine what direction to shoot. The new problem is that the travel time depends on the distance the projectile is traveling. This distance depends on how much the target has moved, which in turn, depends on the amount of time elapsed.

To determine the travel time of the projectile, we will consider the diagram a triangle (3 points):

- The first point is the current position of the target. In the example this is at the top left.

- The second point is the position of the shooter. In the example this is at the bottom.

- The last point is the point at which the hit occurs. This is a point along the dotted line.

This triangle is useful because the length of the right side is the distance the projectile needs to travel. Knowing the distance, we can simply divide it by the speed of the projectile to get the travel time.

Now we have simplified the problem even further. Finding the direction to shoot is the same as finding the length of the right side of the triangle. To find this length, we will use the law of cosines:

Side (a) is the length we are looking for. This is the side on the very right. We will consider the top side to be side (b) and the left side to be side (c). We can see that side (c) is constant; it’s simply the distance between the shooter and the original position of the target. Since (A) is the angle between side (b) and side (c), this is also constant. Since the angle is constant we know that -2cos(A) will be constant. We can simplify the equation by expressing it with the constants:

Side (b) is not a constant size. The length of this side is a function of the time elapsed (as we saw in the very first equation). The length of side (a) is also not constant, it’s a function of the time elapsed. We can express these sides as:

Where (s) is the speed of the projectile, (||v||) is the speed of the target, and (t) is the time elapsed since the shot. We can now express the whole equation as a function of (t):

Now we can clearly see that the relation is a quadratic equation where (t) is the variable and all the other values are constant. Solving for (t) is trivial and it gives us the elapsed time. Since this equation is quadratic there will exist two values of (t), one that's negative and the other that's positive. Since in real life time can only progress forward (at least until the device is complete), we're only interested in the positive value of (t).

Edit: As many readers have pointed out, this is only true if we assume that the projectile has a greater speed than the target. If the speed of the projectile is less than or equal to that of the target, the algorithm must be extended to handle each of the two new cases.

Once we know the elapsed time we plug it into the original equation:

This will give us the future position of our target. Then we can simply subtract the shooter’s position from the target’s future position to get a vector pointing towards the target’s future position. Normalizing this vector gives us the direction the shooter needs to shoot. Assuming the shooter can shoot in that direction, and that the target’s acceleration remains null, after (t) seconds the target will be hit.

Here is an example of an implementation in C# straight from Twelve’s codebase:

That concludes the explanation of the interception algorithm used in Twelve. Since the direction of the vectors themselves is not too relevant and we're mainly focused on the length of the sides of the triangle, if you’re really clever this algorithm can easily be extended to function in a 3D environment. Hopefully this helps other programmers struggling with a similar problem.

-Michael

How it's made: Sound effects

Sound technician kicking in, this post is going to explain how the sound effects are created in Twelve

Sound effects are created using a base sound, usually a weird sound coming from someone's mouth, and adding onto it audio effects such as flangers, phasers and many more. The raw sound is imported into Ableton Live 9 and then those effects are added and tweaked until a desirable game-like sound effect is created. Finally, the sound effect is exported into a .wav file and sent to the code monkey.

Here’s an example:

I will attempt the make a laser sound effect. Keeping that in mind, I record a sound that very roughly resembles the sound a sci-fi laser might produce.

This does not sound very much like a video game quality sound effect. To change this, I add a Frequency Shifter with a low frequency oscillator. This allows me to shift the frequency down to 68 Hz and add a square wave oscillator at a rate of 1/16 bpm. In addition to the Frequency Shifter, I add a phaser and reverb to the sound, which makes the laser sound more lively. Since this is going to be a low frequency laser sound, I add an equalizer and filter off the high frequency noise and clean out the sound. Finally, I add a compressor to amplify the sound.

Basically my role is to make funny sounds with my mouth until someone approves of it. Keep an eye out for a future post where I explain how the soundtracks are produced.

-Sami

How enemies and AI work in Twelve

The AI in Twelve is a crucial part of the game, perhaps one of the most important aspects beyond the very ship you control. These non player characters are programmed to be either ally or enemy to the player, however all AI behaves identically in Twelve.

    (Pictured here is the player [purple] being attacked by enemy AI [blue] in their sector)

In this game there's an emphasis on equality between the player ship and the AI ships, which means they had to appear to be as powerful as the player. Now of course there are differences, notably the player's HP is greater than the AI, that was necessary for the player to be able to play and survive for longer periods of time than the enemies. Which lends to the fun of the game and the conquest of other factions. 

Territory is divided by 12 different factions, each controlling their own bit of space. The sectors at the edge of borders are potential targets for invasion, this will occur every 6 seconds where one of these sectors will be invaded and taken over by it's rivaling faction. 

The image above represents the possibilities for the middle sector to be invaded, it is only affected by the adjacent sectors and itself. The percentages in the image determine the possibility of the middle sector to be changed or to remain to that colour. Since there are two blue sectors adjacent, there's a 20% chance this middle sector is invaded by blue. However there are two red sectors adjacent aswell as the middle sector being red, which adds up to 80% chance of the sector remaining under red's control. All this allows for the universe to function and simulates the constant warfare between the factions. 

AI are programmed to constantly scan ahead and detect the nearest object, they then calculate and adjust their trajectory to avoid collision with said object. To shoot, they will pick a random target that is not of their own faction and pursue it until that ship dies or they do, if no targets are found they wander aimlessly in their original spawn area. AI will spawn randomly near the player offscreen, and de-spawn when too far from the player. The game makes sure there is always the right amount of AI that spawns by comparing the amount of currently present AI and spawning new ones when the player moves around. They will most likely be the same colour as the sector you're in, however some will spawn as surrounding sectors' colours. Similar to how territorial invasion works (as explained above), the colour of a spawned AI depends on the current and surrounding sectors, with possibilities varying by amount of a certain colour. 

AI will generally try to avoid the player and any other ships, they will shoot at their chosen target until they get too close, then they will turn back around to a further distance before beggining to shoot once more. They will begin to flee when their target chases them to avoid collision and being shot, but return to shoot them once their target faces another direction. When in a sector that belongs to the player's faction, also known as a "safe zone", the AI that spawn will most likely be of the player's faction. Which means they will be allies. Allies will act exactly the same as enemy AI except they will not target the player and cannot hurt the player by shooting. They'll instead aim for enemy AI, and in the end aid the player significantly by both being an alternate target and disposing of enemies aswell. 

The AI utilize a very precise algorithm which takes into account it's target's speed and the speed of it's laser to ensure a direct hit. That algorithm is mostly comprised of linear algebra, a bunch of boring numbers and lines that were bred from the blood, sweat, and tears of the poor, poor programmer. 

Ultimately, the AI is programmed to shoot enemies while being smart enough to avoid collisions. This makes them a threat and even challenging for the player to defeat, but still useful when the AI is allied to the player. The collision avoidance, targetting system and territorial invasion of AI all contribute to the challenge of Twelve, and allow the player to feel the true conflict in the universe while capturing territory of their own. 

We hope to have you explore Twelve's expansive universe soon. 

-Brendan

Alpha gameplay video

This is a video showing off many aspects of Twelve including: 

-Combat

-Capturing stations and control points

-Mining

-Ship purchase

-Pilot commissioning

~Enjoy!

Welcome to the World of Twelve!

Welcome to the development blog for the indie rogue-lite space conquest game, Twelve! In this game, you play as an army exploring and defeating enemy factions in the vast emptiness of outer space, purchasing and upgrading different spaceships as you progress.

Twelve features a galaxy under constant war, with many features such as factions capturing bases from each other without remorse. The enemy ships in this game are extremely smart, and make every attempt to outmanoeuvre and defeat you.

This blog is here to help you, the reader, understand and be up to date on all of the latest developments in the game, as well as respond to any questions you may have. On the part of the developers, we wish you good luck conquering the galaxy!

-Ariq

How Twelve was Developed

Lead artist and game designer checking in!
I thought I might provide a bit of info about our development process and how we came to develop Twelve. I have been in constant contact with Michael (programmer) and unfortunately he won't be able to write many if any blog posts at all because he's too busy actually working on Twelve.

Twelve started out as an idea for a multiplayer space shooter two years ago in 2013. Michael had started coding a long time ago and by then we were already coming up with wild video game ideas, little did we know, video game development is very difficult. We had definitely already tried and failed to make other games, we were simply too inexperienced and never planned ahead. Twelve seemed like a relatively simple concept, a pixel art style and simple mouse controls with thrilling competitive multiplayer action. That was the problem though, multiplayer. From what I understand (as someone who never codes), networking is a very difficult task, not to mention the cost of servers involved. We created 10 different ship drawings and drew planets and asteroids. All we did was make the ship fly around and shoot, and then Michael lost interest.

Since then we've attempted even more projects, not all games, but when they were games I would gladly provide the artwork needed. We've even experimented with mobile applications, and earlier this year had actually published our very first game on the google play store. It was a very simple game that had tons of art and very little gameplay, but we finished it and published it and that was the most important part. Now I'll refrain from actually naming it for fear of being associated with that (monstrosity of a) game. Though we may come back to mobile games in the future, our focus turned to one or two other projects and ideas before Twelve again crossed our minds.

The issue on our previous attempts was always that our games didn't feel fun, and that is why Twelve is different than those failed projects. Michael had decided to use the same old ship designs from the original attempt and make a very simple functioning demo, where all you could do was fly around and shoot an enemy ship. This got him thinking about computer artificial intelligence, and how he was going to code NPCs, which, with greater experience and skill than before, he accomplished quite well. This new AI allowed the game to feel fun, the player controls a ship with their mouse and clicked to shoot, and the AI's behaviour allowed for a great experience.

Since we finally had a small bit of fundamental gameplay done that actually felt fun, we decided to move the project forwards, but this time we wanted to finish it more than ever. We both knew that we needed to make a plan in order to organize our ideas and make our project doable. These projects always seem to be much more difficult to complete than previously anticipated, largely due to our overlooking details that should not have been forgotten.

This time we set more limits to our vision, and even though it's all great and wonderful to have crazy ideas and big dreams, when it comes to development it's better to take it one step at a time. So we decided to limit our game to singleplayer only, and attempt to make good use of our fun gameplay mechanic while figuring out what kind of game we wanted. When we saw that we could make our AI just as skilled or even more so than the player, then came the idea of having them be on some sort of "even ground". Quickly we formulated the concept of and open world game, then we decided this would fit well in a conquest styled game. We wanted to make the enemy ships as alive as the player is, and so the concept of territory control was a perfect way of implementing this.

We decided to have 12 different races that were all disputing over territory, each owning a part of the universe and each capable of growing their territory. The NPC races will automatically capture each others' sectors at random intervalls, each time with certain odds of success depending on multiple variables.

We are now around 2 months into development, which we're hoping to get through greenlight on Steam. And we're very excited to have a very fun game that we didn't immediately give up on. We now have a team member making music and another for additional design input. The music so far is phenomenal and the game details have been thoroughly thought out, and we still plan on adding more.

Stay tuned for the eventual release of Twelve on Steam.

-Brendan

You can follow our Twitter account for screenshots, gifs, and videos and any questions you may have.