Category: Chris Talks

Have you noticed a change in the way a game is developed throughout the years?

This is a doctoral thesis sort of topic. The short answer is that everything is changing, all the time. There is no stasis, period.

The simplest way to look at this is hardware and tooling. In the past, you could code your own engine and that wasn’t an insane thing to do. Now it is. There are too many good free-or-cheap engines available for indies, particularly with options that only kick in with costs if you actually succeed. But even a game engine that is huge is not complete without a lot of other middleware, and that will vary from project to project in terms of what you need. This goes for AAA and indie games. To pick one random example: very few AAA companies are hand-modeling all the trees in their game world now. They’re using SpeedTree or another middleware tool to get the results they need and move on. The old joke about lots of artists just sitting around modeling rocks? Nobody is actually doing that, unless the rocks are really specific and impactful for some reason. People are using middleware like Megascans or Quixel to get actual high-resolution scans of physical rocks, and then the environment artists are doing scene composition with those. Some artists are of course doing their own photogrammetry to bring in custom things, but in the general sense why would you pay someone to do that when there is middleware that is cheaper? Have your artists work on something more unique and impactful than the literal rocks.

In the past, there were many limitations with RAM and available CPU and GPU processing. There still are limitations, of course, but it’s on a whole different level now. You can go for something vaguely photorealistic on pretty low-end hardware now, or there’s a thousand ways you can go for a stylized effect. Again, middleware is often really helpful in finding a stylized effect that you want. You need artists to have an eye for this and not just slap a filter on with no sense of design, but the analogy I would give is that there is a supply chain, now. In other words, metaphorically speaking, ten years ago if you wanted someone to “paint your house,” you would hire someone to come out, look at your house, and sit right there and then find just the right pigments and create paint on the spot, then paint your house with that paint, using brushes and rollers they carved themselves. As you can imagine, this is a silly amount of expense. Brushes and rollers are mass-produced and cheap to buy. There are stores where you can get any color mixed with ease. So instead you pay the painter to go buy those supplies and then just paint your house, and the whole process is bother higher quality and cheaper. To torture this analogy a bit, now the painters are going to be doing much more complex paint jobs, though, rather than just picking a couple of colors and applying those. If you look at this and can see why it’s acceptable to have a supply chain that leads up to physical art (who makes their own paint or brushes by hand, and why would we expect them to?), then the same should be true of the virtual supply chain and the endless, endless middleware out there. Someone else already did a lot of the things that you need, probably better than you can, so just license that. But that doesn’t mean that you’re suddenly qualified to just throw things together and expect a good result. Artists are needed now as much as ever, but they are able to focus now on the actual art.

Programming and every other sub-discipline is the same. Are you going to spend two years with your programmers making a general engine that will be outdated by the time it’s finished? That’s foolish. You’re going to license another engine. This isn’t cheating, this is more mature ecosystem. In film, do you expect the director to construct her own cameras and dollys? Of course not. She buys or rents those. She may or may not have a custom costume department, or might contract with a company that does nothing but specialize in costume design.

Anyone that is a “one person show” is still standing on the shoulders of giants even if they try to do all the things themselves. So trying to do absolutely everything yourself is a backwards way of thinking in my opinion, and a bit of a masochistic way to work. You can be an auteur and still use middleware. If anything, that can give you more chances to be involved in all the possible parts of the process.

All of that was internally-focused. Focused on how games are made, not how they are sold. When it comes to those external factors, of how games get sold and what the market is, that is no less dynamic. Every year the market is a bit different, and things move more and more digital. The competition from other companies small and large is more and more fierce, because there are more people trying their hand at this. A lot of them are terrible at it, but there are still an ever-increasing number of people who do a very excellent job. Some of these people you will never be able to compete with because they are a team of talented young folks living in their parents’ basements, working 90 hour weeks for 5 years, to put out a work of utter majesty before disappearing forever because the business was not sustainable. Other companies you can’t compete with because they create unsustainable conditions for their workers, and rely on them burning out before their 30s but just hiring new talent out of school. There is an endless supply of of excited new talent, so a company can freely burn out their staff and have turnover without losing their ability to output amazing work.

We tend to focus on the creative leads, who also work long hours but stick around longer because their life is not quite so grueling. But under them is an ever-churning mass of people with hopes of one day getting that sort of job, only to have those hopes dashed when they realize there are only so many openings. My advice is to not work for a company like this. And if you are trying to create something on your own, then be sure that you consider what your lifestyle is like for yourself and those who work for you. Do you want to have a company culture that allows people to have families, and take vacations? Then you need to budget for that. And you probably need to accept the fact that this will make you slower, and have a lower-production-values end product than your less-ethical counterparts.

Then again, if you can carve a niche for yourself and connect with people, and find whatever balance works for you, this is how you can still be around a decade or three later, when everyone else burned out long before. I love my job and still intend to be doing this 30 years from now. I definitely don’t have everything all figured out, but I have learned that I should not try to chase certain dreams if I want to keep any of my values. Maybe someday I’ll have infinite money for some magical reason, and then I can chase those dream projects. Then again, maybe all I need to do is wait for middleware to mature even more, and no magic will be required. For now, I do what you should do: try to pick something with a scope that you can hit, with production values that are pleasing but not going to bankrupt you financially or morally, and then see what happens. If you truly plan on making this a career, then whatever you’re working on right now is not your last game. Don’t feel in a hurry to “do it all now.”

Try to keep your project times to just a couple of years if you can, so that not all your eggs are in one basket and so that the market doesn’t move on while you’re building your game. And above all, only do this if you actually love the process itself. If you don’t actually enjoy this sort of work, then being able to weather the ups and downs is going to be next to impossible. Games are fun to play, but making them is a serious and difficult discipline even in an ethical company. If you don’t actually love the art and science of it, you’re going to have a very bad time indeed. There are much easier industries to get a steady paycheck from if you are a programmer in particular, if the game development process doesn’t speak to you on a level beyond just money.

The future of indie games looks bright to me, but it’s also a bit of a maelstrom. If that sounds good to you, then come on on!

What tools do developers use to make an indie game?

If you want, you can code your own game engine. I don’t recommend it. I had coded my own from 2002 through 2009, but later ported my custom engine to Unity 3D in 2010. It’s a different time period now, and you want to be able to hit PCs, macs, consoles, and who knows what else.

Unity 3D and Unreal Engine are both fairly straightforward to learn, and both have pros and cons. Personally, I believe that Unity is better in terms of general flexibility and making something truly unique. You can also have something gorgeous in that engine; it has plenty of power. But Unreal makes it faster to have something gorgeous. It is harder to prototype in Unreal, though, in my opinion.

If you are making a 2D game — a challenging sub-market now — then you can use all sorts of 2D engines.

If you’re making a 2D or a 3D game, there are then dozens of products that you will need to use for a ton of different purposes. Every developer uses different things, and it’s impossible to generalize.

I’ll give a partial list of the software that I use on my projects of the moment, just to give you an idea:

  • Unity 3D as the main engine
  • ZBrush for sculpting (I have also used Sculptris and Mudbox, but prefer ZBrush)
  • 3D Coat for uv unwrapping and digital painting (parametric and otherwise).
  • Substance Painter is also great for what 3D Coat is good for, and I also used that on my current project, but overall I prefer 3D Coat.
  • MooTools Polygon Cruncher for general optimization of large models. Though sometimes I do this work directly in ZBrush.
  • Maya for certain types of modeling, although personally I don’t use it — but some contractors do, and I use the fbxes they create from that.
  • Google Docs and Google Sheets for communication with team members and design documents.
  • Adobe Audition for sound editing. Audacity is a free alternative, but less powerful in many ways. I have dozens of plugins for various kind of sound editing in Audition.
  • Various sound banks for foley sound and ambient sounds and sound effects. I’ve collected from a few dozen sources over the years, and at this point I have a few terabytes of compressed material to pull from.
  • Soundminer for poring through those sound banks and pulling out the specific sounds I am looking for based on metadata. You’d be amazed how much time this saves.
  • TextMeshPro in unity for proper text rendering and optimization
  • TexturePacker for external sprite atlas generation (you need this even for 3D games because of UI icons).
  • Amplify Shader Editor (this is a core tool for how I create shaders in Unity. You likely don’t want to just use the standard off the shelf shaders).
  • FinalIK by RootMotion for inverse kinematics support if you’re doing character animation.
  • iClone and Character creator for character design and animation. There are plugins there for facial motion capture and various forms of body motion capture.
  • PolyFew for in-engine final optimization and LOD creation. Use unity’s LOD system if you must, but it’s possible to code a more efficient version yourself.
  • Lighting Box for unity (there are HDRP and other pipleine versions). These help you to get away from that “unity feel” in your games.
  • Feel for unity — this helps you give more impact to motions, and generally just spice up things so that actions don’t feel rigid. You can use this even during your prototyping phase for that first 5 minutes, because the way things react does impact us emotionally and it’s not cheating to use this sort of thing in the same way that good graphics or audio might be considered cheating at the early stages when you are wondering if the game is fun or not.
  • Rewired for unity — if you’re supporting controllers and a variety of control schemes, and you need key rebinding during gameplay, then you need a solution like this one. I’ve used a variety of such solutions on various projects, as well as coding my own from scratch. For the broadest possible spectrum of platforms, Rewired is currently the one to go with.
  • TortioseSVN for source control, with repositoryhosting.com as the provider. If you prefer to host it yourself internally, then VisualSVN Server is not expensive. If you prefer Git, then that’s also fine. Git is more flexible in some ways, but more complex in others.
  • Visual Studio 2019 for coding.
  • Notepad++ for xml editing.
  • VisualSVN for Visual Studio SVN integration
  • Bandicam for video recording
  • Photoshop for everything 2D
  • FileBoss for mass file operations
  • FreeFileSync for moving things around easily during the “push a new build” process. It’s faster and more accurate than using batch scripts.
  • Batch scripting for the actual compile process (this is faster and more accurate than other alternatives). Robocopy is a key part of these sort of batch script chains.
  • WinMerge for file diffing when looking at logs.
  • FMOD can be a great tool for audio, although I am only planning on using it and have not done so in a project yet.
  • Blender for certain kinds of 3D editing. It’s the easiest tool I know of when it comes to outright deleting certain parts of geometry by hand.
  • iDrive for nightly backups so that I’m never losing my work or my purchases.
  • Google Drive for certain large files that need to be shared with the team remotely. This pairs well with FreeFileSync, which can pull and push from there.

And… there’s literally multiple dozens of other tools that I have used or do use, but less frequently. Don’t be afraid to code your own time-saving tools from time to time, especially if you’re going to be doing this for a long time and see places where you can save some time.

What are the different phases in a development cycle when creating an indie game?

My first advice is to go watch the series on Film Courage where they interview Jack Grapes. He explains his philosophy on Method Writing, on which he teaches courses and has written many books. There is not a 1:1 analogue with game development, but as he himself notes, his concepts apply to any field of work. He explains the role of failure and authenticity in leading to future success far more succinctly than I can.

Now, to your question in specifics. I find that the question is broad enough that you’re likely to get very poor quality or very contradictory answers. “Here is the method I used to make a game” is certainly something a first-time indie can tell you, and “here is the formula I use for this series” is another answer that a repeat indie with a series (“spiritually” connected like what Supergiant Games does, or literally connected with proper numerals).

If you are looking to mimic the success of some other game, but you have a twist, then that also has its own process.

I have been making indie games longer than all but a score or two of other folks in the world, so my perspective is a bit different. My observation is that most people pour their soul into a first game, and then if it does well or poorly, they are probably pretty wrung out by the end of it. Most people do not make a second game, and if they do make a second game, it’s rare that that one does as well.

My own experience over the last 12 years has been that I’ve made I think about ten released titles, and something like twenty released products (so that includes DLCs). I have had to recall one game from Early Access and refund players because its prospects were so poor because of decisions I made (In Case of Emergency, Release Raptor), and I’ve had half more than a dozen projects that got some way through production or preproduction and then were scrapped for some reason, or transformed into something else entirely than what I set out to make at the start. Stars Beyond Reach is the one with the most publicity, but even my title A Valley Without Wind (the first one) started out top-down and was in magazines, and then went sidescroller before release. I got a lot of flack for that, and people questioning loudly in comments sections if I knew what I was doing.

The answer? NO.

I have no idea what I’m doing on the one hand, but on the other there is a method to the madness. So let’s zoom out to the phases of understanding a project, personally, as you create it. At the very start of a project, you have some sort of core idea. I have long referred to these as “Immutable Design Goals.” In other words, these are the core things about your game that must be true at the end for it to be the game you set out to make. When I was making my first commercial game, AI War: Fleet Command, which in all has generated more than $2m USD for my company, I had a few: 1) “I want to feel like Ender Wiggin.” 2) “I want to be able to play multiplayer in this with my dad and uncle.” 3) “I want all of the feelings of power and scale that Supreme Commander gave me.”

From that point, once you know your immutable design goals, you can set out on actually doing preproduction on a game. The way I did this for my entire career is wrong and backwards, though, I am now convinced. You can use a suboptimal process for making a game and still make a masterpiece, by the way — you just won’t understand, not truly, how you did it. And you’ll always wonder “how can I do that again?” My suggestion is to use a process that actually process that you can understand why things work. With our game Starward Rogue, and our other title Tidalis, both of which were devestating commercial flops but quite popular with players and critics, this is the process I used. Clearly a good process is not tied to commercial success. Luck plays a role, but so does how you communicate about the game, and how you onboard players.

What’s the most straightforward way to onboard players to a complex game? The unfortunate answer is… there is not one. A very complicated game will typically require understanding many interlocking concepts in order to truly play it and have fun. In other words, with a sufficiently complex game, you as a player can’t understand the complexities of the late game (and all the majesty and fun that might be found there) until you understand not only the mechanics of the many subsystems of the game, but also how the expression of those mechanics plays out over time and experience. Most people will not stick around that long, especially in today’s market.

A better approach is to stick with games that have core central systems that are fun in under five minutes. I don’t care if you’re making the next Crusader Kings or if you’re making a casual puzzle game or a “brainless” action brawler. If you can give players something that they understand in five minutes, that they enjoy for its own sake, then you’re on the right path to onboarding them. Because it doesn’t matter how amazing your game is when you finish it — if it takes players 30 minutes or 5 hours to really “get it,” then you’re playing with fire. You may find success with that, as I have multiple times, but you may also find that the market gives you a miss, which has also happened to me multiple times.

I bring this up, because this is the second phase of game development. You need to develop some sort of “vertical slice” of your game that gives 5 minutes that is enjoyable. Again, let’s assume you want to build the next super-complicated RPG, 4X, or MMO. I don’t care what it is. You need to have an absolutely rock solid 5 minute experience for people before you go beyond the basics. As noted, this is backwards from how I have actually developed most of my games in the past, but I have come to believe that it’s imperative to mitigate risk in today’s market. Attention spans are not long, and if people are not hooked in some fashion very fast, then they will move on. This of course applies to press demos and conventions, but also just people organically trying your game on Steam and deciding if they want to refund it. If you can’t give them some fulfillment in five minutes, you’ve made a terrible mistake.

It is going to take you a long time to get a compelling five minutes. With an individual or team working full-time, it’s likely going to take you months unless you get very lucky. I strongly suggest that any art or music that is happening during this time be of the pre-production variety, because what you are creating at this stage is not something that should have integrated art or music yet. If it’s not engaging without music and without stock ugly graphics, then it’s not going to be truly engaging with gorgeous graphics and a wonderful score, either. Pretty graphics and beautiful music and perfect sound design can elevate a game for sure — but that’s for later. At the moment, all it can do is distract you, or make your game seem more fun than it is (others, later, often won’t share your sentiment, but you’ll find out too late).

So, during this early period where you know what the general goals of the game are, and where you are working on that 5-minute vertical slice with placeholder graphics, you can also be conceptualizing what the graphics pipeline is going to be like, and what the sound design might be like, and what the visual style would be, and so on. But keep these separate. Don’t put the pretty graphics and sound onto your naked game skeleton yet. Wait until that 5 minutes is fun.

You are going to fail, and this is expected. Your very clever ideas on paper will never work in practice — again, unless you are very lucky. Even if you have made half a dozen games before, even if you are a veteran of 30 years, THIS new project is new, and you don’t know what you are doing. You know how you made something else in that scenario, but you still don’t know how you will make THIS new game. So you will fail. Over and over. You will be very frustrated, and think that maybe my idea of the 5 minutes of compelling gameplay is not a good one. “If only people could play the late game, this would be fun, I bet.” But don’t listen to that voice!

When you have failed at this enough, eventually something unexpected will happen and it will be fun all of a sudden. Some combination of ideas that you never would have come to while staring at a design document suddenly coalesce and are fun in PRACTICE, not just in the hypothetical.

I am of the opinion that traditional design documents are a great evil for new projects. I have written extremely detailed design documents for a number of projects, and every one of them suffered for it. What you need is a general idea of your goals, and then to get a prototype of a vertical slice. AFTER you have a working vertical slice that is fun, then it’s time to start working on a design document. You need a roadmap for the rest of the project now that you have a central core that is fun. But you can’t even start this until you have a working core. Design documents are an amazing tool for revising a project, or adding onto it (DLC), or expanding from that central working core. But having any sort of design document prior to having a fun core is a profoundly dangerous thing. It gives you a sense of security that you should not have: “Well, this game is not any fun yet, but this is just the start of it. When I finish implementing the design document that is so brilliant, it will be fun.” Trust me: it will not. Or if it is — in that event that you are incredibly lucky — then you now are back to that same problem of onboarding new players, because they have to play much longer than 5 minutes to find the fun game you made. That’s the absolute best-case of that sort of design style, and it’s not a very good one.

Once you have a core vertical slice that is engaging to play (I keep saying fun, but not all games are meant to be fun — some are emotionally affecting instead, or intellectually compelling, or just pique curiosity to no end), then you have to start being creative in a new way. Games are not five minutes long. In order to give 5 minutes of fun, you had to create some sort of systems and controls to let the player interact with your game, and probably to let the game interact back. Now it’s time to start thinking up variations on this, and how you can layer on new rules, new complexities, new antagonists, new scenarios, new powers or abilities, in order to expand from this core nugget of fun into something more complex while still retaining the central spirit.

During this next process, a design document is a great idea. But even so, don’t treat it like a design bible — again, a terrible mistake. The proof is always in the pudding. Whenever you add something new to the game, you have to ask yourself if this adds to the experience, or if it actually drags it down. A great example of this, in my opinion, is the Yoshi’s Island series. The core mechanics are pretty okay, but it’s not as strong as the main Mario games. What keeps these games especially niche, however, is the fact that there are so many collectibles and items that you get graded on at the end of the level. Normal Mario games allow you to play a level in a way that lets you run through very fast and enjoy the speed and grace of your actions. And they often have collectibles that reward you coming back to a level you played before and exploring further, and more slowly. Similarly, they also have slightly-hidden paths that allow you to run through the level EVEN FASTER if you wish. That’s a great design! All of the parts are in service to the core fun that is running and jumping with Mario. The Yoshi’s Island series has running and jumping and throwing eggs, which is already not as compelling based on how it was implemented. But even worse, you’re constantly saddled with these expectations of getting a good grade at the end of each level, and you feel like you’re doing poorly if you don’t slowly comb through the level for each stupid collectible. It’s not a fun thing to come back to: it’s an upfront chore, or at least that’s how it feels to many people.

This is where it becomes impossible to talk in generalities. Are all collectibles and end-level scores bad? Absolutely not! Some games thrive on them. But you would never be able to tell which ones are actually fun or not based on a written description of those games. You can only tell by playing them, which is why that initial vertical slice, and then further endless prototyping and experimentation, is so important. Hotline: Miami is a great example of a game where the end-of-level scoring is done to perfection. My Friend Pedro is an example of it being done semi-poorly, but not so much that it completely ruins the game as happens with the Yoshi’s Island later entries. (Remember, the later Yoshi’s Island games have the benefit of nostalgia and a giant franchise on their side; they would never make it as indie games without those characters.)

Anyhow. You will keep building and building on your core 5 minutes of fun, constantly evaluating everything that is new for whether it should stay or if it should be cut. If you aren’t sure, then that probably means it should go. Past some certain point, you will still have a pile of ideas that you COULD do, but that you haven’t tried yet, and you will realize “hey, this is already enough; this game is quite big now.” So stop adding ideas and get to polishing. If you keep pushing every last idea, then your game will be over-sized but under-polished. I’ve been guilty of this many times.

At this point, get the graphics to be as good as you can. Work on the music, the sound design, the achievements, any voice work that is needed, and so on. If you are looking for a publisher to fund a game, now would be the time to try to find one. Or if you want to do a kickstarter, then now would be the time to do THAT. Maybe you couldn’t afford art or music or sound before now, or you can’t afford the programmer expertise to really optimize the game. Well, okay then, that’s fine. At this point you can show people something that is demonstrably fun, and also “complete except for hair and makeup.” When you run a kickstarter, DO NOT promise more features. Make it clear that this is about funding the art and music and optimization or whatever. Give people a vertical slice (more than 5 minutes, but less than your whole game) to actually play.

Graphics and audio and the trailer and such — and the game of the game, for that matter — are the first things that people will see about your game, and many will not click a link to see what it is if even the name turns them off. All of these things are important! But especially as a new indie, you can’t be worrying overly much about these things before you actually have a game that is fun.

I used to tell people that games are not fun during most of development, and then at some point suddenly they are. And this remains true. But my strong belief now is that you need to hit that point sooner than later in the project, or stop working on a given project. If you can’t hit a point where you have a fun 5 minute game, then you need to stop and move on to a new concept. This happens sometimes, and that’s okay. Not every core concept is worth hanging onto. If you are not willing to admit defeat and throw away a “great idea” that you can’t execute, you’re setting yourself up for failure. Remember: if you plan on this being your career, you always have a chance to come back to that idea sometime in the future, in a different time when you know more. If it’s that great, then you’ll eventually figure it out, probably while driving somewhere or in the shower. But you do not have to figure it out right this moment. If you’ve hit a brick wall for months, and you’re starting to get truly frustrated, perhaps take a break and at least try a side project. Sometimes that “side project” turns out to be a major winner. This was the exact scenario that happened for me with the original AI War. It was just this little side project from the “main game” I was working on. I released the main game years later, after finishing it, and it bombed hard. It is widely disliked (though loved by an incredibly tiny minority) and has an overwhelmingly negative response on Steam. My side project made buckets of money, is still frequently put on best-ever lists for its genre, and so on. Don’t be afraid to “kill your darlings,” as they say in writing.

Whatever happened to that Chris Park guy?

Right – so I took a 90ish day sabbatical from work. What the heck was that all about? I said I’d update you guys on that (and be coming back to work properly) in January, so here we are. This was a really tough video to make, but overall I’m doing well these days.

There is a new release that also just came out today, so things are getting back into gear production-wise, which is good.  That release is the cumulative work of the volunteers over the last month, they’ve been amazing.  Coming up this next week I will be able to actually get cracking on some creative work of my own, for the first time in basically a quarter.

Thanks again for your patience with me during this, everybody.  It really has meant a lot.

Swizzle Lists! A nonintuitive data structure for AI War 2.

It really seems like there ought to be a quicker explanation for this, but to explain the fundamental goals, the pitfalls, and the usage constraints of this data type… well, data types are hard to explain if they’re off the beaten path. This one is really useful, but also pretty strange.

edit: Aaaand Badger figured out the bug, which was not in this code, while I was making the video. Hopefully someone else finds this useful or interesting. ;)

Using Mantis Bugtracker, And What Everything There Means

Primarily for new moderator/admin Dune, but we know a lot of folks find this sort of thing interesting, so here it is for everyone.

If any other indies are using a bugtracker, this isn’t a bad approach to take, incidentally — we’ve handled almost 20,000 reports over the last 7 or so years in this. The first two years were spent with bug reports going through our forums — yuck! Definitely glad not to be doing that anymore.

Goodbye, Alloy, But Thanks For Teaching Us A Lot

As of our upcoming version 0.610, we’re removing the Alloy Shader framework.

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.

 

Some screenshots of newly-painted PBR ships.

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. ;)

Autocannon Minipod

Old:

First revisions:

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??

Newest:

Aww yiss, now we’re talking.

Fighter

Old (although with some improvements that were overdue on the cel-shaded part):

New:

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. :)

Armor Ship

Old:

New:

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.

Bomber

Old:

New:

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.

Eyebot

Old:

New:

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.

 

More AI War 2 art-related videos!

Figured I’d cross-post this new batch:

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.

https://assetstore.unity.com/packages/vfx/shaders/alloy-physical-shader-framework-11978

https://forum.unity.com/threads/alloy-physical-shader-framework-version-3-for-unity-5.305178/page-34#post-3278461

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.

“Rorqual Hegira” Ark Painting Videos

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.

Enjoy!
Chris

AI War 2 gains IBL (Image Based Lighting)

Recently I showed how the graphics have evolved in the game via switching the materials to be more PBR-based (overpainting our cel-shaded visuals to augment them via Substance Painter).

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.

Actually, you know what?  Just check out this video with someone showing off what Unity can do.  Video is worth a thousand words… squared?

Okay, So What This Looked Like Coming Into Unity

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.

Upgrade One

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.

Upgrade Two

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.

Chris

Updating the ship aesthetic in the game?

Chris here!  Wanted to run something by folks.

Hopefully you can click on that and get the fully zoomed-in full-quality version.  If not, here is a link to a version that will definitely be full size.

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.

Any complaints?

Oh, Also — About The GUI

We’re having a lot of discussion about the GUI, and I’ve made a pair of videos on the topic.  Cyborg has been a huge help in focusing our attention in a positive way in this particular area.

Also, when it comes to the vibrance of the space backgrounds I’ve toned those down as of today, too — with the next build that comes out, 0.601, those will be much more muted.

And About Those Remaining Keys…

Still waiting on those from Valve.  So sorry about that!  I assume I’ll have the keys from Valve either this afternoon (PST) or tomorrow afternoon.  Otherwise I’ll get up with my contact there.

Cheers!

Chris

Plans and Status Updates for AI War 2

(Crossposted from kickstarter.)

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 forumsblogyoutube 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

Code:  

  • 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.

Art: 

  • 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.

Audio: 

  • 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.

Launch Discount

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.

Wrapping Up

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.

As always: any questions, please let us know!

Best,

Chris and Keith

AI War 2 – Quick Look At Ship Designs (less than half).

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.

More info is available in the forums.

Taking a look at some AI War 2 ships during late alpha.

Chris here! This is just a video looking at a variety of the ships in AI War 2, or at least the graphics for them. These are in the version 0.124, which will come out early next week. It’s presently late alpha for the game (in the pre-Early-Access sense), and so these are coming up to a much more polished status now.

As part of our testing thus far, one thing that we’ve discovered is the need to use GPU Instancing. That was something that I hadn’t been sure if we’d need or not, and I’ve mentioned it since our first kickstarter for the game. I wanted to try to get away with dynamic batching, which is compatible with OpenGL 3.x and DirectX 9 and DirectX 10. However, the performance just wasn’t good enough, even in battles with only something like 5000 ships versus maybe 2000.

A few passing bugs aside, the performance was still better than AI War Classic with that scale of battle on the simulation side in particular, but GPU instancing became a clear need. So now the game is going to use that, which requires DirectX 11 or OpenGL 4.1, and basically hardware from 2010 or 2011, depending on your exact hardware and OS.

Realistically you needed hardware from that era at the oldest anyway in order to handle the CPU processing, so this really should be a moot point, but it was a bridge I hadn’t wanted to cross unless it really became clear it was needed. Well — now it’s clear. :)

A bug in the GUI sidebar aside, I was getting about 30fps in the aforementioned battle using dynamic batching. This is on a latest-gen i7 with a GTX 1070. Now with most of the stuff working with GPU Instancing, I get around 80 fps. There are still thousands of wasted draw calls because of some of how I’m handling my custom sprite system at the moment, and I expect to get my machine running that same scene at 120 or 140 fps by sometime next week. Knock on wood. :) But it definitely seems like that will be what happens on my rig, based on all my tests thus far.

Anyway, so we get to the question of how big battles will be able to be, and to that I still have the answer: I really don’t know. For a variety of reasons, we can do larger battles than AI War Classic if you’re running them on modern machines. On a machine past a certain age (maybe from 2012 or before?), then the battles of Classic might be larger in terms of what your machine can handle. I’m not sure. The newer your machine gets, though, and that’s looking to the future as well, AI War 2 starts pulling further and further ahead. This switching to GPU Instancing is a huge amount of future-proofing in and of itself.

Overall we just have a ton of performance optimizations and multithreading in the game already, and it’s built around a variety of design concepts that lend themselves to larger battles than the original. We still do hit the occasional hiccup, like the sidebar thing, though, which makes performance absolutely grind to a halt for a bit. That’s one reason why we do the alpha, though; so we can fix things like that, and they never last long. :)

All in all, we’re looking good! I’m excited about the recent changes, even if I am apprehensive about any potential backlash by someone angry about the system requirements change.

Thanks for watching!

Chris

AI War 2 Video – Debugging Shot Lerping With Chris

Just thought that this was a fun video to do, since a bug in the shot lerping made this an ideal case to show what the shot lerping IS and how it makes a difference in the final visuals of the game.

The video came out longer than I had intended, but it’s a neat look into some of the math challenges behind having a “liar liar” 3D battlefield representation above an underlying coarser 2D simulation.

None of these are intractable problems, by the way, but if I waited to take a video after I fixed the problems, it would be a lot harder to see the innards of how this works. :)

As a reminder, we have a video playlist for our AI War 2 dev diary, which includes a variety of videos that are marked as unlisted on our main channel video listing.