Last week, I managed to put most of this together. I'm running a solo campaign, and we decided to test my new approach to combat with an encounter between the PC and an NPC. If it worked, we'd consider it part of the campaign; if it didn't, we'd write it off as a failed test. It worked.
We played for about 6 hours elapsed time, with probably at least an hour of that being antecedent and wrapup, rather than the combat itself; we also interrupt sessions for breaks, so I think the combat itself probably took between 4 and 4 1/2 hours. I was particularly pleased in that I spent very little of that time distracted: the bulk of my conscious attention went into considering the fictional situation and writing descriptions thereof.
I thought that, with one player, I might be able to get away with using file transfer via Trillian instead of needing a program that functions as a whiteboard, so I loaded up Adobe Illustrator and got my tablet ready, expecting to sketch the terrain and send the player a JPEG. However, it turned out that I didn't need to draw anything. I'd already sent the player a topographical map of the area as part of the general campaign info. I had anticipated needing a sketch of the terrain on a smaller scale, but it wasn't particularly complicated terrain, and the existing map turned out to be all we needed to get oriented.
I still expect to need to send graphical information at times, because not every place where combat may occur is likely to be mapped in enough detail. I've bought
ProjectForum, which is a wiki server, to organize my campaign notes, logs, and maps, and it may be that simply adding a sketch to the wiki would be a satisfactory way of communicating quickly to multiple players. Without testing, I can't tell whether that would be sufficient, or whether I want to go for a program like
Fantasy Grounds that allows players to move tokens representing the PCs around.
I was happy with the way my homebrew worked. It wasn't hard to come up with descriptions of what was happening that more-or-less tracked the dice results and followed from what had come before. The thing that particularly pleased me is that, while it had a tendency to drive results toward the expected outcome, that tendency wasn't so strong that the PC, making fewer tactical errors, couldn't overcome the NPC's edge in skills. He underestimated her, erred in his opening move because of it, and never recovered the dominating position he might have had. She won, by a margin that seemed believable to me given their skills, in a fashion that seemed believable. If not for her capitalizing on his mistake, it in all likelihood would have gone the other way; and that's how I wanted it to work.
I haven't described any mechanical rule for carrying over advantage and disadvantage into subsequent actions. I did some of this on the fly, taking into account the results of a previous action to determine whether someone could act effectively and in a timely manner the next time. I don't know whether having a mechanical rule for this would help or hinder. I could probably use the winner's previous degree of success as a bonus to their next role, and I could even modify the dice code to pick it up automatically for me. But I'm not sure whether this is always the realistic procedure -- is it not possible that a character's next action might be of a sort that a previous failure might not interfere with that much? So I want to try a few more sessions without a rule first, before I experiment with one.
I was momentarily puzzled as to how to resolve a sort of attack that I haven't seen described in any other game system. Usually an attack is physical or magical, but not both. However, this was a fight between mages, and in my setting it's common for mages to use weapons and magic at the same time: for instance, a charged sword may assist in penetrating the enemy's magical shield and delivering a magical strike. Finally I decided to roll twice for such an attack, once for the physical and once for the magical aspect. It produced intelligible enough results, at least in this instance.