What about sunrise
What about rain
What about all the things
That you said we were to gain.. .
What about killing fields
Is there a time
What about all the things
That you said was yours and mine…
Did you ever stop to notice
All the blood we’ve shed before
Did you ever stop to notice
The crying Earth the weeping shores?

Now, the point of this is basically just to tell that we’re finally getting a proper use for Earth Shock as Elemental. The latest Cataclysm beta-build (12803) added in a useful combination of things. First, we get to use Lightning Shield instead of Water Shield, and it will provide us with mana regain and a mechanic somehow similar to Enhancement’s Static Shock. It all comes from the two new talents Rolling Thunder and Fulmination.

Rolling Thunder gives us the nice mana regeneration. 1% total mana is quite a bit, especially with a 60% chance of every Lightning Bolt or Chain Lightning being fired. The side-effect of adding a shield-charge seems to be a bit odd at first – it’s not really intended for us to get hit to do damage. However, that’s where the second part comes in.

Fulmination (the name is incredibly fitting by the way) gives us a way to deplete excess shield charges from the maximum of 9, down to the normal amount of 3, by firing off – yes, Earth Shock. In short, optimal conditions will let it do the extra damage of 6 charges. Improved Shields suddenly looks very interesting, and one could theorize that [Glyph of Lightning Shield] might be slightly useful. Then again, glyphs haven’t been touched upon yet, so it’s quite meaningless to talk about those just yet.

If we use todays numbers, the extra 6 charges would add the following amount to the damage:

Seeing as 3500 spell power is in no way a unreachable number, that would give us a bonus damage of at least:

… and that’s a pretty stunning number, considering Earth Shock‘s damage itself hasn’t been added yet.

There still is some “drawbacks” though. First of all, it’s not really going to be that often we can use it (around every 20th second or so, if we’re lucky). Understandable, since it lacks such a severe punch. Secondly, there’s the thing that it’s not yet included in Elemental Reach, which reels us into 25 yard range. Most likely going to be fixed though, as it would be incredibly awkward otherwise.

Still, it’s a change I thing is very welcome, adds a bit of spice to the rotation, and breathes some new life into an old friend – although, most of us would probably prefer something with Frost Shock instead. Now, if only I had a beta key so I could test this properly…

Last time, I stayed within the familiarity of the Warcraft Universe, with the story “A Change of Ways“. The advantages was that it has a rich lore, with tons and tons of details and places, and the more obvious thing that it’s the universe I’ve spend the most time in, so far. But, what’s a competition without a challenge?

With that in mind, only two real universes remained: Diablo and Starcraft. Being more a fan of dark fantasy than science fiction – although I do like both – and knowing something about Diablo, I chose the realm of Sanctuary. The lore is less detailed, and lots of stuff is still clouded in mystery, which makes a lot of nice openings for a good story.

So far, I’ve gotten a plot shaped, and slowly iterating through it and adding details, fleshing out characters and figuring out what part they’ll have. The main thing I want to do, is tying the various games together, and make further connections, as one of the things I’ve been having on my mind lately is just that. Looking forward to seeing how the story will turn out. This time, I shouldn’t have a problem with with time running out – I hope.

Now, first of all, it was “just” (3 days ago) announced that the Mastery and Talents was up for a bit change, by giving us less talent-points, but giving each of these more meaning, while – as we have known for some time – making all the boring stuff passive. The way I’ve built Thunderstruck, is basically by having a long list of what the various talents does, and add those bonuses to the base spell-values, which are then used to simulate a casts, based on the characters current statistics (as these can obviously change, by using trinkets, being under the effects of [Bloodlust] or otherwise). Less numbers flying around should make that a lot easier.

The fun part about masteries was indeed the Elemental Overload (basically just [Lightning Overload], where Lava Burst can now be triggered as well), which I’ve already covered the basics of. The way I’ve done it, is basically that Lightning Bolt, Chain Lightning and Lava Burst, are all simulated with the same function, with the only difference (except different input numbers), is that the later has a variable set that doesn’t let it do Overload, but instead causes it to always crit. Now, this is something I can change, and completely leave out, as all of them will be able to do it.

In regards to statistical additions, there will be three additions/modifications: Spirit, Intellect and Mastery Rating. The first two are easy, however. Spirit will simply (as it stands now) be added as Hit Rating, and continue as that. Intellect will add a conversion-ratio for Spell Power (and that is possibly being changed to “Spell Power on weapon”). Lastly, there’s Mastery Rating – but do we know that works? Actually, it is quite simple – if my assumption is correct: Like any other Rating, Mastery translates directly into a percentage, from the basic rating formula. This percentage boosts your current Third Mastery (in this case: Elemental Overload), by that amount.

So, basically, let’s say the base percentage of Elemental Overload is 25% (as it looks now), and our Mastery rating translates into 38%, we’d end up having a 34,5% chance of Elemental Mastery doing its wonders. I like that – it’s going to give some nice theoretical wonders in determining which stat is the best, and how they’ll end up scale with each other.

To give a quick rundown of the project, it was done by writing a program in C, that was sent via a serial port to a ZiLOG Z8 Encore! Z8F6403, and from there we could listen via a Telnet-based Terminal (from another serial port), and/or via the on-board LED display (which I got a nice example of here: The Failboard), and get inputs by pressing the 3 buttons. The first week was various exercises to get used to how it reacted to various things, how to control its register-calls, and coding C in general. The various exercises was naturally elements that would all be used in one way or the other in the final project. The last two weeks however, was where the interesting stuff started happening, as we finally got to know the final objectives: Create a game based on “ReflexBall” (which is basically ArkaNoid, without any objects to hit), and develop it into either (you guessed it) ArkaNoid, or something else entirely – pretty much freely chosen, but it had to satisfy certain criteria.

For the fun of it, we chose the latter, and got the idea for a – potenially – pretty fun idea: Gwardar. Naturally, that name doesn’t say much, but it should help a lot when looking at what a gwardar actually is: a snake. So, our idea was a hybrid game of ReflexBall with Snake elements, which ended up being quite fun, and the actual game was – in fact – pretty fun as well.

I mainly worked on the gamefield – where the snake bounces around, collision detection – which was a much more essential part than for an ArkaNoid-game, as the ball/snake shouldn’t be able to hit itself, and react differently when hitting different things, and the ball/snake itself – which made sense to do together with collision, as that should be based upon where the ball was.

The first had some interesting challenges, as we only had a practical resolution of 63 x 21 “blocks” (columns and rows in the terminal-window, respectfully), and still wanted the ball/snake to be able to move with more than 8 different directions. As thus, we gave each block a 10×10 background, essentially giving us a gamefield of 630 x 210, which gave many more possibilities in terms of directions (early screen here, showing it). However, to properly do that, we had to ensure that the ball/snake always moved to a new block, which was done by scaling the directional vector, so that the numerically longest of x or y was exactly 10 (or: 1 block). Any more, or any less, would mean that it could potentially skip, or end up in the same block.

In regards to collision-detection, it was done by first detecting what was on the target block, judged from the directional vector, change it in case the target was a wall or the “striker” (the board the player controls), grow in length if objects was eaten, or die, in case it was itself, or the void below the striker. In the case it was hitting something that would change the vector, the new target block was checked, and the ball would only continue moving in the case that there wasn’t anything there – or it was an edible object. The tricky part about the collision was detecting when it was hitting itself, and let that be handled properly. To explain that, it’s probably best to explain the properties of the ball/snake first.

The ball was given a “history”, of up to 50 blocks, that kept track of up to the previous 50 positions it had been placed on the detailed gamefield (that is, in the 630 x 210 grid), which initially served as a way to “erase” the balls previous position when it was redrawn at a new position, but later – when the ball turned into a snake – also a way to show the tail itself, by only erasing the tail length’th object in its history. In the end, the history was also used to place objects whenever eaten, at the very last position of the history – which turned out to look like it was random, especially when the tail length was short.

Getting back to the collision, it was obvious that low angles (meaning a directional vector of (10,1), for instance), would most likely cause the ball to “hit itself” upon bouncing against a wall, which would make it more or less impossible to ever reach the maximum length, or simply get very far at all. Still, it should naturally be possible to hit the tail, so we decided to simply ignore the first few parts of the history, when checking collision, so that the ball/snake had “time” to get free of itself. Hitting directly into a corner, would however still result death, as the overlap would be too great.

The other collision-based problem that surfaced was when “crossing itself”. A problem we never actually experienced exactly, but would look incredibly awkward if it did. Basically, it could happen as it would never actually hit itself, but on both sides, on points where both the “rough” x and y coordinates had changed (that is, on the 63 x 21 grid). Basically, it was done so that every time a situation like that happened, the collision-detection would check if both the coordinates (current_x, target_y) and (target_x, current_y) was in the ball’s history. In that case, it would have struck itself.

Now, going away from all the technical matter, the game proved to be very fun to play as well. The idea has been tried before, and there are quite many possible ways of combining the two basic games. In my personal opinion, ours was a success – but that’s always easy to say as one of the developers.

As a last word, here’s another screenshot, which should catch the idea pretty well. Try to imagine it with the tail being up to 50 “blocks” long.