Game Dev Log #3 (6/18): Player and Camera Movement

Another sprint has been finished, and it is once again time to a dev log.

Our last sprint focused on drawing our maze using only two different wall tiles.

In this sprint we have added player and camera movement, removed an annoying memory bug and also improved the frame rate of the game.

Player and Camera movement

Adding player movement was super easy, because we had already implemented a input handler using the Command Pattern.

The game is going to be turn-based in the end so the player moves one ’tile’ at the time.

Next up was setting up the camera movement. A key part of the game is that the maze is divided into smaller ‘chunks’ and that you are only able to see the chunk the player is currently in.

This means that the camera does not move around all the time but only when the player moves out of the current chunk and into a new.

We use this camera model to increase the puzzle feel of the game.

Still need a collision system though 😉

Improving frame rate

The game is developed on both OS X, Windows 7 + 10 and Ubuntu. And we always make sure that the game always works in all four.

On OS X and Ubuntu we write code in Emacs and compile the code using a makefile. On Windows however, we use Visual Studio.

In this sprint we first found that the game was surprisingly slow on our Windows 7 machine. This is also our oldest and slowest laptop, so I first tried to make different small optimizations to reduce the problem.

One thing I did was to move smaller things from the CPU into the vertex shader. This first introduced some minor visual bugs as seen below. I’m still not sure why it added a single extra black voxel for each voxel ’tile’.

But it didn’t really fix our frame rate problem.

I then booted the game up on our Windows 10 PC and found that the game was also really slow here. This was really surprising since this is by far our most powerful PC. At the same time it ran perfectly smooth on the same computer booted up in Ubuntu and on our MacBook Pro.

After a lot of wondering and googling it turned out that our problem was not within the game. The problem came from using debug mode in Visual Studio.

In release mode the game runs smoothly. However,  the debug mode can really slow down your application if you use C++ and the Standard Template Library (STL).

This might be fine in a normal business application, but not in a game which constantly updates.

Voxel robot bug

Finally I also created a new little voxel model. A voxel robot bug. The light blue on the back is supposed to be its energy storage. My plan is do implement a bloom effect in the rendering engine to emphasize this.

Next up is adding collision detection, a goal chest and measuring the time from the player enters the maze to the chest is found 🙂