Recent Posts

The game has now finally progressed to a state where the core mechanics (such as ship building and fleet battles) are playable and the basic supporting infrastructure (menus, game settings) are in place. I have decided to do a closed testing round soon with the intent to gather feedback about these core mechanics. All feedback from this group will be considered carefully and thus you will be able to influence the game.

There isn't much of actual content in the game, so trying it out won't necessarily take that much of your time, but you must be willing to spend some time gathering and communicating your thoughts and opinions. The first build should be ready for testing in a couple of weeks, but I also need to create some content and write a simple quick start game guide as well.

In this first pre-alpha testing build you will already be able to:
  • Create your own ship designs with module count ranging from just a few to hundreds.
    • Use 19 unique module types, each with their distinct characteristics. Including thrusters, generators, shields, weapons, armor etc.
  • Use your own or provided ship designs to assemble fleets to take on battle challenges with.
  • Command your fleet in tactical battles against computer controlled fleets. 
    • Get scored for your combined battle command and fleet designing performance.
    • Manually control (fly, aim, shoot) any ship in your fleet during battle.
  • Create and edit your own battle scenarios or play quick skirmish battles.
Introduction to the core ideas of the game can be found here.

What the game is lacking
  • All progression mechanics, it only has single battles
  • Any and all audio
  • Battle environment variety (currently only different sizes of empty space)
  • Many visual effects and fitting UI elements
As a tester you will need to agree to at least to the following terms:
  • You are allowed to record videos and take screenshots of the game itself, and share & monetize such content provided that you clearly mention the name of the game and that the content is from a pre-alpha version.
  • You are not allowed to make copies of, share or sell any of the game files (compiled code, assets etc.) in any form with anyone, with the exception of ship, fleet, battle etc. save files that you have created by playing the game.

How to apply:

Write me an email to and explain who you are, why should I trust you and most importantly what are you willing to do to help make the game better. I'm mostly looking for simple, realistic and concrete pledges like:
  • "I will record and commentate me playing the game for the very first time, pointing out things that I don't understand or frustrate me"
  • "I will try the provided battle challenges and report what kind of ships seem overpowered and any bugs that I encounter"
  • "I will create few ship designs and report my honest thoughts about how the ship editor is too clumsy and hard to learn"
  • "I will test the game with a few different computers I have access to and report any problems I encounter and what kind of performance I get" 

System requirements:

Battlefleet Engineer is a Windows PC only game that is designed to be played on a desktop computer. This imposes some (pretty basic) hardware requirements that you will need to take into account before applying to be a tester.
  • Mouse with a clickable wheel (5-button mouse recommended)
  • Screen resolution of 1920 x 1080 or higher (not a hard limit)
  • Windows XP or newer (Windows 7 recommended)
  • GPU with DirectX 10 support (anything newer than 2008-2010)

Posted by Tomi Thursday, April 23, 2015 0 comments READ FULL POST

End of the 7 month full-time development period

Hello again, time for another monthly update! It has now been 7 months of intensified development, as I have been able to work on this game pretty much full time. During this period the game has got pretty far from the state shown in the introductory core features video, but is still very far from feature completion. The main thing is that nowadays the game is actually playable, and has most of the UI, menus etc. support infrastructure for the actual gameplay in place that is expected from all real games.

Major features implemented since last August include: weapon modules, turrets, damage system, dynamic lights, ship battle AI, basic fleet AI, complete manual ship control, fleet deployment to battle, collision avoidance, battle scenario editor,  shields, battle challenges, scoring, game settings and action groups. Quite a list, isn't it? Combined, these features have taken over 20,000 lines of C# and JavaScript code and countless hours of work to implement. However, this development sprint is now coming to an end, as planned, because I need to take on a job to support myself and get on with my actual profession of automation engineering. Please note that the development isn't ending or even pausing because of this, but it will just slow back down to more of a hobby level of time dedication.
Like Feabruary, most of March was spent working on user interfaces such as battle result and game settings screens. These naturally have some logic behind them in the game engine as well, but creating the visualizations for the data and controls to modify it took much more effort overall.To get away from the quite tedious UI work, I also made the generic action groups actually usable and implemented some visual performance timers for optimization purposes.

Battle result screen

The battle result screen is a summary you get after playing through a challenge battle that shows your score, and various statistics such as fleet values before and after the battle, state of surviving ships and salvageable debris left behind. The scoring is based on multiple variables such as damage dealt and taken, battle duration and difficulty settings. Highscores are now recorded for all challenges, so there is now this simple motivation of bettering yourself. Naturally these highscores should be global and you should be able to view all of them, but those are features to implement much later.
The battle result screen with remaining player ships visible.

Debris is currently completely irrelevant, but something that will be very important later when there is more than single battles to play. Even if I limit the debris to modules that are pretty much without a scratch, there is usually quite a lot of them left after a battle. On the other hand, your fleet also tends to get very badly damaged if you go against an enemy of similar strength and win. This would lead to very tedious rebuilding of your fleet after each battle by replacing lost modules from the debris, a process that I will need to automate as much as possible. Even still, with lots of valuable debris left after each battle, the player could potentially progress too quickly. To balance this I plan on limiting the debris collection by the time it takes to extract every individual module and the amount of loose  spare modules a fleet can carry around. The idea is that in e.g. survival game mode you have a set amount of time to scavenge & repair before the next battle, and in the campaign if you linger around a debris field for too long you may encounter hostile fleets coming to collect as well. Functional core modules will also be quite valuable, as those are what separate a ship from debris.

Settings screen

No game is complete without a settings screen. On PC games this basic utility usually provides at least display and audio settings as well as key bindings for actions. So far I have implemented pretty basic settings, and some changes such as changing the resolution or enabling graphical effects requires a game restart, something I would like to get rid of at some point. These options will naturally still expand as new features such as audio are implemented to the game.

From a technical standpoint the settings screen works by getting the full GameSettings object as JSON from the game logic, and applies those values to the UI widgets. When the player decides to save the current settings, the settings object is updated to reflect the selections from UI widgets, and sent back to the game logic as JSON. This means that all settings are updated and saved at once, and makes it quite easy to add new options.

General game settings
A big part of the settings is the key bindings listing and editor. The game already has a few dozen bindable actions such as "move forward" or "issue a stop command to all selected ships". The binding system allows mixing keyboard and mouse key triggers, i.e. you can specify multiple keys and mouse buttons that need to be pressed for the action to activate. These triggers have selectable signal edge detection rules such as "active high" where the trigger is true when the button is held down and "falling edge" where the trigger is true for a single cycle when the button is released.

One major limitation of the current binding system is that every action can only have a single combination of triggers, meaning that you can't have alternatives. Adding this functionality would be pretty easy on the game logic side, but would certainly complicate the UI. I might implement it at some point if there is enough demand for such a feature.

Action binding editor. Here we have an action bound to holding ctrl and simultaneously pressing the left mouse button.

As the development will now slow down, I don't promise to provide these regular longer monthly blog posts. Smaller updates will still be coming, especially through Twitter, and I also have some announcements to make soon. A major one is that I will hopefully get the closed pre-alpha testing group organized this month, and get some feedback on the core features. Before that I would still like to do some pretty major rework on the ship editor to streamline some editing tasks and add various assists to make ship design evaluation easier.

Posted by Tomi Monday, April 6, 2015 0 comments READ FULL POST

First of all, sorry for this update being somewhat late. I wanted to finish the basic functionality for battle challenges first, and then have been procrastinating for a few days on top of that. A related update video might come later still. Those usually take several hours overall to produce, and I have found just working on the game more interesting and productive.

Overall, February was a decently productive month. Major new features from include battle challenges, fully implemented shields and a all-new radiator module.

Battle challenges

Battle (scenario) challenges is a new feature that allows battle scenarios (levels) to be saved with some extra metadata that allows the battles to be scored. There are three types of challenges:
  • Fixed battle: Both the player and enemy fleets are fixed, the player just needs to fight the battle the best they can for a highscore.
  • Fixed enemy fleet: The enemy fleet the player faces is fixed, but he can assemble his own fleet freely within a set budget. The player can also change the level and deployment area sizes to his advantage.
  • Fleet creation: The player is only allowed to design his own fleet with a given budget, the enemy fleet and level options are fixed.
These challenges are created with the battle scenario editor that now has an option to save the current setup as a challenge. The challenges can be browsed and played through a new screen that lists all of them with basic info, and shows details such as enemy fleet composition for the currently selected one. The battle setup screen is then used for setting up the "fixed enemy fleet" and "fleet creation" type challenges, while selecting a "fixed battle" challenge takes the player directly to the game. All challenges may contain a pre-made fleet for the player to use, and where applicable the player can also overwrite that with his own.
The battle challenges screen

Somewhere in the future I plan to add a challenge sharing feature that will allow the players to upload their own challenges to a central server, download them and compete on global highscores as well. While such a service should be relatively simple to implement, there are several caveats such a cheating prevention and content moderation that need to be addressed as well.


Implementing the shields took a considerable portion of this months work. This is partly because I decided to go ahead create at least relatively nice visuals for them in addition to the actual functionality. Like most of the mechanics in Battlefleet Engineer, shields don't really follow the simplest, most common pattern. Rather than being walls made of energy, these shields are more like magnetic or electric fields, meaning that the functionality isn't limited only to the edge but rather affects the whole area they cover.

The shields slow down kinetic projectiles and absorb the energy of plasma and beams traveling through them. All projectiles are also pushed away from the center, resulting in a nice deflection effect. The effects of individual shield modules stack, so having overlapping shields will increase the overall protection of that area, but the limited radius also forces the shield generators to be placed next to the modules they should protect. This creates a certain design trade off, because you will want to keep the shield generators safe, but also need to place them close to the edges of the ship for maximum effectiveness.

Shields have somewhat complex relation with (electrical) energy:
  • Each shield module consumes a constant amount of electricity for upkeep while active.
  • The shield's own energy is increased by using additional electricity to pump it up to maximum size. The maximum recharge rate and efficiency depend on the module.
  • The shield's radius is direcly defined by its current energy level.
  • Absorbing projectiles' and beam energy consumes the shield's energy that then needs to be replaced for the shield to retain its nominal size.
In combination, these mean that to overpower a shield, you will need to shoot it with energy or beam weapons at such a rate that either it can't recharge fast enough or the ship can't provide enough electricity to keep it up. It is entirely possible to overpower the enemy ship's electricity system with your sustained firepower so that they can't charge their weapons and shoot back.

Shields deflecting 4 kinetic projectiles. The trails expand and fade away.

The visual side of the shields consists of two major parts: static shield drawing, and dynamic projectile trails. The shields are drawn with geometry and gradients instead of sprites for perfect sharpness at any scale. To visually represent the stacking of the shield dynamics, I use a separate render target onto which the shield circles are drawn using additive blending and a color gradient texture. This map then contains the color and intensity of all the shields combined per screen-space pixel. Into that intensity map are also drawn expanding trails for all projectiles that travel through the shields, adding to the color and pattern intensity.

When the shield intensity map is done, the shield circles are drawn to the back buffer with a custom shader that reads the map and adds a repeating hexagon pattern from a separate texture as well. The pattern texture coordinates are defined so that it continues seamlessly from one shield circle to another within the whole ship. This ensures that the pattern looks good even if there are multiple overlapping shields.

Trail render mesh of two projectiles entering a shield from the left and top.


Radiator is a new module designed to deepen the ship design process by bringing new considerations to the table. By adding these modules that store and consume heat energy, this resource is no longer just something that could be replaced with a simple weapon cooldown timer, but is actually transferred within the ship. By adding radiators to your ships you can increase weapon fire rates by removing one bottleneck. This way you may need fewer weapon modules overall.

There are multiple things to consider when using radiators. First of all, they use a fair amount of electricity to pump the heat and keep the radiating elements at a high temperature where the output power is much greater. Like in real life, the amount of heat radiated depends on the 4th exponent of the surface temperature, so you will want to run your radiators at the maximum heat capacity for them to be effective.

The radiator module is also the first one to have dynamic graphics implemented. In practice this means that the radiating surfaces fade from black to yellow/orange with the stored heat.

The new radiator modules glow yeallow when heated up.

Again, the easiest and best way to keep up with the development news of this game and see all the cool stuff first is to follow the game on Twitter.

Posted by Tomi Sunday, March 8, 2015 0 comments READ FULL POST