Level Editor-ing

I had a bit of a falling out with the side project from work-related weirdness that gave me a temporary lack of motivation in all respects, but this has blown over. It does go to show that there are many reasons to lose motivation that go beyond simple procrastination. However, I have had a stronger desire to see this through, and I feel I have more determination and trust in my own abilities than, say, a year ago. I'd like to say that procrastination alone isn't really an issue at my current mental state.

Since the last post, I have made some substantial code cleanup changes, and I'm better accounting for multiple controller inputs. I seem to be moving forward with a brute force, "get this new mechanic to work" method and stopping after it works to do code cleanup. I have no reason to not continue with this method, as it gives an appearance of small spurts of quick advancement. The code cleanup is really for organization and making certain it's easier to manipulate what's there if I need to make changes -- also makes it more readable for the future if I need to step back into sections I haven't touched in a while...

I have a placeholder now for a Level Select screen, but I'm actually bypassing how a level is selected at this point -- I'm just jumping into gameplay logic for now. The first thing I need for gameplay is actual level content. The typical scenario for a sidescroller is some tile-based level editing, so here I've done some reinventing of the wheel with a level editor tool:

Click the tile from the tileset and just click in the level grid to add the tile

Pretty straightforward. My current focus is just on a 1280x720 screen resolution, and I'm not yet worrying about scroll capabilities. I haven't yet added the ability to save this, actually, but it will probably just be an XML file, since those can be thrown in the XNA game's content as something that will presumably be hidden in the final version of the game (though perhaps I should leave some options open for players to generate their own levels with this tool, too).

The only other thing to really save with tile placement in the level editor will be the behavior each specific tile will have for players and enemies:

- Can be stood upon
- Is in the foreground and players/enemies will walk behind this tile
- Is impassable
- Can be passed from beneath, but will not fall through from the top (floating platforms, essentially)
- Etc. (Just keep an open mind for different tile types as I need them)

I may just focus on getting the level content I have to be imported by my game before implementing the tile types, though. One step at a time.

Fighting-Style Character Select

I had been in the dark about end of last week's news about XNA being discontinued until a coworker informed me of such things today. No matter, I say, as this doesn't affect my current progress -- just because Microsoft won't release new versions of XNA doesn't mean the current version will suddenly cease to function.

In any case, here's what I managed to get done today outside of the full-time job:

Just a simple fighter-style character select

Right after hitting Start, we come to this character selection screen. There's clearly lots of room here for more characters, and I think the fleshing out of all the character tiles will have to wait until more assets are made and I have a better grasp of just how many characters I'm going to have here. But for now, lots of empty space.

As it currently stands, pressing left/right on the controller will shift to the only other existing tile:

Who is this mysterious '?' Character?

I plan on using some form of '?' tile in the end to denote characters that have yet to be unlocked, but the 'C' tile will become a portrait image. I'm also storing character name (though mystery tiles just have a '?' in place of the name) and some information text, though they aren't displayed anywhere on the screen yet. The current plan is to perhaps reveal the unlock condition for mystery characters in the information text.

Pressing 'Y' on the 360 controller will also change the color of the selected character. I'm actually going to be drawing art assets as 2 separate images -- 1 which has a static color and 1 with select pieces that will be the color selected through this Character Select screen:

White, Red, Blue, Green, or Black (Dark Gray for the time being for obvious reasons)

I have some placeholder logic for accounting for multiple players, but currently the Player One controller is the only one responsive. My first test on this page was actually to place all 4 players on the same selection square to see how that would look, though since I saw it functioning I've since just left that code commented out. Here's how it looks with 2 players:

Multiple players will be able to choose the same character in the end

Color uniqueness is also not required

I think there's some code cleanup I want to do to all of this before I think about moving forward too much. I would like to get a better handle on positioning of those tiles, utilizing the character name and information text, and think of a clean way to read controller input from all 4 controllers. Before moving to the next Game State, I also need to determine what defines a character in the code, since the only thing being sent to the next Game State will be active players and what characters those players have selected.

Overcomplicating the Simple Things II: Sub-Menus

I spent most of the day relaxing, but I figured I'd return at the end of the day to at least get the Sub-menus functioning. It's far from perfect from a visual standpoint while the game is running, perhaps, but functionally it's solid and looks really clean in the code. I added a few Sub-menus and a new option for the Main Menu since this morning -- 'Statistics'. The Sub-menu items at this point are really just placeholders until I get farther along in the project and figure out what I desire to add to the Statistics display and what items should be customizable with the game.

For just a snapshot of how making menus with Sub-menus in my code looks, here's a sample of the whole Statistics MenuItem class (I did also change the text of all the existing classes from 'MenuOption' to 'MenuItem' after I became painfully aware of that from my last post):

When the game is running, the Main Menu currently looks like this when the Statistics menu item has been selected:

When a sub-menu is closed by pressing B on the 360 controller, the Main Menu's state is still retained, so Stats is still highlighted and all that jazz. The sub-menu is its own animal to control.

I will revisit the Main Menu in the future for further refinement, but now my concern is how I wish to handle the 'Start' for entering the game. I realize some games have a sub-menu for game modes, but I'm also thinking of Dungeon Defenders, where starting a game only has character selection, and game modes are determined when levels are selected... I quite like that model, actually, and may nab it. So next time, look forward to a Character Selection update!

Overcomplicating the Simple Things I

I was going to continue writing some of the code from an earlier project the other day, but I realized I couldn't find that project anywhere on my computer. I do still have the DirectX and C++ project sitting on my desktop, but given how long it takes for me to accomplish anything in that project, I will continue to have it on hold for the foreseeable future. As I may or may not have stated in one of my previous posts (which I would be lying to say 'recent' when my latest post was the middle of last year), I wanted to focus my side-project endeavors on XNA for the sake of speed.

What I have now is 2 projects -- a 360 project and a Windows project. Both are currently identical, with the exception that one is debugged directly on my 360 and the other is debugged on my PC. After a quick search, I couldn't see any settings to determine if this could be done with a single project, but I'm supposing some minor differences between the two will be coming up soon in terms of a settings menu and whatnot, so no matter. I didn't see this as a big enough hurdle to warrant a search on the interwebs for an alternative.

The project I had been attempting to find was the result from my previous blog post, with implementing a GameState interface to handle my different game states. It was just a proof of concept project that I had completed, albeit with somewhat boring results of just changing the background color. Details, details... So this was what I had spent yesterday recreating to catch up to speed.

What I'm realizing now, after spending a morning fine-tuning just the Main Menu logic, is my tendency to expand, and perhaps complicate, what is very simple.

My Main Menu is currently split into 5 different files. This is really for cleanliness purposes, as the code does look highly readable. The MainMenu.cs file is also the largest of those files, sitting at 114 lines, with the others each at 13-24 lines.

I have the logic here revolving around the menu items, where each menu item is its own class inheriting from iMenuOption (though continuing to call them 'items' makes me want to change all of this 'MenuOption' talk to 'MenuItem'). MainMenu just keeps track of which menu item is selected, handles moving up and down the menu, and calls a Select function for the selected option when the player hits A. I also have some placeholder logic to account for sub-menus, though I don't have any of those actually created yet, and pressing B to go back a menu.

Maybe I'm a bit self-conscious of putting 'too much' effort into such a small part of this project, but in a way I find such 'tedious' tasks to be enjoyable. After I complete the sub-menu logic, maybe I'll actually get around to programming the actual game, though it is up for question of how complicated I'll be making that process.

I hope to be a bit more active on this blog now, as I actually strive to do side project work instead of just think about it. Hopefully more to come soon, though no promises shall be made.

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.