Test

Some screen shots:

tac: "Edge"

Just saw this new game called "Edge" on iPhone, and I think it has a great, practical graphical style to it:



The simple Gouraud shading gives you all the depth cues you need, and it looks slick. I would also alternate the colors of the tiles for spatial reference, but it's not a huge deal when the islands are fairly small. Outlining tiles would also do the trick, but that's expensive to do (OpenGL ES does not support line-drawing mode).

Anyway, I would love for my game to have a style similar to this. Using cubes for everything is too restrictive, but a low-poly Gouraud/flat-shaded model seems the way to go. The units can be like Vector Man, but instead of spheres, maybe use tetrahedra. Then, everything is low-poly and we avoid alpha-layered sprites. And it can still look pretty slick like "Edge".

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.

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.

tac: Converging on a graphics solution

After weeks of experimentation, I think I've converged on a best solution (for now): Most of the game will be drawn with opaque triangles (fast), which should work great for most map-elements that have simple shape (such as floor tiles, walls, boxes, hedges, etc.). Then in the second pass, we'll draw alpha-masked sprites using alpha testing. The number of alpha-masked sprites should be minimal (such as units, enemies, and some decorations) to maintain 30+ FPS. We'll need depth testing to make this 2-pass drawing work, so no need to sort on my own.

Another detail, thanks to some Apple developer forum folks: Put opaque and alpha sprites in different atlases, and minimize their size. Opaque textures don't need alpha channel!

With the opaque sprites, we can probably afford more than 2 triangles per sprite. This will allow for more interesting shapes than quadrangles. Of course, at a certain point, it'll be cheaper to use alpha-masking than a ton of triangles. I should probably write a tool to do mesh simplification in 2D (start with a highly detailed triangulation where each pixel is triangulated), with tweakable thresholds, and then let artists tweak the 2D triangulation manually.

Spatial partitioning will still be necessary to cull the number of vertices we send. This affects FPS greatly.

All this is what the tech note suggests, and it sounds like my only real option. There just doesn't seem to be a fast way to raster tons of alpha-masked sprites using OpenGL ES.

tac: Speed progress

OK, after running some tests, here are some conclusions:

- Culling off-screen triangles is important. There's a 20FPS difference between drawing 15,000 off-screen vertices and 5,400 - the latter should be plenty for visible tiles, so I need to do my own spatial culling.

- Tight-fitting my geometry around the sprite (ie. minimizing number of 0-alpha pixels I draw) helps a lot as well. I should auto-fit geometry in my atlas tool. But this still might not be fast enough, if the screen is full of tall tacos, in which case FPS drops to 20 (alpha testing + zbuffer).

- Just using blending with tight-fitting gives me 40FPS with 30x30! Drawing all tall tacos drops it to 24FPS, which is not bad at all.

- Disabling alpha blending AND testing gives me a huge boost - to 45-50FPS even with tall tacos, and it's not really fill-limited at all. With 15,000+ vertices, it keeps a steady 30FPS.

That last one is the kicker. Basically, I can potentially triangulate all of my sprites, to make them perfectly fit, and disable alpha testing/blending completely. I'll still need culling to avoid sending too many triangles, since each "sprite" might use a lot. I'll need to somehow manage the shuffling of all those vertices as well, to keep everything in one draw call with the spatial culling.

But, blending+sorting might be fast enough and yields the best visual quality. It's totally fill-rate limited with no visibility culling. While my test map yields 20FPS worst case, real maps could have much more overlap, causing more fill. There are some details I need to sort out (no pun intended) with between-tile animation, but I think I have a good idea for that (the problem is what order I draw things in - left to right, top to bottom, etc.). Spatial culling is still necessary, since off-screen triangles do still affect FPS. I could do some of my own visibility culling as well, and assuming the map isn't swiss cheese, it should reduce over-draw.

Looks like I'll need spatial culling no matter what I decide to do. Basically, I just need a few redundant copies of all the data in separate draw lists, and just draw the ones that are currently visible (easy). Hopefully I won't need more than 4 draw calls at a time. Duplicating the data isn't a huge deal - display lists won't take more than 2 MB each.

Triangulated-sprites could be an interesting approach, but I'd need to limit the shape-detail of each sprite. This is fine for things like walls and pillars, but for characters with complex silhouettes, this could be limiting. But then again, if the artist embraces it, it could make for a unique visual style.

There's still one thing I must try before deciding between alpha-sprites or triangulated-sprites: Texture compression. Tri-stripping is probably not worth trying, and glDrawTex is unlikely to be fast at all...maybe I'll try them when I'm bored out of my mind with everything else.