How did we get here?

June 16, 2014 at 6:17 PMPhonicUK


How we got here

When it first started looking like server administrators were no longer going to be able to charge players for in-game items or bonuses, the first question that was often was being asked was “How am I going to support my server that costs $xxx/month to run?”

Initially my reaction was fairly unsympathetic - that if you couldn’t afford to run your server without donations/selling items, you couldn’t afford to run the server at all – and that while this revenue was nice, it shouldn’t be something the server relies upon to survive and that those that did depend on it were simply too big to operate and should downsize.

But then I started thinking about what caused this situation in the first place. Why do we have such huge servers and networks capable of sustaining hundreds of simultaneous users all at the same time?

At first it seems very counterproductive. You may be able to fit 200 players on a server, but should you? Adding more players to a server is going to cause diminishing returns. A 200 player server isn’t going to be significantly more fun than a 100 player server, and that’s not going to be much more fun than a 50 player server – simply because there is a limit on how many people you can interact with at the same time. Granted a 20 player server is almost certainly more fun than a 10 player server, but there is definitely a point at which adding more players stops adding any value.

Almost every game I play that has dedicated servers, I find myself a regular on maybe 3 or 4 different servers since a lot of games max out at between 16-32 players, if one server is full you simply join another.

‘Why doesn’t this apply to Minecraft?’ I thought to myself. But there’s a huge difference between Minecraft any many other games. One Team Fortress 2 server is much like any other. The map rotation might be slightly different and there may be some extras, but there isn’t a right lot tying you to any given server (other than its community) – you can just as easily drop yourself into another server and enjoy yourself just as much.

The difference lies in the creative and deeply personal nature of Minecraft. A given server has your stuff there. The things you’ve made, the caves you’ve explored, and the home you built for yourself and your friends by investing time and effort. And that’s before getting to meta-games within Minecraft where players complete quests and acquire resources.

This ties players to a given server much more strongly than almost any other game. There is something to be lost by going to a different server.

What this causes is a pressure on server administrators to allow more players at the same time, because players become frustrated if a smaller server is full all the time thus denying them their existing work and wasting their invested time and effort.

This is the point that I think has been overlooked. The demands of the player base (due to the nature of the game) are in conflict with the realities of running a server. So the only solution was to fund server growth.

Moving Forward

When dealing with a younger audience, micro transactions are a very attractive way of raising funds from both the customer and the vendor’s perspective. For the customer, it means something very quick with instant gratification, and no long term commitment. For the vendor, it means they can get revenue from a very large number of users, some of whom may be simply passing through never to visit again – keeping the payments very small for instant rewards allows this to happen.

What server owners have been told however is that they can only charge for either cosmetic items that don’t affect gameplay or for access to the server.

The unfortunate impact of this is that excludes any kind of ‘casual’ revenue generation as both of these require building a relationship with a particular server.

At a glance this seems ideal, due to the issue I mentioned earlier of the way that player’s attachment to their ‘property’ on any given server. And I’d largely agree that this is the way to go.

My concern is that players won’t contribute financially to servers that require payment in order to play so long as there are other servers available that don’t. Those servers will be smaller on average, but the question that this will answer is how much financial value do players place in their creations? Will they pay in order to stay where they are, or will they abandon their efforts and move elsewhere?

Closing Thoughts

Ultimately, I do think the solution is for there to be a larger number of smaller servers and that the days of 100+ player servers are very much numbered.

The technical problem that needs to be solved is how to keep players in contact with their in game properties.

One solution I think could work well is effectively a rolling whitelist with a queue. A server where anyone can join the queue to be on its whitelist, and players lose their whitelist slot if they don’t play on the server for more than a given amount of time (say 14 days) – this allows people to stay attached to their content without costing the server from inactive players being on the whitelist and denying new revenue opportunities from new users.

Ultimately though the community is going to have to re-think how servers are being paid for, how big they are, and what kind of communities they’re going to build. The two polar opposites are small servers with a very tight, very regular community of users – and very large servers with a casual user base that drop in and out with great frequency.

In this new environment, the latter is almost certainly unsustainable. But what remains to be seen is how far along that spectrum you can go and still have a viable server.

Posted in:


McMyAdmin licence migration plan.

March 10, 2014 at 3:44 PMPhonicUK

After many months, the new CubeCoders software licencing system is built and running. The new system offers a number of benefits:

  • No more dependencies on email addresses for the licence. You'll be able to switch email address much more easily in the future.
  • The server ID no longer needs to be requeried each time McMyAdmin starts up.
  • Proper invoicing facilities, with nice printable PDF invoices for your records.
  • Better key tracking and management. You'll be able to see how many remaining usages you have on each licence you own.
  • Greater licencing flexibility. It means we'll be able to have a wider variety of licence types to suit different users better.
The next stage is getting everything moved over to using it. With nearly 200K users, this is a difficult task.
So the migration is going to be done in stages, the current plan looks like this:
1) Dual Licencing
The first step is to release a version of McMyAdmin capable of handling both the new licences and the old ones, and that can continue operating just using a 'legacy' licence. During this step the old style licences will continue to be issued.
2) New purchases moved to new system.
Next is to have all new issued licences switch to being issued by the new system. This will be done a couple of weeks after the dual-licencing release to allow for the gap between downloading McMyAdmin and purchasing a licence. Old style licences will continue to be valid.
3) Automated migration of legacy licences to 'modern' licences.
After that the legacy licences will be automatically converted to the new style. This will trigger emails being sent out to everyone affected over a period of time with the new details in. McMyAdmin instances with valid licences will automatically collect their 'new' licence from the licence server without requiring any user interaction. During this stage the legacy licences will still be valid in the event that McMyAdmin cannot contact the licence servers due to the increased load.
4) Termination of legacy licences.
Once all licences have been moved over to the new system, another version of McMyAdmin will be released without the legacy licence system and will only run or activate with a 'modern' licence.
5) Mandatory update to 'modern' licence version.
About six weeks after the modern-licence only version of McMyAdmin is released, a mandatory update notice will be sent out to older versions. In addition, the legacy licence server will report a licence failure to all remaining legacy instances.
Other notes:
  • Anyone who has a free or complimentary licence will need to contact CubeCoders to request a new licence to be generated. These licences will not migrate automatically.
  • Enterprise hosts will be required to fill in a short form to migrate their licence. This is only done once for the whole licence (not per-instance) to collect information such as business type and VAT registration numbers (if applicable)
  • Linux users may have to install a new binary to update when the time comes, but all settings will remain.

Posted in: McMyAdmin


WinRT standard text styles previews.

August 19, 2013 at 11:22 PMPhonicUK

Perhaps the biggest irritation of developing for RT (or doing anything with XAML in general) is dealing with styles. There's no way to see a list of all the default ones, or the ones you've made yourself that are available in the current scope. You have to remember them, resulting in lots of tedious back and forth.

Here's the standard RT ones just dumped. They all have a margin of 8 added to space them out.

Posted in:


Email issues and missing keys.

May 28, 2013 at 2:56 PMPhonicUK

We've been having an issue with our mail server, and some licence keys have been lost as a result.

If you've recently purchased McMyAdmin, and do not receive your key by 12:00 GMT 29/05/2013 (Wednesday) - please do the following:

- Visit

- Enter your paypal email address and select "Find Licence"

If after doing that you *still* don't have your licence within an hour of doing that, use the contact form at with a subject of "NOKEY" and we'll send it to you by hand.

Note that the key recovery page linked above isn't usable until the day after your purchase (the transactions are processed in the early morning)

Apologies for any inconvenienced caused. We hope to have the issues resolved before the close of play today.

Posted in: McMyAdmin


McMyAdmin Personal restrictions to be relaxed.

May 21, 2013 at 12:25 PMPhonicUK

Starting in June, I'm planning on relaxing some of the restrictions on the Personal edition of McMyAdmin.

Changes include:

  • Increasing the player limit from 8 to 10.
  • Increasing the panel user limit from 1 to 3.
  • Removing the limit on the number of worlds for multiworld configurations.
  • Only showing the "This server is running McMyAdmin Personal Edition" notice upon user login instead of every 30 minutes.
The following new restrictions will apply:
  • The Remote Assistance feature will be restricted to McMyAdmin Pro and Enterprise.
McMyAdmin is going to start shifting in the direction of including additional value-added features to Pro users such as integration with 3rd party services, and encouraging a higher level of uptake of Personal edition.
Please note that the exact changes are still subject to change without notice.

Posted in:


McMyAdmin to undergo external penetration testing.

May 17, 2013 at 10:38 AMPhonicUK

At some point during this month, McMyAdmin is going to be subjected to external penetration testing by a specialist security firm here in the UK.

It will be tested for issues including potential authentication bypasses, XSS attacks, session spoofing/hijacking and other issues that could compromise security for hosts or end users.

Once complete, McMyAdmin will be the only Minecraft control panel to have undergone professional security testing for the benefit of its users.

While there are currently no known vulnerabilities in McMyAdmin, the purpose of this exercise it to make absolutely sure. Security is no accident.

Posted in: McMyAdmin | Security

Tags: , ,

Proposed McMyAdmin Extension development guidelines.

April 30, 2013 at 11:51 AMPhonicUK

McMyAdmin is moving more towards the point that part of its strength will be in the extra features provided by 3rd party extensions provided by other users. This of course naturally points things in the direction of a 'extension marketplace' where people can distribute extensions.

Whether or not they could be charged for is an interesting question, since they are simply HTML and Javascript and thus very easy to reverse engineer. However MCMA is able to provide signing and verification to prevent people using extensions they aren't allowed to (to some degree) - however in the immediate term, its likely that the initial release of such a market would have all the extensions being free.

So that in mind, there would be some sense in having a set of guidelines for what Extensions should or should not do in order to provide a good user experience.

Below is a first draft of the restrictions. Comments are invited by users and developers.

Extensions must (mandatory)

  • work on Internet Explorer 9 (or newer), Google Chrome and Mozilla Firefox as a minimum with equal functionality on all 3 browsers (exceptions may be made for bleeding-edge technologies such as WebGL)
  • warn the user before deleting or modifying any user data (such as permissions)
  • store user configuration using the extension configuration APIs and not via any other means.
  • not modify the McMyAdmin control panel outside of their own designated tab.
  • not permanently store any sensitive data (such as usernames, passwords, ip addresses, etc)
  • not use javascript or HTML included from external sources (all used code and markup assets must ship with the extension itself)
  • not manipulate any of McMyAdmins existing functionality.
  • not use obfuscated source code. All extension source should be human readable.
  • not attempt to replace the version of jQuery loaded by McMyAdmin

Extensions should (strongly advised, but not entirely mandatory)

  • conform to McMyAdmins overall look and feel (using the same CSS classes) where possible.
  • avoid using 3rd party services outside of the developers control.
  • not modify McMyAdmins own settings without notifying the user that it is about to do so first.
If you have any comments about the existing proposed rules or would like to suggest some of your own, you may post them below.

Posted in: McMyAdmin

Tags: , ,

Everyone should be just a little bit ruder.

April 28, 2013 at 10:54 PMPhonicUK

I've always thought the world would be a better place if everyone was a bit ruder to each other.

Just to clarify on that, I don't mean discourteous or impolite - what I mean is not sugar coating criticism to avoid making the other person feel bad, and that people should not be afraid to tell someone when they've done something stupid or to make fun of an individual for being incredibly dense.

At the moment when someone has been stupid, it's hard to call them out for it without looking like an ass. When an answer to a question is just a quick search away, then it seems entirely reasonable that people should be chastised for not using the tools available to them. However if you point someone to a LMGTFY (Let Me Google That For You) link - the smugness that comes with it would largely prevent the recipient from being open to the (passive) criticism.

If it were the case that criticism of this kind were much more widespread, it seems plausible that people would stop taking it personally - and we could all go around telling everyone else that they are idiots.

Because we are all idiots, every single one of us on this Earth is an idiot one way or another at some point.

But I do worry that some people seem to drift through life unaware of this detail, and need reminding of it.

Posted in: Ramblings


McMyAdmin to be owned by CubeCoders Limited

February 26, 2013 at 11:59 AMPhonicUK

This is a move long overdue, but finally it's happening.

Last week I started the process of moving my business operations to run as a fully fledged limited company here in the UK.

The final switch over will happen on the 1st of April this year. Meaning that at that point, all McMyAdmin related licences and contracts will move to being with myself to being with CubeCoders Limited.

Among other changes that are going to go along with this, all existing McMyAdmin Pro and Enterprise licences are being reissued either on or shortly after April 1st.

This will also trigger a mandatory update in McMyAdmin to change to using the new licencing server. Those with existing entered keys should find that their licence key is automatically swapped over without any intervention on their part.

Part of the move to the new licencing system is to no longer tie licences to email addresses or Paypal accounts to make them more flexible.

All existing licence keys will remain usable for a number of months after the changeover to give people time to migrate - but there will be a point at which old licence keys cease to be usable. There will be measures in place to help people recover lost keys if they have not managed to migrate by that time and the automated systems are unable to assist.

All in all this should be a largely transparent and painless transition, with many long term improvements once everything is done and dusted.

Posted in: McMyAdmin


Paypal, Money and Minecraft Servers - The do's and don'ts to help avoid getting bitten.

February 5, 2013 at 8:26 PMPhonicUK

First off just a little preface: Most of of my advice is based on my subjective experiences with Paypal. I may be entirely incorrect on some of the assumptions I make, so take the following with a few pinches of salt.

So dealing with payments to help with the running costs of a Minecraft server is something that a sizable amount of the community will have come up against at some time or another. Chances are you've read before about server owners being hit with chargebacks or paypal holding onto large sums of money for extended periods of time.

This post is about things you should and should not do as a server owner to help avoid some of the worst problems, and some advice about dealing with common issues you'll come across.


Dealing with payment disputes and chargebacks.

One of the common issues the Minecraft community has to deal with is younger players using their parents credit cards to buy benefits on servers without their permission, and then the cardholder invoking a chargeback with their credit card provider, or a dispute on paypal for unauthorized use.

Chargebacks are the bane of everyone who uses Paypal to accept payments. They're extremely difficult to fight, and worse they come with a hefty £14 GBP/~$20 USD fee if you don't win them, even though you're not at fault.

If the cardholder raises the dispute with Paypal you're very lucky. You'll lose the money originally given to you, but that's it. Paypal even refund the fees. For virtual goods there's no seller protection so there is still the problem where someone can donate, then raise a dispute saying it was unauthorized, and get their money back. This doesn't happen often though because paypal will not allow an unauthorized transaction dispute in the particular case of a family member using your card. Hence parents are very likely to just jump straight to the credit card company who will.

This is where things start to really suck. Since you're essentially selling virtual goods, it's almost impossible to prove receipt/delivery to the degree that will satisfy the credit card company. Any which point you're hit by the nasty fees mentioned earlier. 

Now there are some ways to help mitigate this problem:

For larger donations (Over about £20/$30), consider sending a 'thankyou' card, voucher, or something physical to the billing address via recorded delivery. This allows you to prove where the transaction came from, which makes dealing with disputes much much easier. This of course doesn't work if you're handling higher volumes of smaller amounts.

Discourage minors from donating. This is a bit of an issue since they are likely to make up a large amount of your player base. Consider requiring users to register before they can donate and require their age. If they're under 18, require that they provide a signed parental consent form. You can tie their registration to their Minecraft username to prevent someone registering twice once they find out that there is an age restriction.

Now this will cost you perfectly legitimate donations that you might have gotten otherwise due to the extra hassle. So you'll need to carefully consider the balance between income and risk to determine what barriers you're willing to put in peoples way.


Don't use the 'D' Word

This is a word you should avoid at all costs, not because it's really that inaccurate - but because it's a very easy way to have your funds frozen.

That word is 'Donation' or 'Donate'.

Paypal and other payment providers get very uptight if you use those words but aren't actually a registered charity or non-profit (Google checkout won't even let you take the payments unless you provide documentation proving you're a non-profit). Yes, the reality is that players are in effect donating towards the upkeep of the server with nothing real in return for it - but avoiding those words will save you a lot of pain. There's also legislation in certain countries that dictates donations have to be refundable within a certain amount of time or if they're over a certain amount - so keeping distanced from that will save you a lot of hurt.

So instead you can call it a "Contribution" or invite users to "Contribute" and give them a rank of "Contributor", and on any websites use the "Pay now" button instead of the "Donate" button to the effect that users are buying access to the "Contributor" rank on your server, along with any benefits you decide to bestow on them for this.


Do run your server like a business

This may seem counter intuitive for something that's just meant to be for fun, but it goes a long way to keeping everything manageable. Incoming contributions are your revenue source, the server is an expense, and dealing with payment issues is a cost of business that you need to allow for (see the section earlier on chargebacks).

In this vein you need to keep an eye out on cash flow. If 100% of your incoming revenue is used up the moment your server bill comes in, then you've got a cash flow problem because all it would take is for a single payment to be reversed (or worse, to have a charge back issued on the credit card) then you're immediately out of pocket.

So make sure you've always got a persistent balance available at all times, at least 10% of your monthly revenue should be put to one side each month to allow for either sudden costs that could jeopardize the server or just month-to-month inconsistencies. Just like real life you don't want to be living paycheque-to-paycheque. If you can't afford to do this then you should start either finding new revenue sources, or consider downsizing your server if you're not able/willing to make up the difference out of your own pocket.

Also like a business, look after your 'customers'. Consider rewarding those who donate regularly by sending them real-life gifts (or even just a thank you card) or other benefits to make them feel good about donating and keep them donating. Good will is an asset.

In addition, making your expenses public to your users will help build trust that their money isn't being squandered. Let them see how much your server bill is, and any other costs associated. Transparency is key to building a good relationship with players who are giving you money to run your server.


Don't let users buy their way into power

While letting users buy ranks that give them influence over other players is a near sure-fire way to get extra donations, it's also the best way to stop anyone else from donating and increase the number of chargebacks and disputes you get. This may seem really obvious but it's still something that far too many servers try and do.

The reasoning for this is pretty straightforward. It makes it too easy for one user to put themselves in a position where they can abuse other players, which will very quickly reduce your servers population and the number of people willing to contribute financially. Then when you find out that someone has abused their power and you revoke it - you can be reasonably sure that they will file a dispute out of spite.

This shouldn't even need to be a point here. It's suicide for your server. Don't do it.


Do keep an eye on the tax situation

This varies a lot from country to country (or even state to state in the US) so I'm not going to talk about this too much. The main thing is that you consult a tax adviser and make yourself familiar with your local tax laws to check what you need to do.

In the UK for example, if you're running the server like a business then you may need to declare yourself as self-employed (in addition to any normal day job you have) and you will likely have to pay taxes on your profits (income minus costs) - you still need to do this even if you don't make any profit. This also means filling in a self-assessment tax at the end of the year to declare your earnings and cost from the business.

Posted in: Minecraft

Tags: , , , ,