Author: Gianfranco Berardi

Stop That Hero!’s End of January Progress Update

Post author By Gianfranco Berardi
Post date 2/2/2011
8 Comments on Stop That Hero!’s End of January Progress Update

Halfway through January I gave a progress update for Stop That Hero!, and in the two weeks since, I’ve accomplished a fair bit.

Recap

In the beginning of the month, I did work to create a command system, separated the game’s simulation from the rendering of it, and even added some game play related to the Hero conquering towers. There were other things accomplished, but they were slight changes compared to these major pieces.

Treasure Collection

Since then, one of the things I worked on was treasure collection. Items can be collected, which basically means running an arbitrary command. Since I don’t have much game play in, there isn’t much implemented in this regard. Right now, if the Hero comes across a treasure chest, it just disappears. Well, actually, it has its targetable component turned off so that the Hero ignores it, and it changes its renderable component so that it draws something other than the treasure chest sprite.

Why? Because I haven’t needed to delete game objects before, so there’s no way to do it. Also, I apparently never needed to hide sprites before, so there’s no way to do that, either. The “hacks” are functional for now, so I can move on to other things. I’ll come back to change these when I need to, and I may be surprised to find that I won’t need to. I already do enough unnecessary work as it is, so there is no need to add to my burden. B-)

Enemies

The next major thing I did was create a slime monster to chase after the hero. With the command system, it was as easy as creating a new command which populates the datastore with components that make up that monster. I simply took the CreateHero command, did some copy-and-paste magic, then modified its speed and the renderable component. Now I can create a slime as easily as a Hero!

Except I had no way to interact with the game yet. How did I test that the command worked? I changed the level loading code. Any treasure chests or towers defined in the level would create slimes instead. When I ran the level, the Hero had to find his way to the Castle past an entire army of slimes slowly approaching him like zombies!

Once I was satisfied that the new Slime would work within the game, I changed the level loading code back.

Front-end Architecture

The game simulation is well-defined and is easy to update. If I want to add a feature, it can be as simple as creating a new UpdateSystem, perhaps with associated components that entities can make use of.

As happy as I am with the internals of the game, I was getting frustrated with the user-facing parts. Getting from initialization to the menu to the level selection screen to the game session was poorly-defined and hard to change. I haven’t even provided a way to quit the game outside of clicking the application window’s X. When I wanted to work on providing menus for the player to click on in-game, I realized I had to do something about the front-end if I was going to make the UI work easier on me.

Here’s how my application’s architecture looked:

As you can see, the game took up the lion’s share of the application. There was no concept of screen transitions or anything like that. You were either in a complex menu, or you were playing the game. I had no concept that a game application was anything other than a game.

I spent a few days figuring out the approach I should take. I didn’t realize that my game isn’t everything at first. It’s a tiny part of the full application. To flesh out that application, I settled on creating a state machine. I don’t know why I didn’t think to do it before. I’ve done it for Game in a Day back in 2005.

I spent a few days coding up an implementation of a state manager, and I spent a good chunk of my time at the Global Game Jam getting individual states implemented. My application is now run by a high level state machine, which looks close to what I designed on my white board.

In fact, something like this has been scribbled down multiple times in notebooks and scrap pieces of paper every time I stopped to think about the high level, and it is only now that the state machine is actually implemented.

Also, note that there is one state I call “In-Game Session”. It’s in this state that the game runs. In terms of number of states, it only makes up about 10% of the application!

And additions and changes are easier now. If I wanted to add an Options screen, it would have been difficult to shoehorn it in my old architecture, but now I can simply create a new state. It’s kind of like programming tiny applications that work together.

Now the application’s front-end feels as good to work with as the game code, and since it makes adding and updating application states/modes so easy, I wish I had implemented the high level state machine in the first place.

User interaction

As great as all that rearchitecting is, I still didn’t have a way for the player to interact with the game simulation. Without interaction, it’s not a game.

So how do I add interaction?

Well, it’s the part that I don’t have working yet. Here’s how I approached it so far:

I have the game running as a LevelInstance, which has a collection of UpdateSystems and the database of game objects/components. I created a View that has a collection of RenderingSystems and access to the LeveInstance object.

I didn’t use Model-View-Controller because I didn’t feel it was a very good fit based on my understanding of how it would apply to a game.

If you’re familiar with MVC, the LevelInstance is the Model. So the V part of MVC is obvious, right? Not exactly.

My View is quite dumb. All it does is get information from the model and render it. The game simulation doesn’t care how it is being rendered, and in fact, I can have multiple views attached to a running game.

Ok, so far, so good. What about the Controller?

If you read about MVC, you don’t typically put business logic in the Controller. If I was making a game where you controlled an avatar with direction keys and a jump button, I think I could make things work fairly easily. The Controller would detect button presses and send commands to my game that make sense. For example, if I press the Spacebar, the Controller maps that to the Jump command, and the model knows that the player should jump, never caring that the Spacebar or another key was pressed.

But in Stop That Hero!, you’re not controlling an avatar directly. You are clicking UI elements. Here’s how I envision the player’s interface:

When the player clicks on a tower he/she controls, a pie menu appears around that tower. Each of the four items represent what monster can be created.

Here’s where I’ve been struggling.

If the View knows nothing but to render what’s in the model, and the Controller simply handles input and processes commands, who owns the in-game UI? Does the Model need to provide logic for the View to know what menus to display and how to display them? How does the knowledge that a mouse click (Controller) happened over a tower (View using Model data) get turned into a menu, and then who is in charge of that menu? These struggles were why I wasn’t happy with MVC as the way forward.

Until I had a discussion with Larry, that is. He is way more knowledgeable than I am when it comes to software architecture, and he pointed out that Web MVC is different from MVC.

In Web MVC, the View is simple and dumb.

In a regular MVC, however, the View might have so much logic and data that it rivals the complexity of the Model.

I’ve never thought about the View in this way before! And yet, it seems to make sense. Using StarCraft as an example, the actual game simulation is a complex RTS. Yet, there is a bunch of code to implement the interface that the simulation doesn’t ever care about.

For instance, if you’re playing as the Terran,what happens when you click on an SCV?

The SCV in question gets a little circle drawn around it to let you know what unit is selected.
The Status Display changes to reflect information about the SCV, such as health, armor strength, how many kills it has, etc.
The command buttons at the bottom right change to reflect actions the SCV can take.
The portrait changes to static before showing the face of the SCV’s driver.

And until I had this discussion about heavy vs light Views, it never occurred to me that all of those things happen without the game simulation knowing.

If you tell the SCV to move to a specific location, the game cares. If you command the SCV to harvest minerals, the game cares. If you make an SCV repair a bunker, the game cares. Yet, all of the logic dealing with clicking on buttons and units is in the View. It’s only when the player actually does something that results in a command to a specific unit that the game model cares, and even then, it doesn’t know you clicked anything or hit a hotkey. It merely receives a command from somewhere saying “SCV 1 MOVE TO X, Y” or something like that.

Sometimes I struggle with knowing where code should live in my game’s architecture. With the restructuring of my application into a state machine and a good discussion about MVC, the way forward seems clearer. Stop That Hero!‘s player-facing code needs to be a lot more involved than I originally expected. While the game logic is where a lot of the simulation occurs, the interface has a lot of its own logic. It was logic that I knew needed to be implemented, but now I know where the code’s home is.

Game Design Game Development Geek / Technical

Global Game Jammin’

The theme is Extinction.

The keynote was given by Keita Takahashi, the creator of Katamari Damacy.

And the Jammers here in Ames, Iowa had some pizza to start our night.

Things got off to a late start, but people were throwing around ideas for the theme. Artists and programmers discussed projects, and soon people got to work.

Some people worked on their existing projects, while others dove head-first into the Jam. No matter what, it’s great to be in close proximity to other indie developers.

It’s the kind of experience where you don’t want to go to sleep just because you’re tired.

I took a two hour nap, and as I write this, I’m the only one awake now. It’s oddly peaceful to be jamming in a large room and seeing the sun brighten the sky through the windows.

I’ve found myself wishing I had more infrastructure code so I can get to making actual games faster, but it is especially frustrating during a timed competition. But there’s still 30+ hours to go. Time to make the most of it.

Game Design Game Development Geek / Technical

Participating in the Global Game Jam

Post author By Gianfranco Berardi
Post date 1/28/2011

Today I’ll be participating in my first Global Game Jam and meeting local indie game developers in person for the first time.

Assuming I have a network connection, I’ll be live-blogging the event. I’ll be at Game Jam Ames, hosted at the offices of Intuition Games.

I’ve participated in 24-hour and 48-hour game development competitions in the past, but they’ve always been solo events. The GGJ will be a chance for me meet and work with people I’ve only ever chatted with online. I think it is a great opportunity to make some connections and friendships with people I can actually talk shop with.

Unlike Ludum Dare, the Global Game Jam has a rolling start time. It means that last night New Zealand Jammers were already starting, and Europeans will have already been jamming for hours before we get to start here in Iowa this evening.

48-hours, working closely with other game developers, and generally having fun? Global Game Jam should be a blast.

Are you participating? Where will you be jamming?

Geek / Technical Personal Development

Measuring the Closure of Code

Post author By Gianfranco Berardi
Post date 1/25/2011

Michael Feathers recently wrote Measuring the Closure of Code, in which he described a way to use your version control history to measure how well your software conforms to the Open-Close Principle.

Summed up by its originator Bertrand Meyer, the Open-Close Principle says that code entities should be open for extension but closed for modification.

In practice, it means code that follows this principle shouldn’t need to be touched very often. If a change or added feature is needed, new code is written elsewhere.

For example, if you have code for a Car, and you later want to have a Solar-powered Car, you’d write new code related to the solar-powered-ness of the Car, but the old Car code shouldn’t need to change to accept a new power source. Interfaces are one way to make this possible. A Car can take an IEngine, and so long as the Solar-Powered Engine implements that interface, the Car code doesn’t need to change to accomodate it.

By and large, code that follows the Open-Close Principle is more modular, more cohesive, and less likely to change.

Feathers created a graph of a random open source project’s files and their relative number of changes. His analysis indicated that the high number of changes to a few files can indicate that there is some refactoring work to do.

So I decided to create my own chart for my current project Stop That Hero!. I used something similar to the following command in git:

git log --stat | grep "|" | awk '{print $1}' | sort | uniq -c| sort -n | awk '{print $1}'

and put the result in a spreadsheet in Google Docs. Out came this chart:

At first blush, I’m pleased that the number of changes per file is pretty low. The huge spike on the right is my main.cpp file, and because I’m not loading data from config files, most configuration data is currently being recompiled in there. It looks like my code does fairly well in terms of the Open-Close Principle.

To be fair, my project isn’t very mature. According to sloccount, my entire project is 9,650 lines of C++ code. There are 5,420 lines of production code and 4,163 lines of test code. Some of the code was written before this project, so any churn in git would have happened in a previous project. It’s possible that things will look worse as the project continues.

Still, it looks like a lot of my code is written once and leveraged well; however, the code represented by the far right of the graph is definitely sensitive to change. Those files represent some large classes that experienced some redesign or tweaks almost every week.

I love it when I can get a good sense of some aspect of my project by compiling metrics! And that’s not all. As Feathers concludes:

Another thing that is nice about this view of code is that you can get a sense of what your payback will be for your refactoring. The area under the curve is the total number of commits for the project. If we inch backward from the right, we can calculate something like the 5% mark – the files which you are likely to touch in one out of every twenty modifications. This may not seem like much, but it is over the duration of a project, especially when you factor in the effort of continually trying to understand that code. I have no doubt that there is a decent formula that we can use to calculate the likely savings from refactoring based on the ratio of adds to modifications, and the commits in a code base.

Now, it’s easy for me to look at the chart, nod, and then go on with my day, but I like the idea that I can get some measurable payback for “closing” down more of the code represented by the right side of the chart.

I’d be curious to see how a really well-written piece of software measures up. Is the curve flatter? Are there very few steep climbs? Do changes clump in certain pieces of app-driving code which simply leverage all the other code in different configurations?

How does your code’s closure measurement look?

Game Design Game Development

Stop That Hero! Treasure Collection

Post author By Gianfranco Berardi
Post date 1/21/2011
2 Comments on Stop That Hero! Treasure Collection

You just read a summary of the work that I’ve done recently. The next thing I wanted to implement was treasure chest collection.

In the prototype, the Hero would collect treasure chests that either gave him health or weapon upgrades, depending on how that chest was defined in the level.

I realized that this aspect of the game needed to be redesigned from the ground up.

Why treasure chests? Why not have hearts and swords to make it clearer to the player what the Hero is collecting?

Even then, why have treasure at all? Is it improving the player’s experience at all? The hero can get stronger, making it more of a challenge for the player to try to stop him from progressing. Still, how can the player deal with treasure in an interesting way?

Can the player create treasure? For instance, creating a magic item that improves a Tower’s output requires a small cost that will pay off in the long run, but the hero can capture that item, making it risky.

It’s potentially an interesting player choice. Right now, chests just exist and there is no conceived way for the player to deal with them.

I’ve also been coming up with other ideas, such as natural resources in the world that need to be harvested by producing a machine on top, which the hero can destroy in order to get to the resources.

I think it is harder for me to roll up my sleeves and implement treasure collection because it is not a core mechanic. It impacts the game, but until I have a playable game, I have no idea if the impact will be wanted.

For now, though, I’ve come up with a way to create Collectable items. When a Collector object (that is, an object with a Collector component) is in the same vicinity as a Collectable object, then the Collectable object fires off an arbitrary command. In the case of a Heart, it would have a command that would give the Collector object increased health. If the treasure was a Weapon Upgrade instead, then the Collector’s weapon improves. The arbitrary command could do any number of other things that make sense, such as increasing player resources.

The original prototype hinted at how the Hero can get stronger as he progressed through the level towards your Castle by picking up treasure, but I think this entire mechanic/dynamic needs a lot of work, and I don’t think I can do it justice in a vacuum. I need more core mechanics in place. Still, the infrastructure to handle item pick-up is now there, which gives me options for improving the actual game.

Game Design Game Development

Stop That Hero! Mid-January Progress Update

Post author By Gianfranco Berardi
Post date 1/19/2011
2 Comments on Stop That Hero! Mid-January Progress Update

The last major progress update for Stop That Hero! was in November (see Stop That Hero! November Development Summary), so I thought I’d post about my progress since then.

Between moving, prepping a new office, unpacking, and not realizing how much time was passing, I messed up my project management duties in December. Combined with Christmas and family time, there is very little to report, and I finished 2010 weakly.

January, on the other hand, is looking much better. Here’s an outline of the things I’ve worked on in just the last two weeks:

Integrated pathfinding system with game.
Created Command system to populate game world with game objects.
Updated level definition.
Re-architected the rendering system.
The Hero can clear towers!

Let’s dig into the details!

Integrated pathfinding system with game

The nature of working with unit tests is that a lot of features get implemented in a vacuum. The code you’re test-driving is interacting with interfaces implemented by mock objects to see if specific, isolated examples run as expected.

Sometimes surprises occur when the new features are integrated with the rest of the production code.

The pathfinding system was one such feature. Everything technically worked, but when using real data, I realized there was a problem.

In my unit tests, I would check if the path gets updated when an entity was at an exact node location.

In the game, the exact center of node (10, 10) is at position (10.5, 10.5), and I didn’t realize how it would look when an entity moved to node (10, 10) by trying to get to position (10, 10).

Even when I got things working and looking correctly, I found a problem. An entity moving through a long path would eventually miss its next target node and continue moving away in the same direction it was last moving. It was a precision problem. Again, an entity was rarely at an exact node location. The entity might be a little further away. Eventually the extra precision adds up to being completely off target.

To fix it for now, I just force the entity to jump to the exact center of a node once it reaches near it. It’s a little jumpier than I would like, but the entity is never allowed to lose precision and be off path. I can correct it later, perhaps with a better implementation for movement, but for now, pathfinding and movement is functional enough.

Created Command system to populate game world with game objects

When a level was loaded, it would make use of an image like the following:

It’s blown up to make it easier to see, but the real data is a 50×33 PNG. Different colored pixels would represent the terrain, and I also used the pixel color data to create the towers, treasure chests, and hero’s starting spawn point.

However, level-loading time isn’t the only time objects can be created in the game. During a game, the player can create monsters, for instance, and I’m interested in the idea of letting the player create towers instead of being handed them at the start of a session. Also, it was awkward to have the level loader code know so much about all the different kinds of objects that could be created. There was a function to create the Hero entity, and I didn’t like the idea of lots of functions for each type of game object to create.

So I created a Command system. I suppose most game developers call them Events, but the point is that I pushed the responsibility of creating game objects to self-encapsulated pieces of code that can be created and passed around.

So now when the level loader pulls in object data, it requests commands depending on the data. For example, a white pixel specifies a basic Tower, so it requests a CreateTowerCommand. When that command is executed, the game world has a fully functioning Tower.

If I allow the player to build towers or if there is any reason why a tower should get built after the game session starts, it’s a simple matter of requesting a CreateTowerCommand.

It’s pretty powerful stuff, and I wish I had thought to do it long ago! I have commands to create the Hero entity, the towers, the castle, and treasure chests, and as new features get added, I find this command system provides an easy way to centralize and encapsulate certain activities.

I’m sure there are ways to improve it, but for now, it’s working well.

Updated level definition

If a tower is represented by a white pixel, by default the terrain around it is defined by other pixels. A tower spans multiple tiles, but the pixel’s location defines only the entrance of the tower. How do I get the terrain around the tower entrance to act like obstacles?

In the end, I didn’t solve this problem yet, but in trying to, I realized something wrong with my level definition. I was trying to use a single piece of data to define two different things.

I took the level PNG and split it into two. One PNG defines the terrain, and the other defines the objects that should exist in the level. In the image above, the white, red, black, pink, and yellow pixels are in a separate PNG associated with the level.

At the very least, now it is easy to define what the terrain around a tower looks like without worrying about the ability to define the location of the tower. I suppose I could have used the same image in a different way, but again, this works for now.

Re-architected the rendering system

At some point, I realized early architectural decisions were making it hard to separate the player’s interface with the game from the game. While I managed to get the game simulation well structured and easy to work with, I had a messy implementation for rendering, and I had no easy way to implement a UI.

I explained how I got sprites rendering in the correct screen locations based on their in-game world position in Stop That Hero! Sprite Rendering Questions, but the problem is that the sprite objects were mixed into the game’s object model.

Now, imagine switching resolutions on the fly. If the sprites are all there, they have to be replaced by more appropriate sprites. And rendering requires an updated viewport to deal with the new screen resolution.

Now, what does the simulation care about how it’s being rendered? Nothing! Or at least it shouldn’t!

It took a bit of refactoring, but not a lot. I was able to leverage what I had to get to a new solution.

I now have a concept of a View. Now, I’ve looked into Model-View-Controller, and quite frankly, I didn’t think it worked very well for what I was trying to do. This isn’t a simple application with buttons and a database.

But I did like the idea of a separate view and something to process player input. The input processor is still missing, but there is now a View that handles rendering using data from the game world but without being part of the game world.

Or at least, it will. Right now, Sprite data is still part of the entity, and I’d like to change it so that the View worries about Sprites while the game objects have RenderableComponents which merely describe what Sprite the View should get. So if a Tower has a RenderableComponent that says “Use TowerSprite”, then the View can get TowerSprite out of the 800×600 sprite collection or the 400×300 sprite collection, depending on the View’s resolution.

The Hero can clear towers!

For some time, the Hero had the ability to target Towers, find a path to the nearest Tower, and move to it. But then he’d stand there. It was still the nearest target.

It didn’t take me too long to implement a way for the Hero to change the Tower’s target status. Basically, the game had to detect that the Hero was in the Tower’s entrance, and then it requested a ClearTowerCommand. That command will get more code eventually as more features are added to the game, but for now, it takes the Tower’s Targetable component and deactivates it.

Now, the Hero moves to a Tower entrance, and then he searches for the next nearest Tower until there are no more left. While the implementation details could use some cleaning up, this mechanic is such a central part of the game, and it’s great to finally see it in action again.

Conclusion

My last two weeks have been quite productive, and I wish a screenshot could show it, but most of the work is under the hood. Still, simple infrastructure work has already paid off in implementing some game mechanics more easily. I’m pleased with my recent progress.

Game Development Games Geek / Technical Marketing/Business Personal Development

I’m Going to the GDC (FINALLY)!

Post author By Gianfranco Berardi
Post date 1/14/2011
2 Comments on I’m Going to the GDC (FINALLY)!

I finally purchased a Game Developers Conference pass for the first time!

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?

Marketing/Business Personal Development

A Near Year Draws Near. Command?

Post author By Gianfranco Berardi
Post date 1/4/2011

Happy New Year!

It’s 2011! Flying cars and hoverboards are almost here!

As the calendars get replaced, it’s a natural time to look back at the previous year and forward to the next.

Last year was a good one for me. Intellectually, I’ve known for a long time that I should run my own business full-time if I wanted to be happier and have a chance of doing great work. 2010 was finally the year I felt it and knew it at a stronger level, and I put in my two weeks’ notice in May. By the end of the month, I was no longer relying on corporate welfare.

In June, I moved to a completely different city for the first time in my life. The lower cost of living in Des Moines as compared to Chicago made a huge difference in my burn rate and allowed me to last much longer on my savings.

I got to watch more soccer than I could handle during the World Cup. Maybe I should have hit the ground running instead, but hey, I had the ability to be where I wanted, when I wanted. It was nice not to have to worry about an obligation to a job, and I took advantage of that freedom.

I started my first major project, “Stop That Hero!”, and I learned just how big a difference there is between running a weekend prototype project and finishing a complete game. While it felt discouraging to keep discovering more work for me to do, I can’t imagine how long it would have taken me to do it part-time while working a day job. I wouldn’t have put in nearly as many hours towards this project, and I’d learn at a much slower rate. One of the reasons for quitting the day job was because I was worried I was doing my game development a disservice by putting it at a lower priority than I really wanted it to be.

I learned that a well-structured day does wonders for keeping me on track towards my goals. I also learned that it can be disastrous to stop paying attention to the calendar. After months of making consistent progress in my work, I had a disruption when I moved at the end of November. I wanted to get my new office ready and there were a number of delays. I lost an entire month of productivity without realizing that a month had gone by, and it was partly because I stopped paying attention to the passing of days on my calendar.

Health-wise, I haven’t done as well as I would have liked. I didn’t find a soccer league in Des Moines when I moved, and I consistently wake up later than I would like, so I don’t do much exercise anymore. Somehow I have not gained weight, but I know I wouldn’t be able to jog or walk up a flight of steps without feeling winded. Walking regularly would help with improving my mental clarity, at the least.

Last year I quit my job and moved, pushing myself to run my business full-time. What do I see ahead of me in 2011?

Near the end of the year, I was nominated to run for a position on the board of the Association of Software Professionals. This past January 1st starts my new term as one of the three new Directors, and I’m excited to be in a new leadership position for this great organization. I’ve been the Charter Executive for the ASP Games Special Interest Group for the last couple of years, and I’d like to continue in that role as well.

I intend to spend a lot of my time marketing and selling my soon-to-be-finished game. When I’m not spending development time porting that first game to different platforms such as Mac and mobile devices, I expect to be starting a new, currently-unknown project.

On a basic level, I’d like to get more consistent income. Revenue from ads on this website and writing articles for newsletters isn’t slowing down the burn rate nearly enough.

I’m currently trying to figure out how I can afford to attend my first Game Developers Conference, and I anticipate going to the Software Industry Conference in the summer. Also, can one of my projects get submitted to next year’s IGF? I’d like to see it happen.

What does your 2011 look like?

(Photo: A 2011 Draws Near, using part of the image Standing Guard by London Looks | CC-BY-2.0)

General

Merry Christmas!

Post author By Gianfranco Berardi
Post date 12/24/2010

This past month has been a bit stressful. I moved, setup a new office, and unpacked for what seemed like forever. It took much longer than I expected.

Of course, I was hoping to tackle quite a few things once I was settled in, such as getting back to game development and shopping for Christmas presents. Since settling in took longer than expected, I didn’t realize how close December 25th was or that a month had gone by since my last significant game development effort. Stressful indeed!

Note to Self: when moving in the future, make sure the calendar is the first thing unpacked!

Even with all of the stress, I’m able to enjoy this Christmas with loved ones, and I know how fortunate I am to live in a warm home with a fantastic girlfriend and our three cats.

I hope you and yours are having a great one! Merry Christmas!

Game Design Game Development Marketing/Business Personal Development

Six Months As a Full-Time Indie

Post author By Gianfranco Berardi
Post date 12/6/2010
9 Comments on Six Months As a Full-Time Indie

Mike Kasprzak wrote about his five years as a full-time indie, and it’s a fantastic read. Especially fascinating was how long it was before he made Smiles and his first real income. After years of burning through savings, suddenly things came together for him, and he was winning prizes and being pretty awesome.

In contrast, I’ve been running my business officially for almost five years, but I’ve only been full-time since the end of May. On the one hand, that means my story won’t be nearly as fascinating or interesting as Kasprzak’s, but on the other hand, existing part-time indies aspiring to make the jump to full-time might appreciate reading how things look for me in the short term.

I wrote about some of the reasons why I went full-time indie, but part of it was freedom. Spending 40-60 hours a week on stuff unrelated to my business meant I was giving my business short shrift. I spent so many years learning about game development, but I could only dedicate a few spare minutes to actually doing it? It wasn’t right. So I quit the day job.

Ah, Freedom!

Did I hit the ground running? No. The World Cup was starting, and I was going to watch as much soccer as I could!

I was even writing about it at my new website, Modern American Soccer, which actually got quite a bit of traffic in the weeks leading up to the first game due to the US Central-time specific calendar I created on Google. In fact, that site was going to advertise the soccer-based social networking game I was going to create with a colleague before that project fell through, so it was related to my games business initially.

Either way, my first month as a full-time indie game developer was spent getting used to not having a day job to worry about. I knew that it meant a month of spending my savings with nothing to show for it, but I decided at the time that it was acceptable. I was taking a break and getting my bearings (and watching soccer).

Now What?

When I finally sat down to do real work related to my business, I found it frustrating to not know what I was doing at any given moment. Not knowing when my next infusion of income was coming from made me feel a bit antsy, and yet I felt a bit overwhelmed by the number of different tasks to accomplish. I wrote about how it felt in the article Clear Goals or Trivial Pursuits, and I realized I needed to define some specific goals to tackle, or at least pave the way to learning what those goals should be.

In July, I hosted MiniLD #20 with the theme Greed and the special rule “Only One of Each”, which was meant to discourage people from reusing content and code. It was one of the more successful MiniLDs, with plenty of submissions, but my game wasn’t one of them. My project, The Old Man and the Monkey Thief, was the first game development project I started since quitting the day job, and I didn’t finish it in time.

It was the first game I’ve made that involved a scrolling screen, and I remember feeling incompetent. How can I have thought that I could be a full-time indie developer when I didn’t even know how to make a game with something as basic as a scrolling background? It was a scary thought. Had I made a huge mistake? Was I not as prepared for making a go at a game development business as I thought I was?

Again, one of the reasons why I went full-time was so I could dedicate many more hours towards my games. If I felt incompetent, it is because I didn’t spend nearly as much time on it as I should have, and now is my chance to do otherwise.

Setting Monthly Goals

I decided that August would be the month that I would try to complete three small games in an attempt to learn as much as I could as quickly as I could.

My first project was my MiniLD game, which was taking me much longer than I expected, partly because of how unique everything had to be in the game. I didn’t finish it until right before Ludum Dare #18, and I didn’t feel it was worth releasing.

My second project was my LD #18 project, Stop That Hero!, which involved the most complex AI I’ve ever implemented. That is, I’ve never implemented pathfinding algorithms more complex than “go directly from point A to point B”, and in The Old Man and the Monkey Thief, I learned that there was a lot of problems with a character that couldn’t avoid obstacles well. Stop That Hero! took me three days to finish, but I was fairly pleased with how it turned out and wanted to flesh it out later.

I never did make a third project.

Still, two finished games in a month taught me a lot, and I was getting feedback from friends and colleagues. Even though I failed my August goal of making three games, I made good progress towards it and learned plenty.

Unfortunately, September started without goals set for it. In order to figure out what my goals should be, I spent a good chunk of the first week or so figuring out my options as an indie game developer. I thought it would take me a night to write down the options, but then I thought I could write up an article or two for ASPects, the Association of Software Professionals newsletter. It ended up being four full length articles, and it took me almost the entire month before I submitted all of them. If you’d like to read the articles, for now the only place they’re available is in the ASP members-only archives.

I also caught up on some reading. Business articles, audiobooks, and other literature were consumed. I would highly encourage anyone starting a business to read The E-Myth Revisited. For a long time I ignored it because I thought the E- part of the name meant it was a book about how Internet-based companies aren’t get-rich-quick schemes. I didn’t know it was a book about why most small businesses fail and what you can do to succeed.

Anyway, I spent the latter half of September analyzing the heck out of Stop That Hero! and trying to figure out what design directions to take it in. This time coincided with the creation of an organized daily schedule. It gave me some much needed structure, and I felt much more productive and focused, and I didn’t feel like I was letting anything fall through the cracks. I had time for writing, reading, organizing, and most importantly, game developing.

The October Challenge

While I wanted to flesh out and sell Stop That Hero!, I was having difficulty figuring out out how long to allow the project to run. I didn’t want to put together a skimpy game in a matter of weeks. Who would pay for it? And I didn’t want to spend six months working on it since that would be half of my burn rate. I don’t want to spend all of my savings on one game, and I don’t want to put together disposable games. I learned that Flashbang Studios used 8-week projects, but they had entire teams working on their games. Did I need longer? Could I afford to take longer?

Then Mike Kasprzak announced the Ludum Dare October Challenge, and I had my deadline. Make a game and sell it by the end of the month? I could do that! It took me only three days to make the prototype, so a full month should be plenty of time to make Stop That Hero! with multiple campaigns and different game modes. Right?

I wrote an October Challenge post-mortem, but suffice it to say that I didn’t get the game finished in time. Read the post-mortem for more details about what went right and what went wrong, but one of the biggest problems was not realizing how much technology I didn’t have to leverage.

Hacking a dinky game together virtually from scratch in a weekend is one thing, but making a full-scale game requires a lot of infrastructure and technology that I didn’t have. Rather than go without, I did research and development, which took up a lot of time. Tracking entities and game objects in a way that didn’t require a ton of dependencies was surprisingly difficult, and I wrote about my difficulties in implementing a component-based system in State of the Art Game Objects.

Of course, developing infrastructure is not developing the game. It’s just laying down the groundwork for a game. Kasprzak took time off to work on a framework after PuffBOMB HD, but it sounds like a lot of it was already in a game and he was cleaning it up and improving on it. While I had some prototype code, a lot of it needed to be reimplemented. Stop That Hero!‘s pathfinding algorithm was fairly hacked together, leaked memory like crazy, and required a few other algorithms to compensate for when it wouldn’t work well on its own. The new version is less dependent on knowledge of the entities moving through it and works very well, but it took me way longer to write than I would have liked.

Besides creating the necessary technology for the game, I’ve never worked on such a large scale before. Programming is not software engineering and hacking is not project management. I didn’t have much experience leading or creating a serious project before this one, and I found myself struggling with choices. What do I call this class? Should this be its own class in the first place? Is this overengineering or good practice? And that’s just the software architecture. There was also the question of project scope. I was behind schedule, and it wasn’t due to feature creep. What was I doing wrong?

Continuing the March Towards Completion

But if I could get the game done by Christmas, I think I’d still be doing well. The October Challenge was just a fun deadline and wasn’t a must-hit, urgent business deadline. According to the work I have identified and my actual rate of work, I thought I had a more accurate project estimate, and Christmas seemed to be a doable deadline. From what I’ve been told, there is a trend of increased sales around Christmas, so it might work out better for me. I pushed forward.

I was making decent progress at first, but the end of the month involved Thanksgiving and moving out of my apartment. To make matters worse, individual game systems weren’t working quite right, so I spent part of the last week finding and fixing bugs for work I thought was finished. I was finally hitting my weekly estimates, but there were also setbacks. Progress was still slower than I would have liked overall.

Unfortunately, near the end of November, I saw my schedule slip even more when I identified a ton more work. When hacking a prototype together, there can be missing menus, level selectors, data permanence, or any number of other aspects of a game. A full game missing these features isn’t a full game, by and large. When I initially planned out the project, I glossed over a lot of these kinds of details. I wanted multiple game modes, but I didn’t plan for them, nor did I figure out how I wanted the player to access them. Suddenly my project ballooned to almost twice its size, with a likely deadline in February or March, which made Stop That Hero! the six month project I wouldn’t have started if I knew.

The Future!

It was demoralizing to miss the October Challenge deadline, but this new estimated deadline was frustrating. I initially hoped to make my first sale at the end of October, and now I might not do so until after winter? And that’s assuming anyone is interested in buying it in the first place!

All this time, my savings account has been slowly reducing in size, and it will continue to do so. I’m well aware that I don’t make money producing a game. I can only make money selling a game. I could shelve Stop That Hero! temporarily while I work on something smaller, but I fear I’ll simply end up in the same situation writ small. That is, a smaller game still requires a lot of technology and infrastructure that I don’t currently have. Plus, I don’t like the idea of dropping a project midway and starting a new one. I’m tired of unfinished projects on my résumé.

I read a lot of things that get me second-guessing my choices. Is Stop That Hero! too complex and hard to make? Should I focus on “evergreen” mechanics, as suggested at Lost Garden? Is TDD inappropriate for getting games finished quickly, or is it necessary for getting games finished quickly? Am I expecting too much from my first project, or should I take the problems I’ve encountered as a sign? Am I running into the same kind of problems everyone runs into, or do I need to scale down my ambition until I have more experience? Do I need to work on smaller projects to build up my technology and code base, or can I continue building what I need when I need it for this project? And before you ask, yes, I have made a Pong clone, among other simple games, so it isn’t like I was jumping into a very large project without any experience at all. Or, maybe the problem actually is that I don’t have enough of these simple games under my belt.

There’s a lot of uncertainty, and it would be easy to panic or freak out (and I have at certain points!), but it is good to have some perspective. In six months, I’ve done more and learned more than I have in the last five years prior. While I expected to learn a lot during this time, my existing knowledge wasn’t as helpful as I thought it was. I’m taking on roles that I never had experience with before. Before I went full-time indie, I didn’t make decisions that would have a major impact on my business, and it’s an enormous responsibility.

And yet it isn’t a crippling responsibility. It’s exhilarating!

While I have the added burden of figuring out what specifically is important, I get to focus on it as much or as little as I want. While it’s a little scary to think that my decisions can make or break my business, they’re my decisions, and part of the fun of running your own business is in learning how to make better ones. The stakes are high, but at least I’m not settling for less out of a need for security.

Six months ago, I had very little idea that I’d make the progress I have and face the challenges I did. I knew it wouldn’t be a cake walk, but I also knew it wasn’t impossible. If I could change anything, I’d have tried harder to produce results while working part-time. I wish I had more direct experience working closely with other people making games so I didn’t have to figure out nearly as much on my own.

Still, I’m only six months out, and I’m in it for the long haul. In 2015, I hope I’m writing my own five year retrospective with plenty of good news to report.

If you are a veteran game developer, do you have any specific wisdom to share or regrets to warn against? If you are an aspiring game developer, do you have any questions about what the future might hold? Please post them below!