Reply to comment

 

MightyCow - you'll have to excuse my following exhuberance because I'm a big fan of open source... But the drawback you site for open sourcing doesn't really fly with me. Sure, I could take the latest source of Apache, rename it Sexpache, and make it a huge porn related snuff source. People are still gonna know what Apache is, and where to get Apache from. I won't waste more bandwidth on that discussion - it's been beat to death by many other people, and I'm in agreeance with them...

I'm a sad fan of XML too, even due to it's increasing complexity (didn't Dvorak call it the geek's revenge to the crappy page filled hell the internet is now?). My initial designs for the XML sheets for the game I'm working on are totally attributeless. No [character name="bob" /], but rather [character][name]bob[/name][/character]. It may diminish the "greatness" of XML, but it virtually certifies that existing parsers and code for many different languages will be able to read and write the XML quite simply (primarily, I use XML::Simple to suck in the above within perl).

As for "getting anything" from my work (concerning your server argument), it's something you have to deal with. You run into the same sort of thing as Napster - there are certain Napster servers that the Napster client recognizes. Then there's OpenNap, and people who realize Napigator exists can reach into them. Napster hasn't gotten any less popular, and hasn't diminished any less.

Which doesn't mean I haven't *thought* about those aspects of releasing the server code - that's detailed in the bible I've been writing concerning browserbased games. It's just a matter of telling people that these are trusted servers, and those over there aren't. People can make their own decisions rather nicely, and I'd rather have flexibility than "no! that's not what I intended!"...

Central player database - lots of questions. How big a database? Not a flipping clue. I haven't gotten to that point in the design. As for complexity and permutations - that's not our responsibility. If the game is open source, and the character XML is open source, and we release the server code, a couple of things happen: 1) if someone changes the character XML for their own use, then they'd code their own wrapper to convert between the standard XML and their XML. Again, it's a matter of flexibility and "opting in" to the feature they or they're players want. 2) various XML guidelines suggest pointing the doctype to domain.com/version#/doctype.dtd. If the db XML does change, then backwards compatibility wouldn't be an issue - old servers would still reference the doctype that is applicable to them. Players determine how a game evolves - there's a good chance that if the players know that there is a new version of the game out (that uses a better doctype version) they'll beat the admin into submission for upgrading.

Is it worth the time and effort? That depends on the coder ;) ... I still create webpages for the 1% of the population that uses 640x480 resolutions. If even 10 people think a central db is a good idea, then it should be considered. If 5% is 10, then the load ain't gonna be jooky. If 5% is 1000 people, then that's a pretty sizable audience of gamers (do you have 1000 friends?). It'd be bad to upset them.

So, MightyCow, you code in perl at all? Whistle, whistle [g]... Your concerns of "things to think about" are well founded, and taken to heart - that's where this stupid open source bible is coming in...

Reply

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.