It's been a while since I wrote a blog post. Don't get me wrong, I've been devlogging and making videos for my current game-in-development, Code Name: King Randall's Party. OK, not so much of a code name as the games actual name, but I gotta make efforts to be super cool like the big boys, right? Anyway, today I wanted to write about the power of making checklists when programming.
I read a lot of articles about how programmers need a lot of uninterrupted quiet time in order to get their work done; after all, it's hard to keep the scope of what you are trying to do in your head if you keep getting interrupted. However, that's not always a possibility. I currently live at home with my folks while I develop this game, and my room is on the first floor with doors that open to both the house entrance and the back hallway. Suffice to say, I get a lot of traffic. Also, since they are helping me out with rent, I like to help out around the house, and want to encourage my folks to ask me to help with stuff, when reasonable. But that means I'm going to get interrupted more often than I would typically like. So I formally gave up trying to keep a problems scope in my head all at once, and instead keep it in a notepad. What does that really mean though?
Well, whenever I face a tough challenge I write down a design for the system on a notepad. What do I want it to do and what I want it to do. Then I start writing down a technical design which includes a list of all classes and methods and how it is going to affect and/or interface with them. Of course, I don't get it all in one go, but I find that it's easy enough to add to this list as I develop. Having it all written down has some other benefits too: I have a checklist for what needs to be done, and clearer vision of exactly how the feature will fit into the program. Whenever I use this method, I inevitably get the system completed faster and with better quality than if I had just jumped straight into programming.
This kind of protocol is unnecessary for smaller tasks, obviously, but I usually do it anyway. You never know when something you thought was going to be simple ends up being obnoxiously complicated in ways you couldn't have predicted until you sat down and detailed it out.
When you are about to program a system, how do YOU go about planning it? Or do you not? I'm interested in hearing about what works for others.
So lately I’ve come to the conclusion that I’ve gotten apretty good handle on this “coding stuff”. I've been doing OOP for about four years now, and I've got a really, really solid handle on it. But one area I still really need to work on is in mycommunity outreach, marketing, whatever you want to call it.
A lot of developers create a personal marketing story bywriting blog posts or explaining features in their games and/or writinghow-to’s for other developers. Some devs write about games from a higherperspective: they talk about what games are, what they should be, what they aretrying to tell us, or how to develop them better. What I’ve been strugglingwith for the last few days was, which of these activities is real match for me?Not just me, but my audience. I’m a kindof light hearted guy, and the idea of sitting down to write in-depth, detailedaccounts of how systems work and stuff… man, it just sounds boring. I know somefolks like that, but it’s not my cup of tea. So what IS my flavor of teadammit!? Well, my father gave me an idea that I ended up taking to a usableconclusion that I’m going to test out over the next several months. Developmentstories from the perspective of characters within the game.
Whenever I want to convey something to my audience – a newfeature, a bug fix, etc., I do it through the vehicle of the characters withinmy game. Maybe the Head of the Royal Engineering Corp. publishes a memo to allEngineers about how the Royal Treasurer has been building his forts near chasmslately, that ass, and so bridges will be necessary to navigate the steepterrain – materials to be found in the kennel due to lack of storage space –watch out for the dog in the third pen to the left. This is really beneficialbecause…
A while ago Tadhg Kelly (www.whatgamesare.com) started writingposts about this funky concept called a Marketing Story. I’ll quote from hiswebsite since he tells it much more eloquently than I would have paraphrased:
“A marketing story is a tale that you tell to theinfluential people in your market, which they then tell to other people. Thestory of who you are and what your game represents becomes a part of dailyconversation, which makes people interested and leads to sales. Marketingstories come in many shapes and sizes, but the common trait that they share istheir ability to spread.”
Whoah, that’s a super useful way to think about marketing. Itdoesn’t focus on the nuts and bolts of press releases, blog posts, and mediacontent – all of which can be very overwhelming for a novice like myself.Rather, it focuses on the larger picture of what people will say when they talkabout your game. That is something which is really important to take a day ortwo to think about during the early stages of any games development, becauseit’s important that people are both talking about your game, and that you havealready provided compelling language for them to use.
I've gotten better at this over the years, but sometimes in the modern age of "I need this now and I expect it yesterday" I still get surprised that getting something done takes, you know, TIME. Case in point, I designed some business cards yesterday to use at a industry meet-up next week, only to find out that the fancy styling I wanted to order requires 5-7 business days to complete. Plus shipping. Suffice to say I won't have my fancy cards for the meeting; I'll have to print some basic ones at a local printer.
In my world, if I get something done a week or two ahead of time, I'm golden. However, when relying on others, whether it be for programming, art, or business cards, it is important to add in a buffer of extra time to make sure you get the work done on time. Thankfully this time there was an easy fix, but sometimes there isn't.
Showing off is super important. I don’t mean that in the hot-rod, flashy, “Look at my car and my super awesome muscles” way… though if I have to say so, my muscles ARE super awesome. What I mean is, it is very important to show your work to people. And not just show them, but PLAN to show them, and tell them about those plans so they can hold you accountable if you don’t.
This point was driven home to me a few weeks ago when I showed off King Randall’s Party at the Made in Mass Developers Party, which occurs every year before PAX East. Hosted by some friendly faces at Microsoft, people treat it mostly as a party; great beer and food is served, and we are surrounded by our fellow developers. At the same time there are tons of tables where developers from MA can show off their games and provide entertainment for the party goes. It’s a real win-win type of event.
In the months leading up to the party before it was confirmed that I would have a table, I had been working hard on KRP, or so I thought. After I got confirmation that I would have a table at the event, my development speed jumped tremendously. Just the thought that I would have hundreds of people looking at my game really drove me to produce higher quality work, faster. I've noticed this effect also occurs whenever I tell someone – a friend, family member, or someone else whose opinion I highly regard, that I’ll show them XYZ on such and such date.
Sometimes you just have to stop fixing things and let it be broke. Selectively, mind you. I reminded myself of this as I came out of a daze and looked out the window. I looked down at my rumpled clothing that smelled of rank cheese and desperate hope (typical for indies), and realized it was not winter anymore. Fifteen days of fixing AI Pathfinding so that the enemy could navigate the different environmental scenarios that the player can create. The enemy can now do a seriously good job of navigating the terrain… but not a perfect job.
But I realized that at this point it’s better to leave some of those scenarios unfixed for now and move onto other stuff, IMPORTANT STUFF. Stuff that is core to the KRP gameplay, like traps and structures the player can build.
It’s easy as a programmer to get sucked into a problem and tell yourself “I have to keep going until this is perfect”, but oftentimes you can get it “good enough” to move on to more important tasks, and revisit it later during the polish stage.
I spent today writing the description section of my upcoming Kickstarter campaign, and creating a TON of images for it as well. While doing this, it struck me as amazing how much time I spent working with images as an indie developer. Sure I contract out the in-game artwork and some specific images, like the background to the King Randall's Party website, but I end up doing pretty much everything else myself.
So while this is my own opinion, I'd throw this out there to any aspiring indie developer: you gotta be familiar with a graphics editing program. Grab Photoshop (or pay for the really well priced monthly subscription to it) or even just GIMP, which is what I use. You'll be able to whip up a ton of images using your in-game assets on the cheap that will be SUPER helpful in pretty much anything you do. Launching a Kickstarter campaign? BAM, image. Sending out a press-kit to gaming website? BAM, image. Editing your fellow indie developers faces onto Paris Hilton pics? BAM, image.
So I guess what I'm saying is - not everyone is as rich as the King. For the rest of us, it's a huge money saver to be familiar with and willing to use a graphics editing program - even if you're not an artist.
We are getting together a proper page to represent our project, but we just couldn't wait for that to happen before getting started! This page will list some useful information about the project.
Kung Fu Kingdom was started as a hobby project with the intent of allowing developers, who otherwise don't have the opportunity, to be able to contribute to a small commercial XNA project to gain experience within the industry and bolster their resume.
We are currently looking for a Programming Manager who will be able to take the Kung Fu Kingdom feature list and break it into groups of tasks which can be successfully passed out to interested developers. Upon the completion of these tasks, the programming manager is responsible for checking the quality and accuracy of the submission, and then merging it into the final product. This person will be responsible for the overall quality and organization of the code-base.
In addition, we are looking for talented developers with any type of skillset looking to volunteer some of their time towards interesting game design and development challenges.
Visit our Contribute! page for more information.
Kung Fu Kingdom will be released on both XBox XNA Community and PC sometime in Q4 2009 - Q1 2010 unless something goes horribly, horribly wrong. Like a meteor strike. Or a earthquake. Or Mongol invasion.
To-Do List updated.
Only changes are noted, for the full to-do list, visit the linked to page.
If you wish to sign up for any of these tasks - contact me!
Assemble final website