Monday, 3 June 2013

The Common (Re-)Factor

Have I submitted to this blog before? It must have been some forgotten time because the sense of familiarity is but fleeting.

I kid.

In one of my earlier posts, I mentioned that a lesson I had learned was to never implement flexibility for the sake of being flexible. In retrospect, I would like to modify that statement. Flexibility for the sake of flexibility still bogs down the development process with needless problem solving but flexibility for the sake of impending future addition is still important. A lesson that is becoming all to clear as I revise not only my wisdom but my code as well.

Breadth Over Depth

This is a poorly planned metaphor.
While writing The Wanderer over the last month, my first task was to get as much of my code functional as possible. I wanted to have something to show off and be proud of but alas my arrogance was my folly.

By ignoring the need to account for future features in my code, I quickly found my code messy, improvised and incredibly rigidly structured. In order to get the basic game elements out quickly, I sacrificed future development. Hey, didn't I mention previously that was something I wanted to avoid?

The past couple weeks, while containing the introduction of new features, included a whole lot of refactoring. Refactoring? [Refactoring is] The process of modifying existing code to improve efficiency, functionality or simply for sport. It's an important process and a common one. Unfortunately, more common for me than I'd like.

A great example of this is my map generation algorithm.

Originally, all my map generation did was place blocks in vaguely building-like shapes in order to generate vaguely town-like maps. Although still fairly abstract in it's resemblance to real world architecture, the current algorithm accounts for item placement, trader placement, stair placement (Oh yeah, I added dungeons.) and a multitude of other factors.

Although it doesn't seem like much, when you don't build your code originally to account for the introduction of new features, you end up redesigning large portions to make it all fit together. Adding tilesets into the game meant that I needed to generate new ground textures. This led me to needing to store the textures. I did this by placing them in the same grid used by the wall blocks. This led to me needing to redesign the movement system. This led to me needing to redesign the ghoul ai.

See where I'm going with this?

My Second Rodeo

What should I do next time? I wouldn't advocate building each part of the game to 100% completion at once. That's a fantastic way to get burnt out. One of the biggest successes of this project was to instead break the game down into small tasks that were easy to complete. It allowed me a sense of progress which helped keep me on task and motivated.

Next time I think I need to plan out my systems better. Plan them out with future features in mind. Features I know I'm going to add. Like I said in one of my first posts, I won't focus on making things work that I will never need to use nor account for but planning for impending expansion is a necessity of good code. Plan systems that work now but will also work without too much grief.

One of the easiest methods to achieve this is organizing and segmenting code cleanly. Organize functions properly into functions. Use helper functions. Find anyways to make your code more flexible without actually changing the system. This helps a great deal when modifying it later and modify it later you will.

Get to it.

The reason this post is gradually getting less coherent.

Just keep your code cleanly organized and you'll be okay. Keeping your code as modular as possible with your functions and classes helps a great deal too. It's far easier to modify one feature than a dozen interlocking features.

All in all, the big takeaway is to build your code with the understanding that even when it works, it won't be finished. Even when you release your game, it won't be finished. You should always act as if you will need to modify a piece of code later. If you keep that in mind, your refactoring will go a hell of a lot smoother than mine.

No comments:

Post a Comment