Throwing around ideas on short term fun in a browser game...

[JoyWriter]

Callan I think you make a good point about rapid prototyping in there:

A good starting system that's fun in some small and short term way encourages you to keep playing the game even if the rest of playtesting (not to mention coding) becomes an infuriating bore. This is one good reason for crafting a cute little mechanic to start off with, then plugging them into each other.

I do love nat 20s, especially if they lead to "criticals" or some kind of unusual coolness. But as I said before xp isn't gratifying to me in that particular instance.

But there are bags of ways to make basic combat fun, stefoid suggests one good way:

the random jackpot element was the variety of enemies encountered at any given time with respect to recovering items.  Some types of creatures are tough and dont carry items - wolves or something.  some types of creatures are relatively weak (if your team is not susceptible to their area of expertise) but do carry items - goblin mages say....  Some creatures swarm like bees or dogs, and some dont.  the Jackpot was encountering a swarm of (relatively) weak creatures who dropped items!  A swarm of neophyte priests?  joy!  Wade in and reap tons of team-enhancing booty, (as long as you arent susceptible to whatever attacks they possess in the process)

Differentiation of enemies makes conflicts more unique, and a really good form of differentiation is what they call orthogonal differentiation; it's not more (bigger/badder in the same way), just different.

Now the snag of this is it can explode your coding time:
"No prob making enemies, I'll just inherit everything off the same class, and just change the quantifiers"
"Crap, this means they are behaving the same, so I'll need to make one better at one thing than another"
"I'll need more variables if I'm going to fit in more guys"
"Crap, the master class is now huge and murder to debug, and I have loads of behaviours to test"

Or alternatively you can say "I'll just cut those functions down in to the different subtypes, and slowly introduce more types of enemies in different combinations, and use what I learn to set the progression for the player" basically leading to mario!

So how do you have the variety without annoying coding? Well for a start you could just chuck general overarching descriptors at it from various different mythologies, (for a change how about the ba gua and the hopi medicine wheel) and just play pokemon with them, but only on criticals. That way normal play is preserved, but you get extra cool stuff if you critical, and particularly if the move is matched to their type. It just sits on top of normal balance as something without a massive effect, but a bit of semi-transparent jpg pyrotechnics.

[contracycle]

Geez guys, I'm feeling a complete non responsiveness to gamble from ya'll? I'll ask the same thing I did of Josh - haven't you ever thrilled at rolling a nat 20?

Nope. They have nothing to do with me.  What I take credit for is shifting the odds required to succeed from 18/20 to 8/20.  But then, I don't see the attraction in gambling generally.

[Monkeys]

I don't have a combat system at all in my game.

Sure you do.
Any form of 'combat' that is resolved by a system of rules constitutes a form of "combat system."
Age of Fable sets a difficulty (or difficulties) per obstacle that are compared to a character's static/dynamic value in a corresponding skill/quality.
The computer handles the calculations; the players click through the adventures.

Well, I don't have a different method for resolving combat to resolving anything else, or a fixed set of difficulties or attributes to roll against. The point is that the default assumption is that a game should have one or both of these things. Thus the default assumption is that combat should take a reasonably long time, and thus the problem is framed as "how do I make combat more interesting", when an equally valid option could be "make combat so quick that it doesn't have to be interesting."

[Callan S.]

Yeah, there is that issue of trying to flog a dead horse.

On some of the suggestions, I'm just seeing exploding coding time - I think if the idea of writing out a rough draft of code for an idea here isn't appealing, then the idea is probably too complicated. Or, if you do write a rough draft, cheers!


Right now I'm considering a monster defeat count - after each battle there's a, say, 10% chance your defeat count ends. Otherwise it continues. You win at this when you get to X amount of defeats. I'm planning for X amount to be the amount some other player got (it'll show their name and score) - thus giving a bit of asycronous player competition in the style of legolas vs gimli orcs defeated count! Though I'll probably code it as just a fixed X amount at first, to break it down into easier to code elements first.