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!

At the beginning of every game I take a step back and consider if I should switch engines or if I should just enhance our current engine. Note: we are almost to alpha with our latest game, Din's Legacy, so the last time I did this was several months ago.

When I started working on our first game, Depths of Peril, in late 2004 the decision was fairly easy. The choices were mostly license an engine like Unreal or Quake ($100,000+ per game), use an open source engine (usually graphics only and open source can cause lots of issues), or write my own engine. Given the options available at the time, I felt writing our own engine was the only realistic choice for us.

Fourteen years later, things have changed greatly. There are now several powerful engines that provide an entire game framework and don't cost too much, the big two being Unreal and Unity. If you are just starting out, these are great choices (so are probably many other engines), but Soldak isn't just starting out so it's much more complicated.

Some pros of other engines: better graphics (this is the big one), better physics, mobile versions, console versions, and probably many other small things.

Some cons of other engines: dynamic world problematic (need to be able to load huge parts, if not all, of a world in the background), random levels problematic (works against things like packaging, light maps, and pathfinding - basically everything that happens when you build/compile a level), might have to redo or rework many of our current assets, licensing costs (not nearly is bad as it used to be), learning curve, start over with game code or lots of porting work, no source code (some have it and some don't), and probably various other things.

The pros and cons list is where I get stuck every time. The pro of having better graphics would be very, very nice, but the cons list is basically everything that makes a Soldak game unique. Potentially losing dynamic and random worlds is basically a non-starter for us. Add on top of that all of the ramp up time to learn how everything works, rework/redo old art work, and port or rewrite all of our needed game code, it really just isn't feasible (we would go out of business before finishing the game). This is essentially why every game, I stick with our engine. Our engine has drastically changed over the years though, as I add new features. If I was from the marketing department, I would probably just say it is a new engine each time there is a major graphics change or brand it in some way. :)

Now if we ever decide to make a more linear RPG that will be a different story since a lot of the cons would go away. Anyway, these are some of my thoughts when I have to make a decision about an engine for each game.

As always comments are welcome and encouraged!

In our next game, you play as one of the Mutated. They are closely related to the elves and a little to the dark orcs, but one of the main traits is that they mutate slowly over time. There are 3 main ways that this happens: randomly, mutation levels, and mutating with another character.

In rare cases, they can just mutate randomly. This is usually a direct consequence of things happening in the game. For example, if you are killed by a Scree, you might gain a fear of demons. If you kill a bunch of Orcs, you might gain an Orc killing bonus.

The player has a mutation level that goes up as they gain experience. This works similar to normal experience, except it has a high randomness component to it. When the player goes up a mutation level, they mutate in some way. This can give them a free skill level in any skill they have access to, give them a completely new random skill, add a new mutation, or mutate one of their skills.

A new mutation could be something good like Acid Blood where melee enemies take damage when they hit you. It could be something bad like Hemophilia where you receive deep wounds more often than normal. It could even be something in-between like Horns which increases your physical damage, but doesn't allow you to wear helmets.

Skill mutations affect a specific skill. There is a huge variety of ways that skills can mutate. Let's look at the fireball skill as an example (other skills work in a similar manner). Some possible mutations: splitting (extra projectiles), efficient (less mana used), quick (faster casting), blasting (larger blast radius), forking (splits into 2 when it hits an enemy), icy (adds cold damage), of lightning swarms (chance of adding balls of lightning when a fireball kills something), or armor melt (chance of adding an armor melt debuff on each enemy hit by a fireball), and many, many more.

For all of these mutations, you can go with the flow and accept them or you can fight against them. Essentially you can can spend skill points to remove the unwanted mutations. This is only a short term cost though, since you will regain these skill points when you go through a full mutation. Every time you gain a mutation level, you also get a mutation point.

For every mutation point, you can go through a full mutation with another character or a class specialty. During a full mutation, any skill that is not currently being used in some manner has a 45% chance of staying as it is, a 45% chance of being replaced by a random skill from the target character or specialty, and a 10% chance of being replaced by any random skill from ANY specialty. You will also regain any skill points used to remove unwanted mutations and your mutation level will readjust to how many mutations you still have.

Overall, while your character mutates randomly, you have a lot of control over the process.

Thoughts? Questions?