Programming
Managing collections of objects in XNA: Structs vs. Classes
The first draft
At first, I wrote a nice class structure: every gameplay object originated from an abstract class called GameObjectBase, which defined methods to handle Update, Draw, and intersection with other types of game objects (projectiles, the player's ship, etc.). Then, each additional type of game object had its own abstract base class that, again, defined key pieces of behavior: EnemyBase, ProjectileBase, PowerupBase. The main game loop itself would keep track of all of these game objects, calling Update and Draw on them as necessary.
The plan here was to be able to define a new class for each type of enemy and weapon so that I can define whatever behavior I need for them. That's what I'm really going for here: I want the option to do interesting things with various weapon powerups. And I think I'd actually hit upon an elegant solution.
When you first fired it up, the game ran fine for a while. But there was a problem: garbage collection. Each new enemy or bullet created a new object and stuffed it into the main game object list; each time one of these enemies was destroyed it was removed. Considering that the player can fire ten bullets per second, that's a lot of objects. Eventually, the garbage collector had to clean up all of these old objects, essentially freezing up the game for a few seconds.
Personal Kanban board revisted
I've had my personal Kanban board up for about four months now.
No, it hasn't revolutionized my life. And no, I haven't become a scary productivity junkie, either. But there are a couple of good lessons to take away from the exercise so far.
- One, it's actually helpful to arrange the list of stuff you want to accomplish, and sort through it. You may decide not to do half of it, but at least you've taken the action of throwing it out.
- Two, don't buy the normal Post-Its. Use the Super Sticky kind. It is mildly annoying when notes continually fall off of your wall.
- Three, there is no magic approach to getting organized. Find one that works for you. Throw it out if it doesn't. The Kanban board is working for me, so I'm going to keep it for now.
- Four, you need to review your to-do list regularly to make sure it's in sync with what you're actually doing. If there are any conflicts, whatever's really happening in your life wins.
Anyway, that's the lessons learned. Now onto what I really want to dig into: the thinking behind personal goals and to-do lists.
When I set up the board, it was a way to organize a lot of different projects I had going (or, at least, wanted to have going). My main problem was that I wasn't organized and wasn't really motivated unless I was in a good mood and had a large chunk of downtime to waste. And, what's worse is, I wasn't able to force myself to let go of any items entirely--it really takes a certain amount of opportunity cost analysis to do that. That's where the task list approach comes into play.
So the main benefit of creating this complex organization scheme was to force myself to simplify. And it did. Sort of. Except not quite as much as I needed, apparently.
The first realization came through reading Anxiety, Phobias, and Panic1. The book's first chapter goes over a number of otherwise beneficial personality traits that, out of moderation, can cause serious problems--among them extremely high expectations of self, perfectionism, and excessive need for approval (which, in turn, makes it hard to say no to other people). All of these should probably sound familiar if you're even slightly tempted to jump on the latest fad in personal productivity.
The lesson here is, there's a balance. You can lock yourself down if you only sit around talking wistfully about things you'd like to do someday, when everything settles down (hint: it never will), and never do anything. But you can also lock yourself down if you set the bar too high, and put too much pressure on yourself. There's a sweet spot, and you usually have to lower your expectations to get there.
The second realization came through reading Searching for God Knows What2 by Donald Miller. One of the recurring themes in the book is what Miller calls "lifeboat mentality"3. It's the tendency to compare ourselves to others; the high-school-popularity-contest way of thinking about things. And his point is twofold: (1) it permeates our culture more than we'd like to admit, and (2) it's completely invalid.
It's not so much that this thinking drives your to-do list, but it does seep into the way you prioritize each item. Maybe you think it's expected by the people around you. Or that it's expected of someone in your position. Or you promised someone you'd do it, because you didn't want to let them down. Or you added it for the marketing or networking opportunities.
Whatever the case, you're giving it more weight than it really deserves--or, at least, more weight than the effort you're willing to put into it. And it's not because it's something you necessarily love to do or that you're uniquely qualified to do--if it were, you'd have no problem. You do it because you want to get ahead or (as is more the case for me) not fall behind. (Don't get me wrong, there is some place for that, but only in moderation.)
So, a couple of weeks ago, I eliminated several tasks that I thought violated one of these issues: either my expectations were excessive, or it was driven by perfectionism, or I was doing it for someone else who really didn't care about it as much as I did, or I re-evaluated my reasons for leaving it on the list in the first place. (I made sure to finish up anything I had made a hard-and-fast commitment to do.)
And then I noticed my board was really empty--except for the "DONE" column, which had greatly expanded. Which, strangely, made me breathe a little easier, even though every item on that board I put there voluntarily.
So, oddly enough, I started on a new XNA game two weeks ago. I've now got a real, playable engine--not just playing around, something useful. This wasn't even on my to-do list and it wasn't something I obsessed about, I just did it.
I didn't get there by using my to-do list, but I also wouldn't have gotten there without my to-do list.
1 I've realized I've become a more tense and nervous person over the past several years, and when I saw this book mentioned in a completely unrelated discussion thread I was following, I picked it up. Like I said in a previous post, it's not a motivational-speaker self-help-panacea book, so it's the type of approach I was looking for.
2 I picked up this book knowing very little about it, only that I'd read two of Miller's other books, Blue Like Jazz and A Million Miles in a Thousand Years: What I Learned While Editing My Life. The book is basically an apologetic for Christianity, asserting that our culture has taken a relational narrative and turned it into a set of checklists and rules.
Incidentally, A Million Miles is a great book if you're one of those types that sits around wistfully talking about doing things someday, but never gets around to it. The idea of living a story seems a bit simplistic, but ultimately helpful--so long as you take it as one alternative perspective on life rather than a panacea and the basis for your worldview.
3 The name comes from the game/exercise referred to as "Lifeboat"--you can read a dry written example here, or you can have it explained by a satirical 80's Christian rocker dressed in drag.
Crash issues after installing VS2010 Beta 2 / .NET 4.0 Beta 2
This is a random post, but I figure it might help someone, since I couldn't figure out what was going on for the longest time.
I installed Visual Studio 2010 / .NET 4.0 Beta 2 last night. When I restarted my laptop, I noticed that both the Microsoft Online Services Sign-In app and the Curse-Gaming Client crashed. When I tried to start them manually, the same thing happened.
There were no errors in the Event viewer and no log files, so there was no obvious reasoning. Repairing the .NET 4.0 and .NET 3.5 SP1 installations didn't fix anything either. The only clue I had was from trying to debug the crash in Visual Studio when prompted by Windows. Even then, the error was still cryptic: The type initializer for 'MS.Win32.Penimc.UnsafeNativeMethods' threw an exception.
Several Google searches later, I found the following fix:
- Run Command Prompt as Administrator.
- cd \windows\microsoft.net\framework\v3.0\wpf
- regsvr32 PenIMC.dll
- cd \windows\microsoft.net\framework\v4.0.21006\wpf
- regsvr32 PenIMC.dll
Once that was done, I was able to run both applications without error.
Personal Kanban board
This relates a bit to my previous post, I suppose, but I ended up setting a personal task board up last week. Mike, Cicelie, and I had a lot of success doing this with IncaBlocks (although we also used Zen).
I've put my task board within view of my computer workstation. Literally, I can't miss it. The purpose is for me to organize all of this nebulous "stuff I need to do" (around the house, on projects like IncaBlocks, for other people, etc.) into an easy-to-maintain, prioritized list.
I'm hoping it also motivates me a bit more--most of the stuff I need to do could be knocked out in anywhere from 30 minutes to a few hours. However, I'm usually reluctant (especially after working all day) to tackle it unless I'm completely relaxed and have a large block of free time. These things just seem bigger if you don't define them.
To that end, I've set up five categories: "NOW" (the stuff I can do right now), "LATER" (the stuff that's lower priority), "PROBABLY NEVER" (the stuff I say I'm going to do but probably won't), "NOT MY PROBLEM" (the stuff that I'm waiting on other people for) and "DONE."
"Not My Problem" is a bit harsh, but you have to understand my personality. I've found that lately I have approximately zero capacity for cognitive dissonance; I tend to throw myself in (at least mentally) pretty deep when people start tossing valid, doable ideas around. And then I get run down and impatient when I realize they're not serious. So I need "Not My Problem" as a reality check. (If you heard some of the project management and organization discussion on early episodes of Feel The Func, this shouldn't surprise you.)
Also, the currently-empty "Probably Never" column has prompted my roommates to put up their own interesting and amusing items on my task list. (Let's not discuss just how interesting and amusing they were.)
Success? Well, I've only finished one task so far.
Iterative/Agile for the (Non-Software-Developer) Hobbyist?
So, I just got back from Anime Weekend Atlanta. It was a fun time, and I swear there's a blog post coming... right after I finish my long-overdue post for DragonCon.
My friends and I attended a couple of the costuming panels, mainly armor making and steampunk. And there seems to be some traction of trying to do a steampunk group for next year, which I'm all for--I like the idea of getting everyone together to work on a project as a group, although I'm not quite as gung-ho about steampunk as some of them.
The problem is, discussion evolved from creating some basic themed costumes into talk of complex armor and props as the centerpiece. It went from things we know how to do (sewing and simple props) to things we don't (woodworking or vacu-forming or resin-casting or even large-scale paper maché).
In a word: feature creep. Waterfall design. One that could easily end up half finished before it runs out of... um, steam. No question that it's creative outside-the-box thinking. But you need to think inside-the-box to wrangle that vision into something possible and affordable.
As a software developer, I'm naturally inclined to think iteratively. Start with the essential stuff that you know you can do. If you go no further, at least you have something usable. Then, when you have a working product, start tackling the tough stuff that you've not as familiar with. Break it up into phases, and be willing to say "I'm done" at the end of any phase if time, money, or motivation force you to do so.
Now, when you're talking about projects in the real world, you can't always do that. It's tough to construct a single building in stages. Nor can you call a painting done once you've done the preliminary outlining. Nor would formal agile methodologies work quite the same way in a casual, small group environment. But it seems there's some value in having this alternate perspective in the back of your mind to guide you as you do your planning.
It makes me want to write an article series, a con panel, something that would introduce these concepts in non-technical language to people outside of software development. Not to spread the agile kool-aid around (because if there's one thing I hate, it's buzzword kool-aid), but to give hobbyists of various types another tool in their toolbox that they can use when it's appropriate.
Surely someone out there's already written this, though. Anyone know where to find it?
