Monday, March 30, 2009

tac: Gameplay and the "Sim City" effect

I've gotten around to implementing some basic gameplay rules. You can now select units, move them, attack enemies, and blow up walls (X-Com fans will agree, this is essential). I'm basically aiming to have something playtestable ASAP, since that's one part of game development I've never really experienced. Currently there is no path-finding or even path-checking. It's just an "honors system" of AP-enforcement, which should work fine for testing purposes. Take short-cuts when you can. Next up: mock up UI, with popup menus, inventories, etc.

A funny thing happens when you implement game rules and limits: the game might become less fun for a little bit. For example, currently you can shoot as much as you want because I forgot to implement ammo-checks. This is a lot of fun, since you can blow tons of holes into walls and what not. I know that eventually, I'm going to have to limit this, but I'm a little reluctant to do so because it feels like a party-pooper. So there's an interesting tension between freedom and limits in video games. Freedom is naturally desirable and fundamentally enjoyable, but limits create challenge (and also encourages creativity) which ultimately breeds a more satisfying experience (a sense of accomplishment). I think both extremes are bad if that's all your game offers. Complete freedom all the time makes for a pointless, unsatisfying game, whereas too many limits make it frustrating. I suppose this is more generally just difficulty tuning and pacing - an easier game offers more freedom, which can be fun and rewarding in doses, but ultimately there needs to be some challenge (in the form of limits) to build tension. Just like any other medium, I guess.

Will Wright said that Sim City was the result of playing with the map editor he made for an action game. He was having much more fun using the map editor than playing the actual game, so he made a whole game about editing a map. Thus, Sim City was born. So he found a new freedom in the map editor, the ability to freely create buildings and modify land, and turned it into a game by imposing limits (such as money, time, hurricanes, etc.). But he didn't limit it too much, so fundamentally, you could still enjoy that freedom/ability.

Instead of gimping the unique features too much to keep a game challenging (ie. making it less unique), designers should think of new ways to maintain challenge. Braid was a beautiful example of doing it right. It had time travel, but did not gimp it at all. Instead, the challenge (and plenty of it) was provided by the mind bending puzzles. This provided for a completely new experience. Something like the Force Unleashed, on the other hand, mainly provided challenging by gimping the powers. Not only did you have the energy bar, later enemies were simply immune to your powers.

Another random note: I emailed John Carmack about his implementation of Wolf3D for iPhone (details here), and to my surprise, the man replied in about 2 minutes flat. How cool is that? It was a pretty stupid question too, that I could've answered for myself just by looking at the open sourced code. Just goes to show, Carmack is one of the chillest big shots in games.

Tuesday, March 17, 2009

tac: Graphical Style

It's becoming more and more clear to me that due to the iPhone's SDK limitations (that have little to do with the hardware limitations!), my game will probably not look as good as X-Com or any golden age turn-based tactics game. All that nice alpha-blending just isn't going to fly on the iPhone. I'm gonna need something that looks very polygonal. Something perhaps like this:



That's Darwinia, from the venerable indie studio Introversion. They don't have many artists, so they embraced a style that is practical for their situation. It's nothing award winning, but it works great. I think I'll need to do something like this. I may need to abandon the wizard theme for something more TRON-like, but that's fine.

Turn-based Darwinia (stylistically at least)? That sounds good to me.

tac: Gameplay

It's been a while since my last update, but that's the nice thing about working as a hobbyist, right? If I don't feel like working on it, I don't have to!

I settled on the 2-pass graphics solution (which is what everyone's doing, I guess), and I've moved on to gameplay matters. Gameplay is always trickier than I expect, because even though the logic is simple, having a well-organized code architecture takes some iteration. When I worked at 2K, even up to shipping we still had discussions about how objects and interactions should have been organized. With a turn-based game, things are a little simpler, since it works very much like a board game: Only one thing ever happens at a time. Once something happens, everyone updates their own strategy to reflect the new situation. Then, someone else takes a turn and does something, and everyone updates once again. Nice and clean. With a real-time game, there's a temptation to do everything "all at once" for speed reasons, which can result in some strange logical bugs.

Anyway, the game now allows you to select units and teleport them to arbitrary positions. Next order of business: Put in foundations for taking steps and turns, and some very simple path-finding. Then, you should be able to select a unit, tell it to move to a position, and then it'll "animate" over to that position (modulo the horrible pathfinding) instead of teleporting to it.