This is a duplicate of a post on the Digitanks website
Lately I've been feeling like I have way to many things to do and not enough time in the day, so at the risk of sounding like a middle manager rife with meaningless anecdotes about synergizing with improved productivity, for this edition of the Digitanks development journal I thought I'd share with you how I keep my sanity in three easy steps. My past week has been spent just refining existing gameplay so there's not much game-wise to post about, so read on to learn about my patented method of attacking problem solving.
You've been working all day. You're tired. You have one more thing you need to do before you go home, but it's a monster. It's huge and complicated and you can't fit it all in your head. You have no idea how you're going to even approach the idea of solving this problem, and you don't know where to start. You need to simplify.
As I've covered in previous articles (I think?) any problem can be broken down into a number of smaller steps. Once you get the problem down to a series of bite-sized steps, it suddenly looks like a piece of cake. It gives you a starting point, and it helps you stay motivated since you're only having to attack one small task at a time, and you no longer have to look at the bigger picture.
When I began working on Digitanks, it seemed like a huge undertaking. So much stuff to do! So I sat down with a piece of paper and wrote out all of the individual parts of the program that I would need to tackle.
- Application framework
- Tanks shooting and dying
- Base building
- Multiplayer code
You can also conceptually simplify a problem. I spend a bit of time each day (usually in the morning just after I wake up, or in the shower) reflecting and thinking about the problems I have to face on that day. Oftentimes just thinking about a problem can reveal its inner simplicity. Like Cesar Millan says, life is really very simple, but people tend to complicate things. (Cesar's my hero by the way, my dog is well trained and behaves thanks to all the stuff I learned from his show.)
A while ago I had a problem with one of the libraries I use to render text to the screen. At some point if I was drawing too much text, the library would start crashing, because it had too many file pointers open to the same font on the disc. It was affecting both Digitanks and SMAK, (they use the same UI library) but Digitanks was affected even more since it can draw a great deal more text at any time. I was at a total loss of how to solve this, since it happened deep in the bowels of a support library that I didn't understand. I ignored the problem for a while (ignoring a problem in hopes that it goes away can be a fairly effective way of solving the problem, sometimes -- just don't try it with your bills) until the day that I realized the problem was really very simple. I was opening one font for every bit of text I wanted to draw, instead of opening one global font object and using it for all of the text. It ended up being a 10 minute fix once I realized what the real problem was. But, rather than bang my head against the keyboard for hours or days, I just let the problem stew in the back of my mind until the inner simplicity became apparent.
OrganizeOrganization once conquered the world. It's a fact. I'm talking about the Romans. Many problems present themselves because of lack of organization. I can't tell you the number of times I've had to go in and rip out a bunch of code that was just too messy, due to not having been properly thought out ahead of time. After I think of a better way to organize that code, typically the number of lines of code gets reduced by half or more.
One of the bits of feedback I received from playtesters was that lack of camera control was a major drawback. So, some time after the last demo, I put in some basic camera controls, where clicking on a piece of terrain would move the camera there and using the scrollwheel could zoom in and out. Over time though, the camera code became a mess, it was scattered all over the place. It was very difficult to debug or change something. Eventually I said enough is enough, and I created a "camera class" which was a single, centralized place for all camera-related programming to remain. Then, when an important event happens that requires the camera to be centered, it calls into the camera class to center the camera at that spot, and the camera class handles all of the specifics. Now all of my camera-related code is in one place, it's very organized.
I tend to be a neat person. I really don't have many belongings, just my laptop, some musical equipment and a futon for sleeping on. So my floors are always clear, tables don't accrue oddities, because I have no problem throwing things away with they're no longer needed. When it comes to my desk though, it will tend to accumulate crap. I'm typically engrossed in my work, and I don't like to have to tear my attention away to do other things, so they get piled up on my desk with a promise to take care of them "later." Of course, "later" never comes, and the piles continue to grow higher until the moment that I say "enough is enough" and turn my attention to reducing them. Here's where organizing comes in. Some things go in the trash pile, some things go in the "file pile" to be put in cold storage in a filing cabinet and hopefully never seen again, and some things go in the "need my attention" pile. Then, after everything's taken care of, my desk is clear and organized with everything in its place -- this is typically the period where I'm the most productive.
Now it is possible to be too organized. In my last post I talked about how the Romans lost the battle of Cannae. The reason for this is that the Carthaginians knew about the Roman's organization and exploited it. They knew that the Romans would advance in their tightly knit columns, carefully monitored by the now-predictable generals whose strategy was to advance until the enemy was obliterated. So, the Carthaginians allowed them to advance, slowly retreating the center of their lines, but leaving their flanks to envelop the sides of the enemy force until the Romans found themselves surrounded. They were so organized that they had forgotten to be agile enough to respond to new circumstances.
I worked once at a company that was about three programmers. They decided to implement a new all-in-one project-management, issue-tracking, and time management software system. The problem was, there was only three of us. There weren't hardly enough people to actually merit using all of these complicated procedures. It was eating up more time in the updating of the system than it was saving in organization benefits. We were all three in the same room, if we wanted to know the status of an issue we could lean over our shoulder and say, "Hey John, what's the status of the menu bug?" and John would reply, "Oh I fixed it a couple hours ago." In an organization of 30 or 300 people, you need sophisticated software to handle that, but with just three people, we became a slave to the process of updating the software, and actual work ended up suffering.
PrioritizeSo now you have your organized list of simple problems, just waiting to be solved. Problem is, there's about ten thousand of them. If you're like me, for any project of nontrivial size, you have a list ten miles long of things remaining to do, many of which you'll likely never have time to complete within the time allotted for yourself. You need to prioritize.
Many tasks can be put into one of two categories. It can be the kind of task that nets you 80% of the gain for 20% of the work, or it can be the kind of task that can net you 20% gain for 80% of the work. I call the latter "polish work" and the former "fantastic." In the excitement that's associated with any project, it's really easy to get caught up in the latter, especially if you have the kind of workhorse personality that I do. Artists tend to polish something to a fault. It's never perfect, and you can always tweak and tweak and tweak ad infinitum. Ten hours later, you realize you wasted the entire day on a model of a dirty shoe when your main character is still a big box.
Every day before I start work, I take a look at all of the things that Digitanks needs, and I work on the parts that are the most sorely lacking. For instance, at the moment a lot of people have been mentioning that they're frustrated by the lack of movement in Digitanks. This is kind of strange to me since in many turn-based games the movement per-turn is very limited. In Civilization, the first units the player gets can only be moved one tile per turn, but nobody complains. I increased the movement radius, in fact I almost doubled it, but that didn't really solve the problem. I think the reason that people are bothered is that in Digitanks there's no tile grid, so players take movement for granted. The game looks more like StarCraft, and players expect to be able to move wherever they want. That's my biggest problem, so it's what I'm focusing my time on right now. My solution is a pretty simple one, if you click to move outside of the tank's movement radius, the game will remember that and automatically move that tank over the next couple of turns until it gets to the location the player clicked. Now, there's another issue that I have yet to deal with, which is that the top of my tank's turrets look BORING! They need something to spice them up and make them look less plain. But it wouldn't be a very good use of my time to work on that when the structures are still large boxes, so I put it at the bottom of my priorities list.
The way to get everything done that you need to do is to prioritize which items are most important, and do those first. You may not get to the things on the bottom of the list, but you can sleep well knowing that you made the most impact you could. By the way, lots of people have been asking me to include a way to allow comments on the blog's homepage. I'm working on that. For now, if you have something to say, just send me an email. I love getting emails!