HEXTERMINATE News

This should definitely have happened a long time ago, but I've created a Discord server for HEXTERMINATE, as well as general games development and programming. If you'd like to have a chat and discuss where the game is going, join our Discord server here.



It is one of those things which are inevitable in software development: mistakes are often obvious in hindsight.

If we go back several years, I decided that writing my own User Interface library was a good idea. This was a valuable experiment in a number of ways, providing valuable insight into the complexity of such a system: how do I bring fonts in? How does input need to be implemented in a multilayered system? What about popups? How difficult can it be to get the text in a text box wrapping correctly?

If I was just making an engine for fun and experience, that decision would have been fine. However, since I was actually trying to ship a game with it, that was a mistake. This mistake was further compounded by a reluctance to upgrade the UI system to allow for dynamic reloading, which meant that building and tweaking interfaces was very time consuming.

However, with HEXTERMINATE staying in development for the foreseeable future, there will be a substantial amount of UI work that will have to be done. For my sanity, I’ve decided to finally bite the bullet and layer a more advanced system on top of the current UI, allowing me to modify new UI elements on the fly and store the design as a JSON file.

This has allowed me to fairly quickly iterate on the main menu, bringing it to a much higher standard.

Here’s the original main menu:



And here’s the new one:





Since HEXTERMINATE has already been released, there are some considerations as to how new, large updates are handled. I could write the new UI from scratch, but that would mean no updates for a long time, as all the pre-existing user interfaces would break and they would all have to be re-implemented before a new build was made available to the public.

Instead, I am building on top of the current system. This will allow me to swap in new UI elements over time, improving the quality of the build over several updates. Writing UI code is also not something I find particularly satisfying, so this split also also helps with managing motivation as I can mix in work from other areas.

The disadvantage is that there is clearly “the new UI” and “the old UI”, but it is a compromise I find acceptable until the old UI is completely phased out.



The old UI was entirely created in code. Each UI panel you see in-game would have a wall of code behind it like this:

m_pBackground = gAllocate( Gui::Image );
m_pBackground->SetSize( backgroundWidth, backgroundHeight );
m_pBackground->SetPosition( ( screenWidth - backgroundWidth ) / 2, screenHeight - 200 - backgroundHeight / 2 );
m_pBackground->SetTexture( pBackgroundImage );
m_pBackground->SetHiddenForCapture( true );
m_pBackground->Show( false );
FrameWork::GetGuiManager()->AddElement( m_pBackground );
m_pDockingText = gAllocate( Gui::Text );
m_pDockingText->SetFont( EVA_FONT );
m_pDockingText->SetColour( EVA_TEXT_COLOUR );
m_pDockingText->SetSize( 340, 64 );
m_pDockingText->SetText( "Press 'F' to dock" );
m_pDockingText->SetPosition( 197, 111 );
m_pBackground->AddElement( m_pDockingText );

Any changes to the UI would require changing the code (e.g. move a checkbox 2 pixels to the left), then compiling the game (which takes roughly 30 seconds) and finally launching the game again and getting back to the place where that checkbox was visible.

As you can imagine, this was very, very time consuming.

With the new UI, spawning a new element and defining the hierarchy is still done in code, but most other things are now done with an in-game Property Editor.



The Property Editor lets me find modify exposed properties (such as position, text, colour…) on the fly, without having to go through the modify code → rebuild → run loop. As mentioned earlier, the final layout is saved in JSON.



In HEXTERMINATE, ships have a fairly limited movement range: they are capable of moving forwards and turning. With the Reverse Thrusters perk, they’re capable of moving backwards at a limited speed, while Evasion Protocols provides the ability to dodge sideways on a very low cooldown. Finally, a ship can use Ramming Speed to charge forwards and deal substantial damage on impact.

This makes it easy to quickly get into the middle of a fight, relying on heavy armour and shielding while dishing damage. However, there are several issues with it:

• Evasion Protocols is all but essential. Due to the boost amount and very low cooldown, you can move very fast with it and it can lead to some silly behaviours, such as the space equivalent of bunny hopping.
  
• AI ships which orbit around their target struggle to adjust their distance due to the lack of fine control. And they don’t use Evasion Protocols, either.
  
• Ships that do try to get close have no way to keep to their optimal range. Ideally ships want to keep their targets at the maximum range of their weapons, as getting closer than necessary can bring them into the field of fire of shorter range, higher damage weaponry.
  
• As Ramming Speed is currently a multiplier on the ship’s thrust, lighter ships using it can move very large distances in a rather uncontrollable manner.

To address these issues I’ll be looking into making the following changes:

• Evasion Protocols will now have a single, longer cooldown (rather than two cooldowns, one for dodging left and another for dodging right).
  
• The thrust multiplier applied by Evasion Protocol will be reduced. It will still be of benefit to heavier ships, allowing those to get out of the way of the way of ramming ships or Particle Accelerators.
  
• The perk Reverse Thrusters will be removed. The ability to fly backwards will become a core part of the ship’s movement.
  
• The ability to strafe left and right will be added, also as part of the core movement. It won’t move the ship nearly as fast as Evasion Protocols, but definitely assists with keeping on target.
  
• A new perk (called Thrust Vectoring) will increase the effectiveness of sideways / reverse movement.
  
• Using Ramming Speed will be rebalanced for lower mass to weight ratios, making lighter ships easier to control.
  
• The AI will be updated to use the new improved core movement to better keep distance.

A new build will be coming by Monday (21st of June), which will include the work so far in the new User Interface, as well as the changes to ship movement. Changes to the AI will come in a future update, as I am looking into some larger scale changes on that front.

The plan going forward is to have a regular release cycle, with an update a month (barring any patches if I notice something important is broken) as well as a blog post so you can see what’s being worked at.

• Ships can now have an outline surrounding them, helping you identify whether they are friend or foe. This is enabled by default, but can be turned off in the Options screen. The player's ship has a cyan outline, any friendlies are blue and hostiles are red:
  
  
  
  
• An accessibility option has been added to allow firing turrets to be a toggle, rather than having to hold the left mouse button. This option is disabled by default, but can be turned on in the Options screen.
  
• The engine has been updated to use OpenGL 3.3 and GLEW, greatly simplifying some of the underlying rendering code. This is not expected to make any difference for the majority of players, but it makes further development easier.
  
  

With HEXTERMINATE having been out for a while and the bulk of the issues resolved, it is time to talk about what will happen to the game in the long term.

Although the game is has been released, development will be carrying on for a long time to come: HEXTERMINATE is one of my two hobby projects and one that has an ever-growing list of things I’d like to do.

Before we go any further, let me just make one thing clear: these will all be free updates and available to anyone who has bought the game.

So, lets have a look at the backlog for a broad overview of where development time is going.



The engine HEXTERMINATE uses is homegrown and was started a very, very long time ago (a cursory look shows the first copyright notice in it dating back to 2014, but the first files were probably created in 2006 or so). Over the years it has been updated as necessary and chunks have been rewritten to allow for easier development.

One of the systems that needs some love is the renderer. Although sufficient for what the game currently does, it is quite primitive and had large chunks of OpenGL boilerplate code which is completely unnecessary nowadays. Previously using OpenGL 2 and relying on extensions, the engine has now been updated to use OpenGL 3.3. This is unlikely to cause any issues to anyone who has bought the game, as most cards this side of 2010 will support it, while considerably simplifying any work which touches the rendering system.

These first updates will be available in the upcoming release, Build 16.



[h2]Outlines[/h2]

One of the criticisms the game received when it was released was that it could be difficult to identify which ship was the player’s, which ones were allied and which ones were enemies.

To improve readability, ships have been given an outline to assist with identification.



These outlines will be on by default, but can be disabled from the Options menu for players who prefer to play without them. This feature will be part of Build 16.

[h2]Fire control[/h2]

Weapons are currently split into two broad categories: turrets and fixed hardpoints. In both, the player has to hold the respective fire button. An option will be added in Build 16 to make this a toggle, rather than a hold to fire.

[h2]Control remapping[/h2]

At the moment, all controls are hardcoded. The game uses the classic WASD mapping, mouse buttons for firing, Q and E for dodging and a few more keys for activating the various modules.

There hasn’t been much call for allowing these controls to be remapped, but it’s definitely backwards not to allow it. Additionally, as new features are added, having the ability to do so will be a good improvement.

Purely from an implementation point of view, this is fairly straightforward. In addition to the remapping functionality itself, there are some changes that need to be done in the tutorials and the configuration needs to be stored and loaded. However, the big issue is the interface to allow players to remap it, which leads us to the next point…



The user interface in HEXTERMINATE is functional, but quite basic in certain areas. Before adding new features which will require either new windows or substantial changes to already existing screens, I’m going to spend some time refreshing the UI to make it more functional, readable and easier to implement.

Right now it is extremely time consuming to make any changes to the UI: all the elements are hardcoded and any changes require a compile and game restart. This isn’t really sustainable (my sanity suffers!) and work has already started on created a better UI which can take HEXTERMINATE info the future.

I don’t expect the entirety of the game to get the new UI at the same time as there are quite a few different windows, but you can expect Build 17 to start bringing this in.



This is something that has been on my wishlist since The Beginning of Time and that, somehow, never actually happened. The Codex will be both a repository of in-game lore and of module information, providing detailed information and giving the player a good idea of what’s out there.

Not every Codex entry will be available at the start, but the majority will be.



Right now the movement of ships is fairly restricted: they turn and move forwards. If you have the perk Reverse Thrusters your ship can go backwards and the perk Evasion Protocols gives you the ability to dodge.

This greatly limits the player’s ability to keep range, or even to kite effectively. The current plan is to remove Reverse Thrusters entirely, making the ability to reverse a core part of the ship’s navigation. Additionally, strafing would be added while still keep the functionality of Evasion Protocols.

Weapons also need some love. At the moment, there isn’t much point for using any type of Autocannon over an Artillery. All turrets snap instantly to their target as well, further limiting the ability of a ship to engage in more interesting tactics.

I’ll definitely be adding angular rotation speeds to various turrets and intend to explore firing arcs to further differentiate weapon types. Additional weapon variants will also be added to increase the variety of what the player might face, while also opening the gates for meaningful electronic warfare.
AI improvements

These potential improvements are all well and good, but the AI needs to make use of them. The AI is fairly simplistic and there are many improvements that can be done, both at individual and fleet levels.

Some of these changes will make its way to the Campaign, but I don’t want to change that too much as it can have a substantial impact on the difficulty curve. Currently I expect such changes to mostly be applied in Infinite War and in a new game mode.



These are very early days, but Into Hyperspace (working title, subject to change) will be the next game mode added to the game. It will provide an endless run, taking your fleet deeper and deeper into hyperspace, into areas controlled by rampant AIs.

This is where the more adventurous features will go and where the future of HEXTERMINATE lies.

I hope you stay with me for the journey. :)