Corvus has done more involving story and play than anyone else I know. He has a wealth of knowledge about games, story, play, and community. He’s worked for decades exploring various aspects of “participatory storytelling,” and he talks about the meaning of game mechanics in his Notebook, among other topics. On his old blog, he hosted the Bloggers of the Round Table, which always had fascinating, thoughtful posts on all sorts of topics related to games. Every time I interact with him, I feel privileged because I always come away with a new idea or thought.

So it is with pleasure that I ask you to pledge to fund his current project, Bhaloidam.

What is Bhaloidam? It’s an open and accessible storytelling platform, but Corvus can explain it better than I can in this short video:

I could say it is like a powerful yet intuitive Dungeons and Dragons, but it is much more than a role-playing game system, and I would be doing Corvus a disservice.

Bhaloidam is the expression of my belief in the power of story and play and my belief in the importance of our communities.

If you want to see Bhaloidam in action and get a feel for it yourself, you can schedule an online game play demo.

The Kickstarter project is, at the time of this writing, 60% funded, but there’s only a week left to get the remaining 40%. Do you have $9 to pledge?

Bhaloidam is the culmination of all my creative, philosophical, spiritual, and intellectual, personal, and professional pursuits. It allows me to be an actor, a cartoonist, a computer animator, a writer, a director, a web designer, a storyteller, and while it doesn’t allow me to be an architect, the application of mathematics to creative expression scratches what I imagine is much the same itch.

…

So, Bhaloidam (both as a storytelling platform and a philosophy) is it for me. I am Bhaloidam. Along the way I’m sure to design more games (In fact, I’ve three in the works), but it’s Bhaloidam that lies at the heart of my career. It’s Bhaloidam that reflects not only who I am, but who I have been and who I want to be.

You can read more at the official Bhaloidam site. With a $9 pledge, you can help make Bhaloidam happen, and you’ll get an electronic copy of the 72-page, full-color, comic-format Bhaloidam handbook. For $9 more, you’ll get a printed copy.

There are also many other options available at different perk levels. For $45, for example, you’ll get the “skein pack”, which includes 1 printed copy of the Bhaloidam handbook, 4 Lifewheels, set of 360 tokens, 4 timing track pawns, and a set of 3 custom dice. You can also choose to give it to a friend as a gift.

So I’d like to ask you to do two things:

1. Pledge at least $9 to fund Bhaloidam. There are 12 different perk levels, from the basic ebook to the $900 “Storyteller Special.”
2. Tell at least one other person about Bhaloidam. Send them to the Bhaloidam site, tell them about the Bhaloidam Kickstarter project, and invite them to the online game play demos Corvus is hosting.

Let’s get Bhaloidam completely funded!

Do You Have $9 to Kickstart Bhaloidam? is a post from: GBGames - Thoughts on Indie Game Development

I’m not celebrating because it’s not a good milestone to hit. I didn’t know how long it would be to take the Ludum Dare #18 prototype and make it into a full commercial-quality game, but I did not expect it to take a year. In fact, when the 2010 Ludum Dare October Challenge was announced, I thought a month sounded like a good time period. If it took three days to prototype the game, surely four weeks would be plenty of time to polish it up and release it.

Tomorrow is October 1st and the 2011 Ludum Dare October Challenge (even though an announcement went out saying that it started already), and I was hoping to have the game released before then. In fact, I thought I would have something released by today, but there were some AI issues I tackled last week that I’m still working on.

But eventually I am going to release my game, and I realized that I have never accepted payments for a video game before. Until last month, I wasn’t even registered with a payment processor.

So last night, I posted a few pre-order forms on the Stop That Hero! website. If you want to get the game when it is released for Windows, Linux, or Mac, you can reserve your copy of the game now.

In posting the pre-order, I realized I made a big step. I had some nervousness, partly because I’m selling a game that isn’t released yet, and partly because I’m asking for payment. I’ve never done it before.

It’s possible that no one will care, that no one will even click on the links to buy, but that’s not the point. The point was that I decided to ask people to do so in the first place.

You can’t make money without asking for it, and I decided that until the game is released, the worst-case is that no one bothers to pay me for it. But if I don’t ask for pre-orders, then there is a 100% chance that I won’t get paid anyway.

I’ve taken a step to change that certainty into a possibility, and it’s one of those moments that makes you feel good to run your own business. I don’t have to accept circumstances. I can take action to change them.

In this case, my game is taking longer than expected to make, and I could decide that it means delaying the possibility of sales until the game is released, but I could also try something to see how it goes. The worst case is that it has no effect, that no one will reserve their copy of the game, but there’s a potential now for a lot of upside.

And now I’ll get back to work. Eventually any pre-orders have to get fulfilled with a real game, and I’d like that to be before the end of another month.

Getting Used to Accepting Payments is a post from: GBGames - Thoughts on Indie Game Development

Members of the general games-playing public are invited to show up, meet local indie developers, and play the games they’ve been hard at work creating. It’s fun, it’s free, and absolutely everyone is invited!

I’ll be demoing Stop That Hero! for the first time in public.

When? 1PM – 4PM, Saturday August 20th, 2011
Where? 243 S. Wabash Ave Room 924

View Larger Map

Do you plan on attending?

See Stop That Hero! in Chicago is a post from: GBGames - Thoughts on Indie Game Development

Check out the 2011 candidates to get your last minute votes in!

This post was scheduled to be published at a time when I will not be able to access the computer. I’ll respond to comments when I return at the end of the month.

Last Day to Vote! is a post from: GBGames - Thoughts on Indie Game Development

I saw some people playing this game earlier during GDC outside of the IGDA booth, and I wish I hadn’t pulled a back muscle recently so I could participate.

I recorded this second session, which was much bigger. I had to stop recording since the Moscone Center was closing for the day and I was not a volunteer, but I tried to capture the thrilling conclusion to this session:

I need to hang out with playful people more often! B-)

EDIT: Ah, it’s an Indiecade thing! Free Ninja

This post was scheduled to be published at a time when I will not be able to access the computer. I’ll respond to comments when I return at the end of the month.

What Is This Ninja Game? is a post from: GBGames - Thoughts on Indie Game Development

The Independent Games Summit was full of different groups of indies. Some knew each other from TIGSource. Others have been around forever. And since we’re all indies, we each had our own unique story and reason for being there. Even so, it felt as if everyone knew each other and were fairly supportive. It was like a very odd yet loving family.

I only had a Summit & Tutorials pass since it seemed to be in the sweet spot between the too-expensive All Access Pass and the “let’s hang out with people who want to find a job at the Career Pavilion” Expo pass. While I couldn’t attend a lot of the cool talks and panels in the later half of the week, I was still able to attend any of the summits.

At one point, I skipped out on the IGS summit for an AI summit talk on pathfinding. James Anhalt of Blizzard talked about the pathfinding problems of StarCraft 2, Alexander Kring of Nihilistic focused on Heroes on the Move, and Nathan Sturtevant from the University of Denver worked on Dragon’s Age: Origins. They each gave a glimpse into the tech behind the games, and the Q&A session at the end made me laugh because it was almost all complaints about StarCraft.

If I would have attended the Google Android Day tutorials, I apparently could have received a free Google device. I didn’t, but I got to see the long line for the tutorials that morning. It’s kind of the same, right?

On the other hand, I did sign up for an Intel AppUp event with Mike “PoV” Kasprzak and Phil “philhassey” Hassey and received this baby:

It’s a Meebo-based EXOPC Slate! I finally got a cool consumer electronics device!

The best part of GDC was meeting everyone I’ve only ever spoken to on IRC or on web forums. Whether I was having lunch, standing in line, or walking to a session, there was always someone’s name to call out to and say “Hey! I recognize you from your online avatar!”

I briefly met Leigh Alexander, Drew Sikora, Ian Schreiber, Noah Falstein, and Derek Yu. I met game developers I’ve talked to on the Indie Gamer forums and in the #ludumdare IRC channel. I met game developers I’ve only heard about in passing.

And I got to hug Corvus Elrod of Zakelro! Don’t forget to vote for the 2011 IGDA board!

The Ludum Dare meetup was fun and had a good turnout:

There were so many of us, we needed multiple tables!

And here’s a link to a bunch of us wearing LD48 shirts.

And one action shot of PoV eating:

I was finally able to attend the Independent Games Festival and the Game Developers Choice Awards.

Congratulations to Mojang for winning five awards between the two events, including the Seamus McNally Grand Prize in the IGF!

At the end of the week, we had the Ludum Dare Jam at Noisebridge, a really cool hacker space.

And an action video of Phil Hassey sleeping:

I had to leave the jam early and get on a plane the next morning, but I definitely want to do GDC next year! Heck, two days into it, I half wanted GDC to be over so I could get back home and make games sooner!

In the meantime, what was your favorite part of GDC?

This post was scheduled to be published at a time when I will not be able to access the computer. I’ll respond to comments when I return at the end of the month.

The After GDC Glow is a post from: GBGames - Thoughts on Indie Game Development

WOOOOOOOOOOOOOOOOO!

After years of being one of those people who was a bit jealous of everyone who was going to the Game Developers Conference, I realized that I’m now one of those people to be jealous of. Today I will be setting foot in San Francisco, and tomorrow I will pick up my badge for the GDC!

And then I’ll be wide-eyed and star-struck and generally feel like the humble newbie I am. B-)

I’ll be attending the Indie Games Festival for the first time, meeting Ludum Dare regulars at the Ludum Dare meetup for the first time, and otherwise taking in the sights and sounds of GDC…for the first time!

I’ll be there through Saturday, so feel free to contact me through Twitter: @GBGames

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! GDC!

Off to My First GDC! is a post from: GBGames - Thoughts on Indie Game Development

And somehow I hadn’t realized it before. I knew that the interface should be separate from the game, but I didn’t know that the interface was responsible for more than merely displaying the game world and its objects. It’s a heavy-weight in its own right, handling menus, HUDs, and inputs that the simulation ultimately doesn’t even know is happening.

I used StarCraft‘s interface to illustrate the idea that the player interface is more than a mere window into the simulation. It can have complex logic that the game simulation doesn’t actually care about. As far as the simulation is concerned, it receives commands. Most of the actions you take in StarCraft do not result in commands to the simulation.

If you click on an SCV, and then click the Repair button, and then click a burning Bunker, the interface is responsible for figuring out what you’re trying to do. It isn’t until you click on that Bunker that the simulation receives a command along the lines of “SCV 1 REPAIR BUNKER 5″. Up until then, only the interface has to know you’re working with a particular SCV, what commands are available to an SCV in general, what buttons to display in the SCV menu, which SCV menu you’re looking at, etc.

Stop That Hero!’s interface

Now that I know that I can expect the interface to my game to be incredibly complex as opposed to a dumb and simple view, it actually made it much easier to realize how to proceed with my project. I don’t have to do everything within the simulation, and in fact, I can expect a huge part of the work to involve the player’s interface.

Stop That Hero!‘s interface isn’t like most games in that there is no avatar to control. You’re not directly moving an entity with the arrow keys or commanding it to jump with the spacebar. You simply create them at the appropriate towers in the world, and they’ll figure out where to go and what to do on their own.

But how do you create them at towers? The original prototype had a menu hardcoded at the top right of the screen. If you wanted to create a monster at a tower, you had to click the monster icon at the top right, then click on the tower. If you had enough resources, you summoned the monster you selected.

It was functional, but I didn’t like how it felt. Why is the selection of the monster to summon separate from the act of summoning? While it makes it easy to create a bunch of the same type of monster at once, it’s also easy to accidentally create a monster if you click on a tower without wanting to.

I wanted something more intuitive, and it turned out that pie menus are exactly what I want.

Except my GUI code is incredibly basic. I have menu screens and buttons, and everything assumes it is starting at the top left corner of the screen. In order to even simulate a pie menu, I needed a way to display menus at arbitrary locations, and it would help to be able to offset a menu from its center instead of the top left corner.

Which meant giving menus dimensions (how else can you know what the center is?) and having my IMGUI-ish system understand how to display and detect updates at arbitrary offsets.

In the end, after some research, questions, and determination, I do have this sequence working:

First, click on the tower you want to summon a monster at:

The Monster Summoning Menu appears over that tower, which means it is right under your mouse cursor:

Select the monster you want to summon by moving your mouse cursor to the appropriate icon. Right now, I only have a Slime, but others will be added later:

Congratulations! You’ve summoned a Slime monster!

Besides the infrastructure changes to support arbitrary menu placement, configuring the menu is easy, and each button fires off whatever event I want when it is clicked.

Tricky Aspects

One of the things I still need to figure out is what to do with a tower near the edges of the screen. Right now, the menu is always centered on a tower, which means clicking on a tower near the side of the map results in a menu with icons you can’t see. They’re being displayed off screen.

It’s not such a problem if I can display the menu outside of the screen the way a game like SimCity/Micropolis does, but since I’m not using Gtk to render the menus, they have to be rendered within the screen. I could add more screen real estate around the play area, but I’m trying to keep the game at a low resolution like 800×600 to accommodate players with older computers and netbooks. I could make the play area scroll, so even if you were at a corner of the map, it would be displayed in the center of the screen, but I want the players to see everything at once. I could reduce the play area so that I have a border to work with, but I’m not sure I like losing so much level data just because of the UI.

My best option if I want to keep the pie menu is to detect if the menu is being displayed offscreen and have it adjust automatically, but I’m not sure if the menu appearing away from where you expected it becomes too unintuitive, defeating the purpose. Otherwise, I might have to get rid of the pie menu altogether.

RTS development in a vacuum

In any case, I now have a player interface that I can easily change, but one thing I didn’t anticipate was how similar it is to a real-time strategy game’s interface. I didn’t really think of Stop That Hero! as an RTS, and yet I suppose Dungeon Keeper and Populous had RTS-like interfaces, too. Or, rather, the interface is composed of icons that let you influence the world.

I discovered that while FPS or platformer development articles and tips are a dime a dozen, RTS development seems to be something that everyone must reinvent themselves since there is a lack of information out there. I know of a couple of strategy game programming books that focus on DirectX, and either people found them lacking, or they focused heavily on DirectX as opposed to the game.

Even if there was a basic breakdown of every aspect of an RTS project, leaving the research of each item as an exercise for the reader, I’d find it more helpful than figuring out what those aspects might be as I stumble across them myself.

While most games probably have a hard-coded GUI baked into a game, some games are more expandable upon release. I remembered that Total Annihilation allows player-created units, and I figured that there had to be a way to provide access to the GUI so that new units can be created by the player in game. I checked out the game’s modding tools and discovered how it handled its GUI elements. I spent an entire day perusing technical references and modding tutorials, peaking at the game’s default data files, and generally immersing myself in the internals of the game. It is fascinating how GUI images are tied loosely with the name of the unit or command.

World of Warcraft isn’t an RTS, but its GUI is supposed to be highly configurable by players, and there are interesting references explaining how the XML ties in with Lua commands and functions within the game.

Looking at how other games do it with the limited access they provide is like trying to study a map by staring at the back side. It’s hard work, and I’m sometimes limited by the games I have access to for the most part, but it is sometimes the best guidance I can get when it comes to figuring out how to implement my own game.

Stop That Hero! Is Apparently an RTS is a post from: GBGames - Thoughts on Indie Game Development

After years of having to hear about the conference and the summits and the talks and the panels and the awards and the parties after the fact, I am actually going to be a participant!

Now I’ll get to attend the Indie Games Festival!
Now I’ll be able to meet game developers and journalists in-person instead of merely through IRC, Twitter, or blogs!
Now I get to be snubbed by major game developers when they hear I’m an independent game developer!

There were always excuses not to go in the past, such as not being able to request enough time off from a day job or not having the money. And the cost for registering for the pass, booking a plane, and staying at a hotel for a week was a big obstacle.

And cost was still a major stumbling block for me. Until I can make some income on a regular basis, I’m trying to be very careful with how I spend my money.

So how did I justify the massive expense this time?

For one thing, I have a friend currently residing in San Francisco who said I can crash at his place. No need for a hotel now!

Now, the GDC pass was tricky. I could have saved a lot of money by getting an Expo pass, but I wouldn’t be able to participate the entire week. Getting an All Access pass was prohibitively expensive. I opted for the Summits & Tutorials Pass since it seemed to offer the right balance of access and cost. While I won’t be able to attend a number of events, I will be able to go to tutorials and the Independent Games Summit.

Still, it wasn’t chump change, and I still had to book a flight.

My decision to pay so much at this time was based on a few thoughts:

• I can technically afford to go, and I might be too poor to go next year if my income level doesn’t change from $0.
• I can finally meet people who are involved in the industry, whether peers or mentors. My involvement has almost always been virtual. At least in Chicago there was the IGDA chapter, but the local game developers tended to be inactive, and they seem to drop like flies.
• I hear it is an experience.

So, bottom line, I’m going because it is a huge opportunity for me to be more involved in my industry and get to meet other participants.

I’m really excited. I’m actually going to be at GDC, and I’d love to meet you!

Who else is going to GDC?

I’m Going to the GDC (FINALLY)! is a post from: GBGames - Thoughts on Indie Game Development

I will continue to work on Stop That Hero! because I believe in the project, but I’d also like to get better at project management. Now that the deadline has passed, I can look back on the month and think critically about how I did. Even though there was no business-related urgency in getting the game finished for the Ludum Dare challenge, I still wanted to do so, and it was demoralizing to realize that the game wasn’t going to be finished in time.

For the unfamiliar reader, Stop That Hero! was originally created for the Ludum Dare 18 Jam. The player was an evil villain in charge of a castle and a number of towers, and a hero character was trying to conquer the castle, liberating towers and collecting treasure chests along the way. The player would create minions at any of the towers, and those minions would try to kill the hero. Kill the hero three times, and you win. Lose the castle, and you lose the game.

For this project, I wanted to make Stop That Hero! a commercial-quality game that required no proprietary dependencies and ran on at least GNU/Linux (my preferred platform) and Windows, with plans for a Mac OS X port and an eye toward mobile devices. I wanted the game to be data-driven instead of hard-coded. I wanted the game to have multiple game modes and levels, and I wanted me and the players to have the ability to create our own custom levels with custom rules. I realized that it was a lot to do for a first release, so my intention was to make the game hard-coded yet easy to change so that it was using external data and scripts. Future updates would involve replacing the hard-coded bits with loadable data.

What Went Right

While it might seem strange to think that anything went right for a project that wasn’t finished, I do believe there were some good things that positively impacted the project.

1. Planning and Preproduction Time. Even before the October Challenge was announced, I knew I wanted to take Stop That Hero! and make a full game out of it. I spent a few weeks at the end of September looking at every aspect of the game, from resource handling to monster variety to game modes.

   While I think the original LD18 game’s mechanics were marred by a lack of game balance and probably could stand on their own, I wanted to investigate every possibility for making this game the best it could be. I identified major design challenges that I wanted to focus on early on. I also speculated on how much of the game could be data-driven or scriptable. This early planning helped me visualize how I wanted the finished game to look and feel.

2. A Regular Work Schedule. As an indie game developer, I have no boss imposing a schedule on me. Keeping my job doesn’t require my presence during official office hours anymore. Since I determine my own schedule, I can do whatever I want, whenever I want. It’s not a license to slack off and take vacations every week, of course. My income depends on the output of my efforts.

   The thing is, my time usage wasn’t very productive or balanced, and it hasn’t been for months. If I spent time on game development, I’d find that my writing would slip. If I wrote, I’d find that magazines and books would pile up in my inbox. If I read, I’d realize that I almost missed paying an important bill. Coinciding with the time I started preproduction for this project, I realized that I needed to do something to change my situation. To make my productivity a bit more predictable, I created a regular set of hours for myself. Until I had a game to sell, I wasn’t going to make any money, so production took up the lion’s share of the time I spent in a day. To ensure that there was balance between game development and everything else I wanted to get done, I gave myself regular hours for writing, reading, and organization. I use Google Calendar to setup recurring events. You can see an example of my day below:

   I discovered I wasn’t very good about waking up early enough for the morning stretches part, which is something I want to work on next month, but I tried to stick to the schedule. If I missed stretches, I wasn’t making it up at the expense of being late for game development. If I was late for game development, I wasn’t going to encroach on writing time. If I did make such allowances, it would destroy the whole point. For the most part I stuck to the schedule, which meant I was doing about 4-5 hours of game development per day, an hour of writing per day, an hour of business or game development reading per day, and an hour of organization per day. While part of me wondered if I needed more time dedicated to game development, the balance allowed me the time I wanted to learn, share, and prevent things from slipping through the cracks. While I might tweak the hours going forward, I definitely prefer this self-imposed, organized, and regular schedule over letting each day’s activities be determined by whim.

3. Agile Scheduling As Early Warning System. Once again, I’m pleased with the knowledge I learned from using nothing more than a couple of cork boards, some index cards, and pins. Before the project started in earnest, I created an estimate of the work I needed to do as well as an estimate of how much I thought I could do per week. As the weeks passed, I realized how poorly I was doing in terms of keeping with the schedule.

   I wrote about it in Agile Alert: Slow Project Progress as well as Balancing Current and Future Needs, but the point was that without using story cards and a burndown chart, I wouldn’t have any idea when this project would be finished or what I could do to improve my situation. It allowed me to make project decisions earlier rather than later as well as weighing the advantages and disadvantages of delivering the finished project later.

What Went Wrong

1. Not Planning Time For Art and Sound Work. The Jam version of the game features all art and sound created by me. I’m not that great of an artist, and I’m no sound designer. If this game is going to be polished, I was going to need to hire someone else to do the work. Of course, until I needed the higher quality assets, I could use my current art/sound assets as placeholders.

   The thing is, I never really had a plan for how I was going to go about finding contractors to provide the replacements. For a project that was originally expected to be sold by the end of the month, I should have had a plan in place for getting all of the final polish in. It would have been hard to ask for finished art when the game itself was nowhere near playable, so it isn’t a total negative, but I could have started a search for artists and composers. At the very least, I could have looked into pre-made art and sound packages. Otherwise, I would be spending a lot of time learning how to create half-way decent art and settling for lame sound effects and no music.

2. Underestimating the Complexity of the Software Architecture Hacking a game together in a weekend is relatively easy because the code is prototype-quality. It’s meant to be used for a few days, and you don’t need to worry about maintenance or future updates. The future is mere minutes later, and then it is over. For the October Challenge, I wasn’t interested in a single sale. I was interested in the health of my business. When there is one sale, I expect more to come later, and so I wanted to make high-quality software that is easy to provide support for.

   Unfortunately, I didn’t realize until late in the month how little experience I have with creating a full-fledged project from scratch. When all of the code is in a single, monolithic file with almost no external data driving it, it takes no work to determine what data structures should live where. When you’re working on software with flexibility and maintenance in mind, it’s a completely different mindset. Since I didn’t have much in the way of reusable code that was of the quality I desired, I was spending a lot more time working on infrastructure and scaffolding than I expected. I could write an individual piece of code well enough, but I had very little experience with knowing what individual pieces of code I needed to write in the first place.

   Also, with unit testing, the code that “works” would only work in tests, whereas the actual game still needed a number of other parts of the project finished before I could see anything that looked like progress on the screen. It’s good to see the green bar as often as I do, but it’s frustrating that the actual game doesn’t do anything more than it did the week before. I now understand what the stakeholders felt like at my last day job whenever I would say “Yes, I’m making great progress. No, there’s nothing new for you to see yet.” Sometimes you just need to throw something, anything, up on the screen every once in awhile.

3. Not Being Decisive About What Game I Was Making. Since I wanted the game to be data-driven and scriptable, I thought that the major design work would take place with malleable data rather than rigid code. I wanted multiple game modes, and I had an idea of what each one might include. I thought that there could be single level instances as well as campaigns of levels that tie together somehow. I wanted victory and defeat conditions to be scriptable, but I also wanted some core mechanics to be as well. For instance, while the basic game might provide all of the towers up front for the player with no way to retake a tower that the hero has liberated, a different level configuration could require the player to conquer independent towers first and provide the ability to retake them if they are liberated.

   The problem with the game designer’s “I want it all” approach is that it put a lot of pressure on the programmer to make the software incredibly flexible. Since the designer and the programmer positions are both filled by me, it meant that I was asking a lot of myself. I knew better than to make a game engine that could be any genre, any game, but I didn’t realize that making a Stop That Hero! engine that essentially allowed for endless variety of game modes and mechanics wasn’t any less difficult. While the previous sentence sounds like it should have been self-evident, I didn’t have 20/20 hindsight to help me write it back when this project started. It seemed to be so simple. So long as the game was driven by data and scripts, I could make any mode I wanted.

   At the beginning of the project, I had supposedly made a decision to implement a particular game mode as part of the version 1.0 of the game, but I didn’t want to give up on the flexibility to do any of the others I had thought of. If I really wanted to hit the end of the month deadline, I probably could have pared down the feature requirements list. Flexibility can be retroactively coded in after 1.0 was released. Instead, I gave myself the impossible task of getting everything done and hoping it could be done in time without regard to how long it would take. It’s no wonder the schedule slipped.

4. Getting Into a Developer Funk. Towards the end of the month, I hit a point where I could not make forward progress no matter how much I wanted to do so. I was second-guessing myself, partly because I probably felt overwhelmed with the architecture work, and partly because I made the mistake of doing research and development on the state of the art for component-based game objects. Basically, I wanted a component-based game object system since it would help me in my quest for a flexible and data-driven game, but I learned a number of competing ideas, and I found that any new code I wanted to write had all of these new mental filters in the way. Data-driven Programming vs Object-oriented Programming, game objects vs game entities, encapsulation vs getting things done, etc. It was a lot to take in, and I had difficulty getting all of the new information to settle down in my head.

   When I finally abandoned my attempt at the component-based system, I still couldn’t make progress on a less flexible entity system. How hard can this be? I did a working version in the original Jam version of the game, right? Well, once again, I wasn’t throwing all variables and data structures in the same class anymore. I couldn’t make decisions because I was paralyzed with the fear that I would make a poor one.

   I experienced a smaller version of this when I was getting into unit testing for the first time. For instance, I’m not used to the need for as much Dependency Injection as I did on test-driven work, and I was losing confidence that I was doing software development “right”. Early in a project, you might think of one reference to an interface that an object needs, so you provide that reference in the constructor of the object. Weeks later, and you might have 4, 5, or 6 such references as parameters, and suddenly you’re faced with the need for another one. At this point, it starts to feel wrong, especially since it can hard to keep it all straight in my head. Since I was working alone, I didn’t feel I had anyone to discuss it with, so I would have to move forward reluctantly. Eventually, the fear that I was doing something wrong paralyzed me.

   I did eventually get out of my funk and started making forward progress again, but it was only after a long phone conversation with a more software architecture-knowledgeable friend. Thanks, Larry! When you think you’re lost, sometimes all you need is some guidance and advice.

What I Learned

1. How Much Technology I Needed and Didn’t Have. If I didn’t care about making my game available for GNU/Linux or avoiding proprietary solutions, I could probably have used technology such as GameMaker, Unity, or Flash to make a game. They offer plenty of game development-specific support, either directly or through libraries. Instead, I had to do a lot of work myself. While libSDL provided a number of basic hardware abstraction services, I still needed to write a lot more game-specific code.

   Again, I understood I wasn’t writing an end-all, be-all game engine, but I still lacked a repertoire of code to help me make the game. A lot of my time was spent laying down the basic infrastructure to allow me to work on the game. It’s odd since I can easily hack together a working game in a weekend, but when the project’s seriousness demands more, I found that I lacked the basics. While I knew what tools I would use at a fundamental level, such as which compilers and libraries I would use, I didn’t realize I needed to figure out what technology I needed to create. If I did, I probably would have planned for it in the schedule or I would have pursued a simpler project in the first place. For instance, while I knew I needed AI pathfinding, it didn’t occur to me that I’d need something more sophisticated to track all of the objects in my game than a bunch of independent collections of data.

2. How Much I Still Need to Learn Between software architecture and the basics of game engine requirements, I hit a number of stumbling blocks that forced me to pull books off of shelves and search online for answers. I would have thought I knew enough about game development to make a game, but I had underestimated how much more work there was to take an otherwise working game that was hacked together and writing the code in a way that made it easier to debug, fix, and change.

   Working with others would help us all glean knowledge from each other, but as an indie, I’m going to need to interact with game developers in more than a social way. Also, I need to get better at project estimations. I was too optimistic this time around.

3. How Difficult It Is To Talk About Game Development When It Is Not a Hack Fest. Most of the people I talked to on IRC were helpful when it came to particular aspects of what I was doing, but they almost all seemed to perceive that I was hampering my efforts with the use of unit tests and the desire for high code quality. “Just finish the game” is easy to say when you’re working on an LD48 competition entry for fun, but when your business depends partly on the ability to provide customer support without introducing bugs and problems, it’s not just fun and games anymore.

   Selling a copy would have been nice at the end of the month, but I also want the ability to sell more copies later. Selling a hard-to-support game isn’t a good way to improve my ability to stay an indie long term. The October Challenge wasn’t an end in itself for me. I saw it as a kick in the pants to get me focused on moving my business forward. By and large, it worked. I have a project that is still moving forward even if it is at a slower rate than I would like. Still, it was difficult at times to talk about game development as a business-related endeavor since not everyone had the same long-term goals.

As I said, I am continuing this project even though the October Challenge is over. Using the project data so far and assuming I continue to work at the same rate, I can expect to finish the game by December. It’s still just an estimate, but it is a much better informed one than the one I made at the beginning of the project. While it is disappointing that I couldn’t finish this project in the month, I am pleased with some things. My schedule helped me make consistent progress, and I have a much better understanding of the game’s design questions since I spent so much time thinking about them before the month started. Still, while I had done a simple technical feasibility assessment, I needed to do a deeper study to realize all of the things I needed for this project. Basically, as much as I tried to plan ahead, there were some things that just weren’t on my radar. I know better now. Besides having done a lot of work for this project that can be reused, future projects should benefit from pursuing a better understanding of their technology requirements.

Stop That Hero! October Challenge Post-Mortem is a post from: GBGames - Thoughts on Indie Game Development