AI War 2 v2.062 Released! “Savegame/Networking Data Compaction”

This is on the beta branch, as it’s a freaking huge number of changes.  The more testers the better, please!  Full notes here.

How To Play A Beta Branch Build

To play this on Steam, please go under betas and choose current_beta from the drop-down list. We would really appreciate some testers on this so that we can get back out of beta status as quickly as possible! There is not currently a way to get the beta versions on GOG, but we won’t be in that status for more than a week, knock on wood.

We want to make sure we didn’t break anything with all the substantial changes in here, but we fully expect some savegames to throw cosmetic errors at the very minimum. Please report and upload those here: https://bugtracker.arcengames.com/

What’s New?

  • The biggest thing for me personally is the new data compaction stuff, which I have been pouring hours into in preparation for multiplayer.  The last thing I want is for multiplayer to be functional, but immediately laggy as soon as we have the desync repair stuff going.  I needed to start with efficient data storage and transmittal so that there wouldn’t be a point where I need to disappear for a week to redo all that after we’re into multiplayer’s alpha.
  • I’m not entirely done with my data compaction shenanigans, but I’m very excited about how it has turned out so far.  I do expect it to result in a number of user-facing errors, though, so hence the beta, which I really hope you’ll partake in.
  • Badger fixed a number of bugs, including several achievements that were not triggering.  Also that all the AI units have had the equivalent of mark 1 shields/hull for the last two weeks??
  • Meanwhile, Badger also implemented another major fireteams upgrade, this one which is intended for the upcoming DLC2 but has been backported to the base game.
  • The first use of this fireteams code is to let the AI really fight some other faction other than you with giant fists, without killing you in the process.  Aka, let it fight the Marauders or the Nanocaust using REALLY BIG AND SCARY GUNS if those two factions are taking over the galaxy… but don’t have that be game-ending for you.  You’re not the problem, after all, from the AI’s point of view.
  • The second use of this is to let us have certain sub-groups of the AI faction, most notably Hunters right now, which have a sub-subgroup that just focuses on one objective after you harass them.  The example in place right now is Major Data Centers (MDCs).  Those always triggered an Exogalactic Wave, previously, which was boring — more ships come in increasing waves, and you survive them or don’t.  It felt kind of uninspired.  NOW, instead, the hunters get a major buff to a certain sub-team that explicitly hunts the MDC and its protectors… and if it wins against that, eventually, then they just leave you alone — “job’s done, bye!”
  • The way that the hunter deals with allied factions to you is a lot more interesting, too, rather than your allies causing rapid AIP gains by killing all the warp gates and aggroing the AI in that way.
  • These are some major strides forward towards multiplayer being a smooth and fun experience as we get into that, and towards the DLC2 that will come out around the time multiplayer fully releases (multiplayer will be free).   Please note that none of the DLC2 stuff is slowing down multiplayer at all, as Badger is not working at all on multiplayer and I’m entirely focused on that and related things for now.
  • Oh, also, for the sake of modders we’ve documented some new things that will help with making sure mods are multiplayer-compatible.
  • Note that if a mod you like turns out NOT to be multiplayer-compatible, the game should still be playable.  You’ll just have a ton more desync-repair messages going back and forth, related to the mod.  This is an excellent example of why I want those desync-repair messages to be absolutely as efficient as they possibly can be, which means representing all our data in as tiny a format as possible.

More to come soon!

But here’s some further reading on what we’re doing in detail:

Why Do We Care About Compaction?

I explain what I mean by this below, and go into detailed benchmarks.  The release notes have a lot of other detailed info.  But a TLDR of why this matters is certainly a good place to start:

  • Smaller savegames are easier to transmit across the network when you’re initially synchronizing your game from a host to clients.
  • Doing it via our compaction method, versus compression, uses FAR less CPU cycles, and thus makes the transfer of even small, frequent bits of data run more smoothly.
  • Doing it via our compaction method makes even small bits of data… smaller.  Compression often requires a lot of data before it makes much difference.
  • Given that we are going to have frequent small commands being sent back and forth just to have the game run at all, and then we ALSO are going to have the desync-repair data going back and forth that is still small (but substantially larger at the scale of network messages), this is pretty critical.
  • So the TLDR of the TLDR is that we use less bandwidth and less CPU to do the same thing, and thus your game will run way more smoothly in multiplayer.
  • And it has the side benefit of making savegames a lot smaller, and also faster to save.

Data Compaction vs Compression

What the heck is data “compaction?”  Well, in the most direct sense here, it’s a term I made up.    The way I’m defining the term, for purposes of what we’re doing here, is “making data smaller at the level of small objects, as we put it into a binary stream.”

Wait, what?  Basically… it’s something we do as we go along, and it works on very small pieces of information.  A single integer.  One ship and its data.  That sort of thing.

Compression, by contrast, requires a lot of processing AFTER you put in your data to some sort of format.  So to compress a bunch of data in AI War Classic, for instance, we write roughly 30MB of data for a savegame  into a temporary buffer, and  then we run GZIP compression on that, which turns it into maybe 1MB that we can store on the disk or send across the network.

That 30:1 ratio is legitimately what AIWC was seeing, on average, by the  way.  The downside is that it only really works well for very large amounts of data, and it also requires a lot of processing every time it wants to send or save.  You’ll notice that AIWC has a noticeable hitch in itself every time it saves the game.  AI War 2, by contrast, doesn’t use compression and thus doesn’t have that sort of hitching.

AI War 2 is a lot smarter about how it represents its data to start with (using binary formats directly  instead of a unicode-based format), and uses clever tricks to also know when not to send data of certain sorts (if I don’t have X properties, then don’t bother tracking them).  So this realistically converts what would have been 30MB in AI War Classic into something that might be… 5 MB in AI War 2.

Beyond that, though, requires a lot more work, because we actually have far more data here than in AI War Classic — enough that despite our better formats and such, we’d be back up around 10 MB or so for savegames.

Several years ago, perhaps four now, Keith LaMothe came up with a great new concept he called “buzzsaw binary,” and we posted benchmarks on how incredibly efficient it was at storing data.  After working out some kinks with it, we’ve been using that for the last few years, and it saves blazing fast, as you’ve probably noticed.

Basically, this takes each data point that we want to store in binary and writes it directly into a bitstream (which C# does not officially have — they only have bytestreams).  As it writes to  our custom bitstream, it analyzes each piece of data and figures out if it can make it any smaller than would normally happen for that kind of data.  The types of data that Keith built support for were string, 32bit integer, and 64bit integer.  The last of those also gave us support for our own FInt fixed-integer format, and by extension also some limited float support (thought we avoid float as much as possible).

The plan was always to go further, and he left notes to himself to do so directly in the code, actually.  With this format, storing a byte was actually highly inefficient, taking on average 10 bits rather than 8. But we never even tried to directly store bytes, so that was kind of irrelevant.

In most programming languages, integer numbers can be stored as 8, 16, or 32 bits, with or without the ability to have negative numbers (called signed numbers).  In the prior edition of buzzsaw binary, we assumed all numbers were signed and could be up to 64 bits, and wrote them out in a manner that still produced results that were often 16 bits or less for a 32bit number.  That was a savings of 50% or more, in lots of cases.

A big part of the savings is what to do with “default case” numbers, such as those that are 0.  How many bits should you take to store that zero?  By default, a 32bit number will take 32 bits to say 0, and a 64bit number will take 64 bits to say 0.  In buzzsaw binary, regardless of the bit level of the number, it has always taken us 1 bit to store a zero.

One tricky thing is that we use a lot of -1s as defaults for various reasons, and that was something that required 10 bits to store. Ack!

So for me, I went in and finally figured out Keith’s code, and added a ton of comments to make it clear what was going on.  I added explicit support for

  • 8bit (aka byte) and 16bit (aka short) numbers
  • And some special cases for:
  • numbers of 16 or more bits that cannot be negative
  • numbers of 16 or more bits that cannot be any smaller than -1
  • and 8 bit numbers (bytes) that are frequently 0

Those are… strange categories, I know.  But when you look at the data we use, and apply the same sort of buzzsaw binary approach, but with more hinting from the higher-level program (as well as more appropriate number formats for variables instead of int32 for everything), then you wind up with some truly amazing compaction.  I’ve detailed the macro results of that here.

Bytes now take an average of 4.74 bits in a savegame, down from 10ish in our previous implementations.  In the benchmarks I just not the percentage relative to the normal 8 bits. “32 bit numbers that cannot be less than -1” are averaging out at 2.71 bits instead of 32.

Overall file sizes for the game dropped in this build to commonly about 70% of what they previously were, and as low as 28%  in one case.  The actual data format change only represents a savings of 10%, sadly, but it’s still a win, even if it is a minority of the gains.

Please Do Report Any Issues!

If you run into any bugs, we’d definitely like to hear about those.

The release of this game has been going well so far, and I think that the reviews that folks have been leaving for the game have been a big help for anyone passing by who’s on the fence.  For a good while we were sitting at Overwhelmingly Positive on the Recent Reviews breakdown, but there have been a lot fewer reviews lately and so that has definitely had a material negative effect.  Go figure.  Having a running selection of recent reviews definitely is helpful, but at least we have a pretty healthy set of long-term reviews.  If you’ve been playing the game and enjoying  it, we’d greatly appreciate it if you’d drop by and leave your own thoughts, too.

More to come soon.  Enjoy!

Problem With The Latest Build?

If you right-click the game in Steam and choose properties, then go to the Betas tab of the window that pops up, you’ll see a variety of options.  You can always choose most_recent_stable from that build to get what is essentially one-build-back.  Or two builds back if the last build had a known problem, etc.  Essentially it’s a way to keep yourself off the very bleeding edge of updates, if you so desire.

The Usual Reminders

Quick reminder of our new Steam Developer Page.  If you follow us there, you’ll be notified about any game releases we do.

Also: Would you mind leaving a Steam review for some/any of our games?  It doesn’t have to super detailed, but if you like a game we made and want more people to find it, that’s how you make it happen.  Reviews make a material difference, and like most indies, we could really use the support.

Enjoy!

Chris

AI War 2 v0.749 Released! “Release The Hounds”

Are you a programmer interested in helping out on a multithreading issue?  Be sure to see the bottom (or this forum thread).

Case Study of Modding: Marauders

Before talking about the release or multithreading, this is a great time to talk about the power that our Modder #1 (and volunteer developer to boot), Badger, has been able to exert thus far.  He’s made a ton of factions, but right now let’s talk about Human Marauders, which were in the first game as well.

If you don’t remember them from the first game, that’s because they weren’t too exciting; marauders were units that would periodically show up from the gravity well edge (not a wormhole) and cause some trouble. They were hostile to the player only, and were generally pretty insignificant.  It added a tiny bit of spice, but not much.

Enter Badger.

He started from scratch when implementing these in the new game.  His version of Marauders are hostile to everyone.  They will attack any system they deem “weak enough to take,” then drop in from the edge of the gravity well.  If they destroy all the defenses, then they start building Outposts, turrets and additional ships. They’re already starting to defend the planet as their own.  If you leave the planet alone, the Marauders will keep making outposts, and each outpost will get stronger (ie it will build stronger defensive ships and more turrets).

Once an outpost hits Max Rank, it starts to build Raiders (powerful starships). Once the Marauders have built enough Raiders, they will attack adjacent-through-wormhole systems that they think are “weak enough to take.” If you leave outposts at Max Rank, the marauders will be able to attack more and more often — their “Attack Budget” gets bonuses based on how many Max Rank Outposts there are. Also the Max Budget gets increased every time they capture a planet.

Fun fact: If you take out all the defenses on a swath of AI planets around your empire (but haven’t actually captured or defended the planets) then the Marauders will rapidly take all of them over and potentially become a real threat.  To you… and the AI and other factions.
TLDR: Instead of just launching quick raids, these Marauders are here to take their own stab at conquering the galaxy.

People have been giving lots of balance feedback on the Marauders, as well as positive impressions for that faction on Discord.  This also illustrates two pretty key points:

  • The marauders are an example of what can be done with the modding tools of AIW2, but which was basically impossible for AIWC even for us as developers.  Gives a bit of context as to why making this sequel was important.
  • It’s also a really good example of how a “Decent but not exciting” AIWC faction turned into something way cooler in AIW2, so buy AIW2 to get cooler stuff. 😉  There are a lot of factions like that (all-new ones and revised ones), even though we’re pivoting the core mechanics to be more like AIWC.  For anyone worrying that this is just AIWC HD, please fear not!

The Actual Release

Okay, right: release notes here.

Where to even start?  This release is pretty sizeable.

  • There’s been a bunch of balance to minor factions.
  • Mercenaries got some extra oomph.
  • AI Waves were previously capped at 100 units (cough, whoops), but now will gleefully flood your planets properly.
  • There are auto-build options for your convenience now available in the game settings.
  • The salvage and reprisal mechanics from the first game are added back in.
  • Golems are now available again — five of them, anyway!

…and all of that stuff is just what Badger, a volunteer, has put in this release.  To say we’re indebted to him is an increasingly sharp understatement with every week.  Holy smokes.

On my end of things, I upgraded the game to Unity 2018.2 and mono-.NET 4.6.  Some performance improvements were possible from this, and a lot more multithreading options.  A few boosts happened out of the gate, and I was able to explore (and then discard) the Lightweight Rendering Pipeline as an option.

I spent a fair bit of time on the multithreading problem, but at this point I’ve been hitting a wall where I can’t get the performance any higher.  I’m sure with more time I could figure it out, but in the meantime there are bigger fish for me to fry in terms of performance blockers (namely the front-end vis layer’s extreme performance hits, which I talked about two releases ago).

Multithreading Help Wanted

Last release I asked for some help on the multithreading problem, which was clarified here.  At this point, I’ve basically hit a wall in my ability to improve the threading without getting really excessive in my expenditure of time.  There are a variety of other things that really need my attention right now, so I’m having to put this on the back burner.

That said, I’ve open-sourced our multithreading code and our core sim loop, so if there are any kind souls who want to take a look at it and help more directly with revisions, that would be super appreciated.  I know folks were a bit hampered by being blind to the code before.

How to get at/test code:

  1. Make sure that Steam has updated you to the latest build of the game (0.749 or later).
  2. Inside the install folder for the game, open the AIWarExternalCode.  There you’ll find a AIWarExternalCode.sln visual studio solution.
  3. You can open that with visual studio community edition 2015 or 2017, and then it should let you compile directly to the GameData/ModdableLogicDLLs folder.
  4. Running the game after having compiled a new version into that folder will run it with your changes in place.
  5. If you want to use a different IDE, or even no IDE and just compile manually, you can do so.  Badger has scripts for doing so on linux, for example.
  6. The actual scripts of relevance are in the AIWarExternalCode/src/Sim folder (and its subfolders), which has a variety of C# files that I’ve added comments to.  There are other files that call into and out of those files, but all of the multithreading bits and the main-thread-bits that call them are all there.
  7. I’ve made a mantis ticket on our bugtracker that has the savegame, plus instructions on how to see the issues.

Any help is appreciated!  And I’m happy to answer questions.  I have made a forum thread that is probably the best and easiest place for us to discuss this.

Right, Back To The Release

Anyway, that’s enough out of me.  This new release is pretty cool.

Enjoy!

Chris

I again wanted to mention: we have a new Steam Developer Page.  If you go there and follow us, you’ll be notified about other upcoming releases (including this one, of course).

Pivoting AI War 2: Bring The Fun!

Hey all — Chris here.

We’ve hit a juncture point with AI War 2. We’ve built a lot of cool things, learned a lot, and now it’s time for a soft reboot. The current plan is to pivot the gameplay to very closely resemble the original AI War, but on our new engine, and then build up from that foundation.

Achievements So Far

So very much is going right with this game, from a technical level and an engine standpoint.

  • The game is crazy moddable.
  • It’s multithreaded to take full use of modern computers.
  • The 3D aspect is working out well.
  • We’ve figured out a variety of new tricks that definitely do improve on the first game, and can be kept.
  • The UI has already been dramatically improved by the introduction of a tabbed sidebar in the main view, and streamlining of several other mechanics that felt very difficult in the past. Eric (as a volunteer) has been a godsend for the UI, and we have pages and pages of more designs from him that we’re going to be working on in the next two months or so.
  • Badger (as a volunteer) has been an incredible tester, volunteer developer, and general help to getting us this far at all; he’s created the Nanocaust faction, as well as a new and better implementation of both Human Resistance Fighters and Human Marauders, among many, many other things.
  • Folks like zeusalmighty, chemical_art, Draco18s, and Magnus have been wonderful sources of thoughtful feedback, commentary, testing, and even map creation.
  • We’ve got art for over 130 distinct units (not counting different mark levels), and we’re set up well to finish off the rest of the art despite the staff changes noted below.
  • We’ve got over 1500 lines of spoken dialogue from more than 25 actors, focusing primarily on the human side at the moment; we have a few hundred lines of AI-side taunts and chatter, some of which is recorded but just not processed yet.
  • There are hundreds of high quality sound effects for a varied battlefield soundscape (with distance attenuation if you’re far away, and positional 3D audio if you’re down in the thick of it), all routed through a tuned mixer setup for optimal listening to all the various parts.
  • We have a set of music from Classic that is over four and a half hours long, and the new music from Pablo is partly in, but mostly set to be mastered and integrated within the next week or two.
  • There’s also a ton of map types, many of them new, and with a lot of sub-options to make them even more varied.
  • We’ve created half a dozen custom Arks as backer rewards, we have another four in various stages of completion, and there’s a lot of cool variety from those folks.
  • With a lot of the other custom art-related rewards (custom flagships, fortresses, and gold merc paint jobs — 21 backers affected in all, when you include the custom Ark folks), since we’re having staffing changes in that particular area, we’ve offered alternative options to those backers, yet said we’d honor the original reward if they prefer. We’ve had a mix of both responses, both of which are fine, and things are proceeding well there.
  • Other backer rewards are either already delivered (game keys of all sorts, many of the custom Ark rewards, backer badges, antagonistic AI voice line writing), or something that are still on the todo list but easy to handle prior to 1.0 (custom wallpapers, planet names, cyber ciphers, antagonistic player voice lines, custom AI personalities, and other non-art merc bits).

New Teaser Trailer!

On that note, here’s an excellent new teaser trailer that Chris and Craig created together. It’s light on details, but it’s just a teaser, after all:

The Sticking Point

The new game just isn’t living up to the first one’s legacy. We started out with a lot of design shifts away from the original AI War, and the design just hasn’t been as robust or fun as the original.

  • In AIW2, so far, there was no real sense of logistics. Things felt too simple.
  • The combat was basically getting you to just “fleetball” all the time, though that wasn’t our actual intent.
  • The defensive options felt too limited no matter what we tried, and player Arks wound up sitting away in a corner with their offensive fleet having to return home frequently to help with defense.

The Two Paths

We’ve done quite a lot of engine work to make the actual game that runs on top of it mostly data-driven, so we have a pretty decent amount of flexibility here. For the last few months, we’ve been chasing various issues in gameplay, trying to tidy those up, but it just kept feeling less and less “like AI War.” So, we had two options:

  1. Keep doing that and hope for the best, particularly that it magically starts feeling “like AI War” again.
  2. Go back and actually make AI War again, at least the base game, and then build from that foundation rather than starting way off somewhere else.

As you have likely already gathered, we’re going with option 2. As players, Keith and I have been really let down by how different certain sequels felt from their predecessors, and we really didn’t want to do that to you folks.

We want this to be the sequel you truly wanted, that takes the original game and then goes forward in a refinement fashion. Total Annihilation turns into Supreme Commander, not SupCom becoming SupCom 2. Age of Empires 1 begets AOE2, not AOE2 morphing into AOE3. All of those games listed are good, but there’s a reason that the second in each series is typically more acclaimed than the third.

Future Growth

We do know that some of you backed for something more radical in departure from the original game. Why have the same old experience again? That’s certainly a valid point, and that’s why we talk about this as being a foundation for future growth.

Look at how much the first game grew from version 1.0, way back in 2009, through six expansions and version 8.0 in 2014. They’re radically different games. That said, we were constrained at every turn by an engine that was designed for street racing, and that we were trying to take offroad. That just doesn’t work.

The new engine for AI War 2 is so robust and flexible that we can take it street racing, offroad, or underwater. Maybe we can have our cake and eat it too, at least eventually? Based on the underlying engine, there’s nothing stopping us from having n factions, xyz ships, and all sorts of new sub-games and mechanics on top of it if the response to the baseline is positive enough.

One example: We’ve floated a variety of crazy ideas about hacking in the last few weeks, for instance; and while those are Way Out Of Scope right now, there’s nothing stopping us from implementing those exact systems or something like them a year or two from now, once we know the baseline game is fun and feels “like AI War.”

Second example: in the preliminary design document we’re working on, check out the section way at the bottom about using Arks as champions. That’s something that we want to attempt sooner than later, and it could be an enormous leap forward on the “radical new ideas” front. Same with the mercenaries section in that document.

Schedule Changes

At this point, we’re looking at Early Access (the “fun point” fulcrum) being sometime in July. That will give us a lot of time to further implement Eric’s UI and refine some visual elements and whatnot while we’re at it. Obviously, schedules change, and this is a tight one on the side of Keith’s core gameplay work.

THAT said, the transition toward the fun point is going to come in 5 overall waves of core features from Keith. The 1st wave being minimum set of units to have a functional, winnable and losable game; the 2nd focusing on core variety; 3 and 4 focusing on various toys on human and AI sides; and 5 wrapping up the last toys as well as adding the minor factions noted on the design doc as being pre-fun-point. (Nemesis and Spire are both post-1.0)

Hopefully we’ll have a general idea of our progress, and people’s reactions to it, throughout those five waves.

After Early Access starts, there’s a bunch more stuff to add and tune, and we think the 1.0 can still be October. Some of the stretch goal content (Spire, interplanetary weapons, possibly some merc stuff) may be after 1.0, but that was always the plan, anyhow.

Staff Changes

All the above said, this is not coming without cost; it’s a major financial blow to the company, and unfortunately we can’t afford to keep our longtime artist Blue after April. She’s been with us for five years, and will be sorely missed, but we’ve known for a while this might be something that had to happen (as did she).

We’re basically folding back down into a quasi-one-man company, although that’s giving me too much credit. I’ll be the only full-time employee, at any rate. Keith is part-time and has been for some time. With the AI War 2 project being almost a year over schedule, something had to give. For myself, I’ve taken on a lot of debt, and am about to take on more.

We Remain Committed

You better bet that the game is going to come out; we’re working hard to make this truly shine, not just as a half-baked, unenjoyable mess. We’re determined that this will arrive at 1.0 as something that we can be proud of and that you can enjoy for many hundreds of hours.

This Isn’t an Engine Overhaul

We want to emphasize this! The AI War 2 engine framework isn’t changing much. The engine we built basically kicks butt, with all the moddability and support for advanced UIs and multi-threading, and so much more.

What’s changing is what we do with that engine, back towards something we know was fun on a different (much worse) engine. That solid baseline will be something we can have confidence in, and will be a great place from which to grow.

Example question: “Is the engine is flexible enough to go back to the original vision of mobile Arks as your king unit, and no stationary home command station?” Answer: an emphatic YES. The engine is so flexible that you can designate a king-unit option in XML and select it through the interface. That king-unit could be a squadron of fighters if you want, or the largest spirecraft with steroid stats. All of that can be done, at this very moment already, without any need for more than XML edits.

The 40+ Page Design Document

Measure twice, cut once. We’ve just spent the last week going back and planning things. Here’s the detailed design document.

In general there are a few upcoming stages:

  1. Working on getting it to match the AIWC base game. (The Pre-Fun timespan.)
  2. Players declare it is as fun as the base game of AIWC was. (The “Fun-Point.”) We may take it to Early Access at this point?
  3. We start bringing in more features. (The “Post-Fun-Point.”)
  4. We release the game to 1.0, probably in October.
  5. We do more stuff to meet our obligations as well as our personal goals. (The “Post-1.0 period.”)

At this point, Keith and I are feeling like the feature set as planned for the pre-fun-point is pretty darn huge on its own, and then there’s a variety of stuff planned for pre-1.0 that makes it even larger. We weren’t trying to expand the scope, but such is life.

There are also a number of ideas of varying tentativeness for after the fun-point that we want to try, such as bringing Arks in as a champion style. Things like that should really make the game feel like it has been taken to the next level compared to the first.

Looking for Modders!

Did you know:

  • ALL of the game data is in XML in AI War 2?
  • Adjusting ship stats is as easy as using a text editor to change a few numbers?
  • Adding new ships is just a copy-paste and then edit situation in those same XML files? You can use temporary graphics, and we can do real ones later.
  • All you need is Visual Studio 2015 Community Edition (which is free) or similar in order to edit tons of pieces of code for the game.
  • You can program map types with ease, GUI things with pain (that’s just UGUI for you), and make AI tweaks and similar somewhere in the middle of those two poles?

We’ll provide as much help as we can in getting you the info you need, and documenting all of this as things go on. If you have questions about where anything is, you can always ask Keith or Chris. Badger probably also knows, and before long we hope to have a solid stable of folks who know this well enough to help others.

Further, I feel it’s worth pointing out:

  • If you disagree with us about something relating to balance, you have the option of tuning the numbers yourself in your local copy and then showing us why we’re wrong. (Of course you can still ask us to do it, as has always been the case — but we’re no longer a bottleneck.)
  • If you make something particularly cool, then with your permission we’re happy to integrate that into the main game as an option that people can access without having to download something separate.
  • We wouldn’t have some of the cooler features that the game has right now, like the Nanocaust or some of the more interesting Dyson Sphere behaviors, if it wasn’t for Modder #1 — Badger. We know there were more of you who wanted to get involved in that sort of capacity, and now’s as good a time as any.

What do we WANT from modders?

A good question was raised: what are we really asking of modders, here? Honestly, that depends on the modder.

Some folks like putting in interface bits to solve personal pain points that they had with the original interface. Others have ideas for creative extra factions — for instance the Nanocaust — and we’d love to have those be something that you’re working on as we move toward 1.0, rather than as we move toward 2.0. If it’s all the same to you, anyway, it’s more valuable to us sooner than later, if that makes sense?

But in general, it’s kind of a “hey, if poking around at games like this is your sort of thing, we’re throwing a party and you’re invited.” We’re happy to show you around the house, not just throw you into the deep end of the pool without floaties.

Short Term Goals

We’re going to be aggressively pursuing the Fun Point, with Early Access to follow; and meanwhile building up and refining the UI, controls, and so forth to be the best that they can be.

Long Term Help

On the further volunteering end of things: if you want to help out with any sort of balance testing or custom unit design using the mechanics that we decide on as final, then the XML is easy to edit, and our doors are always open on our forums and on mantis.

Thanks for your continued support!

Best,
Chris

AIWar 2 – “AIW2ModdingAndGUI” Modding Tutorial

This video is directed at external modders, for whom we’ve now set up a unity project that comes with the game and which makes it easy for you to add your own ships, models, sounds, visual effects, and more.

This does NOT cover code additions or changes, and data changes like balance statistics, etc. Those are handled through the AIWarExternalCode visual studio project, and the GameData/Configuration xml files, respectively.

Actually creating content for any of the above is beyond the scope of this particular video, which is more about how to get set up and find what you need. There is an ongoing series of videos that I’ve created that does cover all sorts of topics related to this, however.

And in the future I’ll create more videos that are more concisely focused on specific modder-oriented topics.

This video requires you be on version 0.109 or later of the game.

Thanks for watching!
Chris