Quote from: Kai on June 16, 2009, 02:31:38 AM
There's a simpler model. It's called Flow (http://www.jenovachen.com/flowingames/introduction.htm).
I know I said video game theory, but I'm specifically looking at this in terms of player versus player combat. What exactly are you supposed to do to maintain good flow when the degree of a challenge isn't necessarily in your control. Making a loss less than catastrophic is the only real thing I can think of.
The second thing I'm pondering, is how the hell do you keep the pacing in a limited turns game (akin to legend of the green dragon for those that remember it), where a player can only take so many actions in a day. Is there a strategy for this, or do you simply need to ttract the right kind of player?
Making losses less than catastrophic is good. Also possible are equalizers -- either in the form of random elements that significantly boost one side or the other (because if it randomly happens to the guy who would have won anyway, no change) or by offering diminishing returns on skill/power (many fighting games work kind of like this. It's why button mashers will still win games over experienced players in some of them, and by aficionados of the genre is considered a weakness).
As for how to make losses non-catastrophic while retaining enough impact to matter, FPS games are getting it down to an art. Some of the modes in Counterstrike or Left 4 Dead are good examples.
Turns-limited games (especially turns-per-day games) aren't the best for this, which is part of the reason they have a limited appeal. The typical design assumption is that people will log in once per day (or sometimes once every few days) to use all their turns, and since there is also typically limited player interaction, the 'flow experience' focuses on short time investment. Within that assumption, however, you can plan a pretty streamlined experience. This is arguably why Kingdom of Loathing succeeds (although if we were to discuss that and similar games in-depth, I think we'd probably find more elements as well).
I think an arguably better strategy to maintain flow while keeping traffic balanced is to use a time-till-completion model, which is what Travian, Utopiakingdoms, etc do. I can't think of any 'adventure' games that do this right now, but I can imagine a few models for it.
Travian and utopia kingdom require you to be logged in almost constantly for a minimal amount of fun if you want to grow though. Time to complete seems to be a bit of a wash.
UK is also epic fail at the flow model, since your first combat usually results in complete destruction and subsequently being turned into a resource farm :argh!:
Quote from: Requia on June 17, 2009, 01:02:48 AM
Travian and utopia kingdom require you to be logged in almost constantly for a minimal amount of fun if you want to grow though. Time to complete seems to be a bit of a wash.
UK is also epic fail at the flow model, since your first combat usually results in complete destruction and subsequently being turned into a resource farm :argh!:
Hahah. The problem with UK is that in order to survive being attacked, you have to spend all your resources as quickly as possible and keep your army *away* all the time. It's a silly, silly, stupid system.
Initially both of those games do require a lot of attention, which I agree is a weakness. Part of that is sort of deliberate; by giving people a sense of urgency/weakness, they probably have an easier time selling premium services. If you were making something with a bit more attention paid towards making it something game designers would find 'good' rather than something aimed at being profitable, those are overcomeable weaknesses.
EVE online is a game which adopts that model for an adventure game, come to think of it. That also has some decisions regarding queuing and the like I find weird, but at least offers another example.
Edit: Should've probably mentioned this in my first reply. I find Flow to be
one good abstraction, but not necessarily
the definitive one. It also provides very little advice on what
to do -- mostly it helps rule out (if it's remembered) those weird decisions game designers sometimes make to fit with their sense of 'realism' or 'challenge' but really just frustrate the player.
Since I'm looking at things from the perspective of designing a free to play mmorpg (it'll never actually get made, but design is fun), two of the big things I'm trying to figure out are stickyness and donations. (donations aren't necessarily hard if you have good stickiness, the guy that runs twilightheroes confessed to 50 cents per user per month, and he sucks at soliciting them). Flow helps a lot with stickyness.
Quote from: Requia on June 17, 2009, 01:42:51 AM
Since I'm looking at things from the perspective of designing a free to play mmorpg (it'll never actually get made, but design is fun), two of the big things I'm trying to figure out are stickyness and donations. (donations aren't necessarily hard if you have good stickiness, the guy that runs twilightheroes confessed to 50 cents per user per month, and he sucks at soliciting them). Flow helps a lot with stickyness.
Ha! I'm working on a browser game in my rather prodigious spare time (you'd think I'd be more productive, what with all I've had these past few months. I guess it's something like this (http://xkcd.com/264/)). Monetiziation is one of my big concerns. I'm trying to think of ways to scrobble together a viable system that doesn't make people hate me.
$.50 per account per month would be pretty epic, honestly. I think I could get 500 accounts in my sleep, and that would cover hosting fees, me actually paying (art etc) contributors, and maybe even enough left over for a nice dinner each month.
good ways for monetization
1) While you should keep the benefits of donating relatively low, make sure they'll boost a new player a fair bit. Allowing donations in another persons name plus some sort of resource trading can encourage the players to set a market rate for a donation of a given size.
2) this same strategy should be applied to a second, tournament version of the game, Fast paste and more pvp oriented, it resets every 2 or three months, ensuring that the people who want to, and are willing to pay to, excel in the tournament edition pay you on a repeat basis. The tournament edition should have some sort og prize thats applicable to the standad division, and not obtainable any other way, or be very hard the other way as well, to further encourage starry eyed dreamers to pay in order to get that prize (cybernations lets you add a flag to the game, its simple as hell but people *want* it when they're engaged politically).
3) *don't* be intrusive. The donate button should be obvious, but if you constantly mention all the cool things that donaters get, or ask too often people will quit.
4) don't be corporate. People like giving to individuals, they don't like giving to companies. They especially don't like giving if you hire some grunt with no authority to handle complaints.
Hmm, can you actually do the programming for a webgame?
Quote from: Requia on June 17, 2009, 06:18:24 PM
Hmm, can you actually do the programming for a webgame?
Slowly. I have to teach myself pretty much everything, but no individual thing is actually that hard. In most cases deciding
how I'd like to do something is far more time-consuming than learning what I need to know to do that.
w3schools (http://www.w3schools.com/html/default.asp) (linked to the html reference there, but they have most major web scripting covered) and the online php manual (http://www.php.net/manual/en/index.php) cover pretty much everything. There's also a DIY guide to browser games here (http://buildingbrowsergames.com/tutorials/) that comes in handy when I don't know where to go next.
free tip, if you're just learning to program, pick up Python instead. then use the Django framework to build a website. PHP is a complete kludge, it's the BASIC of webprogramming, with the exception that BASIC is also useful outside the web.
seriously
Quote from: Triple Zero on June 17, 2009, 11:14:09 PM
free tip, if you're just learning to program, pick up Python instead. then use the Django framework to build a website. PHP is a complete kludge, it's the BASIC of webprogramming, with the exception that BASIC is also useful outside the web.
seriously
I'm fairly comfortable coding and scripting (It's the specific languages I need mans for, since prior to this I did most of my stuff in a C variant); I'm less comfortable with SQL. And the best tutorials I have available are with the Holey Trinity of PHP / Apache / MySQL.
ok, well Django supports MySQL, but in such a way that you should never have to write any. and for developing, it comes with its own webserver, so you don't need Apache either.
Using Django would drive your hosting cost way up though, and since you need a dedicated server, you lose scalability. PHP, Perl, Javascript, have an advantage that you can take them anywhere.
A lot of places have python (hell I've even seen things like lisp and haskell) as well, but not necessarily with django.
Going to more general game design stuff for a moment, the Corruption (http://www.principiadiscordia.com/forum/index.php?topic=21144.0) essay (that you hated so much, Requia :wink: ) is a series of thoughts that originated in game theory.
I'm interested in the idea of an uncheatable game. The idea germinated a long time ago, when I was heavily into MUDs. I logged into a game in which the end of character creation was reading a draconian policy statement which, aside from stating that the developers were to be treated as gods (sic), basically said at one point something to the effect of 'using X and Y features of the game will be considered an exploit and you'll be banned. we haven't figured out how to remove those yet and have more important things to do.' Now aside from the hilariously made-apparent fact that the game was a stock codebase with incompetent yet narcissistic developers (I never did finish creating a character there), this caused me to consider what and why games make "social" rules. This thought evolved over time as I saw policies that games had against botting and similar manipulations.
In a computer game, anything internal that is verbotten for a player can be simply coded out. Things like bots obviously can't be coded out, but they always struck me as symptomatic of bad game design to begin with. If you're making a (computer) game in which you are denying players the ability to automate tasks yet rewarding behavior that can be automated... Well, that strikes me as inelegant. Ugly. And even then, there are fairly simple measures you can take which (rather than making a social rule) allow you to limit a player's ability to automate. That's still kind of ugly, but it at least acknowledges the reality of the medium.
Then there are bugs and exploits. These things are in a way definitionally unavoidable -- if you (the developer) knew there was going to be an exploit to begin with, you would have protected against it. So you can't address these the same way. And one of the major troubles here is that smart and selfish players simply don't report these things and limit their use of them, later claiming they didn't realize X behavior was exploitative. There's no benefit to them to reveal it and plenty of penalty if they do (especially once they've engaged in the behavior several times). This is a classic game theory scenario.
So I feel like a lot of what has to change is the definition of 'cheating' and how it's handled. Right now the onus is often put on the player to sort of tread on eggshells while playing the game -- and that if they don't, they're somehow responsible for 'breaking' what was never really 'whole' to begin with. What seems more sensible to me is to, as a developer, say: "Here's this world. Try to break it." Then when the players inevitably do, it's an exploration that both parties can be actively involved in rather than an adversarial relationship.
Rather than punishing players for exploiting something, for instance, you can reward players who report exploits (typically by not rescinding whatever advantage they gained by using it until it's fixed). It's been pointed out to me in other discussions that this is a tricky proposition in some cases (video games, unlike the real world, can run into issues involving infinite numbers of things), but I think there are negotiable elements nonetheless. Similarly, rather than punishing players who bot, it seems more sensible to examine areas where lots of players are botting and make those aspects of the game more fun (or at least streamline them so that botting isn't advantageous).
Since this is a proposition of games theory, I feel like it applies to politics as well -- hence the above-linked rant, which addresses some of the steps you'd take to implement this in a government rather than a video game. But this is sort of where it originates from.
Quote from: Requia on June 17, 2009, 11:39:41 PM
Using Django would drive your hosting cost way up though, and since you need a dedicated server, you lose scalability. PHP, Perl, Javascript, have an advantage that you can take them anywhere.
A lot of places have python (hell I've even seen things like lisp and haskell) as well, but not necessarily with django.
Django is just a python framework. You can upload (or checkout if they have svn) it to your user directory and use it from there. Just like you'd use, for instance, Smarty in PHP.
It's true that nearly all places have PHP, but a modern webhost will also have Python. I don't know how widespread Perl is, I would guess somewhere in between. And Javascript is a clientside language that has a completely different purpose and is not relevant in this context.
But PHP is a kludge, seriously. The only reason why it was your first choice is because everybody else uses it. Because the tutorials for Apache+PHP+SQL aren't that good. First, they teach you PHP. Second hardly any of them advise people to use a templating system such as Smarty, and instead encourage people to mix up PHP code with HTML markup. In fact PHP was originally designed with this "feature" in mind, the fact that this is always a really really bad idea, is just one of the many kludges.
If you are serious about developing an online game, you can also find a hoster that offers a modern serverside scripting language. If you are less serious about it, you can run the alpha from your own machine. Django comes with its own (python-based) development server, and if you insist on PHP+MySQL I can recomment XAMPP (but please do yourself a favour and use Smarty--also disregard any tutorial that talks about medium-large PHP websites without mentioning a templating system)
QuoteGoing to more general game design stuff for a moment, the Corruption essay (that you hated so much, Requia wink ) is a series of thoughts that originated in game theory.
It's not that I hated the essay, it was that you were starting more Or Kill Me threads than everyone else combined.
Quote
Django is just a python framework. You can upload (or checkout if they have svn) it to your user directory and use it from there. Just like you'd use, for instance, Smarty in PHP.
Low cost hosts specifically forbid it, something about persistent processes and minimizing server load. Dedicated hosting is different, but its an order of magnitude more expensive.
Python is definatley available without django though.
forbid what? Smarty or Django? either way is retarded but what kind of hosts are these?
and what do they expect people to use Python for, on a webserver, without Django?
btw I will look for a server with Django support soon enough as my current freelance project nears completion. I hope it won't prove as difficult as you make it sound, but this is 2009, right?
Quote from: Requia on June 18, 2009, 03:52:38 PM
It's not that I hated the essay, it was that you were starting more Or Kill Me threads than everyone else combined.
I was trying to post a piece of kopylefted work each day. I kind of got distracted taking care of my gf, who got her wisdom teeth taken out a couple of days ago, but meh.
Quotebtw I will look for a server with Django support soon enough as my current freelance project nears completion.
They're not that hard to find -- just google "django hosting" -- but a lot of the major "brands" don't have it as part of a shared package solution. I haven't done a price point analysis of the relative cost increase to go with a django host, but there do seem to be some advantages to going with php/apache... it seems to more fill the niche of standard animal. Looking at a comparison (http://wiki.python.org/moin/PythonVsPhp) of the two, the advantages to Python mostly are things that I would care a lot more about if I were using it
not as a web language. (Hooray threading?)
I do, however, feel that the discussion may be moving away from video game design theory. =P
Back on topic then
How would you structure a multi-player games economy?
I'm working on destructuring the idea of economy, actually. I think WoW has a pretty good version of the standard solution, or at least did at launch (I've not kept up with some of its recent additions). City of Heroes recently-ish added in the ability for players to choose any given 'item' in the game by accumulating what amount to quest tokens. I'm slightly more interested by that because I feel like the model was largely abandoned in the midlife crisis of multiplayer online games (between text and graphics).
But I feel like the imposed models have inherent limits to what they can explore. I'm trying to come up with ways to trivialize the idea of game currency and offer players tools to manage secure and convenient service-based exchanges.
A loose example: A small clan builds a castle. The castle is near a mine, which gives it access to those resources, but means it is constantly under attack by respawning groups of goblins. The individual attacks, even when successful, do little damage, but accumulate to be a more serious issue. Rather than trying to have members online at all times, the clan posts an open contract: anyone who repels one of the goblin attacks is given a voucher good for a use of the clan's repair smithy.
This is completely untested, but it doesn't contain anything I couldn't code. Generalizing it is difficult, but possible. One of my interests here is to make a viable inflation-less economy... not because I think inflation is a bad thing, when handled properly, but because I find it an interesting challenge.
Quote from: Arafelis on June 19, 2009, 05:30:05 AM
I'm working on destructuring the idea of economy, actually.
Nobody cares.
There's a reason we stopped using cashless economies 3000 years ago.
Quote from: Requia on June 19, 2009, 06:00:12 AM
There's a reason we stopped using cashless economies 3000 years ago.
Easier to code.
Croesus was one fuck of a programmer.
Quote from: Requia on June 19, 2009, 06:00:12 AM
There's a reason we stopped using cashless economies 3000 years ago.
Lots of reasons. But games offer us opportunities not available in real life. For instance, we can ensure all exchanges are guaranteed to be as represented. We also have advertising and distribution solutions that weren't available when goods were phased out for fluid currency. Availability isn't the issue it used to be.
Plenty of existing games already run on
goods bartering, and do quite well thanks to what I've mentioned above. Travian and UK, again -- they have no currency (or I suppose you could take the view that everything in the game is currency, but the difference seems academic to me). I'm simply extending this idea to explore service bartering.
I didn't play travian long enough, but its got a very similar resource set to UK, in which case I can be pretty sure the economy there is useless. You have 4 different kinds of money, and since everything takes all types of the resources, trade doesn't accomplish anything. You might be short on a resource right now, but in the 12 hours it takes to do a trade in UK, you usually end up being short on something else. It might work better with a less time oriented system though. Hmm
Some interesting stuff in here.
Anyway, those of you who remember playing the early NES/SNES and that era of games may want to check out this article:
http://kidicarus222.blogspot.com/2009/06/its-secret-to-everybody.html (http://kidicarus222.blogspot.com/2009/06/its-secret-to-everybody.html)
A very interesting look at how many of the early game characters got the names that they carried, and how hilarious Japanese->English mistranslations stuck in the meta-narrative of many of the titles. [WARNING: LONG]