Categories
Game Design Game Development Games Marketing/Business

The Complexity of a Casual Game

Since so many people seem to be surprised that Spore, a game that mixes all sorts of game genres into one game, didn’t create the ultimate experience for each of those sub-games, and Will Wright’s recent interview with MTV in which he claims that Spore was meant to be a casual game:

“I’d say that’s quite accurate,” Wright told me. “We were very focused, if anything, on making a game for more casual players. “Spore” has more depth than, let’s say, “The Sims” did. But we looked at the Metacritic scores for “Sims 2?, which was around 90, and something like “Half-Life“, which was 97, and we decided — quite a while back — that we would rather have the Metacritic and sales of “Sims 2? than the Metacritic and sales of “Half-Life.”

And one way of getting there is to present a narrower range of options than a hardcore player might be expecting?

“Yes,” he said. “Part of this, in some sense was: can we teach a “Sims” player to play an RTS [or Real Time Strategy game]? … I think the complexity we ended up with was toward that group.”

So reducing the range of options is one way to make a game more casual, but what options are we talking about? I think there are two ways in which you can look at a game’s complexity: input complexity and rules complexity.

With input complexity, the available interface options are limited. For a complex input scheme, look at NetHack. There is a command for drinking, and one for eating. One for putting on armor, and one for equipping weapons, and one for putting on a ring, and entirely different commands for taking them all off again! Attacking can use any number of commands to kick, throw, fire an arrow, zap a wand, or swinging your weapon. NetHack is definitely NOT a casual game, but look at FastCrawl for a more accessible game. Instead of requiring the player to know every function of every button, key, or icon, you limit the interface. Technically Tetris can be played with three functions: move left, move right, and rotate piece. It’s not a mindless game, though. You can employ various strategies at various stages of the game. There is complexity, but it is hidden behind a simple interface. This combination makes it an accessible game, as the success of the GameBoy with children and adults alike can attest to. For another example of a simple interface, see Fishie Fishie. From the creator’s page:

Yesterday I played a game that had three different buttons for “jump”. Three! I mean, really, what’s happened to the world? How am I supposed to keep an eye on the kids, stay up to date with current affairs, and remember which button to press when I want to esape the toothy maw of an airborne crocodile? In protest I built Fishie Fishie, a game you play using exactly one button.

Rules complexity deals with what’s happening in the game itself. If you’ve ever played the Buffy the Vampire Slayer board game, you know what I mean when it comes to complexity. The interface is simple and familiar enough: roll dice, move players, attack other characters. But then you have to keep track of hit points, goals, who is a vampire when, and yes, the current phase of the moon! And if you’ve never played Dungeons and Dragons, just keep in mind that choosing your character’s class, alignment, feats, skills, and armor is what you do BEFORE you start playing. If you’re playing a cleric, trying to turn the undead will result in moans from the other players since play basically STOPS until you do all the complex calculations to figure out how many ghouls at what strength you turned or destroyed. Now compare these rules to the “0 player” Game of Life. There are only four rules, and yet the ways these rules interact, the dynamics of the game, are rich and complex.

Buffy could have taken a lesson from the card game Fluxx. In Fluxx, the rules change constantly as you play since played cards can add, change, or remove rules. Even though you would think it would be too complex and only appeal to the geeky, in my experience it seems that everyone loves it. I think a key part of it is that the rules aren’t hidden away in a manual but right there on the cards in front of you! You can walk away from the game to get a snack while the rest of the players take their turns, and when you get back you know exactly what the state of the game is just by checking the cards. An otherwise complex game made casually accessible by its interface!

Perhaps Buffy fails to appeal to playing fans not because it is too complex but because this complexity is hard to understand just by looking at the game. Every time you pull the game out of the closet, you have to re-remember the rules before you start, and usually that means someone has to read the instructions, if they still exist. Throughout the game, you have to periodically consult the instructions to clarify what to do in certain situations. With Fluxx, you can just start playing.

So can you make a complicated rule-set accessible by limiting the interface? Can you reduce the rules of the game to a handful and make an otherwise complex game easier to grok? It seems that if the rules are simple, the interface can also be simple, but if the rules are complex, the interface doesn’t have to be. If you believe that reducing complexity is key to making a game more casual-friendly, I believe you can still make otherwise hardcore games more accessible by making the interface intuitive and simple.

[tags] indie, casual game, game design [/tags]

Categories
Game Design Game Development Games Marketing/Business

Indie Business Rules: Relationships and Service

Jay Barnson wrote Business Rules for Indies, in which he tries to apply Jack Welch’s “cardinal rule of business” to indie game developers.

Never let anyone come between you and your customers or your suppliers. Those relationships take too long to develop and are too valuable to lose.

While game portals are a good short term solution for developers who are trying to reach a large number of players and paying customers, they aren’t so good for the long term.

In business, finding a new customer willing to pay for your products is much harder and much more expensive than selling your products to existing customers, who have already shown a willingness to buy from you. But if you sell through a portal, you don’t have a customer. You get paid, but by the portal, as a cut of the sales. If you were to sell directly to your customers, however, you not only get the sale, but also a relationship with your customer.

If you sell a game through a portal for $20, you get paid a small percentage. The portal gets the lion’s share, but of course the portal is the one with all of the traffic and customers, and so you are essentially paying for the chance to sell greater quantities than you could on your own.

If you sell a game directly for $20, you get to keep the income. You might not get as many sales on your own, but what you do get in this situation is customer information. YOU know who is willing to buy the kind of games you make, and so YOU can sell them expansions, sequels, and affiliate products. You can address them in newsletters and tell them about new sales you’re offering. That $20 is just the start of how much that customer might buy from you over the lifetime of your business. You trade short-term financial gain for future profits.

The theory sounds all well and good, but with so much competition out there, how can you hope to get ANY attention unless you’re on a portal? And if you’re on a portal, you aren’t allowed access to customer information, and in some cases you aren’t even allowed to let your customers know who made your game! The portals have become the new form of publishers, which is what being indie was supposed to get you away from.

Dan Cook’s The Casual Games Manifesto addresses all of this and more, but the essence of the article is that you need to develop a relationship with your customers, whether they found you directly or through a portal. Can you integrate your games into a service that YOU and YOU alone provide? Then the portal becomes your access point to customers and not just a distribution channel.

The Casual Games Manifesto got me thinking about specific changes I can make to my business model. If I make one game, and it takes me three months or three years, I have to compete with all of the hundreds of games released in that time. But if I create a game tied to a service I provide, am I competing with the same games anymore? I think what might make such a change hard for indies is that providing a game service requires outsourcing or hiring others to build and manage it. Then again, are you doing this as a hobby that pays a little bit for your pizza and beer, or are you running a serious business?

Either way, don’t feel that you need to let the portals come between you and your customers. If you don’t want them to, you have options.

[tags] indie, business, portal, game development [/tags]

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD#12 Results Are In

The latest Ludum Dare results have been announced. Congratulations to Hamumu, Fiona, and Notch!

I didn’t do very well with Tower Defender itself. Each rating is scored of 5:

Overall: 2.33
Fun: 2.05
Innovation: 2.95
Theme: 3.62
Polish: 1.76
Graphics: 2.57
Audio: –
Humor: 2.64
Technical: 2.10
Food: 4.07
Journal: 4.33
Timelapse: 3.80

Overall, my game placed very low. Still, I managed to come away with the gold medal for my journal and the bronze medal for my food entries. My timelapse video came in 4th place. I rule at participation.

I intend to rule LD#13 in December, though. I’m going to spend the next couple of months getting ready for it.

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development Post-mortem

LD#12: Tower Defender Post-mortem

My 2nd Ludum Dare didn’t go as well as my first. While I managed to get Tower Defender submitted, it can’t be called a game so much as a tech demo.

What Went Right:

  • Simple game mechanics still work.

    Like my LD#11 Minimalist entry, I wanted to use simple mouse-movement-only controls. I feel that mousing over your units to make them attack made sense, and while I only had archers available in the end, it seemed to work. It’s too bad there wasn’t more of a game built around the mechanic, but I intend to flesh it out after LD.

  • I had an office door I could close.

    My cats are incredibly reliable. If I am doing anything that looks like productivity, they will insist on sitting on my lap, resting on my arms, and otherwise preventing me from working. Being able to close the door on them helped keep me focused on game development. Towards the end I got lax about keeping the door closed, but the cats left me to work for the most part.

  • Using Test-Driven Development

    Test-Driven Development, or TDD, is great for designing your code. Also, since code changes often, you can feel confident that your changes won’t break functionality since your tests will tell you if they did break. More than once, I was surprised that a seemingly innocuous change resulted in failing tests, so I was able to keep the game working at all times. I know that I wouldn’t have caught one specific crash problem right away, and it might have resulted in a non-working game for hours, preventing me from submitting anything. Since I found those problems sooner, even in code that wasn’t directly being tested, I felt that using TDD was the right thing to do.

What Went Wrong:

  • Learning Test-Driven Development while using it.

    I know quite a few people would disagree with the use of TDD during Ludum Dare, but I think what burned me was my inexperience with implementing it. I spent too much time trying to figure out how to apply it to rewriting code that I already had written. My first bunch of tests were helpful, but all I ended up with at the end was a slightly smaller Game class with a separate Timer class, and it seemed that if I applied TDD to the entire project I would barely have an SDL window by the end. While my normal projects might benefit from test-driven design, my LD game needed to get finished in 48 hours, so I had to alternate between writing tests first and skipping tests. I’m sure once I get some TDD experience, I’ll be much faster and know when it is in appropriate to write tests. For LD#12, it was a learning experience.

  • I still didn’t have a good handle on SDL

    Last LD, I noted that I hadn’t practiced using SDL much, and right before LD#12 started, I realized that I still hadn’t done so. I never had to render animated sprites in SDL before, and I skipped it in favor of static images moving around, but not before spending precious time learning what I would need to do it. Again, there was too much wrestling with technology instead of game development, and this time it prevented me from finishing my game.

  • Working long hours really does screw with your productivity

    It’s common in the programming world to find people working Twelves, especially in the game development industry. Crunch times are intuitive. If a project needs to get done in a week, and there are two weeks of work to be done, then have everyone work longer each day. Well, it is common knowledge, even if that knowledge isn’t applied, that working longer hours doesn’t translate into greater productivity.

    I experienced these issues firsthand with the 2nd day of LD#12. I realized I had worked about 12 hours straight by the end, and I was making sillier and sillier mistakes. Sometimes my tests would save me, but since I didn’t write tests for a good portion of my code, I had to figure out what I did wrong most of the time. Bugs were finding their ways into my code a lot easier, and debugging was painful. When I did LD#11, I got plenty of sleep and took frequent breaks, and ended up with a finished game. I wonder if I could have done LD#12 better if I took a few more decent breaks during that 12 hour stretch.

  • I didn’t get game play until the very last minute.

    I knew that getting game play up as quickly as possible was important, especially in a timed competition, and yet I believe I struggled so much with the technology that the game didn’t start to form until I had minutes left to package it up and submit it. I think if I had used a few more hours in a productive way, I could have made something enjoyable.

What I Learned:

  • I still have a lot to learn.

    It’s weird when you feel confident going into a competition like this and then hit a wall due to your own lack of knowledge. I was depending on TDD, SDL, and common game programming concepts such as OnMouseOver, but I didn’t have much experience with them before this competition started. I like using LD as a learning experience, but next time I’ll focus on learning only one tech or tool for LD at a time.

  • Test-Driven game development is awesome.

    Yes, the learning curve slowed my productivity down, but I already saw many benefits from using a test-first design for my coding. I could see that my code base was going to be much better for it, particularly in terms of my ability to make cross-platform games, but I had to stop applying it due to time constraints. I was already trying to incorporate TDD into my main development before LD, but now I see that it’s going to provide better benefits than I originally thought.

  • I need to work on my pacing for LD.

    It seems most of my productive work happens during the 2nd half of Ludum Dare, and it makes me wonder what happened during the first 24 hours. I saw that more than a few people had working prototypes up and running within a matter of hours, and I want to make sure my future LD entries are in a playable state as early as possible, too.

Once again, 48 hours resulted in a bunch of code and experience I didn’t have before the weekend started. Even though my submission can’t really be called a game, it has potential, and I had a lot of fun working on it. The next LD is in December. A few months should give me time to develop my skill and technology base.

[tags] postmortem [/tags]

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD#12: GBGames Time Lapse!

My first time lapse was over 10 minutes long, and so I had to cut out a lot of the repetitive images to shorten it. I also found a way to combine music with it.

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD#12: Final Submission

Tower Defender Game Play

Tower Defender source. This is a source only version, and it is 8MB!

Get your smaller Linux-binary here: Tower Defender for Linux

A Win32 binary should be forthcoming.

Unfortunately I only got game play in at the last few minutes, and there are problems. For one, there is no way to win or lose. The enemies don’t know that they’ve already stormed the walls and will keep going until they hit the sky, but they do this cool floating thing…which is a bug. Mousing over the archers will make them fire arrows, and they take a bit of time to reload before letting you fire again. The arrows do hit the enemies and make them disappear.

I’ll have a post-mortem up soon.

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD#12: Lunch with Gizmo

Gizmo tends to like to hang out with me whenever I’m doing anything related to programming. I nicknamed her Hacker Kitty. She’s helping me eat my vegan pizza and apple juice.

Gizmo helps me with food preparation

Diego, on the other hand, just wants to know when I’ll be done.

Diego wants to know if I'm done yet

Well, I’m not done yet, but I have a few more unit tests, and quite a few more lines of code without tests. Progress is being made.

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD#12: More Design

I was sketching out some of the interactions and just trying to make myself aware of what it is I am tackling with only 8 hours left.

More design

Based on these notes, I think my schedule should be as follows:

  • Code to draw tower based on height (determined by difficulty, a nice to have later on).
  • Draw an enemy sprite.
  • Code to move enemies up the tower.
  • Code to determine that game is over if they reach top of tower.
  • Code to mouse over an archer.
  • Draw an arrow.
  • Code to move arrow.
  • Code to handle collision of arrow and enemy.

And after all of that, I should have a good base to work with. I’ll see how much time is left and make further plans when those are done. The cool thing is that I can start writing unit tests again for the classes I’ll be writing.

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD#12: Good ol’ Jarritos

It’s strawberry flavored!

My kitchen is a mess and I’m out of clean glasses, but at least Jarritos doesn’t need a glass to be enjoyed!

Strawberry Jarritos...and grape juice...

And while taking the picture, I realized I have a bottle of…grape juice…and some clean glasses for it. Hmm…

Categories
Game Design Game Development Geek / Technical Linux Game Development Personal Development

LD#12: Tower Defender’s Best Knight

The Knight Owl!

The Knight Owl

He’s 32×32, and I’m worried he won’t show up too well after all the work I put into it. Note to self: learn how to use the Gimp better.