AI War 2 Alpha v0.112 "Plasma, Forcefields, and DirectX11" released!

[x4000]

Since the last blog post I made, we've done two intermediate versions, and this is the third.

In cases when I just don't have time to update the blog for whatever reason, bear in mind that there are three places that always get updated:

• Steam itself will auto-update you unless you're on a specific locked-in "beta" branch for whatever reason.


• Our official forums always gets a quick post, because that's super fast.


• The release notes page always gets a new entry, and the date logged for the build.

At any rate, apologies for not updating the blog on the last two builds.  It's something I try to avoid doing, but I'd rather miss a blog post than a release.



So: what's new lately?

• Keith updated a ton of stuff with the modding capabilities in 0.110, which is a big deal for modders.  It really increases the power/flexibility of the modding system.


• I upgraded the version of unity that the game runs on in that same build.


• As part of 0.111, Keith fixed a bug that was causing crashes on linux and milder problems elsewhere.


• This new 0.112 build includes three new units in the game.


• This build also now includes DirectX11 support, to deal with an OpenGLCore crash bug on at least one windows install.


• There are a variety of under the hood improvements in this new 0.112 build that are getting us a bit of extra performance and quality in a few areas, and which get us closer to getting into some of the GUI work.

Other stuff?

• Blue has been pulling her hair out working on the new icon system for the game, and the results are coming along really well at this point.  It's been a big task and the topic of much discussion with players; even after the direction was set late last week, that still left a lot of experimenting to get something that looks cohesive and clear while still being attractive.  Getting just the right amount of detail is a big deal.  We'll be ready to show that off later this week, I think.


• There is a backlog of 3D models and textures that are done and ready to get into the game, but unfortunately Cinth had a very serious medical emergency over the weekend and so will be out for a few weeks at bare minimum, and possibly more like months.  At the moment he's still in the hospital.  Please share your well wishes for his recovery.  At any rate, a bunch of that stuff will drop all at once sometime soon once I have a chance to get to it.


• In general, Keith has been looking at the GUI more now that I've gotten the unity project set up for him to be able to do that sort of thing.  So we'll see what happens with that, in terms of what he does with it both with and without Blue at this point.  He can speak to that better than I can.


• I've been working on a modified version of the sort of sprite batching system that I use in starward rogue for actually displaying the ship icons that Blue is creating.  That's been a tricky thing, because they are pretty different systems, but after a lot of study I just don't think there's a more efficient way of handling it.  The actual GUI won't use that system (that would be less efficient, not more), and of course the main game doesn't either (same deal when it comes to large ships).  But for this particular case it should pan out well.


• I was also working on some cool stuff relating to a new system for explosions of ships, although I've temporarily set that aside.  The general principle of it works and looks great and seems to perform well, so that's enough for me for the very short term -- I have bigger fish to fry before I finish that one up.

So that's what's going on with us.  Thanks for reading!

Chris

[z99-_]

I was admiring the shininess of the ships in that pic, and it occurred to me, that was all an end result of stuff Cinth was doing wasn't it? I wonder what other cool ideas we're going to miss out on because he won't be around to have them

[Chthon]

Hey Chris. It's a little bit late, but for the past month I've been studying automated testing solutions in my new internship. I went back and on January 10th you guys were trying to speed up the build process. Have you tried using Jenkins with Apache Maven to do that? If you could explain to Maven how to build Unity projects, or even Apache Ant, you could probably automate that stuff, and have Jenkins compile and run all your tests with every commit.

Both of these are free and open sourced. It's just a thought. If you need other ways to test software I can advise on that now. I guess I'm sort of being made into an expert on automatic testing.

[BadgerBadger]

I've always struggled with the notion of good automation of tests in a gui environment. Do you get the test suite to enter mouse clicks for you? Do you expose some other layer of the software for the automation to interact with?

[Chthon]

It depends on what you want to go for, BadgerBadger. The easiest method is allowing it application hooks, where it can pass click objects to the clicked on methods of various things. It's somewhat harder to do input virtualization simply because if the UI changes at all, typically they break unless there's some good OCR involved, even though it's initially easier to implement.

Anyways, that's not what it sounds like they're looking for at the moment. Or were looking for even. They sounded like they needed to get automatic builds and testing set up in the first place.

Edit: If they are considering GUI automation, Robot Framework looks like a pretty good tool. I haven't had the chance to try it yet, but it works on Python, Java, and .Net languages, and you can script in it using keywords so learning it can be easy. It's also data driven so you can take your data out of your test cases, and put it in an external source, and add new similar test cases just by adding more data that your tests can use. It's also free and open source.

[x4000]

I was admiring the shininess of the ships in that pic, and it occurred to me, that was all an end result of stuff Cinth was doing wasn't it? I wonder what other cool ideas we're going to miss out on because he won't be around to have them

Yep, he had the idea and did the first prototype.  I then did some more work on it, got things settled into a process, and then he converted the rest.  So yep, he was a major force behind that, to say the least.  His absence is definitely felt.

I went back and on January 10th you guys were trying to speed up the build process. Have you tried using Jenkins with Apache Maven to do that? If you could explain to Maven how to build Unity projects, or even Apache Ant, you could probably automate that stuff, and have Jenkins compile and run all your tests with every commit.

Both of these are free and open sourced. It's just a thought. If you need other ways to test software I can advise on that now. I guess I'm sort of being made into an expert on automatic testing.

Sounds like a pretty awesome set of work you're doing with your internship!   Very very cool.

In our case, a lot of our issues were based on the literal time that operations take (while blocking our computer from much other than forum posting), and not really related to the number of steps that had to be manually undertaken by a person during said process.  The latter was a milder part of the issue, but batch scripting solved that pretty neatly.

Mainly there are slow ways that unity builds things, and fast ways.  The default ways are super-slow.  So we had to delve into less traveled paths within unity and set up the projects in unusual ways (for a small dev) to get that moving faster.  In general that involves getting unity to use its own cache more, and not do massive amounts of internal repeated work with GBs of data, etc.  That's all black-box, so it was a matter of experimenting with it and listening to what other larger devs were doing.

Fortunately we got that all worked out now, and for the most part I can just hit a couple of batch scripts and the build happens within seconds.  Mostly.  There are a few more automations that would be possible, but for the time being the ones that are not in there are ones that we need to hand-check at the moment to make sure that things are ok.

But those are certainly powerful tools you're working with, for sure!

[Chthon]

I went back and on January 10th you guys were trying to speed up the build process. Have you tried using Jenkins with Apache Maven to do that? If you could explain to Maven how to build Unity projects, or even Apache Ant, you could probably automate that stuff, and have Jenkins compile and run all your tests with every commit.

Both of these are free and open sourced. It's just a thought. If you need other ways to test software I can advise on that now. I guess I'm sort of being made into an expert on automatic testing.

Sounds like a pretty awesome set of work you're doing with your internship!   Very very cool.

In our case, a lot of our issues were based on the literal time that operations take (while blocking our computer from much other than forum posting), and not really related to the number of steps that had to be manually undertaken by a person during said process.  The latter was a milder part of the issue, but batch scripting solved that pretty neatly.

Mainly there are slow ways that unity builds things, and fast ways.  The default ways are super-slow.  So we had to delve into less traveled paths within unity and set up the projects in unusual ways (for a small dev) to get that moving faster.  In general that involves getting unity to use its own cache more, and not do massive amounts of internal repeated work with GBs of data, etc.  That's all black-box, so it was a matter of experimenting with it and listening to what other larger devs were doing.

Fortunately we got that all worked out now, and for the most part I can just hit a couple of batch scripts and the build happens within seconds.  Mostly.  There are a few more automations that would be possible, but for the time being the ones that are not in there are ones that we need to hand-check at the moment to make sure that things are ok.

But those are certainly powerful tools you're working with, for sure!

Ahh, but with Jenkins and either Ant or Maven, it does the batch scripting for you, and you never have to worry about it again. Plus you can set up a build server to run that for you while you continue talking.

There are other tools though out there, like there is one that if you're using Github, it will trigger any time you commit to it, and auto compile and run all your scripts remotely.

Also, I'm not playing with them... yet. I'm under orders to look but not touch, which is very painful for me, as there are many I want to take apart to see how they work.

edit: Just to be clear here, this is what I was proposing:
Jenkins can be set up to detect when you commit a new build. It will then call out to ant with a script similar to what Keith was making, or Maven with a simpler script (supposedly Maven is intelligent enough to figure out what order to do things), and they will compile it.

Then Jenkins will log the compiler outcome and if it succeeded it will run the tests.

Finally Jenkins will log the tests outcome and compile that into a report that you both can view in a web browser. Heck, you could even share that report with all of us that backed you. This will happen automatically every time you commit code, and if you make a server who's only job is to run this, even if it's slow you won't be locked down every commit. Keith could commit, get up, go to the bathroom, and then come back, or just chat for a while, no problem.

Second edit: Gah! I can't find any of the repositories that used Jenkins that I've seen over the last few days. Every one I pull up is using a similar but new one called Travis CI instead. It looks very similar though so here's an example of it https://travis-ci.org/apache/zeppelin/branches

Problem with Travis CI is it's only free if you're writing open source, which you aren't, plus I think it only works on Github, so you'd have to pay for private repositories and pay for Travis CI.

Anyways, I thought I'd give you a taste of what it looks like. Honestly there is no reason why you guys shouldn't be at least using some CI software, as it looks like a great quality of life improvement. I'm going to try setting up Jenkins with my club's repository and see how that goes.

[keith.lamothe]

We do our compiles and tests locally, and don't commit unless it passes. The tests are also not really automate-able, since there's a lot of "does it look right?" involved.

Continuous integration would make sense if we had any automated unit tests, but we don't. You could probably write some if you were curious, like running various seeds through each mapgen and seeing if the graphs are always connected, etc.

[Chthon]

Ahh, most of the tests that you automate are either unit tests, or they are tests for regression, to make sure an old bug doesn't pop back out after a new change.

[BadgerBadger]

Man, .113 looks like it has a ton of good stuff when it comes out! Friday, I hope?

[x4000]

Yep, should be!  Releasing right before the weekend is usually a bad idea, but I'll put up a beta branch for 0.112 just in case.