Qwerty War: day 4

On day four, I add sound effects. There are only a two essential types of sounds:

  • Gunshot when the player fires
  • Explosion when an enemy blows up

I could add some other effects, such as bullets whizzing by; a sound when powerups appear would be nice and maybe an alarm when health gets low. The original has music, but I think that is over-achieving for this little project.

There are a plenty of free explosion and gunshot sounds online; I pick some from freesound.org, and tweak and cut them in Audacity.

I’m playing all sounds with the Web Audio api. To make them interesting, I add a few variations that may actually be more trouble then they are worth: decreasing volume and delay depending on distance from the player.

What does turn out to be important is not playing too many explosions at once; many simultaneous explosions cause clipping and many very close together just sound like noise, so I introduce a brief delay between explosions when the player hits a bomb. This turns out to be a nice effect. Even with this, though, many explosions simply add up to too loud and still clip, so I use Web Audio to insert a compressor and that mostly gets levels under control.

Next problem is that the gunshots contain some hissing noise as they fade out; it is barely noticeable for a single shot, but becomes irritating when many shots are happening close together. A low-pass filter on the tail of the sounds cleans it up.

Once all the explosion sounds are working, I realize I have a performance problem. At first, I think that Web Audio is causing it, but a few minutes with a profiler tell me that it actually is drawing all the explosion animations when a large bomb goes off. I hadn’t noticed it before only because I did not have so many enemies on the screen at once.

Well, optimization will be a problem for day five.

Quad-monitor Linux

The last time I ran multiheaded Linux, I was on Kubuntu 12. Since that time I’ve built about a half dozen machines with same or similar hardware: a couple dual-dvi Nvidia cards. They mostly ran Windows, but it’s 2016 and time to kick Windows out again.

Upon initial install, three of the monitors are basically functional and Kde display settings detect the fourth, but won’t let me enable it. A little research and I remember that I used to use Xinerama.

In 2012, Nvidia supported multi-head configurations on Linux with its proprietary X extension, Xinerama. It was a bit quirky, but worked well enough so long as you had a set configuration you didn’t want to change often.

So I install the binary blob Nvidia drivers, enable Xinerama and get only black screen plus a cursor shaped like the letter x.

It seems that Nvidia abandoned Xinerama and they now say to use something called Base Mosaic. After reading many instructions and questions about this setup and tweaking xorg.conf every way I can imagine, I conclude that Base Mosaic can only span multiple video cards when they are connected via sli, and even if I had cards with that capability, it’s not clear whether I could expect it to work for more than three monitors.

Essentially, I have the wrong hardware. So I abandon the hostile Nvidia and instead order two Radeon cards.

Ati used to ship binary driver blobs, but also made specs available that enabled development of more reliable open source drivers. In the last few years, Ubuntu dropped support for the binary blob “fglrx” drivers, reasoning that the open source drivers are adequate, so the the fglrx packages no longer appear in official repositories for Kubuntu 16.

Two Radeon cards go in and all four monitors come to life. It looks like progress. Unfortunately, though active, they are barely usable: my mouse suffers terrible jerkiness and screens briefly freeze from time to time. I spend the rest of the day trying different combinations of Linux and window managers: i3 on Ubuntu, Kde on Centos, Gnome 3 on Centos, Cinnamon on Mint. All suffer similar problems and the fglrx drivers from ElRepo just crash.

I observe that the the problems go away so long as I use only one card at a time. So, I reason that I still don’t have the right hardware. I order a quad-head card, the VisionTek Radeon 5570. Finally, five video cards, later, I start Kubuntu and everything just works.

Short story: for multi-head Linux in 2016, use a single video card and avoid Nvidia.

Qwerty War: days 2 and 3

For day 2 of the Qwerty War project, I wanted to get all the visuals roughed in, though without final sprites for the player and enemies. It turns out this actually took two days.

I considered doing the whole thing by moving divs about the screen, or even svg everywhere, but the obvious choice is canvas, so best not to overthink it.

User controls – word input, health meter and score – are still regular html elements overlaid on the canvas. At first, I thought I would do the same with the enemy words: reposition the table cells from day one’s text-only version to follow sprites around, but soon decided drawing the text with canvas api would be simpler.

More structural changes came from the rework necessary to allow for delay while bullets reached the targets. This may not have been strictly necessary: originally, I planned to keep reactions instantaneous. When the player shoots, for example, the enemy would explode immediately. I would then animate the bullet motion toward the enemy. Since the bullet would whiz over in less than a tenth of second, the delay would not be noticeable.

As I was starting, though, this felt wrong. The code made more sense if I associated the explosion with a bullet impact, rather than the shot. If I’m inclined in the future, this should allow features like slow motion.

Bullets are the only effect not built with sprites: they are just lines with gradients to fade out toward the shooter. The “collision detection”, if you can call it that, is easy. Since every moving element is arranged radially from the player, it’s a simple matter of checking whether the bullet traveled far enough to hit its target, which causes the target to explode.

Explosions, of course, are the fun part. The nifty http://explosiongenerator.com/ gives me the look I want. There are three levels of enemies in the game, from words length three up to five, so I just need an explosion per enemy type. Stopping the explosion a few frames from the end gives a nice debris and blood splatter to paint on the background. By randomizing the rotation of each explosion and its ending frame, just three explosions look pretty organic.

Explosion generator gives you a download full of .png images; I used ImageMagick to combine them into a single image suitable for animation:

montage images/explosion0{000..191..4}.png -geometry +0+0 -tile 12x4 -background none explosion1.png

That squirly brace stuff is a handy shell trick to pick every fourth image from a desired range. From there I just use JavaScript to animate these frames.

So far, the game on day 3 looks pretty good, but a few details bother me:

  • Enemies run over each other, sometimes obscuring the words you need to see. This also happens in the original Qwerty Warriors. It’s not too much of a problem – you could even say it makes you think a little more strategically about who to shoot – but it seems unpolished. Would be nice to put in collision detection so enemies stay don’t run each other over.
  • The end is abrupt. It might be a neat effect to finish animating all bullets in flight and explosions after the player dies.
  • Bullet animations are not entirely satisfying. They are functional, but not exciting.
  • As I was testing, I realized muzzle flashes are a nice feature to show you who is shooting at you. I put them in as just one extra sprite for each of the player and enemy types, flash on or off, but there probably should be a few frames to that animation.
  • The bullet trail extends through the shooter. I mentally justify that by saying it’s the stuff coming out of the rear of a rocket or something, but actually it just looks odd.

Nonetheless, it looks decent and is becoming fun to play. Day four will be for sound effects.

Qwerty War: day 1

“Qwerty War” is what I’m calling a small typing game inspired by Qwerty Warriors.

The concept is that you are a keyboard-slinging warrior surrounded by never-ending waves of enemies. There is no escape, but you’ll take as many of them down with you as you can. Qwerty Warriors is my favorite typing game; since it surrounds you with enemies, it has an intensity that other typing games lack. Its remake, Qwerty Warriors 2, by contrast, only sends enemies in from the top, typical for typing games, and boring.

The original is built in Flash and often syndicated on shady sites who make their money via ads for scareware and other garbage. So my own Qwerty War will be an open source JavaScript only game.

On day one of this project, my goal is to get a text-only version working with all components. In the text only version, a table of “word” and “range to enemy” replaces the visual of enemies encircling the player, but it contains all the actual gameplay components. There is no reason for a typing game not to be accessible to the blind, so the text only version will remain as a fallback to the final graphical version, build on html canvas.

The final version will include a server-side component for saving the leaderboard, but the game itself runs entirely in the front end. After day 1, it is playable, if a bland. Source is on Bitbucket.