Balancing through number-crunching

After the stressful summer with the election and my sailing hours I wanted to continue development right away, but instead of that I decided to use the distance I gained from the project to take a 2nd look on some of my code, so I was doing mostly minor cleanups and refactoring.

Then I decided that it is time to start with the content. But when I wanted to do so I realized that I had no idea what I was doing. What's a good experience yield for a Level 5 monster? How much is a spell supposed to cost? How much defense should a level 10 robe have? Just making up values on the spot would not have been wise, as I would have to balance it through trial and error. So I decided to buy some Magic Chart paper (cool stuff, by the way. It clings to any surface through electrostatics. You can easily move them around without leaving a trace. You can draw on it with dry-erase marker and just wipe it away just like on a whiteboard) and summarized all the level-dependent formulas I have.

While doing this I realized some balancing errors which would have been quite bad in practice (MP increases quadratic but MP regeneration just linear - ooops). These handy charts will make it much easier for me to make up content.

ToDo until public alpha

Content:

• Mapping for Wenibe and surrounding
• Scripting for some quests
• Create and balance content for 20 levels:
• Equipment
• Mobs

Bugs:

• Instance freeze bug - find it and fix it or add an automatic monitor for instances and terminate those which seem to be caught in an infinite loop.

Technical:

• Create a website
• Find a server hoster and set up the gameserver

Target indicators

The players now see which combatants are currently targeted by spells of which element. This should make barrier-management more easy.

Speaking of barriers: These can now be cast by players and are now scroll-based like all other spells. Just as I planned, each player-character can have only one barrier active at a time, but this barrier doesn't need to be on itself. So a party can decide to stack all their barriers on one designated tank while leaving all other members unprotected.

Still missing on the barrier front: A tutorial, scroll icons and an NPC to sell them.

Barriers

This is a feature I first decided to take off my roadmap to alpha, but I realized that it's a too important part of my game concept, so I started implementing it.

A barrier is a buff which works like a HP buffer for a special element. When it is cast on another player, all damage with that element will eat away the HP value of the barrier before reducing the actual HP of the players. The HP buffer of the barrier decays naturally during the lifetime of the shield.

Currently there is only a provisorical implementation - every player starts out with a 100HP fire shield which loses 1 HP per second. But I am going to make barriers spells. Each player-character can have one barrier active at a time, but it doesn't need to be on oneself, so a player can make the tactical decision to protect another partymember instead of oneself.

There will be two kinds of barriers. Long-time wards which decay slowly but need a long time to cast, and quick counterspells which are cast very quickly but also decays rapidly. The first kind is used as a precaution when wandering dangerous areas, while the latter is cast when you notice someone attacks you to prevent the damage.

Private chatting

Yesterday I added private chatting. The "whisper" option on the character context menu is now functional. There are still two problems, though:

1. Although the protocol allows it, there is no way to open a chat with someone not on the screen
2. There is no way to close chat tabs, except for reloading the website

Implemented parties

I implemented parties today.

This was quite a lot more work than I expected, because of all the edge cases which needed to be taken care of. Handling party requests of people who log out, handling parties disbanding while taking on new members, removing members who are online, offline or in char select... all sources of annoying bugs. The good news is that I will likely be able to re-use most of the code when it will come to guilds later.

Parties don't affect exp sharing because that's not needed in my current system - every attacker gets his full exp share anyway.

What parties do instead:

• Party members share private instances
• Party members can chat with each other
• Party members can see each others location

Base and real stats

Stat increases by equipment and temporary effects are now reported to the client and show up in the GUI:

In other news: I finally fixed the "shortcut over unwalkable tiles" bug.

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.

Yay, vacation!

I got two weeks of vacation, so I finally got some time and energy for my programming project.

In the past days I fixed some small bugs (the bad news: while I did that I discovered lots of new bugs). I also made some more particle effects.

But the greatest achievement was that I completed the tutorial (although I will likely expand it later when I got some more features) and started building the newbie area. I got an outdoor map:

And a small instanced dungeon with a new water-born mob:

What I really need now are more and better map tiles so that the environment doesn't look that blocky anymore. Blocky might be en-vogue after the success of Minecraft and Terraria, but I want to do better.

Particle Engine

I didn't find much time for programming lately, because I have too many other hobbies right now. First I joined a political party and the election in Germany isn't far away, so I spend much time on supporting our campaign. And then I decided to get a sailing license this summer. So I haven't got much time left.

Nevertheless I had nothing to do this Sunday afternoon and got around implementing a particle engine.

I like programming particle engines. A particle engine was my first and most major contribution to The Mana World. My first thought was porting the TMW particle engine to Javascript as-is (just using JSON instead of XML for particle definitions), but then I decided that a different architecture is much more suitable for JS. Instead of defining the physical properties of each particle type in an XML file (or rather JSON), I decided to implement the physical behavior of each type with a function.