I've been working this week to get combat up and running reliably. It is starting to come together now, at least well enough for a screenshot.
There is still lots of work to be done, bugs to fix, more explosion and weapon effects to add. I need to dial the smoke back quite a bit because now, after a half dozen units explode, you really can't see what's going on any longer. I like the realism, but it isn't practical for gameplay. Luckily smoke isn't a problem for the AI so the action continues.
I added crates last week to replace the old loot marker (which looked a lot like the loot markers in Star Wars The Old Republic.) Crates are more in line with vintage Command and Conquer. Players have five minutes to collect their crates which show up on the map as slowly blinking dots. Crates contain cash, unit components and sometimes even complete units. Often those components and units are ones you can't get any other way.
I also had a really fun bug this week. After you log into the game, your units are invisible until you select where to place them. But they're still loaded onto the client, and I hadn't informed the AI of this little fact. I logged in with a large force of red tanks that were previously located right next to where a huge group of blue tanks were. The blue tanks couldn't see the red, but the red tank's AI could see the blue perfectly. So the red AI started blowing up all the blue tanks one after another in spectacular fashion. The fix was easy, all I had to do was tell the blue tank AI to sleep when unit layout is complete. Then, since I tweeted about it, I also modified the server so that it will no longer accept AI commands from clients who haven't finished unit layout. Done and done.
Something you quickly discover when you start developing online games is how hyper-rare bugs can throw off your plans. You have a bug you're working on, then all of a sudden, you're interrupted by something entirely new. Sending messages over the internet, 99 times out of a hundred the server sends a message to the client to delete a dead unit after the client has finished playing the explosion sound effect, but then one time, the server is a little quicker or the WiFi deities shine on you, and the client receives the message to remove the dead unit before the audio is finished. Crash! You have to go after those bugs when you see them because often you can't reproduce them without a lot of effort.
After demoing Miranda at Full Indie last week, I decided it was past time to fix my longest-standing and least-attractive particle bug. Whenever a particle emitter went off-screen, it was put to sleep. When it came back onscreen it would morph into ugly monster smoke clouds. That one was a real head-scratcher and most of my day was spent trying to figure out how the code I wrote 3 years ago worked. Hardware-assisted particle systems are complicated. Coming into it I thought the problem was that for some reason, the geometry shader wasn't killing the particles generated while the particle emitter was offscreen. It turned out that what was really happening was that when the particle emitter came back onscreen it would emit a bunch of brand new particles, then due to a quirk of the implementation, it would zoom all the particle animations forward in time by the amount of time it had been offscreen, producing big ugly smoke cloud particles with a normal lifespan.
So yes, fixing bugs, combat starting to look like it should, progress. Have a great long weekend.
We were unable to retrieve our session cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.
You will not be able to post until you resolve this problem.