State Of Play
Comments Off on State Of Play

We have released a major milestone build build that has been several months in the making. The better part of that work involves some major revisions that needed to be done ahead of our final major milestone (user controlled ground vehicle unlocks). If you haven’t yet, you should also check out the gameplay flow FAQ entry which has been updated for this build.

This build concludes Phase II of our planetary vehicle system. In this update, the planetary defense systems (fixed and mobile vehicles) are AI controlled like the space defense turrets mounted on the space stations, carrier and Orbital Defense Systems, which we completed in Phase I.

Those of you who have followed the game’s development since the start, even if you didn’t buy it yet, will notice that, as I stated way back then, I have a specific way of planning and developing my games. Having designed massively complex games over the years, the key element in bringing it all together is to get most of the integral parts working in some fashion, then go back and start piecing it all together.

If you look at the very first public build, Build | 14-09-15, you will see that the process and procedures have all followed that pattern. Starting with unlocking the scenes, weapons, characters, items etc in a manner that allows each part to be tested and/or revised as they are released. This not only keeps the list of on-going bugs relatively low, but also prevents the distractions that come with freaking out over 1000 entries long bug lists.

Gamedev is like a jigsaw puzzle that you put together piece by piece. Like seeing how the sausage is made, it’s not always glamorous, stuff breaks (like all the time); and sometimes you put in a wrong piece that doesn’t fit (making it either a bug or a bad design choice) at all. Then you refactor (LOL!!) it, put in a new piece that either fits, or breaks everything that previously worked. For example, in this build, right around the time we were breathing a sigh of relief and ready to build the final GA (which we released today) version from the dev (which we released on 03/10) version, we discovered that over time, the game servers would flat out start refusing scene interconnect requests. Due to the server networking design, this meant that after some time, you couldn’t transition from one scene (e.g. Lyrius space) to another (e.g. Heatwave planetary base). In the end, that turned out to be caused by an entirely different – and largely unrelated – issue. That being the proxy server’s “are you there?” requests, which are designed to check on server sessions to see if they are alive, suspended, crashed etc. So yeah, that one was all kinds of fun to nail down.

It’s coming along, and the pieces of the LOD puzzle are all still part of the original (no scope creep, no deviation from the original design etc) design from back when I completed said design for the game that I wanted to make. That being, an original and compelling “pick up and play” combined arms game. And one that nobody else is making due to risks, complexity, industry trends etc. Along the way, having built (read more 1, 2, 3, 4) a custom game engine from a plethora of middleware technologies, we’ve basically been doing a lot of tinkering.

It’s a process; and being an expensive (my most expensive game yet) wholly self-funded game, and developed by several people around the globe, it has been a long road to get where we are today. But the push continues. And seeing as we don’t have the luxury of burning other people’s money, the game is ready when it’s ready; and right now it’s not ready.

The next milestone, GEN8, which unlocks player controlled ground vehicles, will be our final major milestone before the spit and polish phase goes into full swing. If you have been part of this journey, and you are in the closed beta program, thanks for your continued support. Together, we built this.

State Of Play
Comments Off on State Of Play

We released Build on 16-10-04 to both DSS and GA, thus unifying the builds. This was a major release culminating from several DSS releases (starting with Build of 16-09-02) as we worked through a major milestone (see 16-08-15 dev bulletin) that included the AI controlled space defense systems (station/carrier mounted turrets, Orbital Defense Systems). With that out of the way, we’re now working on the planetary defenses component part of that.

The reason that it was split into two parts is due to the major differences in their handling. For example, the defense units on the planet can all be entered and used by the player – whether they are fixed or mobile units. So when a unit is in “passive” mode, it only fires when fired upon, and doesn’t have any faction affiliation. When a player enters the unit, the player’s faction is inherited for as long as the player is in the unit and either driving it or firing its weapons.

The other issue with planetary units is that some have both driver and gunner positions. Though we’ve had the ability to use ground vehicles for years now, aside from updating them to use the newer networking layer and handling, we still have to handle the issue of occupancy in terms of how the weapons are handled in multiplayer. Gunners can enter vehicles which have them, but they can’t drive them; only pilot/driver can do that. And to make things even more complex, some of these ground vehicles don’t have pilot/driver accessible weapons. Which means that, unlike aircraft, a player driving a vehicle doesn’t necessarily have the ability to use/fire its weapon systems.

So yeah, it’s complex.

As with did with the first part of this task, the first build going up on DSS in the coming weeks will give the ground units target acquisition, tracking, engagement capability – exactly like the space defense units. Then the follow-up builds will include tweaks, bug fixes, and the ability for players to enter the units, drive the mobile ones, as well as manually use all the weapon systems mounted on those that have them. The naval units will also be included as part of that.

For more info on the many ground and naval units available in the game, check out the assets dB.

During all this, as seen in the roadmap, several legacy game assets such as weapons, aircraft, vehicles and some environment assets and buildings (e.g. station interiors) will also be getting on-going major visual improvement passes similar to the ones already done for aircraft, some weapons, the character models, animations etc.

Meantime, we’re doing extensive playtesting to weed out annoying and lurking bugs. Some of which have now been entered into the known issues log and will be addressed in upcoming builds. Please keep the support reports coming!


The short-term GEN7 plan includes the three phase milestones from the roadmap.

Next will be the final revision of the Automated Transport System (see game docs p10) which we disabled a few builds ago due to issues with how it was originally implemented. The new version will be more robust, and less susceptible to failures due to server networking updates and such.

Sticking with the AI side of things, we’ll then embark on the AI controlled androids in which their pathfinding as well as target acquisition, tracking, engagement capability will be enabled and tested. Since they will be active in both stations, carrier and on the planet, this will be a major milestone release as well. As these are handled exactly like the defense systems, most of the implementation is already done. The difference with the androids is in their pathfinding and target chase logic, as well as how they use their firearms when engaging threats. Their use as AI player companions will follow in a later update.

With all the above components in place, we will then work through the World Events (gameplay modes) as well as other minor tasks, tweaks, and bug fixes, as the start of the GEN8 builds.


The final game release is going to exclusively require Windows 10, and we will deprecate support for Windows 7 as well as support for DX9. We expect to complete the transition in the near future. Doing this allows us to simplify a lot of things, as well as unify certain tech related to the XBox console build.

While we currently have no plans to support Universal Windows Platform (1, 2, 3, 4, 5), the general consensus is that one was declared DOA even before Microsoft announced it.

Given our game engine and networking design, and through working with our Microsoft counterparts, we have been gearing up to support Xbox cross-platform play (1, 2, 3, 4) via WINDOW10<->XBOXONE, as well as Xbox Play Anywhere (1, 2, 3, 4), and Xbox Game Preview (Xbox version of Early Access, 1, 2, 3, 4) on both Windows 10 and XBox One.


With LOD, though it has a solid design, compelling and unique features and technologies, as well as a flexible business model, there is always that something that you’re going to think you’re missing, and which is going to make all the difference to the game’s appeal and success. I don’t have any such concerns about the game. The only concerns I have are about the business model and whether or not upon release, it will find the core target audience or get lost in the noise.

Thing is, there are lots of FPS games out there. There are also several combined arms games (e.g. the venerable Planetside 2, Angels Fall First etc), all of which have some special features, and something more to offer than just your standard fare shooter. When I designed this game, I did so with the knowledge that I had no desire to compete in the shooter arena, let alone in any standard fare genre that was already saturated. And I certainly wasn’t interested in doing yet another space combat shooter when I’ve got my other titles (even the highly complex Universal Combat is getting a much-needed makeover for my hardcore fans) for that.

As to the business model, back when I designed this game, F2P was all the rage. While there are still a lot of F2P games out there, most aren’t even making enough money to keep the servers online, let alone pay the teams. Others use all sorts of tricks to keep the whales buying into the game in order to compensate for those who aren’t buying anything. Many others have failed and closed down.

The flip side is that the B2P (buy-to-play) model has its own set of challenges; with the most important being the price as a barrier to entry. For a PvP game, pricing still isn’t everything because you still need a compelling game. And there is also the risk of running into the Catch-22 of player engagement. Player checks out the game, doesn’t see many people playing, then leaves to go play something else.

With that in mind, since the very start, the design for the game fit either business model; in that it could either be F2P (with a free Starter Kit) or B2P. So given current industry trends, a F2P business model is probably not in the best interests of the game, depending on when we get to release it. While the PC version will still benefit from the base $19.99 Starter Kit and the optional Tactical Advancement Kit ($29.99 – $59.99), the console versions will probably have a different TBD pricing structure. However, it is important to note that if and when we end up with International (we currently only plan a US launch for the game, and with no localization) launch partners, they may choose a different business model based on their individual territories.


As the console versions were never going to be F2P, the forward thinking design also meant that we would have 64 client player hosted servers which would allow any player to host a game session, as well as play in that same session via an in-game server browser. Pretty much the standard model for most multiplayer games (e.g. our All Aspect Warfare / Angle Of Attack games use this model).

So with that, for the final game release, and in order to be able to support cross-platform play without issues, we’re going to be unifying this model across both the PC and console versions by allowing PC clients to host and join 64 client sessions via a server browser. This basically means that the “MMO” aspect of the PC game only pertains to dedicated (like the ones we currently host) servers which have the capability to support more clients than the standard model.

While there are no plans to distribute (as we did with the AAW/AOA games) the dedicated server binaries at this time, we will still continue to host dedicated WSG servers post-release. Though the ability for anyone to host and have more control over their own sessions is probably more appealing to most of our core audience. However, if there is a strong post-release demand, releasing the dedicated server binaries is a strong possibility.

NOTE that this doesn’t change the “persistent” nature of the game, other than if the player hosting a game session rage-quits, all clients get kicked off due to the host client killing the session. The game is a real-time, non-instanced type; and that’s not subject to change. Due to the underlying combined arms PvP nature, even when the (optional) world event ends, the session still continues running depending on the parameters setup on the specific session.


Another year is now ending and we’ve faced and are still facing challenges in various areas. Though this game isn’t even my biggest or most complex to date, most of the challenges have come from the usual nightmares derived from building (1, 2, 3, 4) a custom engine and game from scratch. Time passes, technology improves, the gaming landscape changes etc. A game designed in 2010 (following the release of our previous two games in 2009) and which goes into full blown custom engine development in 2011, outside of being a heavily marketed triple-A title (even those tend to face major challenges e.g. the excellent Titanfall 2, Mafia III, No Man’s Sky etc) will find it hard to compete if it cannot stay abreast of changes, or find its core target audience.

One of the challenges we’ve had these past months is due to the end-of-life support for the Havok Vision Engine (was Trinigy Vision Engine prior to the Havok purchase in 2011) which we used as our baseline engine. Not only is Havok no longer licensing (it doesn’t even appear on the website anymore) it, but the development of next-gen console (PS4, XBox One) versions of that engine was in a state of flux – right up until it was “no longer planned”. Thinking that Microsoft’s acquisition (in Q4 2015) of Havok from Intel would rekindle those efforts, sadly, that hasn’t happened – yet. So, for all intent and purposes, HVE is deprecated and dead. And we simply couldn’t wait.

Which means that going forward, we have had to make the decision to port the underlying base engine (Havok Vision Engine) to another comparable middleware engine. We looked at a few engines, but decided to go with Unreal Engine 4 due to it’s core and component system closely matching our custom built engine.

Unlike our multi-platform title (which we developed as a marketing promo for the larger LOD game), Line Of Defense Tactics which was developed (I setup another third-party team for that) from scratch with Unity 4, and which then also ended up on XBox One (we developed that in-house, and not with the third-party team) almost a year following release on other platforms, we don’t have the luxury of starting from scratch with this much larger and more complex game which is purely C++ based.

The problem with using different engines for the same game release, aside from update parity, is that it gets to be resource intensive, requires completely separate teams etc. So the end result is that we would have a PC game developed with a Havok based custom engine, and a console version developed with the more powerful and robust UE4. Even with using separate teams as I did with LOD Tactics, like that game, there will still be resource overlap due to asset conversions, game design and features etc. And I’d have to hire more people due to the increased workload.

So going forward, I have to decide whether to release the PC version as planned with the current Havok based engine, then release the UE4 powered console version later in the year or just port to UE4, then do a multi-platform release as we did before with LOD Tactics. The former is a major risk (releasing a PC only game first), while the latter would take a lot longer and cost quite a LOT of money due to the sheer amount of work that would need to be done.

While going to the far superior UE4 not only gives us a far more versatile and powerful base engine than previous engine, with vastly superior and dramatically improved visuals, we also get out-of-the-box support for PBR, HDR, 4K etc. It is also the less risky approach in terms of marketing as well as competing technologies. The downside is that it is also a more expensive approach because putting the PC release on hold while transitioning to UE4 means no game to sell for a game that’s nearing completion. Not to mention the added costs of the port (which also entails a LOT of art and model asset improvements to take advantage of UE4).

Until I make a final decision soon, everything is progressing as normal. But once that decision is made, I will of course be posting an update.


On completion of our final stage Open Beta Test, we disabled (more here) the Steam test page and moved to Closed Beta Test (CBT) for more focused testing. When we need additional testers, we will again be giving out free CBT test keys for testing purposes.