Breadth, then Depth

Game Design
One new edict: Breadth, then depth.
Basically, avoid getting stuck in paralysis analysis hell. I’m going to make a concerted effort to make things work only as much as I need them to. Once a component is established and has gone beyond the design stage, I can start implementing new features. Don’t wax your car if it hasn’t been put together yet!

Technical Design
I was pumped up to start coding today. The little breakthrough I had last night helped boost my hype levels way up, so I started working on an input component, which brought the hype back down to earth. This component will allow the game to read button presses, trigger pulls, stick moves, etc, from the gamepad, as well as determine if states have changed since the last Update() tick. Playing around with input brought about the need to draw some text on the screen, so I began on the Debug component too. Today is the first (of what I’m sure will be many) days where I will be shutting down with a project that fails to build.

I’ve been spending a lot of time reading about game design, here are some of the things I read today, number three will bring tears to your eyes!

  • An online book, Game Programming Patterns, has a informative chapter the explores some ways to decouple your game components.
  • This answer on stackoverflow that goes into why using the same texture is important when calling SpriteBatch is good. It makes me think about the right way to group sprite within spritesheets.
  • If you want to put all of those cores in your new Ryzen to use, Smart Thread Pools are a way you can do that.
  • The Red Blob Games blog has some great articles on various game programming topics.