My plan is to have three threshholds. If you’re playing a game, and someone disconnects, it’s generally for one of two reasons: their connection failed, or they’re quitting to avoid losing. On the one hand, I have spotty wifi at home, and I frequently lose connection for several minutes at a time, and I wouldn’t want to be counted a loser and a poor sport while I waited on my DSL modem to stop sucking. On the other hand, sitting around waiting for someone you don’t know is frequently the suck, and many people do quit to get out of a loss.

So, I’m setting the upper threshhold at 20 minutes. No matter what, if they log off and stay gone for 20 minutes, the game is discarded, and called in favor of the person still online. However, obviously I don’t want people to have to wait around for 20 minutes, so I need to set a lower threshhold. That threshhold will be the point at which someone gets to choose what to do. If I’m gone a little over the lower threshhold, the system will say to the other player “do you want to call it a tie, save it for later, or claim a disconnect win?” If it’s someone who doesn’t know me, they shouldn’t be forced to wait, and should have the option of calling it a tie if the game isn’t very far in, or if I’ve obviously been having connection trouble. However, they should also be able to claim a disconnect win if they smell a jerk.

It would be nice if they could call a tie or a save very early, much earlier than would be appropriate for calling a quitter loss, so the other two threshholds are those two issues seperately. The lowest threshhold is the “save or tie” threshhold, and it should be fairly fast. Someone can choose to ignore it if they want. The next threshhold is the “you quit to cheat” threshhold, and it should be at least somewhat patient. At the 20 minute line, the system will call it, no matter what.
So, the question is, how long should those two lower timeouts be? Twenty minutes is obviously far too long for either. On the balance, ten seconds obviously isn’t long enough; most people can’t reconnect that fast, and we need to be accomodating of people’s computers rebooting, of modem reconnect cycles, of DSL reconnect cycles, and so on.

I’m going to set a range of options. If you don’t see the time you want, feel free to add it; I’ll be using the distribution of answers, not just the most popular, so it’ll still count.
[?php jal_democracy(6); ?]

[?php jal_democracy(7); ?]

That’s also why I haven’t filled the daily image queue in a while. However, I’ll put up a big chunk of images tonight and post-date them, so that they’ll still spill out daily like they’re spota. Huhuh.

At any rate, right now I’m throwing together a few quick demo games, because they’re still higher quality than the commercial things they’re positioned against. Hopefully I can get a publisher to buy one of the games from me at fire sale prices (you hear that? Dead cheap!) so that I can dump the money back into my new corporation, but we’ll see.

Things I’m gonna try to bring to E3:

• One of my crappy NDS well games, probably RoffleBlox
• The Nintendo DS PDA application
• The Nintendo DS VoIP client
• My sudoku client and a few thousand abnormal puzzles (with in-place handwriting if time allows, natch)
• Some BulletML machine demo, not sure what yet
• The Nintendo DS eBook Reader, with some already-attached books
• Two things I’m not talking about in public
• Maybe a drawing program, depending on how much free time I don’t have.

Maybe other stuff too. Dunno.

In other news, I’m now getting four blog spam comments a day.  Whee.

And, to be plain, I’d forgotten how much of a hassle a shadowcaster actually is. I went to dig up maybe some example code, but the good answers were few and far between; there are several each at various roguelike sites like Dungeondweller, but the articles are written to widely varying levels of quality, most without source, and with no apparent method to compare between methods. Most of them an experienced programmer can ignore out of hand, but one of the algorithms up there is just repeated line of sight, which is dead slow. It’s enough to make a man think about writing another tutorial…

Luckily, I know what’s up, so I’m going to implement recursive shadowcasting. There’s a not-half-bad implementation in this tutorial by Gordon Lipford, but in several places he sacrifices efficiency or power for readability. Right thing to do for a tutorial. Wrong thing to do for production code. (He also has several unexplained actions here and there, writes pseudocode where interactions aren’t clear, and requires the reader to reimplement several structures from explanations, but whatever.) At any rate, his method is efficient, flexible, and less painful to implement than some of its competition, so I’m running with it.

One of the very cool things about Lipford’s method is that it’s arc-angle based. As a result, objects don’t actually have to fit a tile; rays are radiated. That means that anti-aliasing one’s shadows is in fact realistic; I’m halfway done with that in my shadowcaster now. Other things could be added, but I’ve decided to skip them for now. One of the really neat things about this modified method, though, which uprises from the line of sight algorithm is that I have accurate overhead cover rules and a good set of premise data to work in the notion of “perception.”

Simulating perception accurately is traditionally a problem for AI behavior, but in a Roguelike it’s a bigger problem than usual. Because roguelikes offer such complex tactical situations, and because speed in varying environments is such an issue, players often want to “lose” the predators by hiding. Lots of the common methods for handling roguelike behavior involve simple distance calculations, meaning monsters can semi-effectively follow you through visual obstacles which otherwise should confuse them, such as walls. Sometimes this is of great tactical advantage to the player; s/he can use slight speed or distance advantages to get around a wall with a u-turn, then rely on the monster keeping the nearest mathematical distance and walk the other way down the wall, acquiring some safety.

Now, I’m all for cheating on the player’s behalf; one of these days I’ll blog about it at length. However, there’s cheating and there’s cheating. Some of it keeps little nagging things from ruining gameplay; that’s good cheating. Being lax on player bullet collision, and being overstrict on player personal collision, means that the player “just barely gets by” when oftentimes they shouldn’t, and “just barely makes the shot” when oftentimes they shouldn’t. You can just crank the game difficulty to compensate, and it leads to a player never feeling like they were ripped off or cheated. The Japanese game company Treasure are absolute masters of this careful balance (sorry, AFAIK they don’t have an English-language page. Just pretend you can read it.) But, there’s another kind of cheating that game programmers do. Actually, there are several others; I’m gonna skip stuff like giving opponent AI information it shouldn’t have to keep it competitive. Right now, what I’m going to talk about is sacrificing realism for computation time.

There are several problems with cheating to save computation time. Some of them are reconcilable; others aren’t. Generally the least controllable issue here is that oftentimes you just can’t afford the raw horsepower to do what you want to do correctly. First person shooters in the 286/386 era are a prime example; Wolfenstein and DooM got by just fine with blitting, but given modern standards they look positively silly. The important bit here, though, is that Wolfenstein and DooM’s approximations were good enough™ they did not adversely impact the game, and until they were made outdated by the horsepower required for a more accurate solution, the impositions their techniques created generally didn’t impact the game. (There are a few exceptions, notably the 2d+height map preventing truly 3d maps, but that was more of an engine issue than an issue of approach, so whatever.)

Horsepower aside, though, there are also issues of sloth or ignorance. In fact, field of view algorithms provide an excellent example even compounded above the previous example. Gee, can you guess what I’m gonna start going on about?

The fact of the matter is that on a complex 2d planar map, even implemented well, field of vision code is moderately expensive. Hansjörg Malthaner brags, and rightfully so, that his field of view implementation can crank out a 59×59 area in under 2ms on a 400mHz k6/2. Whereas that may sound like hopelessly antiquated equipment by today’s standards, please remember that that’s talking about the field of view for just one creature; even dealing with a machine that can push 16x what that does, when you’re dealing with (say) 256 creatures – and that’s not terribly unlikely in a Roguelike at deeper levels – you’re still looking at around 32ms, just to figure out what monsters can see what. That’s before you consider anything like, say, what the monsters’ responses would be. And, to put that in perspective, we’re talking about a full two frames at 60fps (the rate at which most console hardware runs) – that’s slow enough to see a stutter, even on modern hardware.

And – I cannot emphasize this enough – Hansjörg’s implementation is good. This is not the upshot of some naïve bumbling. This is what kind of speeds one should expect.

Now, granted, this is a fairly severe situation. For one, 59×59 implies sight radius 29, which is big by anyone’s standards, and since we’re talking about area which is exponential and a workload tied to a surface unit instead of an edge, and since that workload is also exponential, then having an area that big is pretty serious. Also, games other than roguelikes don’t usually have low to middling hundreds of active, thinking opponents at a time (well, inasfar as roguelike creatures think, really, but that’s beside the point.) But, as we all know, I’m working on the Nintendo DS, which is a 67mHz ARM9; when we’re there, we’re just not talking about cutting edge computational power, and therefore speed seriously matters to me. Granted that the field of view in my game is much smaller, it’s still a pretty big issue.

This is where the kung-fu comes in. See, there are other repurcussions to choosing a field of vision mechanism other than speed. Granted speed is what we’re interested in here, but there are other things to be considered. That is, for example, why I’m not implementing the giant goto map generator of Jesse Welton’s. Instead, what I’m doing is going to give me view regions for specific tiles; that information will be enough to implement a much, much stronger perception algorithm, by gauging what fraction of a tile is visible. That way I can have monsters with very long sight who won’t notice you sneaking up on them around corners, or monsters who only see six or seven tiles away, but who notice absolutely everything in range. It should make far more satisfactory AI chase behavior, especially since I’m going to be tracking actual creature knowledge.

Anyway, that’s just what I’m working on in Southgate at the moment. New topics soon.

Flow is deeper than its ancestor Snake, even though it doesn’t add much by way of game mechanics. Flow is Jenova Chen’s thesis for a Master of Fine Arts degree. The thesis itself seems to be largely about applying Mihaly Csikszentmihalyi’s notion of flow – that is to say, the critical area between boredom and anxiety – to gaming. The application of direct principle – especially the self mitigated difficulty factor – is in many ways impressive. It’s a shame that Chen is such a painfully obvious game design novice; there are simple critical flaws at the time of this writing which make this game suddenly turn frustrating about twenty minutes in. That said, until those problems hit, the design is positively exhilerating, which is weird, because it’s just Snake, for chrissakes.

The germane differences are as follows:

1. Boundless game world, with a camera which (badly) follows the player.
2. The things you’re eating are alive, and some of them fight back, using the same rules you use to eat them to in turn eat you.
3. There is a distinctly Rogue-like mechanism of depth, wherein as the player ascends or descends, new opponent creatures are added, which are progressively more difficult to handle. Some of these opponent creatures are in fact great fun to fight.
4. There’s a froody newage soundtrack which is complimented by atmospheric noises when things happen, such as competitive eating.
5. The credits are actually rendered as inline positioned non-elements within the game world, which is quite pretty once it stops being confusing. They also disappear after the first two levels, meaning they’re not obnoxious.
6. The game is rendered in a very attractive fashion using geometric creatures, yourself included, drawn in a way which makes me want to call them bug-fish. The layer immediately below you is rendered at a shrunken size, and blurred, which though not entirely a convincing visual effect, is positively gorgeous.
7. Entities on the current layer have a very faint aura effect, which is subtle enough that it took me a while to even notice it. However, once I noticed it, I realized that not only does it make the rendering easier on the eyes, but it also makes it easier to keep track of on-screen objects. I don’t understand why just yet.
8. As you grow, not only do you get longer, but you start developing somewhat bacteria-esque flagellae which speed you up.
9. Things frequently vary subtly in size or shape, which makes the visuals consistantly attractive and which staves off the visual feel of repetition ad nauseum so common in other games.
10. Fighting several enemies simultaneously is nearly impossible, so you have to use tactics to drag one enemy away from the herds that they tend to cluster in, and then kill it.
11. Some of the other animals eat the same things you do, and when they’re around, they scavenge your kills, introducing some strategy into fighting.
12. In the tradition of one-on-everyone combat games like sidescrollers and first person shooters, killing something gives you a direct reward. Since there’s nothing like ammo, corpses turn into food, meaning you can partially just up and eat your enemy.

Amazingly – at least to me – this makes for a very, very playable game. In fact, I found it borderline addictive within several minutes of play, something which is very rare for someone as jaded about games as I am. Unfortunately, there are a few problems so serious that I have a hard time playing it for long.

1. The game partially silently fails on Flash 7 or earlier, rendering none of the player and fractions of enemies. However, the failure isn’t obvious unless you’ve seen screenshots of the game in action. I almost gave up on this game before I started playing it, because I only had Flash 7 installed in Firefox; I tried it in IE out of curiosity, and since IE didn’t have flash installed at all I got the up to date plugin, which worked. This is a miserable design flaw, which people on the game’s forums repeatedly attribute to their browser or operating system. What’s worse is that version checking in Flash is trivially easy, and the authors are aware of the problem. This could be fixed, and needs to be.
2. Food sources are not replenished. Ever. After 20-30 minutes, you just get stuck. The first time I played I wandered around for almost an hour before realizing I was just screwed. Food should probably replenish on the layer to either side of you, not on the current level, so that new additions aren’t distracting (in fact, maybe two layers below, so that it doesn’t show up in the blurred layer either.)
3. The death food balance isn’t even. Instead, killing a creature releases less food than it consumed. The game is smart enough not to allow enemies to eat or to fight one another until you’re actually on the level they’re on, so showing the blurred layer doesn’t ruin the upcoming level. However, that blurred layer also gives you information, like how much food to expect when you get there. When you get down there, the enemies start snapping up food, only a small fraction of which is released when you get into murder mode. As a result, the player perpetually feels ripped off by a level that promised more food than it delivered. Rather than reducing the number of food given, as an encouragement to kill early and often, the value of the food released should be reduced. This is less an issue of actual food points gained and more an issue of “I saw fifty things and I only got to eat ten.” If the game balance is served by constantly reducing a level’s food quotient, it should be done by value instead of by count, so that the player’s brain doesn’t insist that 80% of the food it saw is missing.
4. As you wander away from the center of the map, things start to disappear. However, combat happens at very high speed and usually involves a chase; if the combat isn’t brief, it’s easy to get lost. There is no indicator of the direction back to the center, so either you wander around until you get lucky – often making it worse – or you start over.
5. The path between depths are special creatures which don’t serve as food, marked either red to move down or blue to move up. This in itself actually works very well, and confusingly, they are restocked, though the food supply isn’t. Unfortunately, it’s easy to trim that count down to one of each kind, and it often takes a few minutes just to find one. Especially when the food supply on a level is emptied and you can see a ton of food below you, this is extremely frustrating. A mechanism like John Sensebe’s Space Loonies, wherein things you’re looking for are indicated in location by an arrow at the edge of the screen, would be a god-send – two of them, one for up and the other for down. (If there are several, just point to the nearest one.)
6. There is an “eat time” involved when you consume something – you have to wait for the food point to get used before you can eat again. This time increases as you get bigger, and quickly becomes much too long. I’ve been in situations where I’m just swimming around a pile of food created by a destroyed enemy for three minutes or more, eating then waiting to be allowed to eat again. I could see a uniform flat pause of no more than a second, probably better around 2/3 of a second. I could even see an extended lag for the special food marked with a plus, which just instantly gives you a segment. But, this is just too long. It’s boring. By the time you’re done collecting your reward from combat, the rush is gone.
7. The player and creatures are “stunned” when a piece of them is eaten. When the player gets very long, it’s nearly impossible to fight certain kinds of enemy without losing a piece in the process. If the player loses two pieces concurrently, the stun becomes longer than an enemy’s eat time, and then you just can’t move, and have to watch your otherwise gigantic and healthy creature get eaten piece by piece. This is reminiscent of the Ice Monster problem in early versions of MAngband, wherein it took longer to recover from freeze than for the monster to freeze you again and wherein once frozen you have no resistance being re-frozen, leaving you unable to act until you died.
8. The camera routine attempts to lag behind the player’s movement, to make for a “natural” feeling of the window trying to keep up. Unfortunately, the implementation is low quality, and frequently leaves the player entirely off screen. This means either you have to blindly run, or you have to stop running to see yourself.
9. The player moves by putting the mouse in the line the creature should go. However, due to camera lag, there’s a wobble effect like putting a vase on a Lazy Susan – if the vase is sitting still, spinning the Lazy Susan has no effect, but if there’s any wobble it’s exaggerated until it falls over. The camera lags behind the creature, so the path of follow between the creature and the mouse cursor is altered, and changes in a direction which proceeds to do it again and again. This could be called an issue of skill, but that the camera frequently leaves the creature right up on the edge it’s trying to reach, it often makes it impossible to send the creature in the direction you want to go, because there is no location on screen which actually creates that line.
10. Combat with creatures of your own kind is nearly impossible unless there’s a serious difference in power between the two creatures, because of the follow effect – no matter where you hit the opponent, there is no way to get away efore your tail is in his strike range. This means that any attack you make at an opponent hurts you equally, and the only way to take out an enemy is a series of long distance sneak attacks, all of whom take forever and make it easy to lose your opponent. This is extremely not-fun. However, all other creature types have no such problem.
11. Creatures can hurt you whether or not they’ve been recently hurt. This makes the previous problem much worse. If there was a question of equianimity between player and enemy, then it should be both the player and the enemy who have to lag after getting hit. However, the enemies are temporarily invincible after being hit, because they essentially don’t fight each other, and you’ve got that eat time lag; no such protection is afforded to the player. An ideal repair would be to introduce a half second lag similar to the kind one expects of 8-bit era games while a creature is flashing, wherein the creature can neither hurt anything nor be hurt itself.
12. The screen is just too damned small, especially vertically. You can’t see where you’re going. There’s no mini-map or radar. You can’t find the stuff you’re supposed to be playing with. Frequently, you just accidentally hit a layer up or layer down creature, sending you out of the thing you were trying to do, because you just can’t see them in time. This problem is exacerbated by that the player tends to approach the side they’re moving towards, instead of the side they’re moving away from, meaning essentially your entire field of view is the stuff behind you. This is frustrating, unfair, and just amazingly bad design.
13. Creatures change color – white if they’re bored, orange if they’re attacking, or black if they’re being hurt. That on its own is actually very cool, and effective in the earlier layers. However, as the game progresses, the background turns from blue to black; this means that creatures being hurt get progressively more difficult to see. Though this can be argued as a game design facet, the problem is that there is no lag inbetween your hurting a creature and its ability to hurt you, even when it’s effectively disappeared, meaning any time you hit something you have to immediately run away, because the enemy’s mouth is god-knows-where. This is very frustrating, and impedes the prospect of constant combat. The aforementioned lag between taking a hit and being allowed to hit back would fix this, while allowing the disappear to continue – in fact, it would make the disappear a desirable thing, because then you wouldn’t have to sort out the visuals for non-active creatures. Because all creatures have the same base color, when creatures overlap you pretty much can’t see anything. A similar and complimentary repair would be to subtly vary creatures’ base colors, to the tune of things like #fcfffc instead of perfect white, so that they can be seen apart when overlapping but otherwise look roughly the same.
14. There is an infuriating camera bug after long combat when you just barely win, where the player wanders offscreen and never comes back. I’ve lost several creatures that were perfectly healthy this way. There is the appearance of the camera’s position polarity being reversed; it just goes the wrong direction. However, moving the mouse the wrong direction to compensate doesn’t seem to fix anything.
15. The eat radius at the mouth is too small. Sometimes you’ll pass 4/5 over a creature and not get it.
16. The presentation of the game involves a lot of border space, and the nature of the game involves lots of clicking. This means that hitting outside of the edges of the screen – especially common because of the camera bugs – loses you control of your bug.
17. Hello? Pause?

It’s a beautiful game, and has an obvious artist’s touch each to its appearance and its audio. The gameplay is designed by a talented academic amateur, who has the big picture issues dead-on, but who is missing virtually every possible subtle detail. The result is just heartbreaking: a game you really, really want to play, but just can’t.

Luckily, Jenova Chen says it’s a work in progress, and seems to be directly amenable to game repair issues, especially as presented in the forum. Moreover, the game release was on the day of this post, so this may just be alpha game syndrome. This work shows real promise, and if the various serious gameplay flaws are repaired, I see a long term coffee break addiction in the making.

Kudos, Jenova – you’ve done a damned good job on the game’s framework. Time to break out the brass polish.