Effect areas

I added a new feature: Status Effect areas.

These provide buffs (or debuffs) to anyone standing in them. This feature will make positioning in combat even more important and diversify the game experiences on different maps.

Got rid of multiple characters per account

I got rid of accounts. Each character now has its own password.

Why did I do this?

1. this simplifies lots of things in the code like banning, permission handling etc.
2. It makes it easier to do registration during the tutorial, because now there is only one name the player needs to make up.
3. I don't expect that many players will create more than one character, because there isn't much reason to do so in my game system.
4. There is no way to stop people from making more than one account anyway, so they are no appropriate method to tell natural persons apart.


The next thing will be to allow players to start the tutorial with an unregistred character. The player will choose a password when the tutorial is over.

Experimenting with JSP

Today I experimented a bit with Tomcat, Servlets and Java Server Pages. I made a char-viewer which gets a character from my MongoDB and exports some of its data as a website.

I really like the technology. I wonder if I should use it for some web-based components. But on the other hand, I would prefer to avoid mixing too many technologies. So I would prefer all of my non-game web applications to run in the same server application. I would, for example, like to have a forum and I don't want to program it myself. But while I was able to find plenty of free forum software in PHP, I couldn't find anything properly mature in JSP.

Seems like I need to brush up my PHP skills soon. I don't like it very much, but there is hardly a way around it.

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.

Status indicators

During playtesting I realized that when I died it was often because I wasn't aware of how low my HP were and that my barrier was already depleted.

The reason is that the players eyes need to focus on what is happening at the center of the screen during combat, but also to the status bars at the upper right edge of the screen. It's really hard to pay attention to both at the same time.

To solve this problem I decided that these markers need to get closer to the player-character. So I added some HUD elements right below it:

The arcs are, from inner to outer, the current percent-status of MP, HP and barriers. When the character would have multiple barriers, they would appear as additional concentric arcs around it. When the player wants to know the exact numbers, they can still look at the upper-right corner. But these arcs gives the player a constant awareness of the status of their player-character.

Barrier Tutorial

I added a barrier tutorial to the tutorial map.

The player has to walk through a course without taking any non-shield damage.

This required two new scripting abilities: Map areas which trigger scripts and attacks which trigger scripts. Both of these new abilities will likely come in handy in the future.

Balancing through testing

To test my formulas I created a little program to auto-generate mobs with average stats from level 5 to 100. I want to avoid this in the final version (or do I?), but for now it is a nice balancing tool.

This really helped me to file off some edges and balance my procedural barrier generation algorithm. Next one are healing spells.

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.

Banning and Kicking

I implemented banning and kicking. This was a must-have feature.

I cut some corners here by making offline banning an operation which blocks until the database has finished doing it. That means that the map the admin is on hangs until the database did the change, but considering that banning isn't something which happens every minute (at least I hope it won't)  this shouldn't be a problem.

Tutorial

I started with the tutorial. The tutorial is the first thing the user sees of a game, so it's very important to do it well. It has to get the player hyped for the game while still conveying all information the user needs.

It is also a baptism of fire for the scripting engine, because tutorials are always heavily scripted. And bugs will not be forgiven, because a buggy tutorial will alienate many players before they even took a look at the real game.

I created the NPC Firyafoni as a framing device for the tutorial . Her name is an anagram for "Info Fairy" which is a pretty accurate description of her. I plan to use this character whenever I need to give some meta-gaming information to the player.

Fairies are creatures which are capable of existing in many places at the same time by creating clones of them self in remote places. When the fairy doesn't concentrate on a clone, it disappears, but most fairies are capable of handling dozens of clones at the same time. All clones of them form a hive-mind - everything one clone of them sees or feels is also noticed by all others. The individual clones are capable of interacting with other creatures normally. It is, however, impossible for the clones to interact with each other. When two clones of a fairy perceive each other, it's a very unsettling experience for the fairy, which leads to one of the clones disappearing. For that reason, fairies are also afraid of mirrors.

Equip defense

I haven't done any development for a while (curse you, Kerbal Space Program), but today I again did something: I implemented equipment defense. Each piece of equipment can now have a defense value. Optionally, it can also have a different defense value against specific elements. When it hasn't got a specific value against an attack, the general defense value is used.

When an attack hits a player, each piece of equipment removes a random amount of damage which is between 0 and the applicable defense value.

Healing works again

Today I fixed lot of minor problems on both client and server. But I also did something major: I re-implemented healing as procedurally generated spells.

Equipment revamp

While creating the buyable equipment for Wenibe, I noticed that there isn't much equipment can do. It can modify the players stats, but I would expect it to have more fundamental properties. Clothes should reduce damage and wands increase it. They should also be geared for specific situations.

Clothes

Clothes always have a general defense value, and can have special defense values for specific elements which are higher or lower. When the equipment has a special value for the element which is used by the attacker, that value is used, otherwise the general defense value is used.

When an attack hits the character, for each piece of equipment a random number is generated between 0 and the applicable defense value. Each of these numbers is subtracted from the attack. No total immunity is possible that way - even weak attacks have a low chance to break through high-end equipment. But considering that a player character usually wears 4 defense items (hat, robe, belt, shoes), the resistance is still pretty reliable when all of them give about equal defense.

Weapons

Weapons could have these effects:

• Increase damage
• Increase range
• Decrease casting time

	Staff	Rod	Wand	Stave	Scepter	Cane
Damage	X			X	X
Range		X		X		X
Cast Time			X		X	X

I think I should make these percentile boni.

Just like with clothes, a weapon has a general value and specific different values for specific elements.

Each of these effects could only apply to a specific element. That way you have to choose between a general-purpose weapon which boosts all elements or a specialized weapon which only boosts your favorite one while giving a malus to the opposite element.

I could also imagine rare weapons which give all spells a special property, like making all spells vampiric.

The town of Wenibe

I started building a small town map as a test-bed for NPC scripting and to force myself to start doing some tiles. It already showed me some features which were missing on the server to allow effective script-writing.

Some new spell icons

I created the thunder family of spell icons:

How EVE Online deals with 3000 player battles

I read an interesting article about how Eve Online handles the server load caused by an unusual high number of players in the same area.

Their main trick is to slow down the gameplay when the server is overloaded (likely by reducing the number of ticks per second on the server). I could easily do the same, I just have to modify a few places where I assume that the tick rate is globally identical and I would have to inform the client that everything now moves slower. But I wonder if this would really reduce the load much in my case, because I assume that a player which has more time to do things will also try to do more things, and they will still send move- and action commands with the same real-time frequency.

Another thing they mentioned is the ability to temporarily move areas from a weak cluster machine to a dedicated server with much stronger hardware, but unfortunately this has a critical implementation flaw: It disconnects everybody on the server. It also doesn't happen automatically and needs to be triggered by an admin.

Currently my game is not cluster-ready, but in the long term I plan to make it possible to put each map instance on a different server, preferably fully-automatic to keep the administrative overhead low (I keep this in mind, but I won't do anything in this regard until I have a player base with a size which actually justifies the effort). When I do that, I should look into making it possible to also transfer the running instance together with its players to a different server, preferably without them noticing and fully-automatic.

Procedurally generated shop content

Item shops can now have procedurally generated stock. I also improved the user interface by adding scrollbars to shops, showing the rarity as the item name color and adding tooltips. Shopping now works adequately.

Selling implemented

I added the selling gui. Now all that is missing for the item milestone is stack splitting/merging and tooltips in the buy- and sell GUIs.

By the way: I need to fix the price calculation of spells. The high-level ones should be a lot more expensive. But in order to do that I need to come up with a wealth-per-level formula to make up good prices.

Wisdom capacity implemented

I was already considering to can this feature just because I didn't find an elegant way to implement it on the server  (bad software developer), but I finally found a nice way to do it. The purple bar below the quickbar now shows how much wisdom capacity your character is using.

The amount of different spells you can have in your quickbar depends on your wisdom stat. Currently you can switch you hotkey assignment anywhere, but I plan to restrict this to towns, so you have to choose carefully which spells to assign before wandering into the world. That means a high wisdom stat is a prerequisite for a wizard who wants to be flexible.

Each spell uses level / 10 + rarity wisdom capacity. That means that rare spells use a lot more capacity than common spells.

Rest system number crunching

I did some more number crunching with the rest system, and noticed the two constants which are most important:

1. the base of the logarithm
2. the reduction factor per minute

The reduction factor - how many percent of rest the character loses in each minute where it does something exp-worthy -  is most important to define the "cutoff duration" - the length of a play session after which the exp bonus becomes negligible. Due to the exponential decrease it doesn't matter much with how much rest a character starts out. This affects the duration just by some minutes. A reduction by 1% makes it possible to play from dawn till tusk until the bonus falls below 1.5%. A reduction by 2% gives you an afternoon of good exp. With 3% reduction, it's about an evening. When I put it up to 10%, the fun is over after less than an hour. When I set it to a whooping 50%, you burn through your exp bonus in 10 minutes.

a lower base of the logarithm makes the rest system more effective overall, especially after longer breaks. The lower the base of the logarithm, the higher the rest bonus a character starts with after a break.

Rest system implemented

I implemented my rest system the way I described. I still wonder if my rest formulas weren't a bit too conservative. I feel like my character should have more rest bonus after 4 offline days. Especially considering that a character which rested for 20 hours already got a bonus of 2.1.

On an unrelated note, I am making good progress with the animation system. The engine should be ready for turning and animated sprites soon.

Selling implemented

I implemented selling on the server-side. I actually did several days ago, but I forgot to post about it. Now I just need a GUI on the client for selling.

The day I discovered context.shadowBlur

Today I discovered the canvas shadow effect, which can be used to create a glow effect when drawing shapes or sprites. I used it to make the range marker look a lot better and to add a highlight to the object which is currently under the mouse cursor. The latter is an important usability improvement, because without it, it was really hard to pick individual objects when there were multiple ones overlapping each other.

Range marker and damage types

When the player is selecting a target for a spell, the range of the spell is now displayed in form of a circle. This is an important usability improvement, because there was no indication which targets are in range and which are not.

Another usability improvement I added, are damage numbers which indicate the element of the damage with their color. Also, ethereal damage is now shown with a "mp" suffix and healing with a "+" prefix.

I added a rotating heptagram to the circle as a little gimmick. I am not sure if I am going to keep it. It seems distracting without adding much.