Spellcaster Studios

Make it happen…

Battle stations!

Don’t want to talk too much about what I’m doing at this moment (it’s an important moment in the story, and I don’t want to spoil it)…

Let’s just say that Steve and the Skydancer go into battle stations:

screen163

Red alarm light always gives some urgency to the scene, especially if I can find a good alarm sound to go with it (I’ve not worked on sound as much as I should).

Now listening to “Kartika” by “The Eternal”

Link of the Day: Been looking forward to this one for some time now, and it launches in a week, yay! Check out the trailer and give them a follow on Twitter (@robotality):

Playthrough, Part IX

As usual on Mondays, not much time/energy to work on the game, so I started on the next cutscene that leads to a new phase in the game…

Without giving too much away, I needed a ship:

screen162

And I needed it to be bigger than Skydancer, but the map doesn’t have enough space for it… Will have to use some sort of trick so that the enemy ship looks menacing without being any bigger than the player ship… Probably will have to work with camera angles (or scaling and hope for the best! Smile).

Link of the Day: This is some masterful animation, really impressive stuff, done by just two guys! Can’t wait for the movie (in 2016!):

Playthrough, Part VIII

A bit more work on the storyline… Some new cutscenes, and a big boss fight (grenades and pulse gun, which wasn’t working on the enemies). It’s a quite hard fight, if you only have the gun, which is my case…

I fear the game will need a bit more difficulty… I’m more than halfway through the storyline, and I haven’t bought any upgrades yet! Don’t know if I should make the enemies hit harder, or just give them more health…

screen161

Also added a piece of code that links enemies together (so if you attack one, all of them in a vicinity will come running)… Just need to tweak the value a bit…

Link of the Day: Another game that looks pretty cool… It’s a mixture of shooter and point’n’click adventure, all side scrolling… Indies are really doing cool stuff, I feel very jealous!

Playthrough, Part VII

Continuing the path through the game, I had to build one more temple…

First problem I had: because of the procedural generation and random factor, the temple was spawning in a cave planet, which meant that all was dark, so any cutscene would have to account for the possibility of this happen, which makes matters much harder to deal with…

To sort this out, I decided to do the same as the previous temple: have an entrance in the planet, and then build the whole temple separately… This worked very well!

Then, after almost two hours painstakingly building the temple, the editor crashed when I tried saving it! That’s the problem of half-assed tools… :\ Here’s a shot of it before it crashed:

screen159

After I stopped yelling, I started all over again and built the new temple (almost the same as the one before)… and ran into the next problem: scenario. Contrary to the previous temple, we’re not in the dark, so if the camera pans, the player will expect to see some scenario around the temple… I have a few ideas on how to solve this (using the background sub-system to solve it), but for now, I just erected walls around the temple (which kind of screw the camera a bit…).

screen160

Finished the presentation cutscene as well, so I just need to spawn the bosses… I want this fight to be against two big guys, so I need to add a system to the game in which they can call to each other (so the player won’t fight one at a time)…

Finally, also modified the gun effect to leverage the line code I built the day before yesterday…

screen158

I think it looks way better than before…

Now listening to “Clockwork Angels” by “Rush”

Link of the Day: Japan is known by it’s weird TV commercials and shows… Japan in the 70s was apparently even worse: https://www.youtube.com/watch?feature=player_detailpage&v=eak26ohx1Y8

Playthrough, Part VI

Today I carried on with the storyline development, but I hit a snag pretty fast…

When I started to develop the grenades, the idea was to have a boss enemy that had the machine gun and the flashbang grenade, and to alternate between them…

The problem was the way I was making the firing decisions on the AI.

Basically, every enemy had a “cycle time” for melee and ranged weapons. The weapon could then be queried to see if it should/could fire at any point in time. All weapons had such a function… This worked fine for a single ranged and single melee weapon, but when you have two ranged weapon, it doesn’t anymore.

For example, imagine you have a cycle time of 5 seconds for the machine gun and 10 seconds for the grenade, and that the grenade should fire at the end of the 10 second period, and the machine gun during the first half second of the 5 second cycle.

So, the game would decide the machine gun should fire (so it would become the active weapon), and the the cycle would end at the 5-second mark, so it would never reach the end of the 10-second cycle, which made the grenades never fire!

Sorting this one was simple (although a lot of work): I transferred the tracking of the cycle times to each weapon, so both would be kept tracked individually.

But then I hit another problem… Imagine the machine gun has a 5 second cycle, and that it would fire for the first 1.5 second. And you have the grenade with a 6 second cycle, and it would fire when it passed the 5.5 second mark.

In this case, what would happen is that the weapon selected was the machine gun, it would start to fire (so no new weapon decision was made), and then when the firing stopped (at the 6.5s mark), it would see if it could fire the grenade… But the grenade only fires at the 5.5 mark!

After a lot of going back and forth, I decided to change the way the AIs work. They now try to fire all the weapons, so they can fire the grenade while firing the machine gun. The only source of problems is the range of different weapons, but for that I always take the longest range weapon (so the enemy is safer).

After that, I could assemble the new cutscene, but I kind of forgot that I had to keep the player/enemy in the room where the showdown took place, and that took a whole bunch of code so I could “close” the doors on the lair:

screen157

Each time I think “now I just have to fix bugs and add content to be able to get to the end of the game”, I find one million small things that have to be fixed and tweaked, but hopefully it’s all to make a better game…

I won’t even comment in the amount of ideas that are on the drawer for a possible sequel/offshoot!

Now listening to “Inhuman Rampage” by “Dragonforce”

Link of the Day: This has to be one of the funniest things I’ve found on the net lately: https://www.youtube.com/watch?feature=player_embedded&v=W8X5ESeeHds

Electrifying!

Today I finished the grenades, including the shock grenade… For that, I had to create a new electricity effect! Was a bit hard fine-tuning it (one of the reasons I’m a terrible artist is that I’m very lazy!), but it was well worth it:

screen154

It looks really cool in movement (need to start making videos and GIFs with the effects).

This effect is rather simple… A line is drawn between two positions, but that line is “broken” in several segments, to which I apply some noise. Since the noise component changes every frame, it seems to shiver. The hardest part was making a “line-drawing” system. So far, I’ve been using simple line primitives to make most of the effects (weapons, etc), but I was never happy with it, so I just added a “volumetric line”, which has a width and can have a texture applied to it, which leads to this effect you see. Basically I build a quad from the line, using the cross-product between the “camera to segment” vector and the line direction to make something perpendicular to the line direction and the camera, which makes the width more or less constant.

The final part of the effect is the fact that the lines appear very fast (less than 50 ms) but take longer to fade out (300 ms), which simulates the persistence of vision we experience when looking at electrical surges like lightning.

Since I had this effect up and running, I decided to expand it to other uses, like the electrocannon.

It used to look like this:

screen155

Which is quite ugly, but with the new volumetric lines, it looks like this:

screen156

Way better, I think… I think it still needs some tweaking, but I’ll leave it for now…

Also took the time to integrate the new bat sprites I got from the artist:

screen153

Think I’ll have to increase the size of the bats to really make it pop…

Now listening to “The Damnation Game” by “Symphony X”

Link of the Day: This game looks rather cool, and it’s done by a portuguese development team, so spread the word! The trailer is really good, and the game seems very much my cup of tea: https://www.youtube.com/watch?feature=player_embedded&v=1orqZeUbC_4

Kaboom!

Worked on the grenades today. Finished the explosive grenade, and got the flashbang and stun grenades working properly, just missing the shock grenade (it’s like a stun grenade but for electronics). And even that’s only missing the special effect, the logic is already there…

screen151

The flashbang does a fog effect around the player (or blinds the enemies to the player, if it’s the player that shot it). I still have some game design decisions to do about the duration of the flashbang and if our own flashbangs should affect us or not.

screen152

The stun grenade is also pretty neat…

The only problem at the moment is the fact that they are difficult to use… they take two seconds blowing up, which negates some of the usefulness… One possibility is to detonate on impact (easy to implement). The other is tweaking the speeds so that they detonate earlier.

Tomorrow I’ll finish the grenades and start the first big showdown of the game!

Now listening to “Trust Your Soul” by “Sunrise”

Link of the Day: I don’t know if this game will be any good or not, but I really like the spaceship construction system… I wish I could see the different pieces, would be cool to see what can be generated procedurally! https://www.youtube.com/watch?v=EjX-IhFse-o

Grenades!

Today I started by adding some stars to the background of the asteroid… In the process, I found a bug… Can you see if you can spot it?

screen147

And this is fixed:

screen148

Very hard to detect, unless it was moving (you can see above the stars!)…

There was a problem with the ceiling UVs, which would in some cases form a discontinuity, which would become very noticeable in movement or when you walk on top of it… Took me a while to track down the cause as well, which was very annoying because I wanted to introduce some new stuff to the game: GRENADES!

For one of the bosses, I wanted to do something different from the usual shooting/strafing… We decided on flashbang grenades… then I thought, why not add multiple types of grenades (only the detonation effect is different), and give them to the player as well?!

screen149

Since I don’t have art for it yet (neither in the game window, or the UI), I’m just using a black square for now… The grenade launches so it passes the cursor, and detonates after a bit. I only had time to put in the exploding grenade:

screen150

It took me a while to get the equations right (had to remember the projectile equations from physics), and the collision with the environment (is not good enough to know I’ve hit something, I need to know in which face I did so the grenades bounce correctly).

The end result is quite pleasant… Tomorrow I’ll probably finish up the exploding grenade, and maybe the stun grenade… After that, the shock and the flashbang…

Link of the Day: This is something really awesome… I really love cross-media stuff, and this one is a match made in heaven: symphonic metal and games! http://www.polygon.com/2014/7/9/5883623/karamaflow-rock-opera

Playthrough, Part V

Today I didn’t have much time for game development, so I just built the cutscene for when the player finds the the first pirate lair. Was a bit tricky to get right, mostly because I was uninspired… The text flowed all right, but the camera angles were tricky, specially because the pirate lair is not very interesting from the outside.

Still missing some stars for the background as well, the blackness seems wrong…

screen147

Link of the Day: Graphics in racing games are getting extremely impressive… a lot of times, I’m not sure if I’m looking at a screenshot or a photo! Case in point, the weather system in Drive Club is really impressive: http://www.polygon.com/2014/7/8/5880601/driveclub-videos-weather-system-ps4

Optimizing

Let me tell you a story…

As I said yesterday, I felt a real drop in performance with the pirate lair, and I couldn’t figure out what was the issue.

The normal course of action (if you don’t have a decent profiler or are too lazy to find a free one) is to shut down pieces of code and see what happens.

First I tried the expected culprits: AI and rendering… no big changes there.

Then I started turning off different types of enemies. First all of them (which boosted the frame rate significantly), then I turned them on, one by one… Was expecting for the culprit to be the pirates, but those didn’t affect the smoothness that much. The only difference I could discern was with the laser turrets!

I looked at the turret code and couldn’t find anything, so I started doubting the problem was in the turrets… “It’s my perception of smoothness”, I thought…

So I decided to bite the bullet, and following the old saying “you can only control what you can measure”, I built a simple profiler in my framework… It’s actually a pretty nice one for simple measurements, I’m pretty happy about it.

The way it works is by creating “profiling points”. So at the start of each frame, I reset the counters, and then I add to them whatever I’m trying to measure. So I can create a “Enemies” measurement, and when I animate them, it will add the time to that counter. Then I can go deeper and deeper, trying to figure out what is wrong, all of that just by enclosing what I want to profile in something like this:

start_profile_block(12,"Items");
auto it=_items.begin();
while (it!=_items.end())
{
    (*it)->anim(t);

    ++it;
}
end_profile_block();

This will create a profile point called “Items”, with ID=12. I can do this without an ID, just by name, but that will impact the performance more, since it will require a lookup (quite a fast one, though, by using const char* and do the no-no comparison == on it. I’m comparing pointers, but it works while I use literals and not actual strings).

After I ran it, there it was: the turret was indeed responsible for about 24 ms of a 26 ms frame time! So, my perception wasn’t wrong, but it’s still weird… The turret does very little compared to most other stuff in the game. It almost doesn’t have AI, it doesn’t move…

So  I added some more points to it, and found out the problem was in animating the turret weapon… The turret has two laser cannons, and animating them was taking almost 24 ms! Looking at the animation code for the laser cannon, the only thing it was doing was getting a pointer to a rendering mesh, writing all the data necessary to render the shots (which were zero at this point, since it wasn’t shooting), and then closing the mesh so it was ready for rendering (with zero vertex!). Deeper profiling, I narrowed it down to closing the mesh…

And there I found he real culprit, a couple of pieces of code that are necessary in some minor circumstances, but mostly should be kept off:

  • When I close a mesh, I was computing the AABB (axis-aligned bounding box) of it… But, I hear you say, how long can it take to process zero vertex?! Well, it turns out it wasn’t processing zero vertex, but the number of vertex that were pre-allocated. On the laser cannon (and most of the other weapons), I was pre-allocating a mesh with 2000 vertex (so I don’t have to do resizes), but only sending to the video card the ones that actually had to be rendered (so it was alright from a rendering perspective, no extra weight except the memory spent)… But when computing the AABB, I was scanning all the 2000 vertex! And I was not even using the AABB! Multiply these 2000 vertex by two laser cannons per turret, and multiply that by 5 cannons present on this pirate lair… That’s 20000 useless vertex being traversed to compute a completely invalid AABB! This also happened in all of the other line rendered weapons, with the difference that I wasn’t using so many pre-allocated vertex (that’s why I didn’t detect this sooner!). I added a flag on closing the mesh that allow me to specify if the AABB should be computed or not (a lot of cases I don’t need it, it’s more expensive to check for the AABB of a model to see if I should draw it than to send it over to the video card and draw it even if it’s not visible!). That shaved off about 3/4 of the performance hit.
  • I was keeping a copy of the vertex data in RAM when the vertex buffer was dynamic, so I could update it and sent it again. For that, when I closed the mesh, if it was dynamic I was allocating a memory buffer and copying the data from the vertex buffer to the RAM buffer. There’s a lot of stuff wrong with this: one is that I was keeping data that I‘m not using: In most cases, I’m rebuilding the vertex buffer from scratch. The other was that I was copying the whole 2000 vertex, instead of just the ones that are actually “alive”". Removing this copy (or more precisely, having a flag in the Mesh constructor telling me if I should keep the data or not) solved all of my performance issues, not only the ones I noticed, but even in the rest of the game!

So, it was an excellent use of 3 hours of work. Below you can see the output of the profiler after I did all the changes:

screen146

Before, the “Anim” point was at about 34 ms, the “Turret” point was at about 24 ms, the “Turret::Weapon::Finish” point was also at 24 ms.

Fixing this not only dropped down the time for the Turret, it moved the total “Anim” time from 34 ms to only 1 ms… So I had about 33 ms per frame being wasted on unused updates on the AABB and the RAM buffer!

This was present in all of the game, just became more noticeable on the pirate lair…

The profiler I’ve built was a very useful tool which I will without a doubt use again in the future. It allows me to do something that I normally couldn’t do with my “hack” profilers: I can treat stuff that happens in different times (and are not sequential in code) as if they’re just one element. For example, it would be possible to put all the rendering and animation of the enemies in a single point “Enemies”, to have a better view on where I’m spending my time.

With some simple work, I can even make this hierarchical (mostly for presentation purposes).

All in all, excellent work day!

Link of the Day: This is an amazing homage to Wing Commander… It’s been in development for some time now, but it strikes a really neat balance between the old-time graphics (even the clunky rotation and low-res texture work, which were probably more work than making it state-of-the-art) and a modern look and feel in what matters (interfaces, for example, or additional special effects). Well worth a play: http://www.wingsofstnazaire.com/