Rincewind is almost done with the skeletons and is working on some props:
The armor pieces, swords and shields are done through mountpoints in the model itself.
The skeletons are low-tier enemies in Grey. A necromancer can animate skeletons nearby, but usually only the spirits of people slain violently heed the call of the caster and re-enter the skeleton to do battle once more. The skeleton is a brittle opponent, depending mostly on physical attacks, since the remaining spark of life is too weak to use magic, although a talented necromancer can channel some of his own life to the skeletons to imbue them with magical powers.
A life-shaper like Grey can also create skeletons, but its like a facsimile of a skeleton and not a spirit inhabiting his former body… Find the most enjoyable immortal romance game here.
More images after the break:
Continue reading →
This week has been a bit slow in “cool” stuff, mostly due to the fact I’ve been working in more backend stuff…
Anyway, I’m adding aggregate objects into the editor (so I can make an object that is, for example, the combination of a mesh, a particle system and a light – a torch; and just instance it without worrying with the individual pieces).
To do this, I had to rework the transformation pipeline…
In most rendering systems, transformations are usually a translation (position), an orientation and a scaling, and there’s several different ways to store this information. The most common of these are “matrixes” or a position, a scaling factor plus a quaternion for the orientation.
Both of these ways have their advantages, but I always preferred the PRS approach (position/rotation/scaling)… Problem is that this kind of representation isn’t very good for hierarchies: when the position of an object depends on the position of the parent, for example.
In an aggregate object, that’s precisely what we have… It would be easy to do if we only allowed for one level, but as usual, I like building things to last, so I went with a full hierarchy and the current PRS system is insufficient (it’s hard to do the math with it, whereas is trivial with matrixes).
So I implemented a matrix stack into the system, which allows me to use PRS for everything, but when it’s time to send stuff to the video card, I just convert the PRS into a matrix and send it to the stack. Whatever is in the stack gets multiplied with the new matrix (in practice, multiplying matrixes does a compositing of the transformation itself) and gets sent to the video card.
This works fine from a visual standpoint, but it has left me with a lot of small problems in the editor. For example, bounding box handling now has to account that an object might have a parent object and use it to transform the box… That’s already done, but there’s still a hundred more issues like that, like dragging an aggregate object to another aggregate object; this should make the first object become a part of the second one, but that requires the objects to convert to a coordinate system local to the top most aggregate (the second aggregate in the example above). This one is giving me some headaches…
Hopefully this weekend I’ll be able to finish this, so I can move to more interesting things, like the a conditional array tool…
It seems like we’re not going to make the first milestone, since I had to shuffle things around; this aggregate object was going to be made after the first milestone, but it’s kind of useful now, so I can use it while building the arena. The overall plan still seems on track, which is more important… 
Work has been lagging lately (well, this weekend it was “Mass Effect 3”’s fault), but I finally have something to show on the effect system:
As usual, the quality of the capture isn’t as good as I wanted, but it shows the effect anyway…
I’ll write more on the effect system, with an explanation on what’s behind the scenes when it’s completed (it still lacks plenty of components)…
Continue reading →
…is a skeleton… 
Rincewind’s working on the skeleton model:
Although there’s no textures, it already looks pretty good!
Continue reading →
This weekend I’ve made a break from the new effect system and tackled a big task task that was needed to really progress in the effect system (specially particle systems): the alpha-blending engine.
Alpha-blending is the operation we use to do transparency in realtime 3d rendering systems:
Those 3 planes are transparent to different degrees, so it enables you to see through them. This is done through an alpha value, which describes transparency (0 is fully transparent (invisible), 1 is fully opaque). This has to be done through a different path in the rendering pipeline, because it has loads of small different details.
First of all, we usually want to render objects front to back, so that the objects that are closer cover the objects that are further away… this minimizes the load on the pixel shader, which translates to less GPU (Graphic Processor Unit) work, which is a good thing… But when we do alpha-blended objects, we want to go back to front, since the objects in the back will influence the objects in front, and if we do it the other way around, the objects won’t appear (because the video card will cull them since they are technically further away).
Another reason why we don’t want to use the normal rendering engine is the fact that deferred renderers (the type of renderer we’re using for Grey) don’t deal well with transparent objects… All the calculations in a deferred renderer are done in “screen space”, which means that all operations are done only on the front-most object (the one that’s visible). This has loads of advantages, like cheaper lighting and independence of geometry complexity of the scene, but has the huge drawback of not working with transparent objects (because multiple objects share the same pixel on the screen).
Another reason for having separate opaque and alpha objects is the shadowmaps. If we’d use alpha objects in the shadowmap rendering pass, that would make the alpha objects cast shadows, which would mean that something like a transparent window would prevent sunlight coming into a room (which isn’t what we usually want).
We already had an alpha-blending system, but it was a cumbersome beast that didn’t behave very nicely with the remaining system, so we upgraded this to this new one.
Continue reading →
In the depths the Earth, he was spawned
Son of corruption, and of evil ones
Not living, burning
Not eating, consuming
Breath of fire, flames of hate
Merciless eyes, unspoken fate
More than a slave, more than a master
Of Death he is caster
Ancient Lava Imp summoning, author unknown
Sorry about missing the Monday post, but job hasn’t let on and we haven’t had much time for Grey…
Anyway, Rincewind finished the Lava Imp model, and it looks really good (specially in motion)! The glow effect needs a bit of work, specially when the camera is zoomed out, but we’ll save that for the “polish” phase after we get all the gameplay good and ready.
On the tech side, we’ve been working on the new effect system, and it’s shaping up to give us lots of creative space to make nice special effects… I’ll post more on this when I complete it, since it’s still in too much flux.
More pics after the jump…
Continue reading →
Our jobs have been killers lately, so nothing much has been done lately…
Only Rincewind carried on with his work exploring sculpting, so here’s some screenshots of the results:
Love this one, it’s in-engine with just a funky texture as color map… But it actually doesn’t look all that bad… 
Continue reading →
Since the weekend wasn’t as productive as I’d wish, I give you: the Imp!
Work in progress, obviously enough…
The imp is the first creature that Grey gets to life-shape and control. He’s a minion of the Underworld, some sort of animal whose exposure to to the dark forces below has mutated and twisted him into a demon-like monster that likes to burn things as a hobby.
Continue reading →
Most of the work in a game takes place behind the scenes, and we don’t have anything to show for it… The internal systems are often neglected when one considers game development, but they’re crucial to get the system up and running in a timely fashion and without any problems…
And that’s what we’ve been doing lately: working on the game design (all boss fights are designed, albeit subject to lots of changes depending on gameplay tests), working on internal systems of the engine (started development on a new data-driven effect system, but only laid the groundwork yet, but more on this on another post), and some technical work on the models in terms of optimizing, etc.
So, nothing visible, hence no screenshot for this post…
Anyway, some comments on boss design: it’s very hard coming up with mechanics that mesh up nicely with the existing game framework, while not have been overused in the past by other games… Doing that while considering that we’re on building an episodic game, with limited content, while still catering for the human need of “rollercoasters” is a nightmare; fortunately, everyone pitched in with their own ideas on the boss fights, and so we’ve managed to build 5 boss fights that are quite different from each other (and some from everything I’ve seen in the past in other RPGs), that have multiple (theoretical) tactics to being overcome. Hopefully, we won’t have to change too much in the final version, because they’re quite interesting as they are (well, a father should be proud of his children!) 
One other part of boss design that’s hard is trying to keep looking at the fight from fresh angles, without being boxed by tactics that we came up with when we were thinking about that… We need to be able to think like our players, with multiple play styles; for example, what if the player likes going “imp overkill+zerg” on the boss? Is the possible still doable/too easy? And what if it is a tactical player that just positions few units and maximizes his control over them?
All of these keeps us on our toes, terrified that we forget one option… of course, that’s what playtesting will help us with, but even so we can miss something, detracting from the game experience for those players that feel that they should be able to overcome the challenge in a specific way, and the game’s “unfairness” is preventing them… Complicated stuff to balance out!
Anyway, next week hopefully we’ll have more stuff to put on the blog… 
Spent most of my Grey time in the weekend working on creature and boss design, and I can tell you: although it’s fun, it’s a lot of work.
First, we started by defining the player controlled characters. All the creatures have a “creature buff” that can be cast on all the friendly units (like an aura), that augments their capabilities. These are mutually exclusive, which means that the player has to select which aura fits his playing style/taste the better.
The creatures also have abilities they can cast, but they don’t get them at the same level (so that the player can discover something new throughout the game). These abilities will probably be augmented by the individual talent trees of the creatures.
Then, some of the abilities are available for the AI system (this means that the creature can make the decision to use specific abilities regardless of the user input), but others can only be used if triggered explicitly by the player (since they have limited use, or are expensive).
After completing this for the creatures, we started working on the enemy creatures:
We had to attribute a primary role (melee dps, caster dps, tank, healer, etc) and a set of abilities. Usually this set is very small, so that the AI isn’t too complex, and so that the player knows more or less what to expect from them. The though part here is to find abilities that make every enemy unique to a certain extent, to make the player change his play style throughout the game to overcome the challenges in a simpler fashion.
We had also to contemplate that the creatures have to scale with level, so we’d have to think in systems that would allow us to do that without just seeming a version of the initial mob with more health. Hopefully the implementation of the creatures will yield a more varied play experience (so that you can’t tackle a level 3 crazed zombie in the same way that you tackle a level 8 one).
Finally, the really fun part: boss encounters… We only designed the first boss encounter (the Lightkeeper), and looking at the initial draft and what we had after one hour of designing is astonishing; the two fights are completely different! Initially, it was a “kill it before it can kill you” kind of fight, but we felt that had too much of a random factor to it (some randomness is nice, too much and people get frustrated), so we started tweaking the fight mechanics so that we had a very unique fight (compared to the rest of the “trash mobs”); it slowly became an “add control/be aware of your environment” fight, which we believe works better in the type of game that we want Grey to be.
Of course, all of this is subject to change with the playtests, etc, but now we have a solid framework on which to build the rest of the technology and art…
In the next days, I hope we’ll finish defining the remaining boss fight (four more to go), and we can start thinking on actual quest design, instead of just thinking in terms of loose plotline threads.
We’re also looking into doing a sort of "project planning”, so that we can define milestones that will help us have a better grasp on the progress and estimate how long certain tasks are going to take.
