4000 Pounds

Long time since I’ve done a status update.  Sorry about that.  I took an extended vacation in Hyrule, and since I’ve been back to work on the game, I’ve spent most of my effort on getting the game ported to iOS, so I didn’t really have much to report.

In any case, I’m happy to say that it’s finally working!  A Park And Pigeons now runs in a mobile environment using SDL and OpenGL ES.  There are, of course, a handful of bugs that were introduced in the process of porting the game (shadows aren’t working, depth maps aren’t working, the game crashes occasionally), but I’ll be working on those and hopefully some art assets this next week.

Here is a preview of the game running on my iPhone:

I’m going to try to get back in the habit of posting on this blog more frequently.  So check back next week!

My ideal weekend update involves putting a gameplay sample out across social media (specifically Twitter, Facebook, and Reddit) tagged as #screenshotsaturday.  The Reddit post includes a short write-up of what I did during the week.  I also write an update for this dev blog which has mostly the same information, which goes out on Twitter and Facebook.

Some weekends though, I just don’t have the time or energy to do all of that, so I end up just doing the Twitter/Facebook thing and calling it good.  Or I might also do Reddit.  Or the dev blog.  In any case, this is one of those weeks, but since it’s been so long since I last did one of these here, I thought I should, especially since something cool happened last weekend.

Before I do the update – last weekend I submitted A Park And Pigeons to IndieCade 2017.  For those who don’t know, IndieCade is an independent games festival, basically the video game industry’s Sundance.  Every year, thousands of developers submit games that are reviewed by a jury, which chooses games to showcase at the festival, and games for the festival’s award ceremony.

It was a lot of work getting the game ready for submission.  I wanted to have a stable build, running in a stable environment, with easy-to-use controls (i.e. gamepad support).  Plus there were still some glaringly obvious bugs with the game that I needed to get cleared up.  So I spend the last several weeks getting the game into some sort of semi-polished form – the best I could get, since it’s not a complete game yet.

In any case, here’s my status update for this week:

• I sort of took the week off from working on the game, to reset after cramming for the IndieCade submission.  Still, I did go in and clean up most of the changes that resulted from cramming, and committed what I wanted to keep to source control.
• I also started working on some new artwork for the game.  That’ll probably be next week’s update.

Here’s the video for the week:

See you next time!

This week I worked on two main areas:

1. Lighting: Previously, all of my lighting was hardcoded in the method that renders the scene.  Now it’s all hardcoded in a separate class.  That’s one more step to making lights configurable, as the game will eventually have multiple parks to choose from.
   Also with the lights, instead of moving them with each wave, now the lights stay the same for each cycle.  At the end of the crowded wave, when the cycle starts over, the lighting shifts to the next phase.
2. Rendering: I added vertex array objects for all the sprites, which gives me a small performance boost.  I still notice some slowness on the crowded wave (mostly on my laptop).  There are a couple more ideas I have for boosting performance, maybe I’ll write up a more detailed post later this week.

And for those of you who just tuned in to see the sample:

You realize you can view these weekly samples on the 4000 Pounds Twitter and Facebook pages, right?

This week I worked on a few different sub-projects for my game.  Lately, the things I’m working on are a little bit of a struggle, but I’m keeping at it:

• Sound!  I finally added sound effects to the game.  It’s been… a while since I last mentioned them.  But the game has sound now.
  Like most other things, what I have are just placeholders for now.  Implementation was fairly easy – the hard part is trying to find good pigeon sounds.  Have to keep looking.
• Player controls:  I am working on revising the controls, taking out some of the player’s special moves.  I know that sounds like it sucks, but while the “flying” and “long-dash” abilities were well-intentioned, as I’ve tested the game I found them to be more annoying than anything.  Especially when I’d do them by accident.  Working out some other special moves though.
• Progress Screen: I’m working on adding a screen to show the player’s high score, achievements, unlocked things, whatever.

Here’s this week’s sample, with sounds:

Enjoy!

Okay, here’s the update.

I spent this week mostly working on fixing bugs:

• Enemy pigeon AI states were being preserved between successive pigeons – now each AI state resets when the pigeon spawns.
• Incoming player sometimes had wonky physics – now it works like it’s supposed to.
• Player has a little better control over where they will land after being scared off.

I also hooked up my very-simplistic profiler and did some quick performance analysis.  I’m not having a lot of performance issues, but I do notice it getting slower as the number of birds increases.  Here’s something I found that seems interesting:

Each frame takes three passes through the entities (birds, food, dogs, feathers):

1. First, to update.
2. Then, to render shadows.
3. Finally, it renders the surface and then takes a final pass to render the actual sprites.

Rendering is certainly the biggest cost here.  Still, I see a concerning amount of time spent on just the update pass, and I’m not finding anything peculiar happening in it.  So I think a large enough chunk of time is spent traversing the entity lists, that I’ll likely see a noticeable improvement if I collapse all of it into a single pass.  We’ll find out soon, I hope.

Here’s a gameplay sample for this week:

Check back next week!