I’m on vacation, but since I don’t have much access to technology (since I’m visiting neglected friends, etc), I haven’t had much time to work on Grey.
Anyway, my latest development was that I built a “formatted text” control…
The idea was to use some XML-based language (similar to HTML) and use it to describe text of different sizes, alignments, fonts, etc…
The first experiments were very successful:
This was achieved with:
<text background_color="0.2,0,0,1" font="CharacterTitleFont" text_scale="0.5" align_y="middle" align_x="right">
<format text_color="0xff00ff00">AaBbYyZz</format>
<format text_color="0xffffff">Test text 1,2,3,4, xyyz xpto bla bla bla alb alb alb alb alb alb bla</format>
<br/>
More <format align_y="top">t</format><format align_y="center">e</format><format align_y="bottom">x</format>t <format text_color="0xffffff00" text_scale="1.0">that</format>
spans more than one line\nX\n
Some more text
<image bank="test_gui" image="sel_circle"/>
And more teeeeeeeeeeeeeeeext
</text>
The formatting is all wacky because I wanted to experiment with the various tags and the robustness of the parsing engine…
Continue reading →
Although time hasn’t been abundant in these parts lately, I’ve managed to finish the new resource system with the dynamic update feature…
Now, I can change any resource file used by the SurgePlayer (this has to be registered in code, so I don’t use too much processor on this, and so it can be optimized out on release builds), and the game will automatically update to make use of those new resources…
The main use at this moment (and the main reason we implemented this) was to be able to prototype/tweak effects as fast as possible…
As I stated previously, the “frost bones” effect needed some work, since it looked fine while the skeleton was standing still, but it looked terrible when it was moving.
The objective of the effect was to make some skeletons look ‘colder’ (since they apply a debuff to player when they hit him; that debuff slows down casting/attack speed)… The end result wasn’t exactly what I wanted, but I think it will have to be enough for now, since I’ve lost enough time with it already…
I’ve done a narrated video, in which I tweak the parameters and watch the results… It was supposed to show the XML editor as well, but my capture application trashed the output video when it reached 4Gb in size, so I think I need a 64-bit upgrade on that. Anyway, I think it might be interesting for game developers to see how the process of making an effect go, although since it is completely unscripted, it’s not a tutorial or anything like that:
Although we haven’t been able to work on Grey for some time now, I haven’t stopped thinking about games…
First of all, I‘m delving into The Critical Path Project. It’s a collection of interviews with some of the world’s best known game designers, and there’s a lot of interesting stuff in there… One thing that got me thinking was the emphasis on originality and new concepts… Cool as it may sound, I’ve never been much of an “innovator” in my game designs; I tend to think about things in terms of evolution and not revolution, although I think it’s great some people think about that and make the great breakthroughs that gaming needs now and again…
For example, looking at Grey, it’s not a particularly original game… It has a series of concepts that I’d call new and original (but it might just be a case of me never hearing of any games using them), like the upkeep mechanism for the creatures, or the fact that the game’s tactics are focused on the creatures we call into being, instead of the main player character (which is common enough in RTS games, but in those cases there isn’t exactly a main player character), but the game is overall “innovation-free’”… it’s an evolution of games (a mixture between a RPG and a RTS)…
The reason for this behavior in me is that I like telling stories in an interactive setting, and gameplay innovation comes second for me; I just try to find established gameplay mechanics that fit the story I want to tell…
The main point here is: is gameplay originality the ultimate end-game for a game designer? Or is it just one of the development lines he can follow?
I don’t really have a good answer for this… Part of me thinks that I should strive to make something more original from a mechanics standpoint, while the other feels the story should carry old-mechanics, albeit it makes me feel less of a game designer…
Let me know your thoughts in the comments!
Back from Germany, although buried in work…
For the next weeks I won’t be able to put much work into Grey, so the technical side will be a bit delayed… Hopefully the artist will manage to keep busy and show some new stuff!
Anyway, just to let you all know we’re still alive!
Finally, after almost 57 hours of work, I’ve finished the refactoring of the resource system and adaptation of the SurgePlayer to use those changes!
It’s a bit frustrating to be honest, to put in so many hours in a single task and the end result is everything looking exactly the same, but internally the system now runs much better…
What I did was to change the whole way resources/assets are handled by Spellbook… Instead of having a pointer to the resource (like a mesh has pointers to materials, and materials have pointers to textures, etc), now I use resource references (a mesh has references to materials, and materials references to textures)… What this means in practical terms is that I know exactly how many objects reference a specific asset, besides having a level of indirection that will allow me in the near future to replace a resource without searching the whole system for pointers to the resource.
This allows for live updates, and in the long run will allow more complicated systems like caching and streaming worlds; a cool side effect is that it’s less likely to have crashes, since a resource only gets deleted from the system if no one is using it, which is great!
Finding who is using what is a bit more tricky, but it can probably be done in a simpler fashion as well (although very memory intensive, but might be good for debug purposes).
This change to the system entailed me changing about 700 source files of code, and a lot of debugging, specially in the “cleanup” tasks of the engine (which sapped about 10 hours of work by itself, I found a ton of places where in some circumstances the engine could crash because of missing resources).
Anyway, next week I’ll be away on work in Germany, and because of that there won’t be any updates to the blog (and probably no work done on the game as well, besides some design work), but afterwards I hope I find enough time to get the live update done, and finally sort out the “icy skeleton” effect using that same system, which will be pretty cool I guess!
Then, one more huge task I have absolutely no motivation to do, but has to be done: adapting these changes to the SurgeEd… Not looking forward for that one! 
I know, I know, we’ve been silent… But we’ve been working!
On my part, I’ve been refactoring the resource system, and the task is almost complete for Spellbook and the Surge Player… Still need to tweak some minor bugs (and stuff I’ve found that was wrong for years and years!), but it’s mostly done, with little performance impact… Now I still need to upgrade the SurgeEd to use the new resource system, but we should have complete dynamic resource update in 2 or 3 weeks (not sooner, since RealJob™ is been a killer lately, and I’m going away on a business trip for a week)…
Anyway, Rincewind has been working on the asset set for the city of Calabeth, and it was quite hard to get a good pipeline working for the type of city assets we wanted to build, mainly the roofs.
Below you can see the result of the work he did (extremely low poly end result, just three quads for the roof in the example below):
After the break, you can see an overview of the end process we’ve found to build seamless roof textures…
Continue reading →
The highway to hell is full of good intentions!
I wanted to focus on the development of the game itself, and I was creating a new enemy type (“Frost Touch”, a skeleton that slows down attacks when it hits). Visually, Frost Touch is different from the other skeletons because of a particle system:
The effect was looking pretty good in the editor, but when I added it to the game and the character started moving around, the effect became super-ugly, because it is a very subtle effect that takes some time to “change”. That meant that the creature would move away and the particle system would stay put for some time, breaking the illusion of “icyness”.
I started tweaking the effect, but it became painful pretty fast, since every change to the effect would make me reload the game… so I decided to add an auto-update feature to the engine… I could have gone with a quick and dirty solution on this, very special case, but I decided to tackle a huge task instead and rebuild the resource managing system.
The idea is to get rid of all pointers to assets/resources in the engine, so that if I want to change something, I just have to change in the resource manager and the system will react to it… Other additions (since I’m at it) is to add the groundwork for a caching/preloading system and other goodies.
Unfortunately, this implies changing about 1000 different files and classes, with all the problems that will probably come from that… There’s a series of behaviors that aren’t defined properly with this new system. For example, now I have an animation controller tied to an 3d object that makes it go up and down… If I change this object, it will get internally destroyed and replaced with another one, but since the animation controller is tied to the original object through the reference system, it will be destroyed as well, instead of just “pointing” to the new object…
I have some ideas on how to change this in an easy way that doesn’t make me break most of the architecture (since the reference system is so useful for other things), but this will be a big change in the system…
Afterwards, I hope I can prototype stuff pretty quick, changing textures, shaders, effects, etc, all on the fly without having to reload the game! It’s one of those changes that delay development to increase the speed at the end (at least, I certainly hope so… I’ve already put about 11 hours into this, and I’m about only 30% through)!
We haven’t had much time lately, been too tired after work to be productive.
Anyway, we’ve added effect instancing to the editor… It’s still not complete, but although the effects have to be authored “by hand” in XML, we can now create and use them in the editor:
That’s the frost bones effect, which is basically a particle system that spawns particles on the bones of the attached object and makes them slowly fall down. The idea is to use this for one of the early enemies (that doesn’t have a name yet, “Frost Touch” is the main candidate), which leaves a debuff on the creature he hits with his melee swipes. That debuff slows down the attack speed of those afflicted.
Continue reading →
There’s always regrets while coding, specially when we’re talking about a 10+ year codebase (with lots of refactoring, etc)… One of my main mistakes for ages was not to use matrix calculation. Of course, I used matrixes when it was time to deliver things to the graphics card, etc, but other than that, I ran away from them like a madman, because:
- they’re hard to debug,
- my linear algebra is terrible
- they’re terrible to interpolate and manipulate (except in very specific cases, more on that ahead)
- the dreaded gimbal lock problem
Thing is, matrixes are brilliant for hierarchic representation of data… and SurgeEd has plenty of that!
So, I’ve been converting (slowly) my engine to leverage matrixes, using them to describe composite transformations, but keeping my old system of vectors/quaternions to store the local transforms. So, each time I find something I can’t do using my normal system, I refactor another piece of Spellbook/SurgeEd to accommodate it.
A problem when doing this sort of thing is that algebraic spaces get confused easily… A matrix describes a local space, but the composition of matrixes eventually describes world space, and going from one to the other is an issue, specially because Spellbook was always used in a world-space only philosophy.
For example, the routines that compute the bounding box of an object return that bounding box in world space, but in most calculations nowadays, it’s better to use local space in most of it and just convert it in the end, if needed.
I should just bite the bullet and refactor the whole transformation system in the engine, but when you have about 200k lines of engine code+100k lines of editor and player code, it’s a though decision to make…
Anyway, been working in the innards of the editor and engine lately, trying to get some systems to run smoothly and add options to the artist. For example, now I’m implementing custom bounding boxes, so that the artist can just define a bounding box for the object, which is exceptionally useful for skinned meshes that have objects locked to mountpoints. Visibility culling is easier to implement this way, and faster; the only problem is that it is very “conservative”, leading some objects to be drawn even if they are off-screen, but considering the GPU/CPU tradeoff nowadays, it’s a small price to pay.
My bug list is currently huge (quick glance at it has more than 40 active bugs), but hopefully I’ll really tear into it the next few days, since I know where most of the problems are.
RealJob™ has been kicking my butt lately, and I’m waiting on the GUI work so I’ll be able to progress more in the development of the game itself; but none of these reasons has stopped me from work!
Lately, most of what I’ve been doing is backend system coding, stuff like refactoring the collision/intersection system, and the mountpoint system, which I also added support for in SurgeEd.
In case you’re wondering, refactoring is when you take an existing piece of code and you streamline, clean it up, organize it better and improve it without actually adding any new functionalities… I have this urge from time to time when I look at old systems in Spellbook.
In this case, it was the collision/intersection system, which was becoming too unwieldy in terms of organization and new feature addition. Mountpoint had to be reworked so they’d support objects with scaling in the mountpoints themselves (a sword in the hand of a big ogre has a different size than the same sword in the hand of a gnome or something).
Anyway, I still have some stuff to add to the editor that the artist requested; I also want to add support for “effects” in the editor, so that I can create the template for the “Frost Skeleton”, which is one of the earlier nasties we’ll find in Grey.
Hopefully next week I won’t be so tired of RealJob™ and I’ll manage to get more done when I get home than I could this week…
