December 30, 2010 – T-machine.org

(this is a simplified, but complete, version of the “Entity System 1: Java/Android”)

NB: this post is part of the community effort to make working, usable, free, source-examples of actual Entity Systems, found at http://entity-systems.wikidot.com/

Wiki link: http://entity-systems.wikidot.com/rdbms-with-code-in-systems

Github source: https://github.com/adamgit/Entity-System–RDBMS-Inspired–Objective-C-

I’m posting my original design notes here – also copy/pasted to the wiki, but the wiki version will probably evolve over time. Comments on this post will be disabled – please comment direct on the wiki / wiki discussion pages.

NB: the source code is in GitHub, that’s where you should download it from (will include any fixes and updates over time)

Concepts

(integer) Entity
(enum) ComponentType
(interface OR empty base-class) Component
(interface OR empty base-class) System
(class with implementation) EntityManager

Data Classes

Entity

This is a non-negative integer, and uniquely identifies an entity within the ES. If you serialize your ES, this SHOULD be the same after serialization. New entities have to be assigned a new, unique, integer value when they are created. When an entity is destroyed, its integer value is freed, available for re-use.

ComponentType

This is needed because this ES is so simplistic it has no other way of identifying which Component you’re talking about when you’re looking at a single Entity.

(richer EntitySystems MAY not need this type)

Component

This exists purely to make method-signatures type-safe. We need to know that certain objects are valid instances of a “component” (so we use this superclass to indicate that), but we also need a method that’s guaranteed to work on all those objects (see below).

(richer EntitySystems make more use of this, and require it to be a class, but for this simple ES, you can use an interface/header file)

System

This exists purely to contain a known method-signature that your game-loop can call once per game-tick.

EntitySystem Implementation Classes

Each subclass of Component

Internally, the class has the following functions:

(ComponentType) getComponentType();

EntityManager

This contains:

The master collections (arrays, hashmaps, whatever) that contain all the data for all the entities
Logic for creating, modifying, fetching, and deleting entities
Logic for fetching and modifying components-from-entities

Internally, the class has the following variables:

MAP: from “Entity + ComponentType” to “concrete Component subclass”
LIST: all entities in existence (so it never duplicates entity-IDs!)
Internally, the class has the following functions:
1. (Component) getComponent( Entity, ComponentType );
2. (List) getAllComponentsOfType( ComponentType );
3. (List) getAllEntitiesPossessingComponent( ComponentType );
4. (void) addComponent( Entity, Component );
5. (int) createEntity;
6. (void) killEntity( Entity );

I had a serious customer-support problem with Skype recently, relating to money they’ve taken from me. It’s proved excessively difficult to get a response from them – surprising, considering their size, their brand, and the fact it’s a paid-for service. It raises some interesting questions over Customer Support / Community Support, and how they can/should be scaled.

FYI, the initial complaint is over what looks like a scam – if you pay for Skype, but don’t use it frequently enough, they cancel the service but keep the money. It was probably buried somewhere in the smallprint, but I certainly don’t remember that as part of what I signed-up for: “pay now … get screwed later!”. Whether or not it’s legal, it’s certainly dishonest (they give no explanation, it’s NOT part of the marketing materials, it’s just “policy”). It feels like theft.

Their website was useless. So, I asked them about it…or, at least, I tried to.

Reply-to-email: I replied to the email they sent me where they said they’ll be taking my money but NOT providing the service. They sent it from “noreply@notifications.skype.com”; this is a fundamental abuse of the email system, a sign of amateurish support teams. FAIL
Email-to-support: I tried forwarding that + my question to the standard email address – support@skype.com. I’ve been using Skype for 5 years, and I thought this address existed. Eithet my memory is wrong, or they’ve deleted it since. It doesn’t exist at the moment – you get a mailserver error. FAIL
Google for “email support skype”: I tried again, emailing the support address that Skype’s own employees have sent emails from – right now, on Skype.com, you can see example emails sent from “support@skype.net” (maybe this was what I remembered from years ago?). But if you send an email to that address, you get an email back saying: “Thank you for your email. Unfortunately this email address is no longer in use.”. FAIL

500 million accounts … too many?

Skype’s customer-support is unusually weak here; this is a paid-for product, and they’re actively blocking people from getting support. That’s not how support works; that’s what you do when you don’t have a support team – usually because you’re too poor to afford it AND you have no paying customers. Doing this with paying customers is surprising. Especially for a large product/brand.

I remember in the very early days of Skype they already had 50-100 employees for what was a comparitively small operation. IIRC, a big chunk of that was dedicated to support, and a big chunk to marketing – only a very small part was tech. I’d assumed that with their 10’s of millions of users, they had a highly automated customer-support system.

Today, they have well over half a billion user accounts – and it would seem that even their automated systems have failed. Why else would they put a block on industry-standard email aliases? And deliberately shutdown their own support address?

Obviously, those addresses would be flooded with spam and FAQ emails … but *all* commercial customer-support systems are specifically designed to handle those probems – and at large scale, too.

My guess is simply that whichever commercial system they use wasn’t architected to a high enough quality, and is incapable of handling Skype’s uniquely large customer base. This isn’t a criticism of that system – there are very few companies in the world with so many users of a single product. i.e. there’s very little demand for a product to be so carefully engineered.

But it begs the question: why hasn’t Skype put something better in place? Surely they have the resource and the skill to source or architect something better? Or is it a company policy to provide second-rate, low-quality support – even for their paid customers?

What Would Facebook Do?

…hopefully, I’ll post on this in more detail later, but briefly: they *eventually* went to specialist external vendors to provide the scalability they needed:

Facebook was incapable of reliably delivering messages to users for most of the past 3+ years
I’ve run several groups large and small, and found that approx 30% of all messages DIRECT to *opt-in* users went undelivered in the FB messaging system
(speaking to other people who ran facebook groups, or had huge numbers of Friends, the experience was commonly repeated. e.g. I know a few people who had to setup multiple FB accounts because they had “too many friends” to fit on a single account)
Facebook recently (last 6 months) replaced their internal, proprietary messaging with an external, specialist system from a company that specialises in high-volume messaging (according to the vendor; caveat emptor)
Reports from other people who still use Facebook for large groups / large numbers of friends suggest the “lost in the post” phenomenon is now cured

Incidentally, I don’t/didn’t think much of Facebook’s tech team (although quite possiby it’s improvements in that team that have lead to fixed like the one above). It’s very hard to be sure, going on just public info, but I used to read their blog, and their posts about performance and architecture were for a long period … amateurish.

On some core subjects, they betrayed a deep lack of experience and understanding – and apparently no effort being taken to correct that, but rather they preferred to “hack” away with band-aid solutions. Great fun for them, but not appropriate for a billion-dollar service, IMHO.