Thursday, May 24, 2012

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.

No comments:

Post a Comment