I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the eighteenth episode on working on your game development weaknesses:
Welcome to the adventure mechanics side quest, it's me, Chandler. For this month, I've committed myself to focus on one solitary thing for Cartogratour: Art. I've committed to this because I feel like it's needed at this point. I have the bones for much of what I want in the game and I've kinda hit a doldrum of sorts. I was inspired by a game jam that I entered mid-April which was just doing a mockup of an imaginary game. It was called the mockup game jam. Original title, I know, but it helped me personally practice making artwork for a game. So, let's talk about practicing things you aren't good at in game design.
We should probably start by talking about how to take an honest inventory of your skill set. Meaning, you need to look at your previous work and evaluate yourself. Some things are going to be really proud of, other things not so much. And don't just do it for your last game, you should do it for every game. The primary thing to remember is that you did the best that you could after the time. A faultless self-inventory, if you will. Game design is a skill, after all. The best way to learn is to evaluate what you've done and how you could improve it. A useful metric to judge yourself by is what the Ludum Dare rating categories use for the compo. They are: overall, fun, innovation, theme, graphics, humor and mood. You don't have to use these metrics, but I have found them extremely useful in judging my own works. I'll post some of my post-mortems for my game jam games into the show notes for those interested. If you find a metric that works better for you, great. Just be consistent with it when judging your previous works. Comparing by using one methodology to another using an entirely different one isn't going to help you.
Nobody is a perfect developer i.e. No one can make an entire game by themselves and have it turn out exactly the way they want it to by themselves. That inlcudes the savants that hav made their dream game and released them by themselves. With the wide spectrum that game design touches, this is to be expected. That doesn't mean we shouldn't practice all of our skills, however. There are certain blind spots that all we will have in game design that we should be not only aware of, but willing to practice to get better at. For me, personally, that's artwork and anything audio related. Sound effects and music both mystify me, despite my best efforts. The music that I make for games ends up looping horribly and sounding like a child playing with a xylophone. Although I have some experience making decent sound effects for games, most the time the sound effects come across completely different than how I imagined them. Same with making art. I can do characters relatively okay, but doing world design and generating textures for said world is beyond my average skill set. Don't get me started on concept art that I produce. I don't think I've made anything I've been happy with in that department.
Programming, on the other hand, I'm pretty decent at. I've done coding on pretty much every project that I've worked on thus far. I feel like I have gotten a pretty good grasp on how to go about the design process and actually implement it. Not relying on a game engine has forced me to become quite proficient at figuring out how to make a given mechanic. It has also given me a low level understanding of how to implement a graphics library and other fundamental things that a decent game engine provide for you out of the box. I have found that immensely useful and it has worked for me. I have also exposed myself to several game engines on top of working close to the processor. Although limited to working with them on game jams, I've worked with both Unity, Godot, and Game Maker. Each has their own strengths and drawbacks, but they don't really scratch the programming itch for me for some reason. I just love working at that low level and coming up with elegant solutions. The parts that make a game engine run just fascinate me. That being said, only build a game engine if you want to learn how a game engine works. But, that's a talk for another time.
So let's say we've gotten all of our strengths and weaknesses figured out. There are a number of ways to improve them, ranging from focusing an entire game jam on just one or only a few weaknesses, to only spending an hour a week on it as focused study. Make sure that you aren't overwhelming yourself by adding an additional amount of work that you aren't prepared for. But also, make sure that you're giving enough time to work on your weaknesses so that you aren't just saying you're working on them. The goal of practicing with them is to focus intentionally on your weakness and making it an asset. However you end up practicing, make sure that you are consistent about it. After a week or two, or whatever length of time you feel is appropriate, go back and look at your progress from that time period. If you feel you have made enough progress improving, you can always choose another skill to focus in on. Continue on doing this until you feel like you have become a well-rounded game developer. I say that as if that's an easy thing to do.
One way to encourage you to work on your weaknesses is to give your self a little treat to work on after you've reached a milestone in your practice. One of the developers that I regularly chat with does exactly this. They will give themselves a month long goal to focus on for their project, and then work on something art related when they finish their goal. Applying this methodology to practicing a weakness is pretty straightforward. If you are weak in one field, make a goal for yourself in practice terms, such as making a certain number of character studies or something, then you can do a bug bash, or add some small feature that you want to put into your game as a reward. It's been a pretty effective method for me to do personally, but there are some things you should remember about this when working on a weakness. You have to make sure that you don't half-ass your efforts in improving your skill. The popular phrae, "practice makes perfect," is somewhat misleading. It's more like, "practice makes permanent." Meaning, anything you've practiced will be become the first way that you will approach the skill. If you practice your weakness in a sloppy or lazy way, that laziness will only be perpetuated when you use it in the future. Make wise use of your practice time.
So, in terms of me becoming a better developer, I'll be focusing in on artwork this month. Specifically, I'll be working on mockups for the mini games that I want to put into Cartogratour. I've been threatening this for a while now, but I'm going to be using the energy I got from the Game Mockup Jam and springboard back into Cartogratour. And as another form of accountability, I'll be posting the results of this focused time onto my personal blog for all to see. I'm not sure whether I'll post them on a weekly basis, or in one big dump when I finish the month. It's not exactly a huge amount of accountability, but I feel like that will be enough to get me to want to actually post what I make. And if you want to call me out on not actually posting, go ahead! I need the kick in the butt to actually finish Cartogratour. And, who knows, I may actually want to work on it even more. Only time will tell, however.
That's about all that I wanted to talk about in terms of working on your weakness in game design. As always, if you want to leave a comment, ask a question, or anything else reach out on various social media. My handle is @jcsirron on Twitter and Mastodon. Or, you can always leave a comment under this episode on our website: theadventuremechanics.com. this has been another Adventure Mechanics Side Quest and I'm Chandler. I'll talk to you next time.
