2013 Is The Year of The RPG

A week or so ago, RPG Maker VX Ace debuted on Steam. I had spent a lot of time in my youth messing around with RPG Maker 95, 98 and XP. I remembered those days fondly for a moment, and then passed it by. I simply didn't have $70 to spend on it. Steam's Winter Sale started yesterday, and the program was 20% off. Even at this much more reasonable price, I couldn't afford it. That's when my roommate gifted me a copy of it over Steam.

I've been thinking about what I could do with this that would be meaningful and also forward my own development efforts. If you check the date of the previous post before this, you might be under the impression that I haven't been doing any game development lately. This is partly true. November is eaten by National Novel Writing Month every year, and after that 30 day thing, I was just too burnt out from all the rush. I have spent some time working on games though, just not enough to warrant any sort of blog post. There was some fiddling with the platforming engine, some XNA experiments, a lot of article reading, and finally I decided to make a simple JRPG in Unity which got as far as me working out the stat systems and displaying a map before November hit. I've got lots of ideas, but the startup cost for trying them out is always too much because I'm working in XNA or Unity where I have to either start from scratch or spend time understanding other people's frameworks before I can try out the thing I wanted to play with. This is no longer an issue.

With the aquisition of RPG Maker VX Ace, a tool I'm familiar with, I can create basic JRPGs very quickly. The biggest new feature to this version of the program is the scripting editor and it looks very flexible and easy to understand. So I'm going to jump in head first and start doing things: I've decided that 2013 will be the year of the RPG for me. My new years resolution is to make one JRPG prototype per month and I'll release it here on my blog at the start of each new month.

My plan is to focus on one core idea each month, and build the rest of the game around that idea. So for example, I want to dive into the scripting system, so maybe I'll do random dungeon generation for January. Everything else will be incidental, so I'll be skipping over steps I'd take in a more polished game like creating custom art assets. Or really any sort of resource. I'm a programmer and aspiring game designer, not an artist. It simply isn't feasable for me to do the art for my prototypes and RPG Maker accommodates that.

Early on in the month, I'll post what my theme is for the month and what my progress is like. I'll try to post about challenges and the process of getting an idea working and fun. Ideally, this will result in me gaining some experience as a game maker and some cool things will come out of it. I hope you'll be here with me whether I have soaring success, or miserable failure.

Progress Update?

Oh man, Guild Wars 2 is so much fun. I'm spending pretty much all my free time playing it.

What's that? Adventures of Balzac? Programming?

They're crying over how little work has been done.

So I said I would be fixing bugs and then releasing the first level as a demo yesterday come hell or high water. It didn't happen. Between doing a ton of programming for my actual day job (web development) and Guild Wars 2's recent release, nothing has gotten done on my game. This is very frustrating for me since I'd love to get a job in the games industry, but feel like I need a portfolio to show first. Now it's September, 4 months since I started programming my game, and 1 month since I got anything meaningful done on it.

I'm feeling kind of lost on this project because...well, I'm not sure why. Maybe it was the fact that the game is pretty bland and generic in terms of gameplay and I'm not entirely sure what to change about it. Maybe it's that after spending every available free minute during July working on the game, I just burned out on it a bit. I'm not sure what's causing me to feel this way about the project, but I've got to take steps to deal with it and get back on track to shaping the game up to a point where I can feel good about posting it somewhere.

What I've decided to do about this is two fold:

1. I will no longer hold myself to the previous "I need to have visual progress every Saturday" standard that I was keeping up during May, June and July. Progress will come on it's own time and I'll just have to deal with it. I suspect that there will be more progress when things are slower at work though, and less when, like now, we're scrambling to make sure all our ducks are in a row so that we can release our product.
2. I'm going to sit down and be mapping out possible ideas to integrate into the engine. As it stands I have the jumping and shooting aspect more or less down pat. But there are other things to think about including level gimmicks and code structure (which still needs to be fixed up after the rush at the end of July). So I'll be carefully planning out where those go from here.

Hopefully these two strategies will lead to me getting more work done and feeling better about it in the future. If anyone has any ideas on how to deal with this kind of lethargic, wandering feeling regarding a game project or if you have a neat idea for a platforming mechanic that you'd like to see in a game, feel free to drop a comment below and tell me about it.

Progress update 8/11/12 - 8/17/12

This week:

1. I spent some time writing a simple blackjack game for the Petit Computer app on my 3DS. It isn't done, but it was a nice distraction.
2. I spent some time watching panels from QuakeCon and some other talks about game development. July was all about rushing to get something done as quickly as possible, but now that it's over I want to devote some time to trying to prevent myself from mistakes.
3. I fixed the bug that causes you to fly speeding through the floor whenever you get take damage from something when you're in the air. Though ultimately unrelated to the collision handling subroutines, I've already begun rewriting them. The next step in this process will be to determine whether my old subroutines are fine as is or if I should finish rewriting them.

No screenshots this week. Lots more time was spent playing videogames again, something I didn't really get to do in July and haven't really done since May. It's been lovely to remember how much fun games can be and how much I like to just sit down and play one sometimes. The first level is still on track for a public release at the end of the month, so I'll just focus on getting it as polished as possible for that time.

Progress Update 8/4/2012 - 8/10/2012

This week:

1. Worked on a prototype for a different sort of game in XNA. Probably won't keep it in XNA, and might not go much further with it. Who knows right now.
2. Fixed a bug or two in Balzac, but not enough to warrant demo release.
3. Waited anxiously for feedback from judges in last month's contest and recieved none.
4. Reorganized TODO list for Balzac and thought about what needs to be done going forward.

Despite still feeling kinda burnt out from all the work I poured into the previous month and the release of new videogames that I love to play, I'm trying to get back into the swing of things and do something related to my game project each day. I thought that this past week would be more productive, but I guess I burned out last month a bit more than I was expecting. Anyways, the plan going forward is still to fix bugs and some art assets to make the demo more presentable, and then release it. My revised estimate/personal deadline for releasing the demo will be September 1st, which is a Saturday. Come what may, I'll release it that day and start asking for feedback. Maybe after I get some more feedback, I can get back into a position where I'm making visible changes each week!

Progress update for 7/28/12 - 8/3/12

This week:

Coming back from my last vacation for the month, I crammed a lot of work into the last two days of the competition (the 30th and 31st). Below is a short list of things that got done:

1. Created a bad, but topical, main menu screen.
2. Created new enemies: Squid and Miniboss Squid
3. My roommate added behavior for the BallRusher enemy and I ended up tweaking it a bit
4. I also leveraged existing logic into getting the Squid and Miniboss Squid some AI patterns. They aren't great, but they'll do.
5. Added more enemy placement throughout the level
6. Wrote entirely new logic for Squid enemies, the miniboss can deal with having the old logic.
7. Fixed some miscellaneous bugs relating to animation and enemies facing the right direction.
8. Added some music that I got from www.freemusicarchive.org
9. Added support for respawn points.
10. About an hour and a half before the deadline, I started adding the boss battle for our only level.
11. My roommate added a credits screen.
12. I added a fireball sprite for the boss
13. Added the music attributions to the credit screen 
14. Slapped together the entry form for our game and submitted it with about ten minutes to spare.
15. Submitted a patch the next morning because it turns out in my exhausted rush to get this done, I fucked up something simple with the respawn support, so you could crash the game by dying in the first 5 screens.

So the game is in a good state now, but I'm totally wiped out from the constant "go go go" of the contest, so I'm relaxing a bit for a few days and prototyping a different game before I continue work on Balzac. What will likely happen is this coming week I'll spend my time polishing and fixing bugs that I saw but didn't have time to deal with in July and then I'll release the first level as a sort of demo for the game. Hopefully that will make up for the lack of screenshots this week.

Progress update for 7/21/12 - 7/27/12

This week:

1. I made the camera's transition independent of the player's transition between rooms. This lets me move the player three tiles to the left and then the camera can move 5 tiles left and 3 tiles down, for example. Support for this functionality was also added into the editor.
2. I fixed some dialog box values in the Alan Moore level and then finalized the level's geometry!
3. My roommate fixed up our main menu since the save/load functionality won't be done in time for the end of the month and the competition deadline.
4. Added two new enemies to the game for the Alan Moore level. They also get hand drawn sprite sheets from me, ensuring that they look terrible.
5. Added a new AI "Walk" behavior for the above mentioned enemies.

That's about all for this week I'm afraid. July has been really busy for me this year, making this month less than awesome for a game-in-a-month competition. On the other hand, that's how competitions go I suppose. Otakon is cutting my week short this time, which means I'll really be cramming the last two days of the month to add as much polish as possible before it has to be put up online for download.

Progress update for 7/14/12 - 7/20/12

This week:

After recovering from jetlag I made a lot of good progress on the game this week.

1. I reworked my level design for our Alan Moore tutorial level for the new aspect ratio and created all the geometry in the level editor.
2. I also added a respawn mechanism, so now when you die you don't have to use debug commands to return to life. This somehow came out of me fixing a bug that played the player death sound every frame when you passed a certain Y value in world space.
3. My roommate added a volume parameter so that what sound effects we do have aren't blasting our ear drums out every time we boot the game.
4. My roommate added the structure for scoring in the game and set up the beginnings of saving and loading games.
5. Alan Moore now talks to you throughout the tutorial level.

I'm not entirely convinced we needed a score system, but I guess it doesn't hurt to have one and I suspect that leaderboards are a requirement (or at least a boon) when it comes to Microsoft certification.

We also hit a soft feature lock today on the project. We won't be adding any more new features unless we absolutely cannot help it. We'll be spending enough time fixing bugs we find and designing around the mechanics we have now.

Here's the start of Alan Moore's level. The whole thing has been redesigned from the ground up to better teach you the game. Unfortunately, I'm not the best level designer, so it probably needs a lot of work but for now I'm blissfully unaware of how bad it is. It also handles some exposition by having Alan Moore talk to you throughout the level.

This level has a gimmick. The gimmick being that you can jump on Alan Moore's speech bubbles and use them to continue through the level. You may recall earlier when I said I was not the best level designer?

Here you can see the level select screen that my roommate has made. He spent a whole lot of time getting that Alan Moore picture just right. Not helpful in and of itself, but man is it cool.

Progress update for 7/7/12 - 7/13/12

This week:

I didn't do anything! I was on my honeymoon! Luckily, my room mate was much more productive and at home than I was.

1. Added a menu system
2. Added letterboxing and converted everything to use 16:9 aspect ratio
3. Worked on his level for the game

I'm not entirely convinced about the aspect ratio and I'm having to readjust my level designs to account for not using 4:3 any more, but it's an easy enough thing to change later for future projects, so whatever. Plus, I'm pretty sure the reason he did it is for Microsoft certification reasons and I'm definitely not going to try and fight something that would help our game reach a wider audience. 

No screenshots today, and sorry for the lateness of the post. Next week's update will be on time and more visually oriented.

Progress update for 6/30/12 - 7/6/12

This week:

1. The roommate and I are participating in a gamejam this month and are using the Mega Man engine we've been working on for this purpose. Starting on the first, we're going to be making The Adventures of Balzac and Dickens.
2. I've worked out a few problems in the level editor after my roommate and I began prototyping levels.
3. Added platform collisions to the engine. Now you can have tiles that you can move horizontally through, and jump up from underneath, but you can stand on top of them.
4. Added layers to the engine and the editor. Now you can have stuff in the foreground AND the background! So high tech!
5. Changed how transitions worked a little bit in order to have more complex level designs down the line. Rooms now draw on demand instead of constantly being drawn. This lets us do neat tricks like the Lost Woods in Zelda 1.
6. Switched from using alpha blend everywhere to color key for transparency. Especially in the editor.

That's pretty much it. I spent a lot of time working on level design and reading up on some stuff. Additionally, I was spending a lot of time preparing for my honeymoon, which starts tomorrow. So I'm afraid that next week's update will be sparse as well and only contain whatever my roommate works on. In the meantime, here's some screenshots:

There's Balzac and some glorious layers

His glorious jump animation. His shirt even flaps in the wind when jumping.
Pay no attention to the level geometry oversight in the picture.

His idle animation is pretty great too.

Progress update for 6/23/2012 - 6/29/2012

This week:

1. My roommate continued working on AI and got stuck on a weird .NET reference error bug. After he gave up, I took a look at it and came up with a work around. Still no idea on what was up with that bug though. For a more detailed explaination, please look here.
2. Found a link to an article about marketing indie games that might be useful down the line.
3. I finished room transitions to a polished shine.
4. I rewrote the entire control system. Controls are now based on Actions (strings) and I can easily check for button presses, new presses, continuous presses, releases, etc of any button or key associated with a string quickly. The game actually controls a bit better now, though I still want to tweak how bullets are fired and how the shooting animation is played.
5. With level transitions working properly, I went ahead and created the rest of the Cutman level's rooms in the level editor. There were some bugs to work out, but now everything works fine with transitions and running around and such. There's no enemies placed after the first room yet, but that's a minor point and will be adjusted later. Running through the level repeatedly though has shown me that there's still work to be done on the player class. There are situations where, when close to a platform corner, the player will switch to a running frame for just a moment or where the jumping variables aren't quite right and the player can't reach certain areas. These bugs will be worked out later and are just noted for now.
6. My roommate added Beak enemies (Blasters in Japanese), though they aren't quite perfect yet, they're close.
7. I changed Mega Man's injured logic to first push you back and then give you back control after a bit with a short period of invincibility. Before this you wouldn't get control back until invincibility wore off, which let Bladers really tear you up.
8. Spikes kill you now. Sorry.
9. Fixed a bug where the game would think you were on the ground when you were actually jumping past a corner.
10. Fixed a slew of ladder related bugs. Ladders suck.
11. Roommate added more behaviors to the enemy AI after I added an extra generic parameter for all enemies in the engine and the level editor.
12. Added in all spawns of Beaks (Blasters), Octopus Batteries (Suzys), and Bladers (Bunby Helis).
13. Tidied up some sprites and added death particle spritesheets
14. Roommate added Flea enemies. Their AI does little more than jump constantly right now.

Here's a video!

Here's some screenshots:

A room further in the level

This is a bad situation to be in!

Made it to the end!

Progress update for 6/16/2012 - 6/22/2012

This week:

1. I worked on the level editor a bit more, adding in some features I wanted after using the program a bit more like "Load last opened level." I also added some support for adding enemy spawners of different types. There's a lot left to do with the editor, but it's incredibly unfun so I really need to get myself pumped up to do it.
2. My roommate worked on AI some more. We've got some Octopus Batteries (or Suzys) placed now for fun.
3. I started tweaking jumping since that hasn't been working quite right. It feels too float-y I guess.
4. I watched Indie Game: The Movie this morning. I expected to come out of it motivated and ready to program. Instead I came away determined, if a bit haunted. In lieu of coding I walked to the local CVS and picked up some Microsoft Points to buy Fez with later tonight (I'd put that off long enough) and also some candy from my childhood. I'm thinking a lot right now about what I want to do with my life and why I like games. I don't have any answers for either of those questions. I can't even pick out which game I like the most from my collection or which had the biggest impact on my life. Watching the movie, I saw many qualities in Phil Fish, Jonathan Blow and Team Meat that I've been noticing in myself lately. I mean, I saw those qualities ahead of time. Not just thinking "Oh I'm like that too" when I was watching the movie. It was more like they echoed things that I had thought or said to myself before. Sometimes almost word for word. I think that making games is what I want to do with my life, but to hear someone echo what I feel inside of me and then to see what they've done in the field I love...it's scary.
5. Did a lot of tweaking to player movement and control. Still not perfect, but it feels much better now.
6. I added support for designating room exits as well as a lot of general polishing in the level editor. It's not quite as nice as I wanted it to be, but the idea of polishing the level editor to perfection right now just isn't something I can stomach. I know that the tools I build to build the game are extremely important, but the drive to work on them right now comes entirely from wanting to implement new features into the game engine. Later on, the drive for fixing up the level editor will come from a combination of wanting to do things in the level editor (when making levels) and embarrassment that the level editor isn't better.
7. Most of what I need for room transitions got implemented, but there are still some problems with it, so sadly I don't have much to show this week visually.

In summary, I didn't get as much done this week as I wanted to, but still made good progress. At least part of my time went to Civilization V and the new Gods & Kings expansion. Raptr tells me I played 10 hours of Civilization V this week and when I think about it, that's probably the most I've played videogames per week since I started working on this in my free time. What a strange thought.

Progress update for 6/9/2012 - 6/15/2012

This week:

1. Moved the project to some proper source control system called Assembla. It's free up to 1GB and has a nice visual studio plug in.
2. Got my roommate working on this with me now. He added code for doing things like playing sounds when things die and also started on writing some basic AI for the enemies.
3. I started working on ladders thinking that it would be a quick little thing that would take a few hours. I was wrong. So, so wrong.
4. Ladders wasn't actually so bad in retrospect, but it feels like it took a long time just because I didn't devote so much time to programming each day this week.
5. Jumping the gun a bit here, but I was idly listening to this episode of Extra Credits and it got me thinking about my engine and why I played and enjoyed the original Mega Man games. Even better, it got me thinking about what I want to get out of this engine and what I want players to get out of this engine. This is something I'll post more about and think about more later after I've finished Cutman's stage, but it's good to be putting it on the back burner now.
6. Roommate implemented pausing and pausing when the game window is not in focus.
7. Not directly related to development, but maybe Mega Man L should get made; it's more than Capcom is doing now.

After last week's additions, I decided I wanted to take it slower this week so I'm not going to push myself to have anything finished. This decision is also in part because the wife leaves for a week or so starting on Saturday so I'll have PLENTY of free time to be coding this game. I intend to make a lot of progress then because of the sheer amount of free time I'll have.

Late edit: Forgot to take screenshots for Screenshot Saturday! Here:

My roommate added some basic AI code.

I added ladders.

Goals for the Mega Man clone

I think I've mentioned this in replies to r/GameDev's Screenshot Saturday posts, but since this blog is my record of the development process, I may as well put down my intentions here. I mentioned in the first post of this blog that I wanted to write a game that I would enjoy playing and that's why I'm focusing on the NES Mega Man games. I really enjoy these games and I think that they're simple to program compared to other types of games I like playing (grand and sweeping RPGs, Civilization, Dynasty Warriors, etc).

That said, I don't want to just copy the Mega Man games straight up, but I feel that I don't have the experience to create my own original game right off the bat. Like how some artists start their careers with fan art of their favorite franchises or how some writers get their start in fan fiction, I need to start by imitating things I enjoy until I can feel confident in my abilities to make video games. Lots of forums and websites tell new comers to the craft to start really small. They recommend games like Pong or maybe Space Invaders or maybe 1942; but usually Pong. Making a game as simple as Pong can be great to practice your ability to make a game compelling, but I can't let myself go that small for reasons of maintaining my interest in the project as well as feeling like I could learn more by being more ambitious.

With that introduction out of the way, here's the major milestones I want to hit with this engine:

1. Replicate Cutman's level from Mega Man 1, release it (for free of course) online and gather feedback.
   Cutman's level is pretty simple all things considered. There's a good number of things for me to have to account for (boss fight, multiple enemies, some vertical as well as horizontal sections, etc) but not enough to overwhelm me (one level means no real weapon switching/upgrades, no level select or title screen really needed, a ton of enemies won't appear, no need to come up with and polish my own original level design, etc). All the functions of the game are pretty straight forward and easily checked. I could make improvements at this stage, but I probably won't make many (one improvement I will make is not implementing the infamous "Pause Trick" that lets you murder bosses easily). Once I have released this and gotten some feedback on what I did wrong or poorly, I can move on to the next stage.
2. Create a short game in the Mega Man tradition that doesn't copy weapon, enemy or level designs.
   This allows me to polish up things from the previous milestone and then improve on them and implement more functionality. I view this as a halfway point between starting from scratch and releasing my first "real" game. If I can get here, I'll have 4-5 levels with some sort of game mechanic that is hopefully fun and probably not very original. This step will be very much focusing on presentation and what it takes to release an actual game. Reaching this milestone will be a big deal for me because it will mean that I have what it takes to make a "real" game. I will have proved to myself that I have a shot at being successful at this. I'll release it for free online and more or less beg people to play it and give me feedback.
3. Create an honest to goodness video game and release it commercially.
   This milestone is currently a long way off, but it's part of what will keep me going. This is my carrot at the end of the stick. It doesn't matter if it's a success or not, it just matters that I make it here. It'd be great if it was a success for me (I'm defining success here as I can afford to take my wife out to dinner with the profits), but that's not the primary reason I'd be happy. If I can release a game commercially, then I've proven to myself that I have the basic skills to live as a game developer. This is the point where I would feel confident enough to apply to developer jobs at game studios. That far off dream is what gives me the energy to come home after work each day and program for another three to five hours.

I plan on documenting the entire process of reaching for these goals here, on this blog. As I go along I expect that I'll be writing posts about me learning things pertaining to design of a game overall, level design, making sprites (I'm a very poor artist) and debugging. As I release each milestone, I'll be posting about feedback I get and how I intend to incorporate those suggestions/criticisms into the engine. I'll also be taking breaks from programming sometimes to post here about past games I've made (successfully finished ones and maybe a post about the ones that were not so successful), if only to document my past failings and maybe learn something from them. I'll probably start that sometime in the next few weeks depending on how busy I get.

Progress update for 6/2/2012 - 6/8/2012

This week:

1. Worked hard to get the level editor to a level where it can edit levels properly (Picture below)! I still need to add support for transitions in levels and enemies and any other scripted event stuff, but plopping down tiles, saving, loading, changing tilesets and a few other nice features are all implemented and working. There's still a lot to do before it's complete, but I'm at a point where I can create some levels in my map editor for use in my game. Now then, I just need to get my game loading these levels...
2. I've given a lot of thought to the content pipeline in XNA and how or whether I should be using it. I've already got an XML schama that works with my level editor, but it seems like if I want to use the content pipeline I'll need to rewrite my schema to be XNA serializable. Here's a good tutorial about how to serialize XML for XNA. If I bypass the content pipeline, then I can make my life a bit easier even and just save levels as binary blobs, but I lose the ability to run my engine on the Xbox 360. In the end, I decided on using the content pipeline because I don't lose anything by conforming to it and I don't want to close doors I might want to use later (Xbox 360 compatibility).
3. Powered through getting levels to load through the content pipeline in game. I also converted the current level assets I've created by hand from the editor format to the XNA format. It was tedious, but informative. The whole thing turned out to be slightly simpler than expected in some places, so that was a nice surprise. I conferred with my roommate and we isolated the render resolution and the window resolution so now everything looks much more properly to scale like the original Mega Man game. Below you'll find an image of the game running the first bit of Cutman's level in game.
4. Found another good article about the component design pattern. It's pretty obvious that this pattern is better for larger games, but I guess I'm  not sure where the line between "small" and "large" lies. It seems like the sort of thing that requires experience to determine.
5. Levels now properly export to a format that can be put directly into the Xna project, compiled and read into the engine. Before I had converted the files from the editor by hand and boy did I not want to do that more than the once. 
6. I'm still fiddling with collision detection, but that should be fixed for a while in a little bit here. I eventually ended up defining hit boxes by hand for the player character since doing it automatically turned out to be quite a bit of trouble. Everything works a little better because of it though, so it was worth it.
7. Enemy spawns now work properly in the game and can be set in the level editor. Currently the options are limited to exactly one specific case (BunbyHeli, spawn on sight, infinite spawn) and the enemies don't have any AI, but they deal damage just fine when you run into them and they're plenty killable. Overall, I'm happy with them. I included a youtube video I recorded of everything up to this point using fraps. I would've made a gif, but I don't have a good program to do so. If you know of one that's free, let me know in the comments. Thanks.

It's been a busy week, but I really wanted to push myself to get to this point. Looking back at last week's progress report, it feels like forever ago. I'm much happier with the state that the game is in now, but I really haven't spent much time unwinding from work, so I think I'm going to take it a bit easier next week.

Here is my level editor with a carefully reconstructed first bit of Cutman's level from Mega Man 1

So chic!

Progress update for 5/26/2012 - 6/1/2012

This week:

1. Fixed my timestep. This was the end result of debugging some physics problems. I also got to change all my constants afterwards to prevent my player from flying off the screen at every opportunity. Something else I learned about while talking to my roommate about this problem was sweep tests. This sounds like a good idea and as soon as I decide that I have need for it, I'll be implementing it in my own stuff.
2. Read about Tiled and considered using it in place of my own map editor that I've been working on. Tiled has a lot of nice features for map editing that would help me create maps much much much faster than my own map editor will when I'm done with it (because there's no way I'm going to put in more work than I need to into it). I looked into what I would need to do in order to get Tiled to save in my map format that I've been developing. Here is a link I found about writing a plugin to get Tiled to save in your format. I decided ultimately that although Tiled is a great looking program, I would have to include it in my plans from the beginning next time to use it effectively. This time, I think I'll be better off working on this myself.
3. Added a life bar for the player. It's position is a bit close to the screen edge, but that can be fixed later.
4. Worked on the map editor more. Much more. Also thought about how best to integrate my level files from the map editor into the game program.

Didn't get to work as much as I wanted to this week on my project. This weekend I'm either going to work on making a visible change in the level architecture or implementing some enemy AI via finite state automata. Below is a picture of my only visible change this week, the health bar:

Progress update for 5/19/2012 - 5/25/2012

This week:

1. Started the week by rewriting the Player class and the Enemy class. Most actor logic is stored in the AnimatedSprite class. I'll give an overview of how I've structured things soon.
2. Found this link on /r/gamedev:  http://higherorderfun.com/blog/2012/05/20/the-guide-to-implementing-2d-platformers/ I find it very helpful, especially since I've already figured out some of that stuff for myself.
3. Found another link on /r/gamedev:  http://www.wildbunny.co.uk/blog/2011/12/11/how-to-make-a-2d-platform-game-part-1/ It's a 3 part series about implementing 2D platformers. With all these new resources and a three day weekend coming up, I feel like I could really get a lot done in a relatively short amount of time.
4. After thoroughly reading the two articles above, I've noted that the design decisions I had made and were leaning towards are already recommended in those articles. This gave me a confidence boost that I was on the right track. It's also now my fall back position for not being sure about how to do something.
5. The rewrite I started last week is done now. Hurray!
6. I've added a basic camera to the game. It works. I'm so excited by these little things. Next up will be working on finalizing the level editor and, by extension, the level, room and tileset classes.
7. Made good progress on the level editor. Focusing on getting the New Level, Open Level and Save Level functions perfect before I go on to include any sort of actual editing. Should be done with these by the end of the week, I suspect.

This week's screenshot:

A working camera!

Why I'm not using Software Design Patterns

So, this post has undergone some changes. At first I was just going to describe some design patterns and talk about what situations they're useful in so that I would have a reliable reference. The problem is that there are plenty of these already. After that, I was content to talk about how different design patterns applied to video games, mine in specific (which would be more focused on progress in my project and less time spent writing on this blog which does not directly affect my project's progress). As I tried to implement some into my code, I quickly became frustrated. I was talking about implementing components into my code base when my roommate basically said "The Component design pattern is good for two cases in game design and you have neither."

I had been so caught up in trying to program in the "right" and "proper" way, that I had again forgotten to just Do The Simplest Thing That Could Possibly Work. This is a lesson that I've learned the hard way several times, and will probably learn again before I finally ingrain it into my brain. Before I go and discuss anything further, I should clearly state that I am not an expert and am still learning. What follows is my personal viewpoint and I will probably look upon it with scorn in six months or so when I know better.

There are often, in programming, multiple ways to accomplish complex tasks. The problem I'm trying to solve (the problem of making a game) has a large number of solutions; too many for me to research or know. When I started this post I was looking for some optimal pattern to use that would make for a more stable program and make my life easier in the long run. This design pattern is out there somewhere, I'm sure. I also know that there's no way in hell I'm using it.

I started out looking to implement the component pattern, which you can read about here as well as many other places on the web. It has a lot of advantages to a big game (often in 3D) or games with a very data driven engine. That isn't me. My game is 2D, has a fixed number of entities, and isn't built for DLC (I'm not even 100% sure on how to implement DLC on a technical level). My game will probably have a title screen, one level and that's it because I need to start small. It's important to note that I could implement the component pattern and do just fine with it, but it's awkward to me. Whether that awkwardness comes from a lack of experience using it or it just being the wrong fit for me personally, I can't say. Planning on how to split everything out into different components was taking up way too much of my time though; time that could've been spent implementing the simplest thing that could possibly work.

Despite my bold and eye catching title, I am fond of using the Object-Pool pattern (sometimes I've seen it as Resource Pool) where I can to minimize my memory footprint. I really like this pattern as it has a few benefits and not much in the way of drawbacks. It helps me guard against memory leaks and keep my memory footprint small, as well as being really easy to implement.

So if I'm not using popular software design patterns, what am I doing? Well, mostly I'm fumbling along on my own. I'm sure it'll end with me learning which patterns to use when the hard way, but it seems like at least some of that isn't the kind of thing I can learn without making the mistakes myself. Based on my past experience with making games, I tend to succeed in my goals when I just jump in and write horrible messy code. Then after a bit I stand back and reflect on the structure of my program and what I want to accomplish with it. Next, I rewrite my code to more accurately reflect what I want to be accomplishing. Finally, I end up with something approaching a viable program that is like the game I wanted in the first place. I'll wrap this post up here though and show an example of this process in a later post.

If you read something here that's totally wrong, or even a little wrong, please let me know in the comments so I can have the chance to learn something! Thanks for reading.

P.S. After reading this article, my hopes have been bolstered significantly. You'll notice that there's no mention of components anywhere. Also, you can't see it here, but the design pattern that I've been pursuing has been similar to that of their Mega Man example already.

Progress update for 5/12/2012 - 5/18/2012

This week:

1. Spent 8 hours on Sunday tweaking and thinking about architecture changes. During this session, I got an enemy spawning at a set location and dying from player bullets. I also squished some bugs, most of which were caused by silly typos in for loops. Also spent a small chunk of time wading through the enemy and player classes. Eventually I decided I would be better off rewriting them to use a single Actor class and then a component design pattern.
2. Began redesigning the Player and Enemy classes into a more cohesive base class. Took breaks from this to design a rough outline for how the Camera and Room and Level classes need to work. Also thought about how to store all the Level and Room information. Decided to use XML files for metadata.
3. Began work on the graphical level editor. So far this has involved some basic form functionality and then finalizing my design for level structure. I'll write a post about this in the near future once I get the basic functionality of the editor working.

Since there's nothing visually different about the actual game this week, there's no screenshots. Sorry.

Progress update for 5/8/2012 - 5/11/2012

This is the first of a series of posts to encourage me to keep up with this blog and my ongoing game education. In each, I'll catalog what I've done on the project for the period beginning on Saturday and ending on Friday (or in this case, beginning when I created the blog on the 8th).

This week:

I started this blog. I almost don't want to include this since I view it as more procrastination than getting things done, but I'm including it here under the assumption that it'll help me keep on top of things down the road and thus be productive.

Added bullets and shooting to the game.

Started an article on game design patterns.

Thought about how to handle different enemy types and what kinds of design patterns I could apply to make the code more readable.

Created a quadtree tech demo to see how practical it would be to use in a platformer game. Really, I was looking into spatial hashing in general for application in platformers and bullet hell games. I wrote a quadtree implementation in C# and dropped it into a windows form, then drew a variable number of squares and had them move up and down inside a panel to see how feasable it would be to do a large number of objects at once and update them all each frame. Pictures are below. All in all, I think that it's worth trying out, especially for games where there might not be as much stuff on screen at once. Here's a picture of the quadtree program running with 10 objects. Finding an object given a bounding rectangle is trivial in this example. Here's another picture with 10000 objects. Finding all objects colliding with a 1x1 rectangle under a mouse click took about 22 comparisons in the most subdivided areas and 12 in some of the bigger regions. The highest I ever saw the comparisons take was a little over 1 millisecond, returning with as many as 8 objects that intersected.

Amid all this pondering of design patterns, I decided to look up what XNA would be able to do for me. After trying a few different game engines/frameworks, I was wary, but XNA looks like it may actually be helpful...so I decided to scrap what I had and move as much of it as I could over to XNA 4.0 using the XNA 3.1 Platformer Starter Kit as a guide. I'll write a post on this process later, but I did manage to get back to where I was in terms of functionality (not far) within a few hours.

So what did I learn this week? Well, I studied up on design patterns and how I can apply them to my game, I learned that quadtrees are a powerful tool with an expensive insert time, and I changed from using a completely homebrewed engine living in .NET's Windows Forms to using XNA as a base to help build my engine. I feel kind of bad about jumping ship from my DIY approach and going to XNA, but frankly there's a lot of good reasons to go to XNA, not the least of which is that it provides that much more that I don't have to code myself.

See you next week.

The Move to XNA

The Old Code

Let's get something straight right from the get go: I am not a great programmer.
I'd like to think I'm a pretty okay programmer, but I may not even be that. Please bear that in mind as we take a quick tour of my initial code for my Mega Man clone.

Let's start by listing the files and what's inside of them:

GameEngine.cs - Contains the main game loop and references to the Graphics and Physics management classes as well as a List of all the game objects that are in memory.
GameObject.cs - Contains basic logic for tiles in the game. Is it an object that can be moved through by the player? Is it affected by gravity? Where is it located? What's it's movement speed? Direction? Acceleration? All these questions are (or were intended to be) answered here.
AnimatedGameObject.cs - Not everything in our game will have static poses; some things need animation! This inherits GameObject and really only adds functionality for animations.
Player.cs - Inherits from AnimatedGameObject. Most of the code in this class deals with responses to user input, e.g. when the Jump button is pressed and we are on the ground, do a jump.
Bullets.cs - Handles bullet creation and pooling. Also contains basic logic for bullets.
GameControls.cs - This is a static class which contains a list of properties for different actions like move left and jump.
Physics.cs - This class contains my physics methods, such as they were. There are really only two: ApplyGravity(GameObject) changes the given object's acceleration given what direction gravity is affecting it (my thinking being that doing this here would let me have gravity from multiple directions later) and MovePhysicsObject(GameObject) which then applies the object's acceleration vector to their x,y position.
Graphics.cs - This class was supposed to handle all graphics calls that my other classes made as well as initializing the game window. The idea was that by funneling all the graphics calls through this class, if I ever needed to move the code to another platform then I would only have to re-write classes that touch the platform's APIs, like graphics.
GameWindow.cs - The final class in my list mostly just handled receiving user input and updating the GameControls class as needed. This is arguably not the place for this logic, but I never got far enough on this version of the code for it to be a problem.

So that's what the code structure looks like. The player and the level that I was testing in, seen below, were generated each time the program started just before entering the game loop (bad). I began the project thinking about how to implement the game in a clean and easy to read way, but ended up with a mess (double bad). It was nothing that couldn't be cleaned up in an hour or so of refactoring, but that's an hour of time not spent putting in something new. Reading user input was handled in the GameWindow class instead of the actual Control class (triple bad) and the code in the Physics class was barely functional (so bad).

It's hacky, poorly designed, and really only had one thing going for it: it worked. All the problems I listed above would have to be fixed before I felt good about releasing it, and the longer I left them unfixed the harder it would be to fix them, but there's something to be said for something that works properly. Mega Man was animated, he ran back and forth and when you pressed the right buttons he would jump and shoot. Had I continued with this code, the next step would be to fix my design problems, work out any bugs and generally get my program into shape. Ironically this is exactly what I was doing when I decided to abandon this.

Why I moved to XNA

My first experience with XNA was several years ago shortly after graduating college. I hacked together some tile generation system with some basic MS Paint sprites. Figuring out everything was pretty terrible since the documentation was spotty in places and my own knowledge wasn't enough to fill in the gaps. I gave up. More recently I was looking at different engines and frameworks for making games. I tried my hand at Unity, but I never felt like I was using it properly and since all the online resources about how to use Unity were either aimed at people who a) couldn't use a mouse or b) had several years of game design experience already, I was out of luck. I did bumble my way around it for a while, but eventually got frustrated with my lack of meaningful progress. I also tried my hand at GameMaker, which seemed promising at first. It was simple to get into and get going, but I quickly became frustrated by the lack of control over the actual code and my own lack of understanding of how the system worked. I had gone through a few other engines at this point and was, I suppose, just frustrated by spending all my time navigating GUIs and not doing any actual typing. So I started writing the code I outlined above.

My roommate had been using XNA for quite a while and had a book on XNA 4.0 handy. I flipped through it and was pleased with how easy things looked now. Things I wanted were already set up for me, only a minimum of coding for them was involved. I could target the Xbox 360 as well as my initial target of Windows (I'm not planning on putting a Mega Man clone on Windows Phone), there are contests I could enter, there are a ton of tutorials for XNA stuff now (no such luck for my windows form code), and there's even a platformer starter kit that shipped with XNA 3.1 to provide me examples. I could go on, but that's a pretty decent set of reasons right there.

I took the plunge and within two to three hours with my old code and the platformer starter kit as a reference, I had gotten back to my previous level of functionality and then some. One of the things I took from the starter kit was the Level class which, with a minimum of modification, will allow me to have a basic tool to generate levels from easily editable text files. Most of the code is still in there and the class will need to be majorly overhauled for my purposes, but what's there is a good start.

There are a few things about the starter kit that make me scratch my head. For example, take a look at this code from the Player.cs class of the starter kit:

// Calculate bounds within texture size.            

int width = (int)(idleAnimation.FrameWidth * 0.4); //12.8

int left = (idleAnimation.FrameWidth - width) / 2; //9.6

int height = (int)(idleAnimation.FrameWidth * 0.8);//25.6

int top = idleAnimation.FrameHeight - height;      //6.4

localBounds = new Rectangle(left, top, width, height);

This code is in Player.LoadContent(), which gets called once at initialization of the class. The selection I've pasted here calculates the localBounds object which gets used in a few places doing some very useful things like checking for collisions. The numbers in the comments at the end of each line represents what the calculation comes out to with my 32x32 px Mega Man sprite. I have no idea what the magic numbers above are for and the comments near the code block provide no insight on the matter either. There's a couple places around the starter kit where things like this happen, and it's more than a little infuriating. I assume that they made the starter kits so that people new to XNA could learn from them (which would explain why all the functions are otherwise immaculately commented), so it's unfortunate that there's no explaination for this. Perhaps there is and there's something I'm missing, in which case I'll edit the explaination into this post later. It certainly makes it more difficult to calculate numbers than it should be though. I thought I could pass the player's Position variable for where the player bullets spawn, and imagine my surprise when the bullets fired from his feet!

Overall the starter kit gives me a good idea of some things I need to look at to get a respectable platformer going as well as examples of how to do some basic things in XNA as well as how the XNA devs thought the flow of the program should work. I recommend checking it out if you are unsure of where to start. You can download a version of the starter kit updated for XNA 4.0 here and read more about what Microsoft has to say about their kit here.

Screenshots

To wrap up, here's a screenshot of the old windows forms code, showcasing a particularly unfortunate problem with my detection of whether the player was standing on a solid surface:

Here's some screenshots of the new XNA code that I'll be optimizing and adding to the rest of today and tomorrow:

As you can see I am checking for solid surfaces under me better now.

Although apparently shots are coming out of Mega Man's head. Oh well, at least they're shooting, that's good enough for now.

Jumping and shooting works too! Look!

How is the Mega Man clone at the start of this blog?

Why am I making a Mega Man clone?
I really like playing Mega Man. I think it's a great action game. That's not to say that all the games in the series have been stellar, but many of them are great. The first Mega Man game I completed was Mega Man X. Here's a link to egoraptor outlining why Mega Man X is important in the series and what it did right. When I was sitting around recently, unsatisfied with my previous game project (a multiplayer over the internet 3D board game in Unity) I decided to shoot for a very simple game that I would enjoy playing when it was complete. This led quickly to me thinking about the NES Mega Man games.

What has been done so far?
My initial goal was displaying a character and allowing the player to control that character. So I've got horizontal movement, jumping, shooting and animation. Some things aren't quite right yet, though. For example, the animation speed is a bit fast and I don't like the movement speed for the size of the sprite given the size of the screen. Most of these are little tweaks though and can wait until the major systems that make the game "complete" to me are roughly in place.

I also have separate classes for handling input and graphics. The idea here is to call only from these libraries inside the game and then have these classes handle the implementation details in order to make the code more portable. I don't know how good an idea this is at the moment, but I'm giving it a shot. The code is in C# right now anyhow and I'm using .NET's form class to create my window, so I'm sure I have a ton of .NET framework specific calls laying around. My thinking right now is that a rewrite is probably inevitable and I'll learn a lot from this decision as I come up against it's limitations. When I learn those lessons, I'll make a separate post about it.

What am I planning to implement or improve right now?
I know I have a problem where you can jump in the air multiple times if you're shooting, so I should probably weed that out before I do too much else.

Aside from that, I want to implement enemies that die when shot and shoot back. Also, it's important to have multiple enemies and to design them in such a way that they make sense from a code standpoint. What I mean is that I want the code for the enemies to be uncluttered and be easy to read and modify.

Code readability and simplicity is something that I should strive for in all areas, but particularly my experience in making my Silverlight 1942 clone has made me realize the importance of this. When I wrote that game, I was largely following a tutorial talking about some features of Silverlight that were nice for gaming (if I can ever find the link again, I'll try to remember to put it here). The tutorial implemented a resource pool (which I do want to put into my Mega Man clone) and a singleton pattern (which I'm not so crazy about). The singleton pattern gave me trouble for enemy and bullet logic in that it used delegates for update logic and creating instances of the different versions of the item. I'll probably just dissect that code in a later post and look at what I liked and what I didn't like.

After that, rooms/levels might be nice to implement.

Declaration of Intent

I'll keep this brief since pontificating is not the point of this blog.

The goal of this blog is to organize my thoughts and track my development as a programmer in relation to video game software design and execution. I've been wondering lately whether my daily web development job is really where I want to be in 10 years and after talking to an old friend of mine who, as it turns out, is now working for an indie game company, I'm not sure it is. I've been thinking for a while that game development might be more my thing.

I've been very interested in making games for many years, dating all the way back to my childhood, playing on the old IBM computer writing (very bad and rudimentary) text adventures in QBasic. In college I wrote a game for my girlfriend based off Princess Maker. It had stat planning, multiple endings, and a handful of bugs, but it worked most of the time. Looking back on it, it was a hot mess. After that, I made a simple Silverlight game modeled on 1942. Then I made a Silverlight point and click game engine, which I used to write a game for proposing to my girlfriend. Since then, I've created a few projects here and there but none have reached a truly playable status. My most recent of these idle projects is a Mega Man clone, because I like playing Mega Man games.

I will begin this blog by chronicling my development of my Mega Man clone.