Post news RSS Turnover - Progress Report for 1/6 - Sprite & Engine Work

Sprite improvements, cut scene improvements, and engine work are detailed in this progress update for Turnover.

Posted by on


Back from New Year break. I hope everyone had a safe and happy holiday. Let’s get 2015 started!

More Sprite Improvements


I’ve been adding shading to the character sprites to add some depth, so that their palette isn’t as flat. Look at the shading on the Sentinel’s hat above.

I also added some lighting to each sprite, taking into account for gun fire. Here’s a muzzle flash light effect on the Sentinel’s body:


I think the Security Turret may be a better example. Here is the previously turret animation when firing:


Here’s the new animation, below. Notice the proper flash on the body when it fires. Lately, I’ve been reworking a number of sprites to cover details like this.


So you can see it in comparison with the old one, here is the new muzzle flash sprite. Not as square now.


Cut Scenes

I’ve been putting some time into smoothing out cut scenes in game. I’ve coded in much better support for animations and transitions.

To keep with the sprite improvements, I added a little shading to Clea’s cut scene sprite, just to give a better sense of lighting. Here’s a before and after.


New Collision System

I recently rewrote Turnover’s collision system to use a proper QuadTree approach.

The system I previously wrote used a spatial hashing system. It did lower the amount of collision calculations each tick, but it was still pretty inefficient. Collision was the biggest time eater in my game loop. I knew that I would eventually have to replace it with something better.

When I wrote the first version of the QuadTree system, everything worked alright. I was disappointed to notice that tick time was not markedly reduced. Since I just “plugged” the QuadTree work it into my engine, I knew it wasn’t very tailored for the specifics.

The first problem I encountered was that large entities were not checking collision with the entities in every leaf they inhabited. In a QuadTree, you usually determine which “leaf” an entity is in by their general position. This caused a problem when a large entity encompassed many leaves, not just snuggled in single point position within a tiny leaf.

So, instead of using an entity’s position to drill down which sub-tree he would check collision in, I made the entity check all the sub-leaves they collide with, not just position into. It is a little more expensive, but it is more accurate. This fixed the problem with large entities.

The next thing I did was separated static entities from moving entities within the tree. When I initially loaded entities each tick into the tree, I was pulling and pushing ones whose position never changed, which was just wasting time. So, I rewrote my manager system to load static entities (walls) into the tree at level load and to leave them there. From there, I only update the moving entities (characters, bullets, etc…) in the tree each tick. This had a huge impact in improving performance.

So, what was the end effect? About a 20%+ performance gain. The system still needs some fine tuning, but for a few days work, I’m very happy.

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.