07 July 2012

Younger Self Programmer Logic

I've decided for now that I don't have the necessary time to spend on creating a project from scratch in C++ and DirectX. It's not that it's too difficult, but it's a bit too tedious, and on top of a full-time job I need to be a bit more realistic to the boundary of time if I ever want to accomplish anything before I'm 55. And so, I turn again to XNA and put the C++ project in cold storage for pipe dream world.

The last time I made something serious in XNA (I'm not talking about that crappy puzzle game I made for the Windows Phone) was in college. That was a world where I knew that I should worry about how much memory I'm using, but I didn't do this at all in practice.

I knew I wanted to account for a main menu, the main game, and maybe some other edge case game states here and there that I'd figure out as I went, but how would I accomplish this? XNA already has a natural break for drawing vs. game logic, so what seemed most logical...

...To Younger Me


Let's make an Enum and store all our game states in there. When the drawing or logic functions get called, I'll use my Enum in a Switch statement to figure out what to do.

The Problem


Not only is this Switch statement going to get excessively long and frustrating to maintain if I don't break it out into multiple functions, but since I'm using the Enum as my only reference for the game's state, I'm sorta guaranteeing that every variable across game states will need to exist at the same time.

I'm sure there's an argument there for that statement not being true, but that would require extra logic that would have defeated my younger persona's purpose. For the record, I didn't split my Switch statement's logic into multiple functions, so it did become one giant blob of inline code. I still have that code somewhere, too, but I cringe at the thought of looking at it...

My Solution


In needing to revisit the problem of setting up my environment from scratch again, I'm going to apply a class structure for game states instead of just an Enum. Let each state store its own variables and implement their own Drawing/Logic functions. The main class will point to a GameState interface, and polymorphism will handle the rest.

I still have a problem here of how I'm going to change game states, but conceptually this sounds a lot more reasonable. It will probably be easier to solve that problem (if it becomes a problem at all) once I get there, so I'll wait until then.

I don't have a lot of free time now, but perhaps later on today or sometime tomorrow I'll have enough time to dig in.