• Register
Post news RSS Turnover - Progress Report: Forward Momentum

A progress report on the development of the stealth game, Turnover. This week: decoration, color coded security systems, and some code refactoring.

Posted by on

Time for another update on Turnover.

Decorating & Art

I’ve been spending some time decorating the “finished” levels. A good amount of time is being spent creating new sprites to put into the world. I began Turnover having no experience with art, and I think I’m at a level now where things are looking pretty decent.

Undecorated vs Decoration start

So far, I’m have 11 worlds started and 8 decorated decently. Now that I have been tighten up and locking down the finished versions of enemies, the pace of level work should start picking up. I’ve learned that I handle development better if I work on level in chunks of 2 or 3. If I get too far behind on decorating and game idea experimentation, I spend too much time playing catch up when I’m ready to move forward. Lesson learned.

Additions

In the game world, I’ve been putting in little additions here and there to aid the player and give the whole thing some visual cohesion.

Color Coded Security Systems

Each Security System object now has a color coded glow to help the player know what Security Server controls what Security Subsystem. The game could be a little confusing trying to figure out what controls what, so this should help out.

Patrolling enemies also all have indicators to let the player know if they were heard or spotted, and whether or not a recruited NPC needs to stay alive to complete a floor escape.

Code Refactoring

Although the engine for Turnover is fairly complete, I find myself going back and refactoring code. In the heat of coding, I’m focused on just getting things working so I can move on to another task. So, when I go back and rewrite things, it will be to enforce a “best practice” or to correct something I overlooked. Optimization will come last, so I’m not worrying about that at this stage.

For example, my code relies on smart pointers to help with memory management. I use shared_ptrs since I need to assign around important object subsystems or pooled entities. Recently, I caught myself using shared_ptrs when passing them around in situations where I wasn’t assigning them. So, I ended up rewriting those instances to use raw pointers with .get() to avoid the internal reference count on a new copy/destroy. I want to be a better coder, so If I catch myself screwing up, I like to fix it and get in the habit of using the better code.

So…

  • Playing catch up on level work. 3 levels to decorate and a few more enemy experiments to finalize before I can continue level work.
  • No more optimizing until there it is time to optimize, or a game breaker rears its ugly head,
  • Been making steps towards getting a Linux build up and running. Still a decent amount of work to do on that front.
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.