About the death of Glitch

About a week ago, I read that Glitch closed down due to lack of players. I must admint I never played that game. But the game had some striking similarities to mine. It too was an MMORPG, it was web-based and it was breaking conventions. I wondered if the same would happen to my game. Could it? Let's see what their reasons were for closing down.

Technology choice

One reason they mentioned was that the decision to use Flash turned out to be bad. I think they are overrating this factor. Sure, they couldn't port it to the iPad, but when people really wanted to play it, they could have played it on their PC. And seriously, who has an iPad but no PC? Sure, Microsoft and Apple have both decided that Flash needs to die, but so far their attempts at killing it didn't work out so well.

But I am not using Flash, I am using HTML5 which all the big tech companies support. I think I am pretty save in this regard.

Too complex infrastructure.

Their closing-faq mentions that "It takes a full-time team of competent engineers & technical operations personnel just to keep the game open. Even if there was a competent team that was willing to work on it full time for free, it would take months to train them. Even then, the cost of hosting the servers would be prohibitively expensive.". When that is true, they really have scaling issues. Less players should mean less work to do. But obviously that wasn't the case. Maybe their infrastructure was designed to scale up, but not down.

I am still taking this as a warning: I have to try to keep my infrastructure as low-maintainance as possible.

They didn't know what they were doing.

There is a really interesting article on Gamasutra which mentions that the people who made it didn't really had much of a clue about game development.

It seems to me like what they made wasn't so much of a game but rather some interactive community something which threw together gimicky game elements without having anything one could consider the "core gameplay mechanic". Sure, there seemed to be an amazing amount of creativity behind the project. But unfortunately they let that creativity run lose without any sense for coherent structure.

I hope I got this covered. Sure, I can't claim that I am a professional game developer yet, but game development is my hobby for about 20 years. I also collected plenty of experience with The Mana World. I believe that I know what I am doing when it comes to game design.

Not accessible enough

Another aspect the Gamasutra article mentions how hard it was to get into the game: "A lot of people were just like 'I don't know what the fuck I'm supposed to do.' Some people took 'I don't know what I'm supposed to do' as an invitation to explore and ended up loving it. Other people closed the browser. That's it."

The big strongpoint of browser-based games is that it is easy to start playing them. No gigabyte-sized download, just visit the website and you are good to go. But that's also their greatest weakness: It's too easy to close the browser window and forget that they exist. By making the game too hard to get into they fell prey to that weakness.

This showed to me that starting my games content development with the tutorial was definitely the right choice.

There is no such thing as NoSQL

You might have heard about that new NoSQL thing. You wonder

• Is NoSQL faster than SQL?
• Can NoSQL replace my existing SQL database?
• Will NoSQL fix my problem with my SQL database?
• Is NoSQL an option for my next project?

Unfortunately this article can't give you an answer, because these questions are wrong. What's wrong about them? You see, the problem is this:

There is no such thing as NoSQL!

NoSQL is a buzzword.

For decades, when people were talking about databases, they meant relational databases. And when people were talking about relational databases, they meant those you control with Edgar F. Codd's Structured Query Language. Storing data in some other way? Madness! Anything else is just flatfiles.

But in the past few years, people started to question this dogma.  People wondered if tables with rows and columns are really the only way to represent data. People started thinking and coding, and came up with many new concepts how data could be organized. And they started to create new database systems designed for these new ways of working with data.

The philosophies of all these databases were different. But one thing all these databases had in common, was that the Structured Query Language was no longer a good fit for using them. So each database replaced SQL with their own query languages. And so the term NoSQL was born, as a label for all database technologies which defy the classic relational database model.

So what do NoSQL databases have in common?

Actually, not much.

You often hear phrases like:

• NoSQL is scalable!
• NoSQL is for BigData!
• NoSQL violates ACID!
• NoSQL is a glorified key/value store!

Is that true? Well, some of these statements might be true for some databases commonly called NoSQL, but every single one is also false for at least one other. Actually, the only thing NoSQL databases have in common, is that they are databases which do not use SQL. That's it. The only thing that defines them is what sets them apart from each other.

So what sets NoSQL databases apart?

So we made clear that all those databases commonly referred to as NoSQL are too different to evaluate them together. Each of them needs to be evaluated separately to decide if they are a good fit to solve a specific problem. But where do we begin? Thankfully, NoSQL databases can be grouped into certain categories, which are suitable for different use-cases:

Document-oriented

Examples: MongoDB, CouchDB
Strengths: Heterogenous data, working object-oriented, agile development

Their advantage is that they do not require a consistent data structure. They are useful when your requirements and thus your database layout changes constantly, or when you are dealing with datasets which belong together but still look very differently. When you have a lot of tables with two columns called "key" and "value", then these might be worth looking into.

Graph databases

Examples: Neo4j, GiraffeDB.
Strengths: Data Mining

Their focus is at defining data by its relation to other data. When you have a lot of tables with primary keys which are the primary keys of two other tables (and maybe some data describing the relation between them), then these might be something for you.

Key-Value Stores

Examples: Redis, Cassandra, MemcacheDB
Strengths: Fast lookup of values by known keys

They are very simplistic, but that makes them fast and easy to use. When you have no need for stored procedures, constraints, triggers and all those advanced database features and you just want fast storage and retrieval of your data, then those are for you.

Unfortunately they assume that you know exactly what you are looking for. You need the profile of User157641? No problem, will only take microseconds. But what when you want the names of all users who are aged between 16 and 24, have "waffles" as their favorite food and logged in in the last 24 hours? Tough luck. When you don't have a definite and unique key for a specific result, you can't get it out of your K-V store that easily.

Is SQL obsolete?

Some NoSQL proponents claim that their favorite NoSQL database is the new way of doing things, and SQL is a thing of the past.

Are they right?

No, of course they aren't. While there are problems SQL isn't suitable for, it still got its strengths. Lots of data models are simply best represented as a collection of tables which reference each other. Especially because most database programmers were trained for decades to think of data in a relational way, and trying to press this mindset onto a new technology which wasn't made for it rarely ends well.

NoSQL databases aren't a replacement for SQL - they are an alternative.

Most software ecosystems around the different NoSQL databases aren't as mature yet. While there are advances, you still haven't got supplemental tools which are as mature and powerful as those available for popular SQL databases.

Also, there is much more know-how for SQL around. Generations of computer scientists have spent decades of their careers into research focusing on relational databases, and it shows: The literature written about SQL databases and relational data modelling, both practical and theoretical, could fill multiple libraries full of books. How to build a relational database for your data is a topic so well-researched it's hard to find a corner case where there isn't a generally accepted by-the-book best practice.

Most NoSQL databases, on the other hand, are still in their infancy. We are still figuring out the best way to use them.