Battle Bazaar Blog

Battle Bazaar.net Developer / Designer Blog

Site changes coming soon

clock December 6, 2011 16:30 by author DaveB

I wanted to talk about exactly what you can expect to see coming in the next few days.

First, users who currently have accounts (our staff members) will be receiving instructions out-of-band on how to connect up. Basic access will be available after OpenID authentication -- including making posts, working on tickets, etc. -- however administrative functions will require a second, hardware authentication mechanism. A number of mechanisms will be supported out of the gate, but I bought keys for us all. :) The keys will only be necessary in order to perform administrative functions, such as banning accounts, deleting posts or sending modules to the servers. You will, however, be able to opt-in to using the key for everything.

This will be in the form of an invitation, in order to test the invitations functionality, although I'm going to ask that people not invite tons of people just yet. :)

The first big change is going to be in URL's. Existing URLs will continue to work, and will redirect to the new pages -- however, the application is going to function more like GMail or Hotmail, where the application is basically a single HTML page and some scripts. When it needs to update itself, it's going to update the HTML -- versus reloading from the server. As a result, it will be highly interactive. The blogs and wiki will be modules.

There will be a tagging facility, which will be site-wide. Anything you can see, you can tag. You'll be able to create an RSS, ATOM or ActivityStream feed based off of any tag or tags, in order to watch all site activity related to those tags. Similarly, there will be a global, threaded comment facility that includes a "vote up" feature. Many items on the site will have a rating from 1 to 5 stars, as well. The blog will be expanded to support Youtube/Netflix style video streams from Amazon S3, Microsoft Azure and Cloud1. There will be an interactive messaging system -- which will also be accessible via XMPP, a standard instant messaging protocol. There will be API access to many parts of the system.

I've worked up a module that lets me create access control lists on properties in Mongo, so that I can produce filtered objects based on an OpenSocial ID -- a group or user. By default, properties are excluded, and are Owner/Staff view only. That means the owner of the item, and our on-duty staff can see them, but nobody else can. On a privacy screen, you can explicitly grant access to particular properties to groups -- including the "All Users" group and the "Entire Internet" group. The only fields required to be visible (that cannot be hidden) are the random object ID assigned to your record, and the display name.

We don't currently support most of OpenSocial, and probably never will. While I'm basing what I'm doing off of OpenSocial to a point, the way we are functioning is enough different that I don't want to try to implement their standard. For example, user records are always owner and staff only, and so having an OpenSocial endpoint for the user object would be rather futile. We have characters, which are kind of like OpenID people -- but it's not at all clear to me that it would be appropriate for a character to interact with other OpenSocial sites. More importantly and fundamentally, I am using jQuery templates instead of OpenSocial's Java-derived templates, and so I can't support OpenSocial modules in our container. However, I'm providing activity stream support -- among others -- in a fairly compatible way, because it is clear that being able to subscribe to a given character's activity stream might be useful.

Incidentally, the design is also such that all official NPCs in our current project and all future projects will get their own page, with a wall, info, etc. In some cases, game staff may respond on their behalf even. You never know.

There will be more coming in the next few days. Some of the concepts are based on what Microsoft is doing with Windows 8, and it should be the case that our site works quite nicely on Windows 8 devices. Our game will still work on older versions of Windows (as will the site), and I will be testing the game on Ubuntu and BSD as well. I am leaning strongly towards dropping Windows XP based on current timelines and when I expeect to get the thing out the door, but we'll see how it happens.

The important thing is this:

Part of the new site -- fundamentally -- is to let us start setting up game content in a format that the engine can already understand, with a convenient editing facility. The NPCs will have pages because that enables us to edit them, to make certain information public, and to have them interact with players inside and outside the game. One of the things that I want to push for, fundamentally different from other MMOs up there, is the concept that player actions influence the world.

To put it in Dungeons and Dragons sorts of terms...

The Orc Army may be attacking Greyhawk. If the players step up to the challenge, and fight the horde back -- it shouldn't show up again in ten minutes. While I really do like Rift's zone events, and do want to do some of the things they're doing (Ultima did them too) in terms of ongoing semi-dynamic content, the big thing that I want to do is make sure the game itself isn't static. That doesn't mean that there can be no static quests -- it doesn't mean that at all. It doesn't mean there can be no static instances or overworld areas. What it means is that in general, I would like the story to move along, and for there to be new things for newly created characters to do, over time.

Particularly, I want to focus on the feel of a character "fitting in" to the world, and contributing. One of the biggest issues that I have with some of the new games that are coming out is that the developers are giving lip-service to story, but then still piling newbies into an overland zone, where all 8000 of them get to be the first person in a thousand years to forge some weapon. We can have an overland zone with 8000 newbies, too -- that part isn't the problem. The problem is that the zones aren't designed, the stories aren't designed, for the reality of the fact that there are many, many players swarming around the zone.

If there are 20 players standing around newbie land, it is perfectly acceptable to have an army charge them at the gate -- to have them have to work through. I would argue, in fact, that's the ideal scenario if you're wanting to foster membership in player associations, if you're wanting to encourage roleplaying. It's just like having the skill chains be unlocked via trials, versus being unlocked via just levelling and paying some trainer. It is a much more personalized experience, it is a much more entertaining experience.

For example, what I'd like to do with some of the quests is similar to what some of the old hero background systems did (Mekton, CyberPunk had mini-versions of what I'm talking about, Heroes of Tomorrow was a book just about as thick that only did backgrounds), where there are interchangeable quest modules that get shuffled in at various points, to help keep the scenarios fresh, to help keep them enjoyable, to boost replay. The company that did Heroes of Tomorrow had these game decks (forget the name) that had plot elements, and you dealt cards out to the players at the start, and they played them to contribute to the plot in various ways -- it was kind of a "help you along on writing an adventure" sort of a thing. I want to be more like that, because players are going to spend dozens of hours a week (per player) playing the game, and are going to go through various parts of the content more than once.

While I've said I'm against rewarding players randomly -- against the great loot lottery -- on multiple occasions, and that I don't like randomness in combat (my opinion is that combat should be predictable, you should never lose just due to the random number generating deciding to have a run of low rolls), I'm very much for this idea of randomness in repetetive elements of the game. Having your fireball sometimes hit for 100 points and sometimes hit for 700 points isn't particularly fun, particularly if it is just random. Going into a dungeon, and not knowing what critters are going to spawn, etc. -- that part can be random, and if its done right, will greatly increase enjoyment of the game overall.

Which is my primary goal -- to create an enjoyable game, a fun game. There is no competition -- I don't aspire to be as huge as World of Warcraft or Rift, I don't believe we'll take on those major games and win. But I believe if we're a fun game, if people want to play it, that we don't have to compete with those bigger games to do it. All we need to do is to be the best game that we can be, to do things in the best way that we can, and most importantly to understand the users of MMO's and other games and to focus on being what they want, how they want.

I think once you have that -- the players, they'll come.



What if there were a way to dramatically cut phishing?

clock October 10, 2011 09:25 by author DaveB

I was looking at two fake e-mails today -- one from someone proporting to be Trion (Rift) who spelled World with two V's, and another pretending to be Blizzard. While the e-mail was caught, I saw a heuristic that is so simple -- that I can't believe it's not already implemented.

So there's this link, right? And it's an anchor element in the HTML version of the message. Now here's the check:

Does whatever is inside the anchor look like a URL?

See what they're doing is putting the real URL as the text in the anchor (http://battlebazaar.net), but then putting a different URL (http://battlebazaar.net.x=some-other-site.someother-tld.fake/string-o-garbage) in the HREF of the URL. This makes it so the URL that it shows in the e-mail is the real one, and when you click, that's what's displayed in the leftmost. Now, I've previously stated the web browsers should provide a separate box for the host, domain and path -- because doing so would greatly help with the phishing problem (because most people don't understand how the hostname or path work -- those are just magic values -- and so split them off so that the part they *do* generally understand is visible).

But what I'm going to say is this. There should never be a time, ever, where there's a URL pattern as text in a link and clicking that URL takes you anywhere other than what the text says. And so any message that ever has that pattern (an anchor element where the text is a URL pattern, http://whatever, www.whatever, etc.) and where the href doesn't match, should be deleted automatically. That simple step would go a long way (and splitting the address bar into three pieces -- host, domain and path as three separate bars -- would help even more).



Pet Peive: Sending Order e-Mails from a no-reply box

clock August 31, 2011 13:45 by author DaveB

If you're going to do electronic delivery of products, always use a valid reply address -- or verify the e-mail address before you ship.  Send a "click here to activate" link, send an account key, generate and send a one time password, w/e.

But if you're going to just blindly send, you might be sending to the wrong person.  If you send to the wrong person, they might not even speak the language that you speak.  Going to your website and struggling through a 20 part reply form written by your marketing department isn't a good experience, and you almost certainly want to know that you've delivered a password and a bunch of CD keys to the wrong person so that when your customer calls and says "WTF," you have an answer for them.

I filter tons of spam every day, but I still am going to maintain the support, parental guidance, etc. mailboxes at easily identifiable and easily contactable addresses.  I mean, it's just the right thing to do -- what spam gets by SpamAssassin and the other filters, we can deal with that.  So what there's an e-mail for viagra sitting in there.  If we keep just one, single, solitary customer because they can e-mail us, that's worth it. 



Spam and Linux

clock September 29, 2010 11:43 by author DaveB

Just because people say Windows is the source of all spam:

Author information

Name: distrocar
E-mail: ...
Website: ...
Country code: US
IP address: 110.136.161.73
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10 GTB7.1
... OK so maybe user agent isn't reliable.  Maybe they bounced through some windows host to deliver the spam, I can't prove it really was a Linux box...  But I can say that user agent claims to be FireFox running on unbuntu, and posted spam.
Note: I flipped our DKIM signatures to production; mail to Yahoo, Google and others that support DKIM should now indicate (somewhere) that the DKIM matched.  On Google, it appears underneath the normal headers.


New Website - Just to pass it along

clock July 23, 2010 15:38 by author DaveB

I am making progress with the new website that handles registrations, player associations, etc.  Currently, I am accepting logins via OpenID from any provider that supports SSL/TLS on the channel between our web server and it (e.g. Yahoo, AOL, Google, MyOpenID, most others), as well as via Windows Cardspace.  A single account can have as many OpenID and CardSpace cards associated with it as the user wants, and the CardSpace stuff should magically disappear for users that don't support it.

Groups, including groups with start/end times (e.g. subscriptions) are fully functional, and I have activation codes approximately 10% done.  I hope to get those done this weekend, but may/may not get to it and it may have to wait until next week.

When I get it done, we'll need to re-establish the accounts.  I'm going to do that by e-mailing activation codes, and letting people who should have access enter the code and activate.

Note: there is also support for OAuth, and that is how I will be providing third party websites with access.  OAuth works similarly to Facebook applications, when an app wants to use information from us, it asks.  You go to your profile here, and you approve it.  Until it's approved here, the app gets nothing.  From a control panel here, on the account management screen, you can control the access -- including revoking it.  OAuth is an open standard, and there are multiple available implementations, and so it should work well for this application.

Note: I also have an XMPP server close as well.

Forgot your password?  Since we don't have passwords, that can be an issue -- so keep the account key around.  The account key and information on the account can be used to re-establish with a new OpenID or CardSpace provider, in order to reconnect to the account. 



Move of Blog to Windows Azure

clock May 21, 2010 11:39 by author DaveB

As part of testing with Windows Azure, I will be moving the blog from Blog Engine to Azure sometime this week most likely.  I will be bringing the account management services up around the same time.



Comment Filter

clock January 6, 2010 04:59 by author DaveB

Due to continued spamming after I enabled comment moderation, I've installed a plug in to check against a shared database.  We'll see if that cuts it down a bit.



TextBox

Tag cloud

Calendar

<<  February 2012  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
2728291234
567891011

View posts in large calendar

Sign in