The issue Most people involved in games development have likely heard of Havok Physics: a middleware solution which provides collision detection. HEXTERMINATE used Havok for a long time, as it was free for Windows even in commercial projects, as long as they didn’t sell over a certain threshold. However, the hobbyist version has stopped being distributed years ago and this caused some issues: more modern versions of Visual Studio weren’t supported (anything past VS2012) and most importantly, could the game still be shipped with it? An open-source approach The alternative chosen was to use the open-source library Bullet: Conceptually similar: most of what HEXTERMINATE uses could be done in Bullet without massive refactoring. Functionally equivalent: there were no holes in the feature list, everything I needed was present. Permissive licence: the ZLIB licence puts essentially no restrictions on the game. Source code available: I could republish the library binaries myself, getting me up and running in VS2017 quickly. Linux support: although not something I have spent time on, Havok was the last library holding off multi-platform support. Making it all work Getting the basics up and running was fairly straightforward. What ended up taking up most of the time was that many places in the game’s code were using Havok’s maths library rather than GLM, which required some head scratching and debugging to make sure that it was all working. Most of it was fine, but swapped order of operations caught me off-guard a couple of times. When a battle goes wrong, it can go really wrong. In the end it was actually the smaller things that took the longest: getting callbacks with the required information for when two ships collide was non-trivial, as I needed information about which two modules were colliding, not just the parent “ships”. The other problem which took a while to figure out was that raycasts which return multiple results do not return results in an ordered fashion, so I was seeing odd behaviour with some weapons, e.g. a beam weapon being blocked by a shield but still damaging the module behind it. Improved behaviour Cylindrical shapes In HEXTERMINATE, each ship is composed of a number of individual modules. Each module can be destroyed separately, so each ship’s physical hull is composed of a number of physics shapes. Historically these shapes have been spheres, as it is algorithmically much faster to calculate the collision between pairs of spheres than pairs of hexagons. However, a problem that comes with the sphere approach is that it is possible for a projectile to go through two modules and hit the module behind them. It doesn’t happen very often, but because the outer modules are normally some sort of armour, when it does happen the player definitely notices. The alternative was to use cylinders rather than spheres: still faster than hexagons and it prevents the frustrating projectile punch-through. In red, the debug draw of the new collision shapes. Bypassing shields Shield modules generate the classic science-fiction bubble around a ship. Until the replacement of Havok with Bullet, the shield had to be disabled before the underlying ship took any damage. This had a few issues, such as making the choice of weapon less relevant, but more crucially this meant that the optimal way of building your ship was to put as many shield modules on it as you could. Missiles now get through shields, so a missile interceptor might be a good choice. A way to mitigate this was to make certain types of weapons to be able to bypass shields: missiles and torpedoes can now hit the underlying modules directly, making up for the fact that unlike other weapon types they can be intercepted. This worked very well and made some encounters more interesting after a few tweaks to the designs of certain ships. No more ghost collisions A long-standing bug had to do with the ships or projectiles colliding with something invisible. This was quite rare, but it was obvious that some of the physics collision shapes weren’t being properly deleted. Tiny memory leak aside, I was concerned this might lead to a memory stomp and crashes, as the parent ship no longer existed. To help me track this down I’ve made use of Omar’s excellent imgui library to get some of required debug information on screen. In the end this was tracked down to the shields on ships: if the player left the sector, any ships which still had their shields up wouldn’t remove the associated physics object correctly. Next steps The game is now very much near completion. There are now two chunks of work remaining: Finish the campaign: the campaign leads the player through the galaxy, providing a direction to head towards without overly constraining the player’s liberty. It is about 80% completed, so the push is to finish the remaining couple of missions. Steam achievements: achievement support is already in place but not all achievements have been hooked yet, as some depend on the campaign. Thanks for reading!
Date
6 years ago
Views
176 Views
Reading Time
4 Mins Read
Finally, the game that I have been working on during my spare time is ready for Steam Greenlight’s process! HEXTERMINATE is a space shooter written for PC, putting the player in the role of an Imperial Captain as part of a campaign to conquer the galaxy. Onwards to cutting the trailer and getting the game on Steam, then…
Date
8 years ago
Views
143 Views
Reading Time
< 1 Min Read
It has been a busy month in HEXTERMINATE’s universe. I’ve assembled a short trailer to showcase the game, backed as usual by =kontinue’s great sound track! Be sure to check it out. But lets take a look at the game’s development itself. Sound effects A game can’t be complete without sound effects, even if it is a space game and have to ignore little things like physics going “you’re aware there’s no sound in space, right?” Hogwash. Most of the sound effects are now in place, making use of FMOD’s positional audio which made it easy to implement automatic panning and volume rolloff based on distance. Overall I’m quite pleased with it and it makes battles sound far, far more alive. I’ve also written a small post on the the implementation gotchas that might be of use to other developers. Balancing pass Balancing a game’s is almost always tricky and HEXTERMINATE is no exception to this. The variety of factions, the kinds of ships they use and the large amount of modules that can be used make the task of balancing everything properly a fairly time consuming one. Overall the pace of the game has been slowed down as ships were exploding too quickly, which made it both difficult for the player to manage to pull successful, higher-risk raids into hostile sectors and fairly frustrating to try and keep a fleet’s losses manageable. Additionally, most ships of the Ascent and Iriani factions have been redesigned and made more specialised. The Iriani in particular remain, as before, terrifying: attacking their territory is not for the weak of heart or for those afraid of losing ships in the process. Of course that over the campaign you’ll have to conquer their homeworld but hey, no one said that the life of an Imperial captain was an easy one. Loading games For a long, long time, the game has been making use of TinyXML to handle XML files, which are used to store data about all the modules as well as save games. This has been working quite well until I’ve recently noticed that with 50+ games saved attempting to open the “Load game” menu would make the engine choke and the framerate to plummet to the “seconds per frame” level. This has now been addressed by running the file loading in a separate thread, which keeps the framerate solid and the user interface responsive. I’ll also be looking into updating to the new version of TinyXML (creatively named TinyXML 2), which promises to be considerably faster than one I’ve been running with. The next steps Over the next month the focus will be on the modules which don’t have custom models yet, such as the armour repairer and shield generator. This was meant to be tackled this month but I’ve made a detour to get the sound effects in, but this is now blocking other work and needs addressing. Additionally, I’m looking into the actual Campaign, which provides a thread for the player to follow in the open galaxy of HEXTERMINATE.
Date
9 years ago
Views
170 Views
Reading Time
2 Mins Read
One of the great things about FMOD is its ability to play sounds in 3D space, internally handling all the details of panning, volume rolloff and Doppler effects without requiring too much trouble from the developer’s side. I’ve recently started adding sound effects to Tannhauser and I’d like to share with other people some of the problems I’ve had – perhaps it will save someone a bit of time. Setting up the listener The listener is the player’s “head” in 3D space. It is setup by calling set3DListenerAttributes() and receives a position, a velocity, as well as a forward and up vectors. However, make sure that the forward and up vectors are normalised: due to a bug in my code the forward vector hadn’t been normalised and it was causing the sounds to always play at full volume from both speakers. 3D sounds are initially placed at the listener If a 3D sound is created without being set to start paused, it will begin playing at the listener’s location. Even if the sound’s 3D attributes are set immediately afterwards, you’ll likely still get a noticeable “pop” as the sound starts playing and gets relocated. To avoid this, create the sound as initially paused, set the attributes and then unpause it. Minimum sound instance distance Setting the minimum distance on a channel allows us to define how audible the sound is as you get further away from it. Something I am currently playing with, however, is having different minimum distances for the player and for other ships, making the player’s actions more noticeable in the chaos of battle. Too many active sounds There are explosions in Tannhausers. Lots of explosions. On a bad day, there are over fifteen ships all flinging large amounts of missiles, torpedoes and other fun things at each other, potentially creating hundreds of sound instances within a couple of seconds. This both makes the game very noisy and makes the CPU fairly unhappy at having to handle that many simultaneous instances. The current solution is to prevent sounds of the same type (e.g. the same explosion resource) from generating a new instance more than once every 100ms. This still makes it sound like there is a great deal going on, while preventing an excessive number of instances. This is also helped by each sound effect having a short duration. Audacity Audacity is a great free program to play a bit with sound effects, which is something I’ve been wanting to do for a while. Other than modifying the sound to generate variants of a sound (such as the “missile launched” sound being used as source for the “torpedo launched” and “rocket launched” effects), it also allows for sounds to be trimmed in order to remove any silence at the beginning or at the end of the sound.
Date
9 years ago
Views
172 Views
Reading Time
2 Mins Read
With having to split time between programming the game, creating the art assets and trying to get the game out there while juggling a family and a full time job, time is a rare commodity these days! To try and make more progress in the actual game, I’m starting a monthly column of development highlights, showcasing the new stuff that is making its way into the game. Requisition system Until now, the player was always given three gunships to assist him, which was extremely useful in the beginning of the game as it provided a way to even the odds against hostile fleets. However, as a game progressed, the allied ships would become less as less useful as the player began tackling harder factions, the little gunships finding themselves turned into space dust without really contributing anything to the battle. The new requisition system targets this issue. As the player is part of a greater Empire, he can now request that the Imperial Headquarters provides additional ships to his fleet. This bringing a kind of currency to the game, Requisition Units, which can be earned both by conquering sectors and by keeping them under Imperial control. No longer constrained to gunships, the player can now bring Imperial battlecruisers and battleships to his fleet. Missile interceptors In Tannhauser there are several kinds of weapons but of all of them, missiles in their many variants can be some of the most difficult to counter. Particularly as the size of ships grows larger and armour gets heavier, dodging out of the way of torpedoes becomes as difficult as negotiating the Greek bailout. To assist a Captain who finds himself on the wrong side of missile barrages, the new missile interceptor module has been added, which will attempt to shoot down nearby missiles as long as there is enough energy to power it. Two missile interceptor modules providing protection to the player’s fleet. In combination with the Requisition System, it is now possible for the player to request ships which are dedicated to this role if so desired. In the end, the balance between defence and offence is delicate and the new Missile Interceptor provides a much needed alternative to keep your fleet intact. Shield effects In their basic setup, shields have been around for a while. But there have been some tethering issues such as impact positions not actually being completely correct (although it is quite likely no one would have noticed!) and, perhaps more importantly, the fact that I hadn’t been all that happy with how the shields looked. So I’ve made a few changes, tweaking the shader and adding proper texture mapping and further animation into the effect. I’m quite pleased with how the new version turned out and it is likely this will remain unchanged until the game is released: The new shield is now properly textured and animated. Next steps There are only a few new module types I want to add, although on the art side there’s still quite a bit to do. In September I want to get the proper models in-game for the Armour Repairer and Shield Generator. With those done, I’ll be looking into getting the Rocket Launchers functional and all ships in the Requisition System up and running. Finally, there are two large systems that need to go in: sound effects and the mission generator, which will be the “big one” and essentially wrap-up all of the game’s systems, as well as giving the player a clearer purpose in the wider galaxy.
Date
9 years ago
Views
176 Views
Reading Time
3 Mins Read
Hello and welcome to HEXTERMINATE’s third devlog. The last week has provided a big jump forward with the project. I’m now collaborating with kontinue for the game’s soundtrack and it is a very promising start which does make want to integrate FMOD right now so I can get these songs in. Do check his bandcamp and soundcloud. So, let us take a look at what’s new in-game… Hyperspace In the last week I’ve added a proper effect for visualisation for the hyperspace effect, which makes entering and leaving a normal sector much more interesting. It is particularly pleasant to see the hyperspace gate open when the player’s ship is being shot to pieces and desperately trying to fleet to safety. As it had been talked about in a previous devlog, the player is not the only one that makes use of hyperspace. While contesting a sector the galaxy does not stop dead in its tracks, so all the fleets in the galaxy keep doing what they were doing: contesting a sector of their own, travelling… or perhaps they’ll spot the player’s battle and decide to join in. This is something that works both ways, with both enemies and allies considering if this is a battle they have a stake on. This does add an extra layer to the game, as the player does should consider if a region of space is too “hot” to attack, as the risk of being caught off-guard by mid-fight reinforcements is quite real. This risk can be reduced by having a bridge with hyperspace sensors, which will provide an early warning. Further work Additionally, most items are now in-game and can be found as loot from the enemy ships. As expected, the quality of the loot is proportional to the kind of enemies the player is facing. It is important to note that there are no artificial constraints (like levels) that prevent the player from entering certain areas, making it quite possible to attempt hit-and-run attacks on powerful enemy ships. Skill is definitely rewarded and since each module can be destroyed individually, landing a few well-placed shots on an enemy ship’s reactor can be enough to see it dead in the water. What’s next? The first thing on the list is to finish the itemisation, which should be done by the end of the week. A round of balancing will be required and that play-testing should reveal any major issues that might affect the game’s stability or other bugs that need to be resolved before the Pre-Alpha.
Date
10 years ago
Views
172 Views
Reading Time
2 Mins Read
