Monthly Archives: March 2014

Chrome for Android

I’ve been liking the Android experience since I got the new phone, and Chrome in particular has been pretty good to work with, but.. there are a few quirks to it that I find a bit infuriating. One isn’t major, but it’s a tad inconsistent, and just annoys me to no end: when you hold your finger on a link and select ‘Open in New Tab’, it does just that – it opens a new tab for the link. But then, it HIDES THAT TAB, shuffling it to the background and returning you to the previous tab. I wouldn’t find it so irksome, except that in literally every other situation, the new tab gets focus. Did the link itself specify a new tab? No problem, open it up and switch to that. Did the page open an unrequested popup of a writhing nymph doing unspeakable things to herself (complete with audio)? OF COURSE the browser should automatically switch to that, especially if you’re at work or your inlaws’ house. But if the USER goes out of their way to hold their finger on the link for two seconds and select an option to open the link in a new tab, well, that’s probably not anything they actually wanted to view. Let’s just shove that to the background, and let the user jump through a few hoops to get to it. Again, it’s not that it’s hard to switch tabs, it’s just annoying as hell that the only time Chrome doesn’t give the new tab focus is when it’s blindingly obvious that I wanted it to.

Beyond that minor quibble, there’s the train wreck that is Font Boosting. What it is meant to do is adjust font size of individual html elements, to avoid situations where the user needs to scroll left and right to read the entire text – long, fine strings of text are boosted to a size that is legible when zoomed out so the whole element is in view. In practice, though, what it actually does is make any site with dynamic content a complete mess, with some chunks of text tiny and others huge. Most sites I browse, I actually have to zoom repeatedly in and out to read everything – it makes reading, say, Reddit MUCH more difficult than it has to be.

It doesn’t have to be this bad, though. For years (as far back as 2012, from what I’ve seen), the majority of Chrome’s userbase* has been asking – PLEADING – for an option to disable this horrible, horrible mess of a UI ‘improvement’, and by and large the response has either been suggestions to add a certain workaround to a site’s CSS (which is useless to users, since it can only be done by each sites’ web admins), or to suck it up and live with it because it’s ‘better’ (we’re all just too stupid to see why). All they need is one simple dumb toggle in the Settings menu, and everyone would be happy – if they can give us an option to mangle the UserAgent to avoid awful mobile sites, you’d think this wouldn’t be that big a deal.

*If you think I’m exaggerating, just Google it. For every snippet of praise (mostly from their press releases), you’ll find at least two bug reports, three ranty blogposts, and five ‘WTF is this’ forum posts about Font Boosting.

**Edit: Okay, so Z2 put the ‘New Tab’ thing in perspective. Seems it’s a holdover from desktop browsers, where Ctrl+Click does the same thing; the logic behind it is that the typical user does that to background something to be read next, after they’re done with the page they’re on. I guess that makes sense, but it still seems rather counterintuitive to me, when every other method of opening a link foregrounds the resulting page.

Damage calculation

Got three weapon prototypes up and working: Knife (light/pierce), Sword (medium/slash), and Hammer (heavy/bash). Still playing with the timing and properties of each, but it’s a good start. Now to decide where to go next: combat, map/environment mechanics, or further fleshing out the GameObject class (which, realistically, should probably be first).

For combat, I’ve been doing some thinking on what equations to use. Attack is easy – (weapon base + strength) * modifiers – but defense threw me for a bit more of a loop. How much should armor affect damage taken? I don’t like the thought of a linear design (ATK – DEF = DMG) – a low-level character is overwhelmed too easily (especially if DEF > ATK), and if ATK and DEF scale at a similar rate, then you’re stuck doing a constant amount of damage no matter what level you’re at. I’ve decided instead to use exponential decay, something like:

DMG = ATK * e ^ (d * -DEF / ATK)

..where ATK and DEF are self-explanatory, e is Euler’s Constant, and d is a configurable rate of decay. This method tends to skew things toward the underdog – if ATK is much higher than DEF, then small increases in DEF will show a large payoff in the amount of damage mitigated, and if DEF is higher than ATK, the character will still do a small but decent amount of damage. A few examples:

  • d = .9, ATK = 80, DEF = 20: 64 dmg
  • d = .9, ATK = 80, DEF = 30: 57 dmg
  • d = .9, ATK = 40, DEF = 70: 8 dmg
  • d = .9, ATK = 50, DEF = 50: 20 dmg

Playing with different values of d will change the effectiveness of armor – the lower higher d is, the more heavily DEF is weighted. My hope is to have a combat system where magic users don’t get unconditionally bulldozed, and the player doesn’t get stuck in too many situations where they constantly do 1 or zero damage.