Introducing DragonBones

[CavemanJoe]

Eric, you raise some good points.  I'm very happy that you're considering this, but you're right in that the community has to be involved.  Let's open this up for discussion in another thread.

[MightyE]

This post from over two years ago seems relevant to the discussion:
http://dragonprime.net/index.php?topic=8785.msg79197#msg79197

I seriously doubt that anyone would take issue with a successful site, probably even a pay-for-play site, as long as they believed you were contributing meaningfully back to the community (and "meaningful" takes a certain context from how successful we're talking about - make hundreds of thousands of dollars, and people will expect to see a substantial amount of contribution back; make $50, and that won't carry the same expectation).  Good faith and good stewardship alone should be sufficient protection, and for my part, I can say that if I'm satisfied that those are being upheld, I wouldn't challenge it.

I wish there was a way to codify this good faith assertion as part of a legal license and not have it cause more problems than it would solve.  As I said, I wish people success with LOGD, and if people are able to turn a profit, that actually gives me warm fuzzies, assuming that they're not doing it in a predatory Zynga-like fashion.

Zynga is a perfect example of the primary fears which caused me to select the license I did (with a lot of help from JT).  They're the poster child of kind of abuse which it was my intent to prohibit, and it's that sort of behavior which still makes me leery of a BSD license.

[caliban]

Hopefully you don't mind forum ghosts like myself contributing to the discussion.  I have ran a LotG server for some friends a few years ago and recently come back to see what updates have happened and saw this thread.

I was involved in a few CMS systems that were gpl to cc licenses and thought I would throw my 1 cent in because I have seen this same discussion in other situations/industries.  In the CMS market, quality projects were in the same concern but their decisions had little affect on the industry as a whole.  Quality systems were not being ripped off as much as out developed.  Companies that started providing licensed development and closed off their code spent the money to exceed the abilities of some of the open source projects I backed.  Adobe ended up purchasing a few of those and brought them under one roof as a SaS product which increased their production budget by leagues.

One thing I noticed:

Companies that will out spend you by hundreds of thousands in marketing(I believe someone in this thread said millions, but realistically they could spend a lot less with favorable results)  could easily spend a fraction of that to replicate a game in their own style.  You gain nothing by protecting it, if you are worried about big business competition.

Maybe the game industry is different but I am sure some of the same principles are non exclusive to most markets.

Again, this is for what its worth, I know you don't know me so take it at face value

Good luck in whatever decision you make, I hope the project does well.

Caliban
 

[Boris735]

With regards to the variable output system, and vokainer's comments over in the Core Items System thread,
it seems to me that there is one significant point of departure between variable output and the current translation system.  Namely, the former appears to require output in order for translation to be done.

This would seem (at least to me) to make it harder to piece together sentences from separate parts, each needing translation.  To take a hypothetical example since a real one might get boiled down in irrelevancies:

  $drinks = array("beer", "wine", "ale", "pig swill");
  $drink = $drinks[array_rand($drinks)];
  output("You spend %s credibucks for a glass of %s.", 10, $drink);

Under the translation system we would call translate_inline() on the drink.  It is not clear to me what the variable output equivalent would be.  (I can think of a few possibilities, but also drawbacks to them, so I don't want to start speculating unhelpfully.)


Additionally, I'm belatedly concerned that this also means that every variable-output hooking module fires on every output call.  This superficially feels like a lot of work, especially when a site is fully translated using this approach.

I assume that you (CavemanJoe) must have devoted much thought to these issues already; I would love to hear more about how you intend to deal with them, or whether I am making mountains out of molehills.

[ssheeley]

Is Dragonscales and then Dragonbones going to be released?  I've started working on a game and have found that I too want to do most of the things that you've mentioned about already doing.... Why reinvent the wheel I sae!   

[CavemanJoe]

I'm not sure whether I ever gave links out for this, but:

DragonBones / DragonScales GitHub:
http://github.com/CavemanJoe/Improbable-Island---DragonScales---DragonBones---LotGD-2.0---Season-Three

Improbable Labs:
http://labs.improbableisland.com

Latest cool stuff:
* Partially-cached and separated Accounts table.  Parts of the Accounts table that update on every hit (like allowednavs) are stored in a separate table, and everything that isn't stored in the new table is cached.  Previously, hits to the Accounts table took an unusually long time in the "statistics" state, even on a server caching its entire database to RAM.  The result of the new system is a site taking on average a quarter of a second to serve each page with 185 players online.
* De-restricted $output for modules, and a new "prerender" hook - change any item of text, template element, image etc. in the entire page, through a module.  This is like a primitive form of my Variable Output system.

[Nightborn]

Did you (without looking at the code) separate the nasty text fields out of the accounts table, and mayhap even normalized it?

I recall moving the last page (that is always stored in the account table) moving into a separate table to handle that kind of nasty stuff.

That takes indeed a great load off the back.

After that, I compensated with better hardware ]:->

[nebosja]

Are you still working on this, CavemanJoe? If so, and you'd like some help, let me know.

EDIT: This previous sort of outlines what I'm interested in doing: http://dragonprime.net/index.php?topic=11884.msg98977#msg98977

Basically I think it would be less effort to clean up this code base in a usable form than to write a new game from scratch. The basic plan of attack I had was to first go through and make each script a function that doesn't use any global variables. Then I can separate each function into a part that handles logic, and a part that purely takes care of output/display. With this done, you can such away the hard coded constants/strings from the logic part into a configuration file that basically "customizes" the game.

The end result of this would be something close to your vision of DragonBones, I think.

[Nightborn]

He is already doing that, from what I recall: writing most things from scratch

[minilife01]

I can't see any updates of this project

[CavemanJoe]

Right now it's all kind of Island-specific, and of limited use to anyone.  Honestly given the licensing issues I'm probably gonna write a completely new engine and to hell with the backwards-compatibility.

Right now I've got a version of LotGD that runs several orders of magnitude faster than the old version, with a built-in Item system, improved chat, problem reporting system to replace Petitions, and a few annoyances fixed - but there's no installer and it's not user-friendly in any way, shape or form.  At some point soon I'll give it a decent installer, make it usable, and release it under the CCL.

[nebosja]

CavemanJoe: Thanks for the update. Do any of these things I've described in the other thread for improving the code base (for either game) sound interesting at all?

[CavemanJoe]

Potentially - but DragonBones isn't going to be LotGD, or anything really like it.  We're gonna have characters and accounts as different entities, and we may be ditching the game-day mechanic.  It's too soon to tell at this point, since right now I'm still bimbling along on my heavily-modified 1.1.1 codebase, with a plan to start working on Season Three / DragonBones / Improbable Game Engine sometime in the middle of 2012.

(although realistically, it's probably gonna end up more like 2013...)