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.