Hey Everyone,
Today I talk about sparks and monsters (and how the game got faster).
The three core monster classes still are: swarm (lots of tiny monsters), normal, and giant (slower but stronger). The wave stones’ side cravings show the class of the arriving monsters (no ornament for normal monsters, tiny cravings for swarms, larger ones for giants).
Monster abilities are also shown in the wave stones, stronger craving of the ability runes mean higher level monster perks.
Some abilities can’t be given to swarmlings, and some are for giants only. Each wave (thus its monsters) can have up to 3 abilities, each ability can have 3 levels, and they can come in almost any combination, so giants, who can wield any abilities, can have 10.837 ability combinations in the latest build of the game. (This number was much larger until recently, when the gem type immunity abilities were taken out.)
Sparks arrive along waves, having their small spark stones, and can be boosted with gem bombs just like waves (more on this topic in 2 weeks). When the spark stone hits the header (or footer if you flip the battle frame), the spark activates, giving some instant bonus (like, charge boost for your spells or shrines), creating something (gem, mana shard), or, for example, bringing a burst of thunders, randomly hitting targets.
One of the biggest problem for hardcore players of the previous GemCraft chapters was the awful lag that came along with the lots of monsters roaming on the screen, which was mandatory if you wanted to progress to even higher wizard levels, thanks to the loved and hated xp system of the series (no infinite xp for beating some easy battle repeatedly).
I have some good news. I’ve just checked again to be sure, but it still works: 4000+ monsters running around on my core i3 notebook, and the game, even if not running smoothly, is still playable (I can place gems), at around 7-8 fps. This can still get faster (code optimization) or slower (as more content gets added to the game), but it’s definitely better than before.
Mostly tech details below, skip to the end if you’re not interested:
(please note: I’m not an expert on this topic so I’m probably totally wrong at some points, but what matters is that it works and it’s lightning fast compared to GCL 🙂 )
If you read the blog last year, I wrote about my experiments with Flash Player’s new Stage3D API (and the Starling framework), with the aim of boosting the performance. The results were not quite what I hoped for, and although I’m sure things will get much better as 3D is an untapped and evolving part of the Flash platform, I had to move on.
I wandered across the technology called blitting. Although I had read about it before, I never tried it, but it was just what the game needed to speed up.
Previous GC chapters drew the monsters using the Flash player’s classic vector renderer, which took the bitmap of the monster, put it on a rectangle, applied rotation and scaling, and even drop-shadow filter, and drew the results on a canvas. Of all these, using drop-shadow was a huge mistake on my side, applying it on hundreds of monsters each frame (ideally 30 times per sec) it has a great toll on the cpu.
Blitting, or block image transferring, is a good old technique from the age when processing power was measured in gold. Instead of doing anything on a source image in real time (rotating, scaling, and applying various filters (shadow, color adjustments and what not), it takes a piece of bitmap from one location in the memory of the computer (from a sprite sheet containing images prepared for blitting) and copies it, as it is, to the memory location that represents a canvas shown on the monitor (in the Flash player it’s more of an abstract canvas I guess, not the real memory location on the video card, but still, it’s much much faster than the classic vector renderer way of the Flash Player).
I’ve implemented an other way to fight the lag as well, limiting the number of drawn monsters per field. Each time the game refreshes the monsters, it first measures all the 44×32 fields for monster density and flags monsters that can be drawn. The second pass ignores the remaining monsters. It’s not that disturbing (some flickering can occur), because the dense crowd of monsters looks like a centipede anyways, be it 50 or 500 monsters crowded on the path.
And finally, changes in the game rules should bring some relief to the cpu too. Summoning, instead of resulting in tons of monsters, is planned to be geared towards the monsters getting more powerful rather than larger in numbers.
Blitting has its drawbacks of course. All the monster body parts have to be pre-drawn on sprite sheets (currently the game stores 48 rotated states for all actively used body parts (it selects parts from a large collection, only a part of the total variety is shown at any given time during the game) and that takes 5-15 secs when the game starts, and will hopefully take no more than 2-4 secs before each battle as the game will make some partial changes (recoloring sheets, dumping an overused sheet, drawing a new one). It also needs more memory to store all the sprite sheets (it eats 110-150 MB now, but that will surely increase as lots of more content will be added to the game). And the last drawback I met so far, is that monsters can’t be colored on the fly, because multiple monsters can use the same sprite sheets, e.g. I can’t paint them green if they are poisoned, so now a green icon appears under the health bar of poisoned monsters instead.
But all these are a fair price to pay for the performance boost and the added detail: Now monsters have legs and arms moving autonomously, not just a floating monolithic body (a normal monster has 10 body parts, swarms have 2, giants have 23), and the game still runs much faster.
Coming up next:
11th of June:
rapid gem bombing, summoning/heating up sparks, gem wasps
25th of June:
updates & more insight (on the topics covered so far)
