The above is a tutorial for Blue, our artist, though if any modders who are creating custom models are also using substance painter, this shows you how to set up your setup, too. You can also infer pretty easily how to do combinations manually using Photoshop channels to create packed maps, too.
Anyhow, we’re moving away from the Alloy Shader Framework to instead use custom shaders that give us an equivalent look with a vastly reduced workload and with definite compatibility with future unity versions, and this tutorial covers Blue’s side of what needs to change.
The above is a tutorial for Cinth, but this also is useful for any modders who are creating custom graphics for the game.
As noted in this video, this saves us a ton of manual work. A ton.
Also in this video I randomly stumbled across a visual improvement to the custom player ark Rorqual Hegira, so you can see how that evolved a bit thanks to the extra flexibility of this new shader set.
These ships are painted by Blue using Substance painter — well, overpainted by Blue. These were ships that she had previously painted in photoshop directly in a cel-shaded fashion, and which now she’s overpainting to give it a mixed realistic look.
It’s worth bearing in mind a couple of things:
These are screenshots from Substance Painter, so it will look a bit different in Unity. See my recent videos on that subject.
These have emissive parts on them, but that REALLY doesn’t show up properly in the substance painter view, so you’ll have to imagine that part for now. 😉
My main note on that was that it didn’t feel beat-up enough, although beyond that I really love it. And, um… what a difference, right??
Aww yiss, now we’re talking.
Old (although with some improvements that were overdue on the cel-shaded part):
I just love the fighter, with how metal and beat-up it looks now. It should do particularly well in the in-game lighting and with the lightmaps on. 🙂
I also really love the metalness here, and the added details. I’ve asked about adding a variety of scorch marks on that, though. We could do a variety of smart masks and then make them black with a very high roughness and potentially low metalness and that effect happens easily.
Overall I really like the bomber, although it feels a bit too gleamy-shiny in some ways. Maybe having it a bit more worn of a metal as a base there is something we’ll do — or just introducing layers of wear. I love the scratches we have going on.
The eyebot is perfect, I love that glassy look it has and how perfect it seems in a lot of ways. Really a different form of character to it, which is fantastic. 🙂
That’s all for now!
Just thought I’d share a bit of the progress that is being made. Now I guess that our main problem is that these ships are drawn so bloody small in the battlefield — relative to the camera — that all that awesome detail is lost…
We’ll figure it out. Someone on kickstarter was mentioning the same thing. Maybe the answer is smaller squads of larger ships, or using more verticality to fit larger ships in the same radius, or who knows. I don’t want to shrink the feeling of scale of the game, but at the same time we want to be able to see more than just the icon-fest, at least when zoomed in.
The above is a tutorial for Cinth on how to get things ready for Blue to do her painting in Substance Painter. It doesn’t handle the old-style of very-high LODs for us yet, but it gets all the rest of it.
The above is a video for Cinth on how we need to update our existing ship definitions to fit with our new “one material only” approach, which relies on mipmaps and GPU instancing for the bulk of its efficiency, rather than on baked vertex colors and dynamic batching.
The above takes a look at the newly-free alloy shader framework, which we’ve used in other projects, and looks at the difference in quality when we’re now integrating it into AI War 2.
Starting at 8:30 in there is a tutorial for Blue, and at about 23:00 in is a tutorial for Cinth.
The above video is about three ships that I’d done with standard shaders previously, including the first backer’s custom Ark, and now they’re converted over to Alloy. Just a video of me working and chatting about it as I do. Why not.
No actual painting takes place in the first video. Instead we go through mesh simplification, examining the mesh, sizing things up, and generally getting things prepared so that we can just sit down and paint in the next video.
The second video shows the first of the 11 custom Arks that kickstarter backers commissioned for the game. This will be one of the Arks that anyone who plays the game gets to choose between.
This Ark, dubbed the “Rorqual Hegira”, was the vessel for the cetacean flight from Sol. I can’t say any of those words. 😉
Anyway, this goes through the process of actually doing the painting to make the cel-shaded baseline turn into a PBR (Physically Based Rendering) style. Basically what that means is taking something that looks intentionally cartoony and adding on a layer of processing that makes it react to light more like real materials do.
As part of that I also wind up adding various procedural details, naturally, as Substance Painter is really excellent for that sort of thing. All those little scratches and splotches and so forth that humans just aren’t meant to paint by hand with any speed or lack of repetition.
This video took way longer than I expected, mainly because my first idea for how to handle the metal body didn’t work out (I had feared from the start it might not, but it was a fun one to try), and because handling the “glass with something down inside it” is an inherently super-tricky request, and something I wanted to do justice to rather than just slapping an emissive glow on it and calling it good. I’m quite happy with how the result came out, although we’ll see what the backer thinks once he sees this video.
At any rate, one of the things that was bothering me was the drop in quality between Substance Painter’s view of things and the view of things in Unity. It still looked great in Unity, but was a notable step down.
So, I thought about that a bit, and made some changes to the lighting in Unity. More on that in a bit — but first I should note that this isn’t something that is costing any extra performance hit on your GPU. Yeah, you heard me — these sort of visual improvements can be “free” in terms of performance cost. It’s all in the techniques, and I’ve been learning a lot on that front as I’ve been working on my “secret side project.”
Anyhow, that’s been paying big dividends for AI War 2 that I wouldn’t have anticipated.
Where We Started
That’s purely a cel-shaded approach modeled in Maya by Blue, and painted in Photoshop. There’s a lot to love there, particularly in most of the ships in the game, but this was probably the number one ship that bothered me because the asteroid doesn’t look at all like rock. (Then again — do rocks in any cel-shaded game look like rocks??)
At any rate, her painting and models were being fed into some custom shaders I created, and then tuned to have custom reflection maps and specularity and rim lighting, etc.
One of the big things that I struggled with with my shader was making the ships look really dramatic — but also visible — on their dark sides versus their light sides.
Often this really caused issues with the normal maps (those images that make things look more bumpy than the actual underlying geometry is) either being too harsh or too subtle depending on how close you were to the ship or which side of it you were on.
Next Up: Substance Painter
In a video you can see me painting that mesh using Blue’s cel-shading as a base. The end result — in Substance Painter — is this:
Now, there are a few things to bear in mind.
First of all, this is using different shaders than Unity has. Ones that don’t have to render in realtime, and certainly not thousands of objects in realtime — Substance Painter would choke and die on that. But that tool is equally useful for offline cinematics or feature films as it is for realtime game usage.
That said, it should translate pretty well — shockingly well, to be honest — to Unity. When you’re using full lightmapping and calculated ambient occlusion and so on, the visuals get very very close between the platforms.
Problem, though: you’re not able to bake lightmapping in unity for dynamic scenes. At least… mostly not. There are a variety of complicated techniques, and even some simple ones. But let’s just say for our purposes here that isn’t feasible in this particular case. 😉
At any rate, the second issue is that this is using IBL, or Image Based Lighting. And in Unity I was not.
What Is IBL?
Basically that means a 360-degree image cubemap is “shining” on the model from all around it. Imagine having a painted translucent box and putting the model in it, then shining light evenly through every side of the box at once. The result is an IBL look.
This is a huge improvement over what was in Unity previously, but it’s still… not my favorite. The lighting is very stark and harsh, and the specular reflections feel wrong, making me have to tone down the smoothness of the metallic shaders. All that combines with the flatness of the lighting in general to make it feel… like a blander version of what I had before.
Well, heck — I’ve worked with IBL plenty of times before. Let’s see what I can do.
Starting with this:
We then move to this:
In order to get that second look, I turned off the main directional light in the scene, and am using just a single IBL light source. I have to “bake” that in a really broad sense for Realtime GI to work in unity, but my understanding is that it isn’t really using anything other than the original cubemap since there’s no true baked data (no lighting probes, etc) in the scene.
At any rate, this is with the ambient light coming from the (invisible) skybox, which is an HDRI cubemap. And then no other light sources other than the emissive materials on actual ships. Oh, and the global reflection cubemap has also been toned down a bit and switched over to use a compressed version of the HDRI skybox rather than the studio lighting look I was using before.
This approach is pretty cool, and certainly more vibrant… but it’s still missing something. It’s a very flat look to it, and if you circle the asteroid the lighting is even on all sides. There’s no real shadows happening.
Now we’re talking! This tones down the ambient light a bit, and then adds back in the directional light — but tones that down to about 60% of what it previously was, too. I also made the directional light warmer rather than a harsh white, so that it would match with the HDRI image I chose. Incidentally, I went through a variety of HDRI maps before finding one that felt right.
The overall settings used in Unity for this are as follows, if you’re curious:
And That’s Where We Are Now!
In a non-procedural game, there’s all sorts of fancy and highly-performant things that can be done with lightmaps and reflection probes and so on, but this is not that game. 😉
For performance reasons I’m not using parallax mapping/heightmapping/tessellation or baked AO on these models, either. Those don’t contribute enough to the scene to be worth the added GPU and RAM costs, and we want this game to be able to remain as huge as possible. All of the changes thus far have been either GPU/RAM-neutral, or come with a performance savings.
I may move back into slightly custom shaders for this, mainly so that I can handle the death effects for ships via parameters on the ship itself “eating the ship away” as it dies. But in general, beyond that, this is how the game looks now (or will look, once we paint all these models again — blending what came before with what we can do now).
Hopefully this was an informative/interesting read. 🙂 It’s obviously something I’m passionate about, and I think it contributes a lot both to the mood of the game and our ability to sell it to a wider audience.
In case that (tiny, tiny) text at the bottom is hard to read, here’s what it says:
Note that this effect actually uses vastly less VRAM than the other approach — insanely — because we’re able to use compressed textures. The smooth, cel-shaded look shows imperfections in texture compression super fast, so we have to use higher-quality compression or even no compression. The PBR-based approach is inherently grungy and messy, which fits with the general vibe of a war-torn galaxy anyhow, and DXT5 compression doesn’t show any artifacts that aren’t just something your brain writes off as more grunge.
This overall aesthetic helps to make things look less “happy,” since that was a complaint withthe art before, but it also keeps the exact sameunderlying textures. However, we’ve overpainted those textures using procedural work in Substance Painter, giving a blend of hand-drawn and PBR styles that seems unique.
Thematically this seems more appropriate, and it’s also a lot (LOT) more efficient on your GPU, particularly if you’re on OSX or Linux (which can’t read BC7 compression. We’re talking a 4x to 10x reduction in VRAM, while getting added detail — just to be crystal clear. 4x on Windows, 10x on OSX and Linux.
We should also be able to make some of our LODs and asset-integration work a bit more efficient using this, too.
Chris and Keith here! Apologies for not having made any kickstarter updates since June, good grief. We’ve had daily or weekly interactions and updates on our forums, blog, youtube dev diary, and release notes pages for anyone who wanted the full firehose info dump, but that’s no excuse.
Schedule Slippage – Overview
Let’s get to the toughest topic first. We had originally planned to have an Early Access release on Steam in May, and then a 1.0 release of the game this month, October. As you are no doubt guessing, a 1.0 release this month is not in the cards.
With the Early Access launch-pushback in May, we went ahead and gave out the keys to all of the early access backers at that time, even though the game wasn’t available for purchase on Steam yet. We’re going to do the same thing with the “launch” backers: we’ll have your keys to you later this month, even though the game isn’t in a launch state and won’t be launch on Steam just yet.
In both cases, you’re still getting your key when we said… but, well, the game is not in the state that you would want just yet. So at best that’s a half-kept promise. Obviously schedule slippage is not exactly uncommon with kickstarters or game development in general, but we are still very sorry about that.
Where We Are Right Now
All of the core code for the game is done.
Multiplayer is currently broken for some reason, but should be quick to fix.
Massive amounts of work on frameworks for a flexible UI and extra modding capabilities have been put in place.
There are actually a number of extra goodies in there, like multi-squad formations and some other surprises.
Gameplay and Interface:
Balance leaves a lot to be desired.
In a general sense, the “feel” of the first game isn’t quite there yet.
There’s no tutorial, which makes starting to play quite hard.
The lobby interface is very sparse.
The overall GUI is ugly, but becoming increasingly usable through iterations. Our goal is for it to be better than the first game in terms of incorporating a lot of the longstanding requests people had for that game.
The Spire, Nemesis, and Interplanetary Weapons stretch goals are delayed, possibly until after launch.
Unexpectedly, we have a whole new minor faction in the form of The Nanocaust, created as the first mod for the game by BadgerBadger and integrated into the official builds by us.
All of the ship models and textures — all two hundred and six of them — are complete as of last week.
The actual integration of those ship models and textures is only about halfway complete, give or take.
The ship model and texture work includes all of the Spire, Nemesis, and Interplanetary Weapons stretch goals stuff — so the art for those are already done, at least.
The far zoom icons are done, although we will probably change some of the “flair” parts of them as we get closer to release.
We have done a number of pieces of concept work for the GUI in terms of figuring out a style, but none of that is integrated into the game yet (no point until the actual underlying elements stop shifting around so much), and there’s still more concepting work to do in general.
The visual post-processing stack is still evolving at this point, to give the game a more sophisticated look and avoid the “circus lights in abundance” feel that sometimes hits right now.
The visuals for different shot types are still on the todo list.
The visuals for how ships die are also still on our todo list. There’s a balance there between performance of particle systems and the frequency (read: very high) at which ships die that we have to work out.
We’re still working on inside-one-squad formations that look awesome, although some of those are already in place. Basically making them look more like actual naval or air force military formations rather than just grids of ships. This has been pretty cool to see evolve.
The “ships flying around inside one squad with flame trails everywhere” approach has just turned out not to be feasible on modern hardware without impacting our ability to have really large-scale battles, unfortunately. There are some special tricks we could do to still make this happen, but that would get into some budget that we don’t have. This is a real shame, because this was something we showed off a lot in the kickstarter videos, but in pretty much every other respect our art is exceeding what was shown in the KS videos, so this has been a pretty decent tradeoff — and something we can return to in the future.
A lot of the sound effects for different shot types have been selected and set up, but are not integrated into the game yet. So the battles don’t sound as variegated yet as they will later.
Another bonus that we’ve chosen to explore thanks to the urging of backers is extra voiceovers for human ships when you give them orders and when there are various alerts. We’ve done about 30% of the recording with a variety of voice actors for this, and we’ve integrated maybe 5% of that into the game so far. It’s something that brings more of a feeling of commanding actual humans rather than just lifeless ships, and it’s something you’ll be able to disable. It’s also something that we’ve got a system for making sure it doesn’t over-saturate you with the same voice cues over and over again, too.
As far as AI taunts or human taunts that you can give back, we have not yet started recording any of those yet.
The music is partly in place, but overall only a few tracks thus far. Pablo tends to work in a massively parallel fashion, and so a lot of his tracks are at various stages of completion rather than him finishing one piece fully and then pushing it out and repeating. Bear in mind he has to compose them and then perform them and then do all the audio engineering and mastering on them, so this process gains a lot of efficiency.
(The GUI is being gradually blocked out and iterated-on in that fashion before being made pretty.)
Upcoming Schedule: October through November
During the next two months, more or less through December 6th, there’s going to be a flurry of extra work going on to try to get the game to a point where all of the AI War Classic enthusiasts are able to come to the new game and feel both somewhat at-home as well as like they’re in the next era of the game.
Exactly what that means is a bit unclear at this point, but we know it focuses on usability, balance, the interface, and possibly tutorials. The reason for the lack of clarity is that there’s a big back-and-forth between us and you in this section — this is a huge game, and so we need feedback on things that are unclear or break balance, and then we’ll respond to those items, and repeat.
There are a number of things we already have planned to work on through the early part of October prior to us releasing the “launch” Steam keys, and then after that point we hope we’ll see an uptick in the number of people who are giving us feedback.
Upcoming Schedule: December
After the December 6th date, or thereabouts, we hope to have things in a state where a LOT more people are comfortable jumping onboard and testing and giving us feedback.
Right now feedback has been really limited to only coming from a few people, largely because the game has been too unapproachable and too unbalanced. So that’s on us.
But we just absolutely cannot go to launch, or even to giving out press previews, with that little feedback. Our goal is to get our side of things to where we can start getting your feedback — from more and more of you — while at the same time seeing more and more of you enjoying simply playing the game without having major complaints.
Upcoming Schedule: January
Once the new year rolls around and we’re into 2018, hopefully we’re pretty close to where things are so polished that we can start handing out keys to the press and getting some previews. We don’t know if that will be at the start of January, or later into that month, but either way the goal is sometime in this time period.
At this point in time, when we start sending out press keys we plan to disable our backerkit preorders store and our paypal preorders. This is also likely when the “Coming Soon” page on Steam will go live, although we might conceivably do that in December.
Upcoming Schedule: February
This period might start sometime in January, if things are going really well, but either way it bleeds into February. Basically this is the “press review period.”
During this time we’re not taking any new sales for the game, and press are able to play and review the game. We hope that you folks are also playing the game and enjoying it and giving us feedback on how to make it better during this time so that we can apply some final polish to it prior to launch.
This time period is pretty critical for a number of reasons. Firstly, it gives press a chance to have reviews ready for launch, which can help a lot with purchase decisions. Secondly, it gives the game time to “settle” and hopefully have a lot fewer changes required despite a lot of backers playing it.
Thirdly, it gives a period of exclusivity where only backers and the press are able to actually get the game. People have an increased desire for things that they cannot have, and the press prefers writing about things that the general public cannot yet have, so we wind up with this funky period because human psychology is what it is. Hopefully this doesn’t feel manipulative to you, but we’re being upfront about why we’re doing this — basically it will increase the strength of our launch week (which is critical) and the number of reviewers who will play it during this month (also critical).
Upcoming Schedule: March
Obviously these dates get less certain as time goes out further, but the idea is that about a month after the press gets their hands on the game, we launch the 1.0 on Steam.
The exact day will partly be determined by what is going on with other game releases by other developers, what conferences and conventions are in that time period, what store-wide sales might stomp our launch, and so on. We won’t have visibility on what the exact ideal release date is until probably 6 weeks prior to choosing the day; and even then we might need to shift the day forward or back a week or so because of something else in the market that comes up.
Speaking of the importance of a good launch week, one of the things we’re going to need to do is have the traditional 10% launch discount for the first 7 days. This is potentially contentious, because that’s a $2 discount that all of our existing launch backers (early birds aside) are not getting.
If this is something that angers anybody to a huge degree, then Chris will refund the $2 discount to those individuals out of his own pocket. So please put away your pitchforks. 😉
That said, I think we all have the same vested interest in seeing this game do well and go on to have lots of post-launch support (which require sales to fund), and expansions, and so on. Basically we all want to see the same sort of arc that AI War Classic had, I think?
The market is a lot more hostile now than it was in 2009, however, and the launch weeks are more and more critical to having any sort of momentum. The more we’ve looked at the data and talked to other indies, the more it has become clear what a problem it would be to not have a good leadup to launch (that month with the press), or not have a launch week discount that buyers have come to expect.
The backers and preorder customers here are the customers who have made this game possible in the first place, and so the 10% launch discount can really stick in the craw of some people when situations like this occur. We’ve witnessed the backlash against certain other games and developers when a development like that comes up out of the blue, which is why we’re telling you now, way in advance, and offering that $2 refund to non-earlybird launch backers if anyone is angry enough to take us up on that.
THAT said, in general we’ve been taking the approach that Prison Architect did, where “you pay more if you buy earlier,” which is counterintuitive in a lot of ways, but something that we’ve talked about the mechanics of with backers for a year or so now. Obviously the alpha and early access tier backers paid a whole heck of a lot more than the launch folks did, and those backers both help to support this game getting made at all, as well as having the game earlier and being able to influence the game’s design from an earlier stage.
We could go on at length about this particular topic, and we feel guilty about that as well as about the general schedule slippage here, but hopefully you read our reasoning and it makes sense — particularly if you’ve been watching the PC market as a whole lately.
(The above image is a good example of us still needing to do some work on the post-processing pipeline, although it’s already much better than that as of today’s release of 0.522.)
Backer Rewards Status
There are a variety of backer rewards in a variety of states of completion right now. For practical reasons, it’s pretty much breaking down like this:
Now that we’ve finished all of the ship art for the base game, we’re starting in on fulfilling backer rewards that are ship-art related. We’re working first with the custom Arks, since those are the most numerous and most complicated of the backer rewards, and then we’ll be moving on to the others that are art-related.
For things that are design-related (custom AI types, ship stats, etc), we probably won’t get to those until December. It’s better if things are more stable and you can play the game more before you get into that sort of reward.
For the audio taunts and the text and lore bits, I’m expecting that probably January would be the timeframe, just to balance with our workloads.
As far as all of the digital rewards, other game keys, etc, those are available now and you should already have them. The wallpapers aside, which again will likely be January.
To reiterate, the last of the AI War 2 game keys (those for “launch” backers) will go out later this month, and anyone else at a different tier should already have theirs.
Hopefully that covers the questions of where we are, where we’re headed, and why. The blogs and dev diaries and release notes show where we’ve been recently. Again we apologize about the delay, but we’re doing our best to mitigate its impact on you, and are feeling good about how it will impact the project as a whole.
Chris here. Since we’re now moving into starting the custom Ark backer rewards work, it was suggested that we show the existing ship designs to players. This videoonly shows the ones that are currently “wired up AND uploaded,” which doesn’t include remotely everything that is complete just yet, but it’s a good start.
This is basically completely about the build menu being more usable, and tooltips being more useful and legible. They still need a background to really be fully legible, but we got a lot of the other things with them. The unity ui is still… a learning process, sometimes.
This time around, I made a quartet of videos rather than Keith making them:
I wrote: A lengthy look with me at how to set up new GUI prefabs and then use them in code. This is shown while setting up the build menu to look better/clearer.
I wrote: A quick look with me at how to set up sound effects for buttons. It’s not a complete tutorial with everything in-depth, but there are tooltips for the bits that might not be clear, and this shows the workflow with greater clarity thanks to not going over every detail. At least that’s the goal!
I wrote: For Cinth and for modders, this is how you create new formations for ships of various scales to use in the game. I look forward to seeing a lot more creative and militaristic formations than my simple grids have been. 🙂
All that said, as noted in the release notes, I think there’s a way for us to work around the <sprite> tags in general and not use them. Even when those are working as well as possible, they still regularly show up improperly because we can’t control the exact relative scaling and offset per-font and per-font-settings.
Anyhow — major usability strides in this new build, although as always there’s yet more to do. Also a number of bugfixes.
Still not time for “beta” status, or Early Access, just yet. If you’re waiting for the smooth gameplay experience, there’s still a bit to go — but that’s now squarely the next thing on Keith’s plate (and the GUI is a big part of that, yes).
There are two dire guardians in this one (which are two of the most nasty ones), and then there are four big honkin’ Zenith golems. This includes the Dyson Sphere, the Zenith Trader… and yeah, the Devourer. 🙂 Ho-lee smokes.
Bear in mind that these are the last of the ships until things are playing really well and the interface and whatnot have matured substantially. Sometime during the Early Access period when things are running well, Keith will work on those interplanetary weapons (a stretch goal), the spire stuff (another stretch goal), the Nemesis (yep: stretch goal), and whatever other minor stuff might be left that I’ve overlooked. I think basically everything else is in the game now, though.
Anyhow, so this is a very big milestone for us, because that means that Keith’s focus can stop being on content, and can shift instead to refinement, usability, and all that sort of thing.
I’m finally done with all my performance-chasing stuff as of a little while ago, and as of last release the sound system is in place (though not with all sound effects yet, of course), so cumulatively this makes for quite a satisfactory 0.500, I think.
Post-Processing Visual Stack AGAIN!?
I just finished redoing that, right!? Well, it’s been redone yet again thanks to some issues that are detailed in the release notes. The overall look is pretty similar to what it was before, except things are a little crisper and better antialiased, and there’s a very slight vignette effect.
The big difference is in the bloom effect, which is generally more subtle now, but also more diffuse and thus a bit more dramatic in how it blends things around. Previously things were super intense in their bloom in a short range, but now they’re intense in their immediate area, then fade out more gradually. Gives a more natural look.
Additionally, in order to deal with the flickering glimmering lights that could happen in some cases previously, the game now uses a much longer (about 3/4 of one second) temporal filter on the bloom, which can cause some really pleasing light trails that are purely a screen-space (and thus “free” in terms of performance) effect.
You can see that with:
The first shot in this post, which has the camera stationary and then the Ark moving away from it, leaving a bit of a ghosting trail from its engines. That’s completely a screens-space effect.
The second shot in this post, which has the camera panning super fast to the right while the ships are stationary, and so you can see the glows being pulled to the left. This looks less good, but is also a lot less common of a case and generally happens so fast you can’t see it unless you screenshot it while you’re in motion. It does give a bit better sense of your own speed of movement, though, I’d say.
The third shot in this post (below) shows a stationary camera and both ships and shots that are moving, and how the glow trails help a bit with those. This is more subtle since the shots themselves are trail renderers in a lot of the cases there. It’s noticeable in a still shot, but during gameplay I wasn’t sure it was actually even happening.
If the temporal effect feels too strong to some folks, then I can easily make that a slider that folks can adjust in the settings, and we can debate what the best default setting would be if this is not it. For the moment — and I’m too close to this at the moment to speak with any real confidence on the matter — I like how this is looking, though.
Over the next half-week or so, Keith and I are going to be pretty quiet/absent, because of some other-life things that we need to take care of, respectively. But then after that he’ll be working on the user experience and GUI and so forth, and I’m sure a bunch of mantis reports. I’ll be working on mantis reports and more sound effects work, and getting the first voice acting in place, etc.