Postmortem: Programming.

February 4th, 2012

All right, this is going to be the last post-mortem post for “Girl with a Heart of”. This one will be primarily about technology: programming, tools, and builds.

 

Hot Spots:

There is probably a section of code in your game that just keeps throwing bugs at you. You keep fixing it over and over again. This means there is an underlying problem that you are not solving; instead, you are patching it. Sit down and figure out exactly what you want from that code, figure out how it should look/work ideally, and then rewrite it to make it so.

More generically: if you keep fixing the same thing over and over, you probably need to rethink it.

 

Unity Scenes:

I had a separate Unity scene for every level, but you could only start playing from the main menu scene. That meant I had to go through the main menu each time I wanted to play-test. Moreover, if I was working on another scene, I would have to switch to the main menu scene, play-test, and then switch back. This is too much overhead. Ideally, you should be able to drop into any place and time in your game.

More generically: make your play-test time as productive as possible.

 

Unity Components:

This one you’ll really grasp once you work with Unity for a while. Learn to love components! Figure out the minimum required behavior and put it in its own component.

 

Final Builds:

Find a good way to label your final builds. Make sure each build’s filename has the date you made it, platform, and version number. If you upload it somewhere (e.g. Desura), make a local copy of it, and name it appropriately: GWH_v0.2_Windows_Desura_5-17-11.zip

Builds for iOS and Android should take minimum amount of steps. I can’t even remember how many times I had to manually edit .plist file for iOS builds. Make a good copy of it and reuse it!

 

Create Tools:

If you find yourself doing something tedious, you probably need a tool. One of the best tools I wrote for GWH was the dialog parser. I decided exactly how I wanted my dialogs to look when I edit them (minimum meta-data and mostly dialog text), created a custom format to match, and then wrote a tool that parsed and loaded the dialog text file into the game.

Other useful tools: set certain texture import properties for all textures, teleport to anywhere/anytime in the game, edit various game data during runtime, make the avatar move faster, count words in a dialog file. A lot of these tools were easy to make, but they saved a lot of time.

 

I’ll try to post a lot more often to this blog, but my primary focus right now is to work on my new game: Alchemy College. You can follow its development right here.

Posted in GWH, Postmortem | No Comments »

Postmortem: Design.

December 11th, 2011

I’ve covered a lot of various game design points in my previous article, where I addressed reviewers’ comments. However, there are some issues that the reviewers didn’t bring up, but I still want to cover.

 

Gender balance:

I really wanted the game to be gender balanced and not sexist. I’ve succeeded in some respects. For example, I had the same number of female and male characters, and the main character is a girl. However, there are some things that escaped my notice until it was too late. For example, everyone in position of power/authority (Count and John) is a male. There are also some really gender stereotypical roles: Deena makes jewelry, John is a teacher, the only surface runner is your father, Trent is trying to win Cynthia’s affection (active role), but Cynthia is pining after John (passive role).

One of the easiest ways to fix this is to just swap roles. Let’s say Raven’s father was a jewel maker, Raven’s mother was a surface runner, there was a Countess instead of a Count, Trent would be pining after Cynthia (suits him anyway), and Cynthia would be actively trying to pursue John. (I really like John’s character, so I wouldn’t change this role, nor would it be really necessary after changing other characters’ roles.)

 

Combat system:

I should have went with one of the two ways. One, just have no combat. I am a huge fan of this approach, because it means less work (see below). Or two: have a lot more combat. With this approach, the combat would be used a lot more often, a lot sooner, and be a much more integral part of the game, and it would have also made it a lot more obvious how much stronger Raven becomes over time. Notice, that the middle path is the worst. I ended up with the cost of both paths, but none of the benefits.

 

Cut, cut, cut:

You must cut features. Whatever your original design document is, there is probably way too much fluff. For example, originally I had two extra NPC characters: Mr. and Mrs. Blackwoods. He would be working in a bank, and she would be staying at home, taking care of Raven. Now, if you’ve played the game, you’ll immediately notice how unnecessary those characters are. That’s the point! Their roles were easy folded onto other characters: John and Cynthia, respectively.

I’m really glad I cut those characters, but I should have went a lot further. I should have cut the Count. He has a minor role, which is completely unnecessary. Everything he had to communicate could have been done through John.

I should have cut Trent. His story is rather weak, and I would have rather cut him off entirely, and focus more on the love story between Cynthia and John. His role as an imbuing guide could have been folded over onto John.

Notice that with every cut your other characters grow more complex and more interesting. The game and story become more round and tight. That’s the beauty of cutting features. Not only do you save yourself lots of time, you end up with a more polished experience.

And don’t get me started on the library and all the backgrounds…

 

Naming:

Some reviewers noted that the dialog was too plain. That was actually on purpose. I wanted the dialog to be easy to read and understand. Because of that, I also tried to not invent a lot of new terminology or names. I think I’ve succeeded, but I went a little bit too far. The “Dark” and “Light” terms became way too overloaded. They refer to dark and light in the physical world, to kingdoms, to people, and to the Great Powers. I should have come up with a different name for the kingdoms, which would also give different names to the people.

 

Map layout:

You want to minimize the amount of time the player is doing non-interesting things. Walking (aside from initial exploring) is not interesting. This means the map has to be tight, and things that the player will want to visit one after another should be close.

Initially, I didn’t have a shortcut from second city level to fourth, but after working on the game, I had to add it. I only intended it to be for testing purposes, but I realized that if I get tired of walking up and down after a few play tests, then the players will be even more so. I left the shortcut in there, and it was a very good decision.

 

Overall design:

I implemented the game by implementing each Day sequentially. I think a better approach would have been to implement a very louse overall structure for all six Days, and then fill in more details, starting with the ones that I knew had to happen. I think this would have given me a lot more flexibility, because, in my case, after working on Day 5, and realizing I wanted to change something substantial in Day 1, I often couldn’t, because it would affect Day 2-4, and I couldn’t rewrite them easily.

 

That about sums it up. There is one more post-mortem article left to be written, and after that it’s on to the new pastures.

Tags:
Posted in GWH, Postmortem | No Comments »

Postmortem: Budget.

December 5th, 2011

One very crucial aspect of making a game is managing your budget. For “Girl with a Heart of” my budget was around $20,000, and I ended up spending $17,565. Not bad! However, I’m still not happy with how I handled it, so let’s break things down and see what could have been better.

Before you start your game, you need to have a rough idea of how much money you want to spend on it. For an indie game, this will be on an order a thousands of dollars. That’s your budget. (Of course, you could try to make a game for free, but even then you should still think about how much work will go into your game.) You should also anticipate how that budget will breakdown in terms of assets. What percent goes to art, programming, music? Which gets cut first? And, ideally, within each area you’ll have a percentage breakdown as well.

If you can’t do this, that means you need more information. Start looking at costs. Make a post for an artist, describing what you want, and ask them how much they want to be paid for that kind of work. If you are inexperienced, you’ll find out that your original estimates weren’t very accurate. Personally, I found out that art is a lot cheaper than I thought.

For example, for art I spent: $8,080 on characters, $4,485 on backgrounds, $1,705 on portraits. Outside of art: $1500 was spent on PR, $775 on music, and $600 on dialog editing. Ideally, you can come up with these rough breakdowns before you start producing any assets. And once you do start paying for assets, be sure to keep track to make sure you are not spending beyond your means. Here is a quick calculation I did to make sure I was staying within budget:

 

Budget left: $17,000

Primary characters’ designs and skeletons: $90 * 11 = $900

Primary characters’ animation: $10perFrame * 12fps * (9chars * 5anims) = $5,400

Portraits: 10chars * ($70 + $40 * 3) = $1900

Secondary characters’ designs and skeletons: 14 * $40 = $560

Secondary characters’ animations: $7perFrame * 12fps * (14chars * 1anims) = $1,176

Creature design and skeleton: $90 * 4 = $360

Creature animations: $10perFrame * 12fps * (4chars * 5anims) = $2,400

Backgrounds: $85 * 48 = $4,080

Total: $16,776

 

Awesome!

However, aside from simple cost per asset, there is a second parameter that you have to be concerned about: number of assets. Even if all assets are cheap, you’ll quickly burn through your budget if you order a lot of assets, or if you let your game scope expand. I almost ran into this problem. The number of assets for animated 2D games can get out of hand really fast. This requires you to look at all the art assets you want, and think if it’s possible to cut some of them out or replace them with more generic versions that could be reused in multiple scenarios. Alternatively, you might have to cut the budget for some other parts of the game.

 

Be prepared for unexpected expenses. For example, I had to buy a Unity license, and, once I decided to port the game, I had to buy additional Unity licenses for Android and iOS, as well as hardware: Mini Mac, iPod, and iPad. (I already had an Android phone.) I also realized I had to hire dialog editors when I realized how important the dialog is to my game, and how my writing could use a second pair of eyes. Your budget should either try to account for these potential unexpected expenses, or you should be flexible enough where you can adjust the budget upwards (be very careful when using the latter option, since it can easily mean you’ll pour more and more money into the game).

 

You should definitely create a document where you keep track of all the assets that you’ll need for your game. Whenever you realize you’ll need an asset, add it to the document. Whenever you actually order it, update your document. Whenever it’s delivered, update your document. Whenever you pay for an asset, guess what? Update your document. Keep it up to date at all times. Give your freelancers access to it, so they can immediately see if you think you paid for something, but they haven’t received the payment. For me, this document looked something like this:

 

Raven:

Design+skeleton ($90)

Single Frames (8 * $10 = $80)

Breathe idle (5 * $10 = $50)

Walk animation (8 * $10 = $80)

2 turning animations (6 * $10 + 4 * $5 = $80)

Falling (7 * $10 = $70)

Getting up (8 * $10 = $80)

Cast Bolt (18 * $8 + 8 * $5 = $184)

Cast Shield (8 * $10 = $80)

Cast Bubbles (3 * $8 = $16)

 

This is an excerpt only, of course. The full document was many pages. Everything is highlighted in green because I already paid for it. If weren’t highlighted, then I hadn’t paid for it. You could add (Ordered) once you actually let the person know you want this asset.

Ideally, you’ll keep this in a spreadsheet, so you can always see how much you’ve already paid out, how much is left, and how much of your budget is left.

And remember: cutting features often makes your game a more polished and tight experience, and it also saves you money. Don’t be afraid to cut features!

Posted in GWH, Postmortem | 2 Comments »

« Older Entries