Video Dev Diary for February 10th!
about 7 years ago – Fri, Feb 10, 2017 at 08:31:13 PM

Chris here!  Lots to share today.

Obligatory: 106 of you still have yet to send in your surveys, so please do that soon if you have a chance.  Thanks!

Marquee Video

In this one, recorded just moments ago, I walk you through some things that are happening in the game right now:

Highlights:

• Lots of galaxy map styles already in place!  All of the ones for 1.0, if I'm not mistaken.
• You can see a bit more about how the planets at the galaxy map actually show the key ships that are there (thanks to Astilious for suggesting that!)
• You can see the really REALLY ugly tempy gui that is nonetheless functional.
• Keith has been playing games all the way through in multiplayer with success, and has been building out increasing numbers of features.
• This shows the earliest version of the forcefield visuals, which are not the most exciting thing in the world yet but are highly performant.  I'll experiment with making higher-load-but-prettier ones with time.
• This shows some combat, albeit still without the extrapolation or ship flocking within squads.
• It shows my new custom LOD system, although that's tuned improperly for the missile corvette right now.
• It shows off a lot of the incredible performance gains that we have made, although there are still some architectural hot spots that we're homing in on.  In general we want this to look super good up close and then be really high-performance as you're further out.
• I talk very briefly about Controllers and Guardians.
• Can I just emphasize one more time that the current GUI is worse than bad and we know that?  It's for internal use only, but I'm showing it to you anyway so you have an idea of what we're up to.  It's easier to work with really ugly buttons and text on the screen, just blocking out the play flow, before even trying to make it pretty (and/or not eye-bleedy). :)

Other Videos!

The count of working-videos style things in our dev diary channel has grown a lot, and so the dev diary channel is now up to 25 videos as of the moment.  Mostly it's of a semi-technical or technical nature, but if you're in to game design there's some cool stuff in there.

Alpha: End Of This Month!

We're looking quite on schedule for that. :)  No promises on how horrible the GUI will still be for the first build for you alpha folks, but a lot of the visual stuff will have been filled out further by then.

Multiplayer, Linux, OSX, and Windows will be available from day one of the alpha.  

If you have trouble running the game on your system on day one for performance reasons, then I'll go ahead and say right now -- please TELL me!  With you alpha folks, I'm particularly counting on that.  I have four good computers representing a range of capabilities for me to test on, but there are always surprises.  

In response to those things I can both optimize in unexpected places as well as providing toggles for simply turning off some visual whiz-bang bits for machines that can't handle those bits.  But I'm definitely counting on you alpha folks to tell me rather than just assuming it will get better without saying anything! :)

Early Access At The End Of May!

We're still looking great for the Early Access launch at the end of May, too, and of course well before then the GUI will be massively cleaned up and improved.  In large part thanks to feedback from the alpha folks, I have no doubt.

And yep, the "sometime in October" schedule for 1.0 is still holding steady, too.

Our production of ship graphics has been substantially slower than we desired originally in terms of the final models, but we're also putting out much higher-quality work than we originally expected.  In my original pitch for 3D with this game, I never expected to be doing fully-painted models, but we figured out a way to do so (and thus massively improve the look of the game) without completely destroying the budget and without sacrificing much in the way of performance thanks to LODs.  It's a worthwhile improvement that I'm footing the overage bill for.

Conclusion

Things are going well!  We're still somewhat in the "measure twice, cut once" phase of things, so I always feel like it looks like less progress than it really is.  If you saw the number of code changes and improvements each time, and the amount of productivity and performance improvements each go... well, I wish I could show that in a visual way, but I can't think of a good one. :)

Nonetheless, my list of "things that are not all that visible but that are very important to do" is getting very short now, while the list of "things that are definitely visible" is starting to get some hefty bites taken out.  Lots more of that to come next week, and the week after... and then we're into the start of alpha, so you can expect floods of release notes as per usual with us.

Thanks for watching and reading!

Chris

The AI From Within - Part 4: The Special Forces
about 7 years ago – Thu, Feb 02, 2017 at 08:50:09 PM

Keith here.

A Short Update on Development

Goodness, how time flies. We've been pretty quiet for the last few weeks finalizing the Kickstarter (95% of you have completed your BackerKit surveys, thank you! 137 backers have not yet, please do so!) and getting everything setup for the alpha. We been applying our noses directly to the grindstone and believe we have developed the right foundation and workflows for both our own work and for modding support. We are currently planning to start the alpha Monday, February 27th, 2:00pm EST.

Sidebar For Modders

As we've mentioned before, the graphics in AIW2 are much more complex than AIWC. Adding or replacing graphical assets won't be as simple as adding or replacing a .png file. In order for the game to work efficiently with the meshes, materials, and so forth (and also with sfx) they have to be baked into "asset bundles" in the Unity editor. Thankfully, there's a free version of the Unity editor that modders can use to create these asset bundles. Furthermore, the asset bundles aren’t baked into the game’s executable but can be loaded at runtime. So we’ve double- and triple-checked that this actually works and that we can hand you a workflow (with examples) that will function correctly. This has been going well, and as side effect, we've significantly reduced the amount of time we ourselves spend waiting for the assets to re-bake after a change, etc.

Other Progress

I've also spent a fair bit of time making sure that my workflows for adding new user interface elements and input bindings (i.e. "things you can trigger by pushing a button on your keyboard/whatever") do not require recompiling the game itself or otherwise require anything an end-user won't have access to. The list of bindings and the layout of the windows is in xml, and the code-logic that says what those keys/buttons/etc should do is defined in C# code that's compiled into an external dll.

That external source code will ship with the game and you can modify and recompile it (with whatever you'd normally use for c# on your platform, be it VS or MonoDevelop or whatever) or add your own external dll's that your xml can reference. Obviously playing a multiplayer game requires that you be using the same stuff which gets trickier on the C# side, but it's doable.

We've also made a ton of progress on the game itself, but that's better shown in a video when Chris finds the time to make it :)

You call that a short update?

Yea, good point.

Last time in this series we looked at how an AI (or human) ship's guns decide what to shoot at. Before that we covered the low-level "where do I go?" logic for AI ships not assigned to guard duty or some special purpose. Together, those two sets of logic basically make a complete opponent.

But we would never leave well enough alone. Not at all.

Today we're focusing on something much higher-level: the AI's Special Forces Fleet. Due to some interesting... comments... during a recent performance review, Laser Guardian #443x-023 will be conducting the briefing.

Those pesky humans

Laser Guardian #443x-023 here.

Stupid developers. I tell them "how do you expect the meatbags to be properly frightened when I show up without any paint on?" And they just mumble something about working on higher-priority things and we'll get to it soon and shuffle me out the door again. HIGHER PRIORITY? Clearly an adjustment is in order.

Ahem.

So, a quick history lesson. Back in the day (AIW Classic version 5.0 and earlier) the "Special Forces" were basically just some special guard-duty ships that marched in a weird sort of galactic line-dance between the various Special Forces Guard Posts. Cute, but not especially effective.

When the galaxy was so obviously under our thumb, it wasn't a big deal.

But the humans were getting entirely too cheeky about picking off our planets with no particular fear of immediate consequences.

On August 30th, 2012, thanks to feedback from several of the more provocative organic target-practice-units (notably Hearteater, Faulty Logic, Martyn van Buren, Diazo, TechSY730, Lancefighter, Sunshine!, Bossman, Draco18s, Ozymandiaz, Wingflier, and chemical_art), that all changed.

Malice aforethought

First, rather than just getting odds and ends of the normal Reinforcement budget, we got our own new Special Forces budget to maintain (but not exceed) a certain overall force level. Silly restrictions, but I guess there are other things to spend it on too.

Second, rather than just getting whatever random ship was selected for reinforcements, we got the ability to weight our preferences based on things we thought would be useful. Lots of anti-bomber stuff, for instance, since bombers were so annoyingly effective against everything we wanted to protect in AIW Classic.

But my personal favorite was getting to spend 10% of the budget on the ships specifically found to be most annoying to the player. Well, that was basically just two ships: Tackle Drone Launchers and Lightning Torpedo Frigates. Neither of which were remotely well-balanced and aren't slated for the (first) official release AIW 2. Oh, Tackle Drone Launchers, I will miss you.

Even when we didn't get TDL's, it was great fun to focus on really long-ranged stuff, or stuff with lots of tractor beams (nothing like nabbing a bunch of human fighters and dashing off to alert other AI planets with them), and so on. Good times.

Later we even got Riot Control Starships, though they were never as effective as they were in human hands. Some players could achieve simply stupid kill-to-loss ratios with Riots, and they don't even have decent firepower. We're still sore over that.

Third, rather than our individual ships just following a line to the next special forces post, we got to pick a single planet to all gather on. We were generally only allowed to pick friendly planets (sigh), and we weren't allowed to rush to the defense of particularly unimportant planets, but this let us build up a strong force instead of just trickling in. Especially since, if our services were not in immediate demand, we'd hang out on a friendly planet 3 hops or so away from any enemy planets.

Fourth, when the enemy dared show their faces we could check to see which planet we could do the most good on (prioritizing our homeworld or core worlds, avoiding planets where we couldn't get there without passing through a grinder, and otherwise preferring the biggest concentration of organic intruders), and make a beeline over there.

The result?

Nobody expects the Special Forces

A massive roving fleet of jolly AI ships, specifically built to annoy you, singing sea shanties while they crash your party and ruin your fleet's day.

Of course, this didn't stop the most virulent meatbags (stupid warheads...), but it did make them work a lot harder. And our refrigerator is covered with pictures of SF assaults scissoring in behind unsuspecting human fleets and stomping them flat.

The Future

So where are the Special Forces going in the sequel? All over the place. Literally, actually. Instead of a single fleet we'll have regional headquarters, each with its own fleet.

We weren't sold on the idea, at first, since concentration-of-force is pretty important. But then we were told that these regional headquarters were actually secret ninja hideout fortresses. How could we say no?

This also allows for more exotic behaviors and ship-preferences, since each region can use its own. An all-cloaking SF fleet that only attacks when you're multiple hops from your territory may die like flies in some circumstances, or it might be the thing that stymies the human infestation in others. We're all about iterating over permutations. That's... actually about all we ever do.

... Ah, good, it appears the paint crew has finally arrived, so we can strike terror into our enemies and the appearance of the SF fleet can once again have its proper brown-trousers effect on hapless human attack fleets.

Ok, make sure you get plenty on the weapons ba-aaAAAAhhhHHH!! (entire ship dunked into vat of MurTech-brand Astatine-enriched Universal Solvent)

Up next

Keith here. Whoops, it looks like the quartermaster made a mistake on that paint order. Oh well.

(pushes speaker button, "Cleanup, nebula three.")

Bear in mind that the plan is for modders to be able to define their own Special Forces controller logic sets, for determining which ships a fleet picks to build and/or which planet to rally at in a given situation. Then you can have those controllers be put into the normal rotation, or even remove the vanilla controllers and only use your own. Naturally, you would never use this to make your game easier by reestablishing the galactic line dance.

I'm not sure when the next entry in this series will be, since work on the game itself obviously takes priority, but we'll probably look at the offensive equivalent of the Special Forces: the Threatfleet. The SF gets to play dirty tricks on you, but a Threatfleet has much better opportunities for gratuitous vandalism.

Also in the works is another combat video from Chris. In general we'll try to check in every now and then so you know we haven't suffered a misfortune at the hands of disgruntled machines.

Another batch of working videos!
about 7 years ago – Mon, Jan 30, 2017 at 07:12:32 PM

Chris here!  Last update I talked about a variety of random things, and that's what's in store once again.  Later this week, Keith will have another update for you in the running series about the AI. :)

The Ark Is Finished!

Mostly finished, anyway.  And bear in mind that this is just the first Ark design -- something like 8 backers are going to be working with Blue in order to come up with alternative designs for anyone to choose from.  Thanks to those who chose the Arkitect backer tier or preorder item! :)

Anyhow, here's the final product:

AI War 2 - Ark Visuals Update: January 24th, 2017 -- Just a quick look at how the Ark now looks inside the game and inside the prep project.  Sorry I don't sound more enthusiastic, but my voice is giving out a bit. :)

This is a good example of how things have evolved from my original terrible mockup, which I'll embed here again as a reminder:

Internal Working Videos From The Last Week Or So

If you want to see these dev-diary style videos as they come out, there's a playlist for those right here on youtube, although we're not having all these videos popping up as "new videos" on our main channel (they're unlisted to not clutter things up).

Tutorial - AI War 2 Texture Quality Import Checking: January 19th, 2017.  Notes for Cinth on how to check after me to make sure I haven't fudged up the import settings on any files.

Also it just plain documents how the ideal file import settings should be, which is pretty useful for modders making their own asset bundles in the future.

Plus I have a random epiphany part-way through there regarding my shader, and there's a variety of discussion of the pros and cons of some of the past performance of importing of textures in our 2D games.

Tutorial - AI War 2 Setting Up Ship/Structure Models and Gimbals: January 20th, 2017.  Notes for Cinth on how to take a model/prefab of a ship and in the prep project, set up a gimbal for it (along with all the other scripts and whatnot), and get that into the game for use.

Also covers the general xml setup, and collision boxes and so on.

As an aside, this is honestly quite useful for modders, too, although the video is overlong for that.

 AI War 2 AI Master Controller Initial Mockup For Concepting: January 23rd, 2016.  Visual mockup for Blue (artist) of unpainted model of my rough concept for the AI Master Controller for AI War 2.  This is incredibly unpolished and unoptimized and is meant to be a bit of a "throw together some legos as a 3D concept" sort of thing.  

She then takes it and makes it into something that is actually awesome, though this will probably be in the game instead during most of the alpha since this one is a really large undertaking and there are better ways to spend her time in the meantime.

Warning: this is very much "how the hotdog is made" in terms of the nature of the video!

Tutorial - AI War 2 Getting To Projects (For Devs): January 23rd, 2017.  Notes for Blue and Cinth and other staff/contractors that may need this, on how to get into the unusual structure of AI War 2's internals and get to an actual project that runs and that can be tested in.

There isn't any confidential information in here, so hey why not let kickstarter folks see this, too, if they are interested.

Tutorial - AI War 2 Model And Texture Import: January 23rd, 2017.  Notes for Blue on how to import her models to our specific prep project area, and also how to use the values in my custom shader.  This is actually super useful for modders, come to think of it!

Tutorial P1 - Ship Optimization And LODs In AI War 2 (Prototype ships): January 30th, 2017.  Notes for Cinth on setting up LOD groups and otherwise optimizing the ship LODs for prototype ships for AI War 2 to keep the framerates high during the alpha.  Later tutorials in this series will cover handling the actual final ships, which take more work.  This is the basis under all of them, though.

That's It For Now!

Keith will have his update later in the week on the AI, as I noted, and then next week I should have a new combat video for you, I expect.  Lots and lots of stuff is happening, and I'm really excited about that evolution that we're seeing.

We look to be properly on schedule for a release to the alpha players in very late February, based on how things are going.  Definitely good news!

Cheers,

Chris

AI War 2 Random Working Notes Video Roundup - Circa January 19th
over 7 years ago – Thu, Jan 19, 2017 at 10:33:18 PM

Chris here! Okay, so this is a whole lot of random stuff from the last month, and these are some of our internal videos that I did a quick vetting of and figured were safe to release for those people who might be interested in them.

These are all unlisted on our youtube channel, to not clutter that up with this sort of thing, but if you're interested in the development work side of the process (technical or art or otherwise), here's some meat for you (in chronological order):

December 10th, 2016: Chris rambles about custom editors for Keith, but generally fine to show for whoever.

December 5th, 2016: Notes for Keith, specifically aimed at showing what was done in AI War Classic so that he could replace it with something much better for AI War 2 (via Forge Networking).

January 16th, 2017: Quick visual mockup for Blue (artist) of unpainted model of my rough (VERY rough) concept for the Ark for AI War 2. This is incredibly ugly in a lot of ways and is meant to be a bit of a "throw together some legos as a 3D concept" sort of thing.

She then takes it and makes it into something that is actually awesome, which is work that is currently in-progress as of the time of this post (though there are some screenshots from Maya).

Warning: this is very much "how the hotdog is made" in terms of the nature of the video!

January 16th, 2017: Notes for Keith on some craziness that happens with external DLLs and moving the cheese on unity, plus how to re-link assets that become unlinked.

January 17th, 2017: Here's are some progressive screenshots from Maya of what Blue (artist) had done at that point (very very incomplete) and how her work was evolving from mine.

On the left in the first shot is the terrible mockup fbx file I created, and then in the center is what she was evolving that into in broad form:

 Then later that day, two more shots of the Ark.

January 18th, 2017: More screenshots from Maya from Blue's work, where she is basically done with the model itself. She notes "I left all the small bits in grey-checker so you can distinguish them from the main ship."

A few hours later that day, more stuff (in false colors). She notes: "UV's done and organized. Each color indicates a set of UV's. So if they share a color, they share a UV set. So there will be 8 texture sets."

And then actually painting those uvs in Photoshop comes next, and is currently in progress. :)

Here are the flat colors, actually, with her notes: "I haven't done any of the detail work yet. Just laying down the base over all."

January 18th, 2017: Quick visual mockup for Blue (artist) of unpainted models that may or may not be used, with the general idea of the motion they would have, and the vertex-animated internal model for the "wormhole" inside the AI Warp Gates for AI War 2.

Very very rough, and not meant to be any sort of final product.

January 19th, 2017: Notes for Cinth on setting up LOD groups and otherwise optimizing the particle effects for AI War 2 to keep the framerates high.

 Visual Evolution of the Bomber

This is out of sequence because it happened over the course of many days throughout this whole process, but here's an interesting look at some of our workflow.

I gave Blue this reference bomber model to work with that I had created, but it was messy and needed a lot of work, and had no textures yet:

 In the above two, it's shown next to the fighter for scale.

She then had to do a lot of fixing of the model, which is a process we've decided to scrap because it's much easier for me to create a rough approximation with notes (ala the Ark, as seen above), and then her to create the final model from scratch herself rather than trying to repair my wreckage. Nonetheless, she spent 3ish hours repairing the wreckage of my bomber and made something awesome out of it:

Note how crisp all the lines are, although it's not yet having a proper shader, and it looks washed out, etc. This is to be expected. Generally once I pull it into Maya and apply my shaders and tweaks, it is basically the final touches that turn it fully awesome. The post-processing effects and bloom and her emission maps help a lot with that, too, to be sure.

But this time, there was a problem. I set it up, and did so like this:

Grooooosss! While the lighting and so on is cool, there's a lot up there to hate compared to the original model. She noted there was some quality loss, and I wasn't sure specifically which things she meant, so I pointed out the following possible areas:

With some detailed commentary on each area that are not worth repeating here. At any rate, I made a lot of tweaks to the shaders, and we got to this:

Muuuuch better. Still needs work, though.

She finished her tweaks to the emission map and the albedo texture, and I figured out some big improvements on the texture import side (both quartering the VRAM used by the bomber as well as improving its crispness), and we arrived at this:

 Biiiiig difference.

That's It For Now!

Just a lot of random notes, since we've been quiet. There was a ton of other stuff happening as well, but this gives you some idea. :)

Cheers!

Chris

Surveys Reminder! Only 322 of you left. :) Plus general status update.
over 7 years ago – Tue, Jan 10, 2017 at 08:24:35 PM

Chris here!  Just a friendly reminder that we still need Backerkit surveys back from 322 of you.

Get Your Steam Keys DRM-Free Builds For Not-AI-War-2 Backer Rewards

As those surveys come in, we're locking them down and thus having it send out things like the steam keys and drm-free links for the not-AI-War-2 titles that people get included with various tiers:

• Bionic Dues and Skyward Collapse + Expansions at the lowest tiers
• Then AI War Classic + Expansions
• Then The Last Federation + Expansions
• And finally Stars Beyond Reach at the highest tiers

Forum Badges Coming Soon!

The other thing the surveys do is give you a chance to tell us your forum name, and thus we can apply your kickstarter badges to that.  Here's a near-final (but not quite final) version of what those look like:

We experimented with a variety of things, and decided that short and wide was a really cool way to do them that at the same time doesn't completely disrupt the flow of the sidebar with something giant (while at the same time not being underwhelmingly small).

Questions About Tier Rewards?

You can always ask here, but we also have plenty of discussion on those on the forums.

Other News!

We've been back in the office for a week now, so what have we been up to?

Chris with BackerKit/Kickstarter

I've had a lot of things to take care with backerkit and with kickstarter, so that ate a fair bit of time, but fortunately the worst of that seems to be settling out.  And we've raised another $4k on backerkit thanks to add-ons and preorders, so that officially pushes the overall kickstarter-esque funding over $100k total, which is very exciting.

How exactly that extra $4k contributes to stretch goals I haven't even calculated yet, since I need to get that stuff into excel first and I haven't had a chance to yet.  But a very large portion of it does, and the other portion is mostly adding new things that everyone gets to enjoy like new mercenaries with their own graphics, and things of that nature.

In the last update I went into incredible detail about how the post-kickstarter stretch goal stuff will work, but I just haven't hooked up the number-cruncher yet.  We have notably moved the needle closer to solar systems, though. :)

Keith's New Lumber Mill

Keith has had a lot of... strange... work that he's been doing in the last week.  Some of it has involved writing batch files for our local machines, one of which looks like this:

That first line gives you a bit of insight into his state of mind, perhaps? ;)  But in seriousness, I think he's been having a load of fun with the odd stuff.

Basically something we realized is that the day-to-day of compiling and running the game to do "unit testing" was just too darn slow.  Unity's editor has some really funky ways of doing said compiling, which can take upwards of 20-30 seconds even on latest-gen i7 processors and SSDs.

With that in mind we basically had to move to a system where we started putting more code into external DLLs that we can compile in literally 1-2 seconds in visual studio.  This may sound like fluff, but if we're looking at between now and October of doing compilations (which would only get slower as more code gets added, on the unity side), these changes actually save us approximately 5 man-hours per month per programmer where we'd just be sitting there waiting for things to compile or start running.  That's assuming an average of 50 compiles per working day per programmer, which is high for some days and very low for others.

And really that was just looking at compile time, not even the improved loading time, so the savings of wasted time are actually greater than that.  This translates into literally weeks of extra time for us to do something more productive than stare at the screen while the little compiling circle spins.

But of course it can't be that easy, right? ;)

One of the challenges is that Unity, for whatever reason, can't interpret the normal debug symbol files from .NET or Mono.  That would be too easy!  That means that we'd basically no longer be getting any line numbers from error messages, which then slows the debugging process waaaay back down.  So -- back to staring at the little compiling spinning circle?

Pfff. :)

Unity has a tool that allows us to convert pdb files into mdb files, which are the obscure outdated symbols format it for some reason uses.  It took quite a lot of fiddling to make it machine-agnostic (so that it works for both Keith and I when we compile, since our machines are set up slightly differently), but Keith got it figured out.  [Correction from Keith: we didn't wind up using the tool that converts pdb to mdb, I'm just literally using mono's compiler to generate both the dll and the mdb.] The two batch files that I just posted are two out of six.

One possible side benefit of this is that we should be able to use this sort of logic for mods that include code, I expect, which is really nice.  Though that would require running the game itself in "unity development mode," so I don't know just how helpful that will be in the very end to modders.

Chris and Asset Bundles

I was already planning on using asset bundles as a way to load in custom content from modders, but we were hitting a point of frustration with our own assets, too.  Some of the shaders and models and textures and so forth take a while to pack up, and by "a while" I mean charitably 5 minutes per platform, and occasionally (yes really) thirty minutes.

These things only have to happen whenever we build a non-unity-editor-integrated version of the game, which reasonably in most cases we need to do once per day at most.  Although whenever I have to push a build to players, I need to do it four times in a row (thankfully one-button-press so I can go get coffee or catch up on reading API documentation or something while my computer thrashes through 10 GB of stuff).

Tangent: Keith and Networking

By the by, Keith has been working on the new networking layer on and off since sometime in December, while also doing other things.  We were using the Lidgren networking library in AI War Classic, but now we've switched over to using the latest version of FORGE networking, which is why you see a reference to Bearded Man Studios up there in one of the batch files.

Anyhow, the new networking library lets us transfer data more efficiently between clients and the server, as well as avoiding some of the issues and bugs that sometimes came up before.  You should never have to think about your MTU in AI War 2, which is a very good thing.

One thing of relevance, though: in order to actually TEST his networking code, Keith has to do a build of the standalone game on windows (thankfully not all four platforms)... which takes 5-30 minutes per time...

Holy smokes. ;)  To work around that, he made a little test visual studio project (that compiles in under a second) for communicating back and forth when setting up the networking at a most-basic level during December, but that's no use once you start getting into game logic on top of the networking (which is where we are back to now).

Back To Asset Bundles

Right, so the big problem is packing all those textures and compiling all those shaders.  The C# code is slow to compile in unity, yeah, but it's only 30-seconds slow, not 5-minutes slow.

The solution we hit upon is to split our unity project into two projects, one of which will be responsible for generating just asset bundles, and one of which will be the front-end for the game.  This actually has two cool side effects aside from major productivity gains for us:

• It immediately readies the pipeline for modded content, since it will also use asset bundles.
• It lets us control at a more granular level how we want content to load off the disk into RAM whenever anyone loads the game, which lets us improve launch times for the game itself (useful for us in testing turnaround time, too).

So that's what I've been working on doing, while also stripping out a lot of the test and demo code I had been working with.  I'm not quite done with that, and Keith isn't quite done with some of his reorganization/refactoring that he's taking some time to do at the moment while we're at it, but the overall picture results in five freaking projects in one source control directory:

 That's two unity projects, and three external visual studio projects (in two solutions).  Those all get wired up with the post-build batch files that Keith created for automation purposes, and it works really smoothly and saves us probably double the time estimates I gave above, when you add it all together. 10+ hours per month per programmers in time saved waiting for things -- woohoo!  That's a big win for us using your money as efficiently as possible.

We always guard against premature optimization, but there are a lot of good analyses about why the pop-programmer meme about that exhibits a shallow understanding of what that actually is.  In this particular case, we've figured out what the optimal data structures are and are shifting things to that, which is costing us about 3-4 days but saving weeks.

Blue -- And Less Geeky Stuff :)

Blue -- Daniette Mann, our art director -- has been working on a variety of things ranging from the forum badges to some experiments with new skyboxes/cubemaps, to ship modeling and texturing.

She and I have also been working on trying to optimize our workflow so that we get you the best possible result in terms of visual quality, but without having TOO much per-model creation time cost.  That way we can hit a good balance between having lots of content within the budget we have from the kickstarter, but not having that content look like junk.

We spent a lot of time figuring that sort of thing out in December, and we've gotten very close to where we want it to be.  We'll have more to show on that front soon, which is probably a lot more exciting to most of you rather than the programmer geekery.

Okay, That's Plenty

There's other stuff we've been doing as well, but I think this is a good enough snapshot for today, heh.  Things are looking good!

Chris