It has been my intention to do a monthly Drox 2 early access report. This first one is at about the 3 month mark, so I'm a bit behind. :)

Drox Operative 2 is currently available on Steam and GOG.

As of this post, we've released 14 patches with 579 total changes (which can be read here). This consists of a ton of small fixes and balance changes, but there have been a bunch of larger changes.

Skill system: The biggest change so far is probably the new skill/command system. Now instead of unlocking bigger ships and more slots with crew points in command, you unlock slots in the skill system. Each ship has 21 slot skills, 21 general skills, and 14 race specific skills available to put skills points into. The slot skills are basically the new way to get bigger ships and more slots. The general skills are available to all races, are generally weaker, but provide a little bit of everything. The race specific skills are what makes each race more unique and are usually the more powerful skills.

Weapon Grouping: You can now group weapons (or other components) so that when you press a mouse button or key for a use slot, up to 4 components can be fired/used instead of the usual 1.

Multiplayer: We have improved multiplayer connectivity and optimized traffic to make the multiplayer experience better.

Young races: We have had young races that have random portraits, icons, and traits since the start of early access, but now they are more interesting due to having random services and they can emerge into the galaxy. So even though they are random, if they do well, they can become a more persistent friend or foe.

Guild Win: Guild quests have come back similar to what was in Invasion of the Ancients though instead of being mandatory they are optional. However, you will now get a Guild Win if you complete enough of the guild guests.

Resurrection: After your ship has been destroyed, resurrection is now much safer. On resurrection, your ship's engines and thrusters are repaired and you get 10 seconds of immunity to make it a bit easier to get back on your feet.

Crew Points: In Drox 1, pretty much every ship had to put a lot of the their crew points into tactical. Now most of the weapon types have an alternate crew attribute that you can meet the installation requirements for. For example, you can install fighters if your helm is high enough or beam weapons if your computers are high enough.

Icons: And last, but definitely not least, we've added a ton of new icons for planet bonuses, random race portraits, military stances, outsider attitudes, social stratification, and race traits.

That's it for all of the major new changes, but there are still a lot of potential changes coming up (which you can see here). Hopefully I can start making a post like this each month.

As always comments are welcome!

It looks like Drox 2's Early Access is going to get postponed a little bit. We are still in the Steam build review approval process. I submitted it last Thursday and Steam rejected it last night. I had left the Steam cloud stuff set as developer only and they wanted screenshots with the UI visible. I fixed both of those issues and resubmitted this morning. Since it is completely out of my hands I don't know how long the delay will be. It could be day or a week, I'm not really sure. Also on the Steamworks page it warns that their people are working from home because of Covid-19 and that could delay things more than usual.

As an aside, I actually never meant to have an exact date visible in the first place. I thought it was going to just say coming soon. When the store page went live with the actual estimated date, I was annoyed at Steam. However when I reread the options in Steamworks for the coming soon part, the store page was doing exactly what I selected. I either read it wrong this time or it has changed since we released our last game, either way it was my fault. :(

Anyway, as soon as we have the go ahead and it's not a terrible time to release, we will start Early Access. I'm hoping it will at least be within a week. In the meantime, I'm doing builds every couple days, so the game is getting better and better. I can't wait to get all of your feedback!

Comments

For those of you that follow us on social media or our forums this isn't a surprise, but I've started working on the design of what will probably end up being Drox Operative 2. I say probably because to me design is kind of an exploration and you aren't completely sure where you will end up. I'm pretty sure it will end up being Drox Operative 2, but Din's Legacy was originally going to be a mutating, permadeath, generational character type of game. The mutations is the only part that stuck (the rest just didn't work well enough with the mutation system).

Currently, and this all could easily change, I have 3 focuses to make this game better than the first Drox Operative.

1) Combat/action: I'm looking to make the moment to moment side of things a bit more fun. This will probably mean things like faster acceleration, faster turning, and maybe even strafing to make movement and dodging a bit more fun and important. Weapons might be more powerful, but rely less on auto-aiming. I'll probably also try to see how real momentum makes things feel.

2) Graphics: I'll at least be getting it up to Din's Legacy tech wise: VBOs, normal mapping, better shadows, and better lighting. Just doing this would make the game look a good bit better than the first game. It might even go faster and Drox was our most CPU friendly game.

3) More detailed systems to add more depth to the exploration, gameplay, and interactions between everything. By this I mean things like a planet could be rich in minerals. After discovering this planet, selling this information to a race might be very profitable, it could greatly help that race build fleets of ships once colonized, and it could also be a weak point for sneaky Operatives to disrupt or even destroy.

Again these are things that I'm thinking about now, but could easily change. Also these are just a small glimpse of the ideas I'm already thinking about.

Finally I would like to stress this part, comments and suggestions are always welcome!

Comments

We've supported the Mac platform for 11 years now, but yesterday Apple released OSX 10.15 which removed support for 32-bit applications. Basically that means that our games (and probably tons of other games and apps) no longer work on the latest version of OSX. It's certainly possible to fix this on our part, but the following is why that's not feasible.

• 32 bit apps no longer supported - This is the initial, direct problem. This is mostly changing to compiling as 64-bit application, fixing any compile problems, and then lots of testing and fixing any problems that crop up. This part is probably not too bad.
• Apple's Carbon API is 32-bit only - Pretty much all of our Mac specific code is using the Carbon API. We would need to rewrite all of this to use Apple's newer Cocoa API.
• Other libraries - Going from 32-bit to 64-bit is likely to break some of the libraries we use. Hopefully this just means we would need to update to a newer version, but it's possible we would need to go to a completely new library or write it ourselves.
• Now required to be notarized by Apple or app won't run - This is basically just getting an automated tool to run against your app. The process itself is probably pretty easy, it's the requirements that would cause issues for us. These can be seen at here.
• Notarization requires OSX 10.13.6 - This requires a jump of multiple OS versions for my Mac. The reason why it's on an older OS version, is because, in my experience, every new version of OS X breaks something in my developer tool chain.
• Notarization requires signing the app - This should be relatively easy.
• Notarization requires XCode 10 - Just like an OS X upgrade, XCode upgrades tend to break something in my developer tool chain and again this would be a jump of multiple versions. Also XCode requires 10.13.6 (at least that is consistent).
• Notarization requires an app to link against the OSX 10.9 or later SDK - This would force us to make the min OS we support as 10.9, so this would screw over customers on older OSX builds or I would have to make 2 Mac builds.
• OpenGL is deprecated - Apple hasn't completely killed off OpenGL, support but they have announced that they are phasing it out to support their Apple only Metal API. We don't even support Microsoft's platform specific graphics API.
• My Mac computer - My current Mac computer max OS that I can install is 10.13 (2 behind the latest). So I can barely get to the min OS version needed by Notarization and XCode. How long until Apple forces me to buy a new computer?
• How long until Apple drops Objective C for Swift? - Given everything else in this list, how long until Apple completely drops Objective C for Swift. Currently all of our Mac specific code is in Apple's Objective C language. It's already annoying enough that the Mac specific code is in a different language (we use C++), but being forced from one Apple language to another Apple language would be worse. Considering I would already be rewriting most of the Mac specific code it would make some amount of sense to get this over with now. Note: learning a new programming language isn't that big of a deal, it's just one more thing added to the long list.
• Gatekeeper Path Randomization / App Translocation - This has already partially broken our games before 10.15. This makes it so our games can't access our own data because it's not included inside the app bundle. Fixing this isn't hard, but it's annoying to need to fix it in the first place.

So the final list of things needed to continue supporting the Mac: move to 64 bit, transition carbon API code to cocoa API, probably replace some of our libraries, sign the app, notarize the app, upgrade Mac to 10.13, upgrade to XCode 10, transition OpenGL to Metal, transition Objective C code to Swift, restructure directories, fix everything that broke in all of these upgrades, and probably buying a new Mac computer sooner than later (and Macs are expensive).

I'm sure Apple has a good reason for all of these things, but a company with $250 billion in cash pushing all of this work on much smaller developers is kind of a crappy thing to do.

All of this would take more time than the initial port to the Mac in the first place. While the initial porting turned out to worth it, our Mac revenue has gone down a lot since then. So doing all of the above would be a pretty big money sink and unfortunately that is not something that we can handle right now. :(

NOTE: All of our current games that get patched will continue to get Mac patches. They just won't work on 10.15 and above.

As always comments are welcome and encouraged!