The main thrust of this week’s work was gameplay prototyping. I spent the majority of my time prototyping gameplay – either by building new mechanics, tuning existing ones, or constructing small prototypes in the editor.

Some of the more interesting things I built:

I added support for attaching pieces of geometry to each other, so that I could make composite objects for use in puzzle designs. In the following video, I’ve attached a Crank (a new variation on my existing Switch object, which I’ll describe a bit later) to a moving platform, and tied the crank to the platform’s velocity so that you can use it to move the platform:

I also spent some time on the Assist mechanic, which allows the player to have abstract control over the inactive character by hitting a special button on the controller at appropriate times. Right now, it merely allows interaction with objects, but in the future, it will allow high-level orders (like ‘come here’ or ’stay there’) that will help guide the (currently unfinished) AI that controls the inactive character in order to keep it from getting left behind during platforming segments. In the following video, I demonstrate using the assist button to operate a crank with the inactive character while the active character makes his way past some spikes:

The culmination of my work this week was constructing a larger puzzle prototype that combines many of the smaller elements I’ve built previously. It’s a puzzle that utilizes the Assist mechanic along with many of the mechanics and technologies I’ve built so far and stresses many of the limits of my current engine. In the process of building it I had to fix numerous bugs and performance issues in my game code and ended up discovering some serious flaws in my collision detection code, which I’ll no doubt have to address in the coming weeks. Nonetheless, it was quite satisfying to see it take shape:

Finally trying it out made me realize that it was far more difficult than I anticipated, and that my UX needed significant improvement. I spent some time refining the puzzle and improving the game’s UI and was finally able to beat it myself:

Naturally, a lot of work still remains, both in the art, design, and technology departments. But it’s nice to finally be able to build a piece of content this large without running into any showstopper issues – all said, it took me about 45 minutes to construct and tune this puzzle in my editing tools. Not as fast as I’d like, but more than good enough to get started on enough content to fill a playable demo.

One of the more surprising technical hurdles this week was the discovery that SpriteBatch.Begin was accounting for over 10% of the CPU usage in my game. This turned out to be due to the fact that each game object was responsible for setting up its own render state, so I was beginning and ending an individual batch for every object in the level – over a hundred spikes, dozens of moving platforms and doors, and hundreds of tiles. I invested some time into writing code to automatically manage beginning and ending batches, so that objects would no longer need to explicitly call End in their Draw methods, only Begin.

Once I had that working it dropped off my profiles entirely, and my framerate climbed back up to where it was a few weeks ago. On one hand, it’s nice to be able to see such large performance gains from little effort, but on the other hand, I’m a little embarassed that I didn’t think about it earlier. It’s likely that in the future I’ll end up writing a RenderManager class of some sort to automatically handle sorting objects based on their material and other parameters so that I don’t end up having to send thousands of batches to the video card every frame.

I ran into numerous minor issues with my collision detection code this week, which has me considering ways to rework and improve my current approach. The worst was a bug that I discovered where if I placed an object at negative coordinates (on either the X or Y axes), it behaved differently in collision detection than if it was placed at positive coordinates. Instead of diving into the math to try and figure it out, I ended up just relocating all the objects in my test level so that they had positive coordinates, but I can’t put solving this one off for too long.

Later in the week a friend stopped by and I had him test the game out on my machine. Not only did he have some good feedback, but he found two bugs within a matter of minutes! Always nice to get fresh eyes on your design and see someone else try out what you’ve built. I’m looking forward to having things at the point where I can start handing out test versions for people to bang on.

Finally, a question for anybody who’s reading on a regular basis: The Gruedorf weekly progress format is becoming rather difficult to work with lately, so I’m considering changing my approach for this development log. I’d greatly appreciate it if you let me know via the comments section which topics interest you the most, and whether you’d be interested in seeing multiple shorter posts during the week focusing on single topics.