No Small Steps

I worked mostly on sorting out the initial component interfaces that I talked about yesterday. Towards the end of the day I made a short recording of the prototype playing a sound and displaying a pressed button. We makin’ all kinds ‘a games.

LOUD

 

Input, Innnnnput

Part One
Today, I’m working on the Input component. I need to track previous state, current state, and allow for comparison between the two. The way the game pad works, is that a button us pressed, or it isn’t. There are no events for ‘button pressed’ or ‘button released’, so you need to compare the current state of the button to the previous state. I hooked that up, then tied the A button to a new SoundEffects class, and now the protoype plays a sound when you press the A button.

Part Two
I tried to be as hip as possible and went to a coffee shop to finish designing the base component system. I drank a big coffee, wrote in my notebook, and stared thoughfully out the window for about an hour. I want to get the component system as right as possible so it doesn’t cause me pain later on. I’m also trying to stick to edict #6 by coding what I need, and avoiding the urge to look ahead to every scenario that may pop up. There’s a balance there between too much and not enough. I’m still trying to find it.

Part Three
Once I started messing with the controller input, I realized I was going to need some kind of debug display to show controller button states. I drew a couple drafts and came up with something I kind of like, then found a nice controller button sprite sheet, and started working on the new DebugController class. Here is the sketch I’m working from. The outside rectangles at the top are the triggers and the inside ones are the shoulder buttons. The three circles in the bottom middle are the View, Xbox, and Menu buttons.

A sketch of the input debug component

 

A Day Off

Today is a scheduled off day for Element work, but I wanted mention that I’m bouncing around some names for the game. I haven’t thought of any good ones! I really don’t even like the code name ‘Element,’ so I’m going to change that eventually. Also, this site has moved to nvn.io and has been redesigned.

 

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.
 

River City Ransom

Game Design
I gave the weekly state of the game presentation to my supporter.

Technical Design
There is a great post on stackoverflow about general game architecture that I came across today. It helped me understand how game objects are tracked and made me think about interfaces as they relate to games, and how I should be using them. It was a bit of an ‘Aha!’ moment for me. There are a lot of things I’m not sure how I’m going to do, this article helped me get a little closer to checking one of those things off the list. I wanted to see a little more info about the guy that made the post, so I checked his profile to find out that he is the Lead Engine Developer for River City Ransom: Underground.

 

A Little Bit of Code

Game Design
I drew a mockup of the DPS tester, storyboard pane #7, and took a bunch of notes on how it will function.

Technical Design
I extracted a couple of classes from the Player() object to make them usable for other characters. It doesn’t seem like much in writing, but it ended up being a fair amount of code.

 

Game Design

Game Design
Here’s a list..

  • wrote a dream sequence featuring the main character
  • drew up some plans for how gun mods may work
  • wrote a few paragraphs of ‘World’ backstory
  • started a list of ‘things to try’

Technical Design
I did more work on the prototype, specifically on animated sprites, adding a feature that allows sprite animations to play out of order frames from the sprite sheet.

 

MonoGame Tools

I installed the monogame tools and intend to use them to build a prototype. I want the prototype to have:

  • a moving character
  • animated sprites
  • a weapon that shoots bullets
  • hit scan bullets
  • traveling bullets
  • joystick input
  • sounds for movement and weapon fire

For the prototype, I’m using sprite resources from Kenney Assets. I also added a couple of design edicts to the list (see top of page).