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:

Write me an email to testers@battlefleetengineer.com 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:

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.

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.