Pixel Scaling And Licenses

[Tempel]

I'm more than willing to debate this issue, really, so long as I'm not called evil at the end if I decide to stick with closed source.
Tarn Adams is not evil. Though Tuomo Valkonen is. Sorry, unrelated. Don't worry, we cool.

So, to make that clear, whether anyone feels its naive or not, this is more or less my career future we're talking about here. I've worked hard to become as good as I can at this stuff for a reason, it's not just a hobby for me.
Ambitious! Well, to invoke Tarn Adams again, along with Jason Rohrer, it's evidently possible to live off of nothing but donations. Probably not easy, but. Furthermore, since you'll control the official server, you'll still be able to make money from microtransactions even if you release the server source. This model may not work for all future games you want to make, but it'll work for this one whether your source is open or closed.

I fully agree! In fact I have considered doing something to spite the bots, and if I decide to do it it may in fact contribute greatly to me deciding to go free as in speech: sell gold myself.
That's not a bad plan, and it certainly goes with your microtransaction model; however, that's not quite what i had in mind. I, admittedly, have played very little in the way of MMOs (I played Kingdom of Loathing for two years, but that hardly counts, and a two-week demo of EVE), but i wonder why players should be rewarded for slaughtering a pile of rats or harvesting stationary resources all night long. Instead, rewards should be linked to favourable actions, like progressing in a story or helping another player through something. Easier said than done, i'm sure, but just keep in mind that you should reward the behaviours that are best for the game, and it will make players want to do what's best for the game.

On the other hand it might turn into an arms race between users adding features deemed unacceptable by the majority of users and those users who frown upon it adding counter measures.
If there's something you don't want to players to do, you should be preventing at the server, not at the client; again, if you make it possible, people who want it will get it eventually, open or not. Also, countermeasures in other clients' software won't really stop them, so no arms race is possible. In my idea of user-made clients, i'm thinking more of customization. For example, players heavy into the economy might want a highly advanced market interface, but you might not want such a daunting interface as the default for people new to the game, or you may not want to bloat the code, so you can let others do it if they want it.

I'd feel a lot warm and fuzzier if people in my vicinity stopped frowning on me because I'd become a contributing member of society. That may be an unfair argument, but personal reasons do weigh in this!
It's an unfortunately large group of people that frown upon struggling artists. In your case, it's especially difficult because so few people view videogames as legitimate art. So, if you wish to become an indie developer, you may be doomed to a disapproving society! Of course, if you can support yourself financially, they won't care so much, but as i've said, financial rewards should be about the same for this project whether you open or not, except where it comes to the quality of the player community. And that's all guesswork and speculation for now.

After lurking for months, i sign up and post walls of text. This feeling is... unusual.

 

[TaG]

I have a couple of thoughts here - they might be mad but I'd like to share them to see.

First I agree that if you have spent 10 years developing skills there ought to be reward for your efforts. But presumably that should apply to the people that developed scale2x etc. I see the point of GPL as trying to do something free speech so that further software becomes free speech.

So how to make money? If you release the game for free you could work backwards on the maths. Decide what you think you could achieve in terms of users and earnings. If you thought you would have 2000 users and wanted €1000 income per month that is only €0.50 per user per month. So you could build in a nice donation request, but make it part of the game whether taxes or a 'bet' or something. Then this justs tweaks the odds a little in the donator's favour for one event the next time they play. It shouldn't alter the overall game; it should be possible to win without donating. Of course anyone that wanted to donate more would not be 'nagged' until their donation was used, eg €6 lasts a year, which would seem pretty reasonable to me. Some won't like it. Some will see it as a challenge to win without paying. Others would be more generous. The biggest problem is there is yet more coding required. You could also sell 'head-start' characters for a few euros.

As to bots, try and devise challenges that bots would not succeed at. If a character fails, it gets another similar challenge where failure again would have severe consequences. I'm not very familiar with how bots work, but somebody would need to set up the characters. Could you detect this behaviour from the IP address? Agian, flag as a potential bot and set the challenges.

 

[Svartalf]

Well I'm working in Python, so I'm pretty much resigned to the fact that if someone really wants the code they can get at it. But I'm certainly not going to help them along. No amount of server verifying of what a client is doing can stop people from automating the process of playing an MMO. Hell, just look at what botters are doing in MMO's supposedly protected clientside by Gameguard; even though GG is supposed to block automated input there is no real way of accomplishing that and botting will happen regardless.

If you're using Python, you're pretty much done in. Interpreted code equates to fairly effortless reverse engineering work. Unless you make the client bog simple and the server managing pretty much everything, you're going to end up with all sorts of hackery on the client side and your concerns will become reality.

QUOTE

Sure they're going to rip me off. But I'm not going to make the next big thing. A niche product will probably have very few individuals organized enough to make a proper dent in the whole ripping off thing. In fact, obscurity may mean I never get ripped off, whereas if I go open the threshold lowers enough that it might happen. Probably will happen, considering how easy it'd be to script things in Python.



Any assets will have to be server side to have any chance of protecting them, but even then, since it's Python, they can very much intercept the stuff you're doing with scripting hacks or wrappers around your original code.

The only way you're going to actually make it come more together is with C/C++ or something twisted like Forth.

QUOTE

You can't stave off botters. You can't stave off people who automate client side things. You can't ward off gold-sellers. But I sure as hell can try to postpone it as long as humanly possible, for my own sake and for the sake of the people who will be playing my game. And in that sense, yes, I'll lose anyway if my product is worth ripping off, but what does the community at large playing my game, and I, have to gain by making it easier and more probable?



It'd help you more if you were using a language NOT interpreted but compiled- and Java barely counts in that regard... Since you're using Python, anyone who knows that language will be able to figure out what you did. If you mix and match, you might be able to fend that off, but you indicate you've chosen Twisted (nice choice, by the by... ) so that mostly goes out the window.

QUOTE

There has to be some positive that comes out of opening the source for me, for my players, that trumps making botting a certainty from day one, and while I would like to believe in the goodness of humankind a decade of playing MMOs has taught me that assuming the lowest common denominator is generally the way to go.



You're going to have botting from day one if you're using Python as the main code framework for the network code. You can't help that one if you're using what I think you're using.

QUOTE

And that's not even getting into the fact that code I converted from Nuclex has to be licensed under the IBM Common Public License which actively conflicts with other open source licenses! Man this topic gives me headaches. It's like there is no correct answer, just varying degrees of how screwed I am or will be.



If you're using CPLed stuff, you're fubared already. You can't ship ANYTHING with that piece in there because you're at conflict with the other licenses.

Licensing is a nasty thing. It causes the prices for Linux titles to be the way they are. It causes no end to grief (as you're finding out) unless you do a careful vetting of things BEFORE you roll something out. All the licenses have to be in order for you to use them. Any one of them are off for redistribution and you will be held liable for infringement and other sundry torts for the licenses you breach. There's a reason I go strictly with LGPL, BSD, MIT/X11, select Artistic licenses, and public domain. Anything else and the pain level goes right up through the roof. Unless it's going to be GPL, you can't use GPL licensed libraries. Unless it's going to be CPLed, you can't use CPL licensed anything in it. Unless it's going to be MPL, ditto. It's a bit of a mess.

 

[Eniko]

If you're using CPLed stuff, you're fubared already. You can't ship ANYTHING with that piece in there because you're at conflict with the other licenses.

Going to reply more fully later, just wanted to comment on this one. From my understanding and this FAQ:
QUOTE
# Can I take a Program licensed under the CPL, compile it without modification, and commercially license the result?
Yes. You may compile a Program licensed under the CPL without modification and commercially license the result in accordance with the terms of the CPL.

# Do I need to include the source code for such Program with the object code distribution?
No. But you do need to include a statement that the source code is available from you and information on how to obtain it.

# When I incorporate a portion of a Program licensed under the CPL into my own proprietary product distributed in object code form, can I use a single license for the full product, in other words, covering the portion of the Program plus my own code?
Yes. The object code for the product may be distributed under a single license as long as it references the CPL portion and complies, for that portion, with the terms of the CPL.

So from what I understand I can use the CPLed code without adopting the CPL for the rest of my code, so long as I make the CPLed code available somewhere separately. Of course, it's debatable what "without modification" means. Porting could be seen as modification. Oh well, if that becomes a problem I'll just use a different/less efficient bin packing method.

 

[sindbad]

There are ways to obfuscate python and you can protect just some essential modules by compiling them with cython. For most things, it takes few changes to compile even if you don't use it for optimisations.

But even then, most stuff can be reverse engineered easily enough to get assets and make bots.

Yes, it is a minefield. I also never use GPL libraries. The LGPL was very well named as Library GPL until they changed it.

 

[Xanas]

I will say if you are making the game for pandora for which the linux enthusiast community is very large you'll probably get more people to play it if it's open source. It really depends on whether more people playing it is your main objective, or making a financial return on your investment.

I think you should go ahead and release as you want up front, but consider releasing the code later under GPL.

 

[BenTolputt]

Well, given the number of people advocating GPL licensing of code, allow me to provide an opinion from the other side of the fence.

Quick History of my Experience:
I earn my crust as a developer, and have done so now for over ten years. I have worked in a variety of industries ranging from financial/insurance processing systems through GIS/mapping related applications (online & embedded/mobile) to network distributed audio/video security systems. Honestly, I simply worked on whatever the job paying me required & where my interest took me.

I have worked with proprietary code (obviously) and open source (GPL/copyleft & otherwise) based on the requirements of the project. I have released a couple of minor games in this time and spend time assisting in the development of game engine related open source projects (though less so now as I move toward the release of a more ambitious gaming project).

General GPL Game Project Opinion:
If you intend to make money from a game project, I would highly recommend you don't release the code as GPL. A few reasons include:

• Protecting "art/assets" is much harder than protecting code - simply put, compiled code (even for interpreted languages such as Python) are self-obfuscated. However, even assuming you encrypt the art/assets - open source code gives even the most "script-kiddy" of crackers a road-map to how to get around your protections.
• Protecting the "features/story" elements of the game from premature revelation - if you are like me, part of the coolness of the game is the revelation of new features &/or story in the game. Open sourcing code makes it that much easier for people to spoil this timed revelation by looking at what makes up the game. This may be as simple as the sprites/mesh of a monster in an as yet unrevealed section of the world (for MMO's and RPG's) through to cool puzzles/story elements & features for adventure / action games.
• Art/asset Clones - even assuming that nobody cracks your game, decrypts your assets, and/or reveals parts of your game prematurely (to themselves or others) - you still have the problem of art/asset based forks. There is a pattern amongst GPL users of replacing "non-free" elements of a program with free alternatives. Given enough popularity and effort it does not take long for bored geeks (the usual suspects of which I am a proud member) to split the community you have built up around your game.
• Ease of making the purchase decision - Some people will never pay for your game, but there are a large number of people who would have paid for your game were there not a free alternative (this relates to the above point). Even assuming your art/assets are superior (a generally true assumption) once there is an "all free" alternative - alot of otherwise paying customers will try the "all free" version, likely play for slightly less time and then drop it. I am actually guilty of this whilst being a promoter of proprietary products!

For MMO's there are extra things to consider such as client security which are much harder when open source. Hell GPL3 has anti-DRM clauses that make it difficult to even sign the compiled binary without giving out the key used.

 

[Eniko]

Well, since this thread has attracted quite a bit of attention (thanks TaG ) I would like to get a few things on the record about my project, so that there are no misconceptions here.

License issues

Okay, I did start the thread and the entire license thing is a bit annoying, but I'd just like to go on record that there's - to my knowledge - nothing deal breaking here. Right now, in the client, I am using four licensed codebases:

• Pygame: LGPL
• PyOpenGL: BSD
• Twisted: LGPL
• Cygon bin packing: IBM CPL

I already have a custom implementation of scale2x as a pixel shader, and I can just as easily write a scale3x pixel shader. Since I'm not using any of the actual source, and the algorithm isn't patented, I'm completely in the clear as far as that one goes. So the game will be distributed with the scaler I've been using in a few sample images.

Cygon's bin packing algorithm is great, and it'll probably set me back a few days if it turns out I can't use it because of the CPL. Of course there's always the option of contacting him and simply asking for his permission. If not, I can implement some other algorithm. Even if I use my own - poor - algorithm, that means having a few more image atlasses and slightly decreased performance due to texture switching. But it's nothing game breaking.

I would have liked to implement more scalers, because more choice is better, but the GPL license is really looking like it'll hurt that. If anyone knows of scaling algorithms that are covered under LGPL, BSD, public domain or some other equally permissive license please let me know so I can plan to add it to the distribution. Regardless, even if the client is distributed only with scale2x, there will be other scalers. I will - probably regardless of what happens - make it so that the community can interface their own scaling with the client, probably letting the community gain access to GPLed scalers through community effort.

The biggest thing here is whether or not the PyOpenGL's BSD and the LGPL collide somehow. Considering how widespread the use of PyOpenGL/Pygame is, I highly doubt this is the case. If someone can give me some clarity on this issue though, please do.

Code safety

Yes, I am aware Python bytecode can be easily decompiled. However, like sindbad said, there is Cython. By the time the client is ready for actual distribution I'm pretty sure I can convert entire swaths of it to compile with Cython, making it rather more difficult to be decompiled. I'll probably leave less critical segments of code more open deliberately so others can mess with it in ways that will enhance the game without giving unfair advantage. Something like what WoW's addons do.

So, just wanted to get that out of the way since I was getting the feeling things were looking a lot worse for me than was the case.


Now then, on to business:
QUOTE
Since you're using Python, anyone who knows that language will be able to figure out what you did. If you mix and match, you might be able to fend that off, but you indicate you've chosen Twisted (nice choice, by the by... ) so that mostly goes out the window.
Aside from Cython, mentioned above, I am currently not using Twisted inside the client. Only the server. The client is using Python's built in socket module. I might use Twisted later on inside the client for it's IRC support, which means that even if through using Twisted I somehow reveal internal workings of the client then they'd only have access to the IRC parts of it which does them little good.

So I think I'm okay there. Oh and yeah, Twisted is awesome. I can't recommend it highly enough. I've written all of 40 lines of network architecture related code for my server, and that's counting empty function definitions with pass statements and process forking. I'd hate to think how much work I would've had to do if I had to do it all myself. Plus it runs like a dream, nice and speedy.

QUOTE
Licensing is a nasty thing. It causes the prices for Linux titles to be the way they are. It causes no end to grief (as you're finding out) unless you do a careful vetting of things BEFORE you roll something out. All the licenses have to be in order for you to use them. Any one of them are off for redistribution and you will be held liable for infringement and other sundry torts for the licenses you breach. There's a reason I go strictly with LGPL, BSD, MIT/X11, select Artistic licenses, and public domain. Anything else and the pain level goes right up through the roof.
Yeah, I'm definitely going to only be using things under those licenses from now on. I really don't need the kind of headache GPL and similar licenses give.

QUOTE
But even then, most stuff can be reverse engineered easily enough to get assets and make bots.
It's unlikely that they'll even need to reverse engineer anything. All they need is to do is catch the packets being sent to and fro, figure out the couple things they need, and program a layer outside of the client entirely to feed it the proper input. If they're clever enough they don't even need to know anything about the packets. Like I said earlier, there's really no way of stopping this, just look at any game "protected" by Gameguard, so I'm not going to bother myself over it.

What's important is that I don't make it too easy, that I don't make it too easy to crack vital parts of the client that could be used to give some players unfair advantages, and the rest... well, if the game becomes big enough to merit this kind of stuff, then GMs will have to deal with botters and cheaters. That's just one of the realities of managing an MMO.

Selling gold as a service will probably do a lot to eliminate at least the undesirable side effects of gold-sellers: bot herds camping/hogging spawns, and spam everywhere to sell their gold. Plus since players do buy gold it's obviously a desired service. If anyone is going to be getting paid for that service I'd rather it be the devs and staff than Chinese gold farmers. I'm sure most people will agree with that one.

QUOTE
I will say if you are making the game for pandora for which the linux enthusiast community is very large you'll probably get more people to play it if it's open source. It really depends on whether more people playing it is your main objective, or making a financial return on your investment.
Well, I've got bills to pay. If that offends Linux enthusiasts so much that they'd completely avoid a free to play MMO that they might enjoy, then that's their prerogative. Not much I can do about that, is there? Considering the amount of interest in other closed source games, and even the commercial closed source Bob's Game though I think this won't be so bad.

And if it is... well, good thing I can port to Windows and Mac where people are used to that kind of thing, too!

QUOTE
I think you should go ahead and release as you want up front, but consider releasing the code later under GPL.
If it ever stops paying the bills (assuming it ever starts) and/or I'm just plain done with it I wouldn't mind at all handing it over to the community at large. I've said so earlier, actually. Of course, I'd probably go with the BSD license, after the past few days I've become pretty disillusioned with GPL. To me free, open source software should be more free than that particular license lets it be.

I don't think this whole viral open source thing it has going is good for the open source movement at all by depriving start up independent developers the chance to use it in a commercial venue without giving away any and all code "tainted" by the GPLed code. "Good going keeping the money in the hands of the big boys" comes to mind. Not to mention that these upstart businesses would probably be more than happy to donate changes they made to the GPLed code back to the community, so long as they could hang on to the rest of their product. That won't happen with GPL as is.

BSD is from now on my license of choice.

Also thanks for weighing in BenT, you make several very compelling arguments!

 

[Prometheus]

QUOTE
I will say if you are making the game for pandora for which the linux enthusiast community is very large you'll probably get more people to play it if it's open source. It really depends on whether more people playing it is your main objective, or making a financial return on your investment.

Well, I've got bills to pay. If that offends Linux enthusiasts so much that they'd completely avoid a free to play MMO that they might enjoy, then that's their prerogative. Not much I can do about that, is there? Considering the amount of interest in other closed source games, and even the commercial closed source Bob's Game though I think this won't be so bad.

I'm afraid I don't have anything of real use to add, here (my apologies for that), but I've been following the thread and just wanted to say something, if I may. I'm a bit of a Linux enthusiast myself, but I fully understand that open sourcing things doesn't necessarily *always* work for games (particularly new ones), and the other issues that come up with all of that. The key part for me, is if the game is good - that's what will get me to play, not the status of the source code. I'm sure there are plenty of others like myself, also.

Best of luck to you - looking forward to seeing the finished article.

 

[Svartalf]

I don't think this whole viral open source thing it has going is good for the open source movement at all by depriving start up independent developers the chance to use it in a commercial venue without giving away any and all code "tainted" by the GPLed code. "Good going keeping the money in the hands of the big boys" comes to mind. Not to mention that these upstart businesses would probably be more than happy to donate changes they made to the GPLed code back to the community, so long as they could hang on to the rest of their product. That won't happen with GPL as is.


Depends on what you're trying to accomplish. If you want to insist that the people modifying your engine give back, you can use the LGPL to the desired effect. As long as it's not in your code and it's in theirs, they can do with it as they see fit. If it's in your provided piece, they HAVE to give back. With BSD, they are under absolutely NO obligation whatsoever- in fact they can rip you clean off past attribution if you use it, and under some forms of the BSD license, attribution save where the source is concerned is not required at all.

QUOTE

BSD is from now on my license of choice.



Caution should be used when choosing licenses. Each one has it's own consequences, just as much as your library choices' licenses have on your project. There is an aforementioned in this thread individual that clean didn't get the GPL and was "unhappy" about what was being done with the code so licensed by himself that he's made a great and general ass of himself and he's bitched about it at length and "is going proprietary" at this point, only doing Windows applications, stepping clean out of the Linux space. Had he paid attention to what he was doing, he'd have been happier, we'd have been happier, and he'd not have made himself look the fool. This is not to say that you shouldn't choose the BSD license for your stuff (It IS your code afterall...)- but you should be clear on just precisely you want to happen when you license it. You can "take it back" after a fashion, but once licensed under BSD, you've a copy that's out in the wild that someone can take to the GPL or take private. It doesn't QUITE work the way many people think it does.

 

[sindbad]

I don't think this whole viral open source thing it has going is good for the open source movement at all by depriving start up independent developers the chance to use it in a commercial venue without giving away any and all code "tainted" by the GPLed code. "Good going keeping the money in the hands of the big boys" comes to mind. Not to mention that these upstart businesses would probably be more than happy to donate changes they made to the GPLed code back to the community, so long as they could hang on to the rest of their product. That won't happen with GPL as is.

BSD is from now on my license of choice.

The GPL has been useful in protecting end-user stuff (linux kernel, various applications) and helping build a community around them. However, it is not appropriate at all for libraries.

For stuff you make, it's alright to choose the GPL (or dual-license) as long as all your dependencies aren't.
I'd like to throw in MIT as a less confusing choice to BSD (2-clause and 3-clause, the latter can get a bit annoying, but never a problem).

Good luck sorting this out!

 

[Tinnus]

Not to mention that these upstart businesses would probably be more than happy to donate changes they made to the GPLed code back to the community, so long as they could hang on to the rest of their product. That won't happen with GPL as is.

They call that the LGPL

 

[CyruzDraxs]

I don't see why it'd be a problem to GPL an MMO client...just code smart.

The first rule when coding an MMO client is to never trust the user. All the client app should do is render the graphics, play the sound and collect keypreses to hand off directly to the server. Everything else should be handled on the server, that way there is nothing a bot could work with. The only returning data would be changes in asset states, such as an NPC's coordinates changing or the length of your health bar decreasing.

I made a small 2D MMO before and, with a year of improving the code to try and deter the rampant hackers, I learned that the client app should never be trusted for anything.

I combined all NPCs, objects and even maps into one big asset array with nothing to distinguish one type from another--just an ID that was shared with the server and changed frequently.

I also had one nasty trick that the hackers weren't too fond of; collision detection was handled by the server, so even if you managed to match the correct ID, if you tried to make the character move you would just get stuck in a tree or something.

The hackers pretty much just gave up at that point...it's hard to hack an app that doesn't actually do anything.

 

[Tempel]

Wow, quite the cacophony in here. I think most points have been covered, so some final thoughts, then i'll shut up.

As BenT pointed out, an "asset clone" is a possibility if you open the client (see Iceweasel). But i wouldn't expect that to fork the community; you may get people with different clients, but they all interact with the server in the same way, and any changes to the base client would be reflected in both clients (as happens with Iceweasel). I wouldn't worry too much about this happening unless you're really intent on people seeing your hard-made artwork. Overall, i would say to let them choose freely if they care enough.

Where it comes to licensing, don't be too hard on the GPL. It is designed to be about the most restrictive free license possible, and exists to ensure that the volunteer efforts put in by developers don't get turned into proprietary software. LGPL is nicer because of dynamic linking (and the GPL with Classpath exception is even nicer for allowing both static and dynamic linking), but even those ensure that the codebase is used as-is, thereby preventing proprietary improvements. Finally, BSD is wonderfully free, and a lot of people would like it if you released things under it, but that's also its weakness; Windows contains networking code derived from BSD Unix, and i doubt they ever contributed anything back. In your case, a BSD-licensed client could be copied by people making a competing MMO, improved so as to compete better with yours, and made proprietary so yours is left behind. I guess what i'm saying is, any free license should be chosen wisely; take the time to consider a few popular ones, then decide what's best for you.

I'd also like to point out that you may get a free pass on the server code. It would be great if you opened the server code right off the bat, but that could lead to unofficial servers and therefore lost revenues for you; therefore, i expect you'll keep from distributing that for a good while. But, if you're not distributing it, you may be able to use whatever code from whatever conflicting licenses you like (i think any FSF-approved license allows you to do whatever you want with the code, only placing restrictions on redistributions). Of course, once it gets to that "not profitable/don't care" point, where you would like to release it, all those conflicts could come back to bite you and probably keep you from ever releasing it.

Finally, to reiterate my earlier points, your business plan is the same whether open or closed, and, as others have agreed, all your botting/abuse protections should be server-side anyways. Therefore, i still think that an open client would be swell, but you should, of course, release however you feel comfortable.

 

[Eniko]

Am I missing something here or are some of you confusing botting with cheating/hacking, in other words doing things that shouldn't be possible? Because the latter can (and obviously will) be solved by not letting the clients decide anything on their own and making the server check commands from clients for legitimacy. But I fail to see how you can have the server check against botting unless you implement random captchas for clients to solve; if the game can be played it can be botted.

Back to the debate of open-sourcing or not; for now I have seen little compelling evidence that opening the source will be a generally beneficial thing for those playing my version of the game. Sure, it'd be great for people doing as BenT said and trying to create an asset free fork of my game and driving a wedge into the playing community, but that isn't good for the community at all if you ask me.

And even if I didn't open source the server, with the client code in hand making your own version of the server is trivial. Replicating all the exact same features is non-trivial, but for a fork not required anyway.

It is true that opening the source could lead to enrichment of client features and usability by the playing community itself. However this can just as easily be accomplished by creating an add-on interface a la WoW. In fact, it seems that as far as client enhancements go this would be the preferable way to do it, since it maximizes client enhancements while attempting to minimize people implementing things that the community as a whole considers to be an unfair advantage.

I suppose the best way to get rid of botting is to think outside of the box and create some gameplay equivalent of a captcha. Unfortunately I'm not having any lightbulb moments in that direction.

 

[BenTolputt]

Eniko:
I used to be a member of the MUD-Dev mailing list before it kinda shut down. I have an archive of the lists on my hard-drive somewhere as there is alot of good material in there (we're talking nigh on ALL major MMO developers posting in there). I would not be surprised if there is something in the archives that would be helpful to you (perhaps for your client verification thing). If you do not have the archive (and want it) drop me a PM.

Also, glad I could be of assistance (even if it was only morale support )

Licensing:
The "GPL with ClassPath Exception" sounds good, but is not quite as clear (according to my legal counsel) as the wxWidgets License which is basically LGPL with explicit static linkage allowed. I tend to use this one when I absolutely must have improvements given back to the project (not too often, but it happens).

 

[closetwam]

I suppose the best way to get rid of botting is to think outside of the box and create some gameplay equivalent of a captcha. Unfortunately I'm not having any lightbulb moments in that direction.

I'll share my little light bulb I had a while back. Moderator points, ala Slashdot. Devise a system where any player can be a moderator some of the time. The more you play, the more you moderate. The more you get modded, the less you moderate. If people mod your modding decisions up, you get more mod points. If your moderation choices are modded down, you get fewer mod points. Keep the process as transparent as possible, to avoid abuse. You may have more moderation abilities depending on how reliable you are. Moderation abilities could include slowing a player down, freezing a player, kicking a player, teleporting a player.. whatever. Let every player have their mod record on display (both as a moderator and as a moderatee). Perhaps the record only extends back a few months, so if you keep your nose clean, you're considered clean again. You get the idea. When everyone is a potential moderator and the majority of users are walking around with mod points, botters don't stand a chance.

 

[Tempel]

I suppose the best way to get rid of botting is to think outside of the box and create some gameplay equivalent of a captcha.
That's what i've been saying! In general, the easier it is to create a bot that accomplishes something, the less of a reward it should give. Ideas:

If the strategy of "hit over head; repeat" is enough to take down a monster, then it should give next to no rewards. In other words, if fighting an enemy that is appropriate for the player's level, the player should be forced to plan and strategize rather than following simple patterns. So, rewards from enemies should quickly decrease as a player becomes more powerful, forcing them to fight the enemies that require human-level intelligence if they hope to advance quickly.

Another option is to simply make fighting random enemies unprofitable. As i've said before, how does it improve the game to have a large contingent of players, live or bots, wandering the wilds, slaying wolves? If these enemies drop no gold and only some mildly-useful items (as real wolves do), there is less incentive to spend time killing them. Of course, as in all RPGs, there are times when players need to get experience somehow, so some sort of activities will have to replace this.

An easy option is to make quests profitable in terms of money and experience. These are more interesting than random fighting, and thereby provide more enjoyment to the player. Of course, players could quickly run out of quests if do not yet have enough experience to move on to the higher-level ones. You could implement randomly-generated quests, but these run the risk of becoming predictable, possibly giving another avenue for botters.

You could also reward player-player interaction in several different ways. One might be highly-rewarding enemies that are much more vulnerable to teams than soloists (like a monster with two weak points and the ability to defend only one of them), but this could prove a problem in the early days of the game when there might be few concurrent players capable of joining against such monsters, or it might even lead to team botting. Another might be a karma system, like closetwam's moderator points, whereby players can reward those who have helped them. Since we all know robots hate humans, they would never help.

Those are all the poorly fleshed-out ideas i have at the moment.

Edit: Just pondered CyruzDraxs's comments and realized that it should be a pretty effective anti-botting measure that has no effect on gameplay for humans (no, we are not "confusing botting with cheating/hacking"). He said:

collision detection was handled by the server, so even if you managed to match the correct ID, if you tried to make the character move you would just get stuck in a tree or something.
Essentially, by not passing collision information to the client, instead just giving object locations, you've turned the whole thing into a computer vision problem. A human can quickly tell when a character is stuck and compensate for it, but a bot would have to analyze the screen output; pretty much no one can make decent computer vision applications, let alone spare-time bot makers. It might be easier for the bot, since the textures are all predefined, but it seemed to work well enough for CyruzDraxs.

 

[BenTolputt]

OK, in reply to Tempel above, I submit the following...

The reason most MMO's (and I assume this one will be the same) have players kill random monsters wandering the wilderness (a.k.a. "'grinding") and not making quests the primary means of advancing is two-fold.

Firstly, and never underestimate this, making wandering monsters and the like is ALOT easier than making quests (even "fed-ex quests" where you simply deliver an item, message, whatever from one NPC to another). The monsters have to be created anyway (for the MMO's we're talking about) and hence it is much easier to stick a few "Goblinoid" spawn points in the "Goblin Plains" zone than it is to think of decent reason to have a player deliver something from one NPC to another, write the "flavour text", and link the NPC's to the quest. Never ever underestimate the power of laziness (& let's face, economy of time) in the reasoning of game developers & their management.

Secondly, and this is related to the above, "grinding" random monsters (or 'mobs' as they used to be called in my text MUD days) for experience combined with limiting quests to character levels spreads the content out over longer periods of time. This is much more important for MMO's requiring money but is also a factor in free MUD's/MMO's as well. If I have, say, ten well designed quests that you can complete anytime you like - you are likely to do them as soon as you can... and then run out of fun content. If, however, I space these quests to "one per level" - you need to spend enough time between each quest to gain a level. Most likely spending more time playing the game than you otherwise would (and likely paying me more money as the game publisher/host than you would have). There is a tonne of papers as to why people allow this to occur and keep playing (relating to reward cycles, gambling, and addiction - Google is your friend here), but the key point is longer player retention and hence longer lasting revenue streams.

 

[Tempel]

BenT -- compelling arguments. Getting a lot of content and playtime with little development work would be a wonderful thing, particularly for this three-person team. Though with this kind of community, and your MUD-dev archive, hopefully we can collect some ideas to reduce the boring, bottable grind, while still maintaining content and that "reward cycle" addiction feeling (though these ideas probably deserve their own thread). Am i being too much of an idealist here?