I managed to get the player character responding to user input, including basic sprite animation, in reasonably short order! The screen locks its view on the player while moving. The grass graphic is temporary here -- it was one of the grass images from The Garden of Eating. ?

While getting this working seemed more involved than I thought it might be, it somehow took less time to get here than I thought it might.

One mistake I made while developing The Garden of Eating was the timing on the game loop. Each iteration in the loop, I had it process user input, update the game state, and render the screen. I checked how much time this took, and told it to sleep for the rest of the 1/60th of a second. I incorrectly assumed that this would make the game run at exactly 60 frames per second, while ensuring the process didn't use up all the CPU. It seemed to work fine during gameplay, but the flaw in this thinking revealed itself when processing the story mode's cutscenes. Each cutscene had a separate audio track, and the video kept drifting out of sync. I fixed the issue during cutscene playback, but not during gameplay.

So for The Colon Case, I decided to handle the game loop a little bit differently. I'll be keeping a game clock, and passing this in as a parameter when updating the game state and rendering the screen. Anytime a sprite animation is supposed to start, I'll record its timestamp. The renderer will then be able to compare the sprite animation's start time against the game clock, in order to pick the correct sprite frame. So far, this technique seems to be working just fine.

One issue I encountered was a "shimmering" effect when the map scrolls during movement, and the camera view is pulled out further than what you see in the above screenshot. I believe this was caused by the scaling down of the grass texture. SFML provides a generateMipmap function on textures, and this seems to have solved these visual artifacts.