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.

On Being a Fan

When it comes to being a fan of someone when I realize they have a public email, I tend to just make a spontaneous decision to email them at some point with the same generic email they probably receive by countless fans every day. And then I get all excited to check my inbox when a reply never arrives. Sorry Trevor, but too much praise just comes off as creepy. To be fair, I wouldn't know how to respond to a "OMG I love what you do, you inspire me, and I look forward to every breathe you take!" type of email, either (though for the record, mine have never been that bad).

So I shouldn't get that bent out of shape for never receiving a response from John Green ages ago.

It's the times that I make inquiries or have meaningful things to say that responses tend to occur. Take the time I asked WheezyWaiter what format he wanted his wink clips in. For those who don't know, WheezyWaiter features clips of his fans winking at the end of all of his videos. He doesn't mind what format they're in, and a couple months later my wink clip was in one of his videos.

Also the time I sent Terry Goodkind an inquiry through the mail, since he doesn't have a public email but has an address on his website. I got a rejected reply to my question, but the signed postcard made up for it.

Now, I've been a fan of CommunityChannel for a while, but I never had anything meaningful to say outside of the generic "ZOMG Nat, you're amazing!!!<3!!!" That was, until I started going through some of her earlier videos and had a ridiculous thought. And yes, I really did send this email:

Current State of Affairs (Personal Project 2012)

I have every right to be disappointed by my own out-of-work work ethic. As far as personal projects go, I don't have much to show for them given the amount of time I could have spent working on them.

That being said, I'm still a bit surprised by just how much code went into making such a simple thing. I guess from here on, I can almost focus exclusively on the game if I wanted, since all the DirectX setup and deconstruction nonsense is complete (until I want to add in user graphical settings *shiver*).

The speech bubbles aren't 100% complete yet, but the only thing left is to determine placement and which of the 4 corners has the focal point (the pointed edge of the speech bubble). Also Events -- what happens after the bubble is closed.

I'm not planning on touching those again for a while, but Events are my next step. There are some parallels to how I set up the speech/choice bubbles and how I plan on setting up Events.

There's a very basic abstract class UIElement. Probably deserving of a more awesome name (mainly because I'll eventually want to use it for not just UI), but that was a placeholder name I haven't given a chance to grow up yet. UIElement just has a pointer to a sprite, an x- and y-coordinate, and two unimplemented functions to draw -- DrawText() and Draw(). Anything that gets drawn on the screen can inherit UIElement, and I only have to worry about the new logic to draw that object.

As of right now, the only class directly inheriting UIElement is SpeechBubble. ChoiceBubble inherits SpeechBubble, as they're basically the same, except that a ChoiceBubble needs to store a currently selected option and draws an additional arrow to tell the player which selection they're on.

I want the same abstract layer to account for Events, where all Events could be treated the same. My current thought is to have the base Event store a Trigger() that would handle the logic for the event getting called and a pointer to another Event that can get triggered when the current one completes.

So yes... This is the stage I'm currently at. There's lots of hesitation for moving forward too quickly for fear of backtracking, but I haven't needed to move as slow as I have been, either. It's not as though backtracking is really that terrible, since that's what a lot of bug fixing at my current full-time job seems to entail. Hopefully I can keep some updates on my progress going at a pessimistic yet realistic "once a month" quota. More frequent if I'm feeling adventurous.