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.