Loads of new stuff!

The reason why we’ve been so quiet is that we’ve been working (finally) on the game systems themselves and the gameplay is starting to take shape!

First, I finished the “highlight” effect, that kicks in when the mouse cursor is on top of something that can be interacted with:

First I tried making a simple “outline” shader for this, using the same technique I used back in Blitz and Massive, some years ago:

Unfortunately, with the more advanced rendering we’re using in Grey (like much more alpha testing/blending), the final effect wasn’t very pleasant to look at… Inspired by Diablo 3, I’ve just added a “highlight object” to the engine, that during the alpha-blend stage draws the same mesh as the highlighted object, using a different shader, that adds some color depending on the angle between the pixel being shaded and the view direction. The closer it is to 90 degrees, the less transparent it is:

Some objects/angles don’t look as well as others, but overall it looks pretty good, considering the objective.

As you might have noticed, in these screenshots we’ve changed the camera setup a bit. First it was an experiment, but the end result is more pleasing than the axis aligned camera we have previously… We still have some internal discussions on exactly how the camera is going to be setup:

• Axis aligned (as previously)
• Isometric like (as in the screenshots)
• Free orbit camera – considering the more RTS nature of Grey, that might work a bit better, since players can place the camera where they like it the most. The drawbacks is that we don’t have so much control on what content is displayed on screen at any one time.
• In all of these options, what do we do when the play area is occluded by something in the foreground (like tall trees)? We have several options, like zooming in the camera so that there’s no more obstruction, or we can fade out the occluding objects (don’t like this one very much, since it would entail breaking geo clusters, etc). Another options is to make the camera move more to the vertical (a more top down view) when that happens…

We’re still discussing all these options, trying to reach a good compromise from a technical and artistic standpoint… For now, we’re playing around with this isometric camera model…

We’ve also finished the basic AI design, so some enemies already engage Grey and attack him:

The way it currently works is that all enemies have an agro list that gets modified with the actions of the player (or other creatures). The entity on top of the agro list is selected as a possible target. Then we look at all options the attacking creature has, measured with some probability factors and we decide on one attack. We then move the creature to the desired range (some attacks are only available at melee range or at a specific distance) and we trigger the attack. The path-finding is still a bit wonky, but for now it is functional enough.

We’re still working on the exact system of the attack (and the actual values for damage, health pools, etc). Currently, our metric for the tuning is “time until someone dies”, on a one-on-one slap fight. We’re aiming for 30 seconds fights (we’ll probably tweak this value when we can finally account for the “fun-factor”).

A lot of RPG sub-systems are already up in the air. Currently, we have the “haste” and “critical” systems in place. The creature has a “haste factor” that defines how fast it attacks and how long that ability stays on cooldown. It also has a “critical strike factor” (well, actually two: a spell one, and a melee attack one, since they’re modified by different stats – intellect in the first one, dexterity on the second), that influences the probability of any attack to be a “critical strike”, which deals from 50% to 100% more damage.

Still missing are the “miss” (also known as hit rating system), “parry”, “dodge”, “block” and “armor resistance” systems. All of them are simple to implement in the current architecture, after I figure out exactly what we want to do with the systems.

For example, parry and block are both systems that absorb part (or all) of the incoming damage, but using different factors (parry involves dexterity and the “parry” attribute, and block involves strength and the “block” attribute, and requires the attacked character to have a shield). I’m still considering merging these two systems into a single one, but we’re still discussing it. I understand these systems as being different things, but the end result is a bit the same.

So work has been progressing nicely enough, hope to have some time to work on more of these systems in the next weeks, since I can’t wait to actually start playing and trying to figure what exactly are the fun actions and how to reinforce these, letting the less fun stuff drop by the wayside…