Spellcaster Studios

Make it happen…

Finished the patrol drone

Finished the patrol done today… Took me a bit longer than expected due to the enemy spawn, since I have to modify the pirate AI from the drone AI, which I didn’t remember to do…


Anyway, it works now and I can move on to the turret (which hopefully will be silly simple!)

Now listening to “After” by “Ihsahn”

Link of the Day: I’ve showed in the past a link to a modeling tool using VR, now how about a painting tool? This is very cool, at least from a “demo” perspective (they’re still pre-beta)

AI: Patrol Drone

Work today has to be cut short, something unexpected came up…

I’m in the middle of making the patrol drone AI, which is going rather well, just missing the “spawn enemies” behavior when we’re spotted:


Tomorrow I’ll wrap this up and maybe start the turret code (which should be very simple).

Link of the Day: This game looks drop-dead gorgeous! I really like this sort of minimalist aesthetic in texturing, with a goog lighting solution, it works really well and it’s kind of future proof (meaning this game will probably look as good in 5 years as it looks now, contrary to the “realistic” games which look terrible after 5 years)… I’m not sure how well will the voice-commands thing work, but I’m very curious about it!

More indoors behaviors

Today was very tiring to get the AI behavior just like I wanted when indoors…


That and the pull of “Warlords of Draenor” made it very hard to work! Smile

Anyway, I had to tweak, and tweak, and tweak, and a once little, simple, beautiful script becomes a tangled mess again because of fringe cases… I really need to figure out a better way to architect/structure AI code… It becomes messy very quickly (even if it isn’t as messy now as when I started, and it’s way more robust)… Probably some data-driven structures to encapsulate cause-and-effect (which is a bit how human beings work), plus some constructs to help out (for example, how long have we been in a certain state or conditional timers like “how long have we had no LOS on the enemy”?). When I go back to “Grey”, I’ll have to delve seriously into this, before I spend more time on the AI than I’ve already done.

Now listening to “Space Police – Defenders of the Crown” by “Edguy”

Link of the Day: This is an extremely elegant solution to the scripting language binding issues normally present on engines. The only drawback (that I can see) is the fact that it requires a very modern compiler to work: http://www.gamedev.net/page/resources/_/technical/general-programming/implementing-a-meta-system-in-c-r3905. Personally, I’m using a slightly different (and not so elegant) solution: I built an utility that scans the code files for some tags and exposes the methods I want (and I’m not exposing the variables themselves, besides through assessors, which can be generated automatically).

Indoor behaviors

Been working on the indoor behaviors… They’re slightly different than the outdoor behaviors, because they have to be constrained to the some indoor area/room.


Some stuff is going horribly wrong, although I can’t pinpoint it… For example, a lot of times, the enemies will run outside, instead of finding cover inside the base…

I think the problem is that I’m looking at the minimum distance that has no line of sight towards the aggressor, instead of looking at the path length; this means that sometimes is “closer” to go outside than around the next door, because I just account for linear distance.

The reason I’m doing this is so I don’t have to compute the path for all the “probe points”, but I don’t know if that’s possible at all to avoid. I could check LOS from the enemy to the probe, but that would skip some potentially good points (namely most of them, if the player was in a straight line with the enemy).

I’ll have to check the performance hit…

Now listening to “Zero Order” by “Re:aktor”

Link of the Day: Well, I’ve been playing WoW again, so I’ve spent too much time on sites such as this: http://www.icy-veins.com/

Ninja skills!

Today I mostly worked on the stealth mechanism…


So, the enemies with the “ninja skill” will hide from time to time, or when they receive a burst of damage. They can move or not while invisible, and they’re invulnerable while at it…

Now, only the “indoor” behaviors missing and most of the complex stuff is taken care of, and only the simpler behaviors are to be done. Now “World Of Warcraft”! Smile

Now listening to “Somewhere in Time” by “Iron Maiden”

Beam me up!

Teleportation is now working for any sentient AI… Only the corporate soldiers will have this capability, but for now I’m testing it on robots:


Stealth is next and I’m done with the basic components (except indoor navigation, which shouldn’t pose much of a problem)… Then it’s just the decision layer for all of the enemies and I’m done with the AI…

This one is already significantly better and more stable than the previous ones (of course, only extensive playtesting can really tell, but it looks good so far, except for some twitching sometimes).

Now listening to “In Paradisum” by “Symfonia”

Link of the Day: A couple of days ago, I linked the trailer for AC: Rogue… Now, how about a compilation of AC: Unity glitches?! Smile

Gameplay/Tech tweaks

Today I mostly worked on tweaking the targeting system of the game.

Gateway is a game that has a lot of shooting, so that has to be fun… The last thing we want is the player thinking “I was clicking on the enemy, why was the weapon missing?!”, even if it is 100% correct from a math point of view…

The problem is mainly the fact that we’re converting a 2d position (the mouse position) into a 3d one (a point in space). This is done by projecting a ray from the eye position through the mouse cursor and detecting where it collides with the ground. That gives us a 3d position. But if there’s an enemy in front, shouldn’t he be hit, like a player is “selecting” the enemy for shooting?

Of course, if we do this, the game becomes rather easy (especially in big enemies), so we need to make the player “hit” the enemy reasonably well with the cursor before we define it as the “target”… If this radius is too small, the player will have the feeling he’s not hitting because the game is failing hard, if it is too large it becomes too easy and a bit “sticky”…

So I tweaked, and tweaked, and tweaked to get what I feel is the right feeling, although this is one of those pieces of code that’s really debatable, since it depends on “feeling” and “intuition”…

Anyway, hopefully alpha and beta tests will give me more feedback on this…


Now listening to “Avantasia: The Metal Opera” by “Avantasia”

Link of the Day: YouTube’s 60 FPS mode was made for the demoscene:

Run, you fools: Part Deux

Finished the running behavior, fixing the fringe cases… The enemy will now effectively retreat from battle until it has restored his shield, or until it gets his courage back (stupid robots!).


Robots won’t have this behavior, though, it’s just easier to test here…

Next step, teleporting behavior!

Now listening to “Doombound” by “Battlelore”

Link of the Day: Although I’m hearing terrible stuff about it on reviews, I can’t help but want to play this:

At least AC: Unity seems to be a worse mess and I don’t feel like playing it much (no boats!)

Run, you fools!

Some more work on the AI, but not much since “World of Warcraft: Warlords of Draenor” is consuming a lot of my time… Smile

Anyway, worked on the “run” behavior… It doesn’t work how’s it supposed to most of the time, but it’s getting there…


The scorch mark shows what happens when the AI doesn’t run… Smile

Since I started with the most complex AIs (robots, pirates, ninjas), the rest should be a breeze… At least I hope so, I want to get rid of this refactoring before the end of this week! Smile

Now listening to “Reign of Light” by “Samael”

Link of the Day: Microsoft R&D comes up with some amazing stuff sometimes… This is one of those cases! I can imagine a game around this tech: http://msrvideo.vo.msecnd.net/rmcvideos/230533/230533.mp4

More AI work

Today I spent a lot of time rebuilding the AI system for the game… It’s a bit more manageable that before, but the technical solution still looks “sloppy”, to be honest…

I think the only good solution is to build some sort of visual language for the top level decisions, with the low-level part being done either in the code or scripting… The idea is that you could at any moment in time check where the system was, what state was running, etc… That’s maybe a good idea for the Spellbook! Smile

Anyway, I got basic behaviors working!


While it already behaves better than the previous version (less indecisions, better positioning), it still has some borderline behaviors, a nervousness to the behaviors that look terrible…

Anyway, it’s good progress!

Now listening to “Unarmed” by “Helloween”

Link of the Day: Here’s a nice article about future/modern engine architectures… I thought it was an interesting read, and can’t wait for the future articles on this series: http://molecularmusings.wordpress.com/2014/11/06/stateless-layered-multi-threaded-rendering-part-1/