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.