Tuesday, July 29, 2014

Mining System implemented

I implemented the mining system. I also made the first mining map, an NPC which sells the mining spells, and two Foni's, one giving mining hints and one telling a bit more about herself. I am not that happy with the iron ore item sprite, though. It looks like shit. No, it literally does. Just look at it:

But otherwise, I am quite happy with this feature. It works just like I designed it. Sensing and prospecting isn't implemented yet, but probing and mining works just as intended and I think hunting for ore is really fun... at least compared to the "click on ore, watch progress bar" resource gathering systems of most MMORPGs. Now I just need something which can actually be done with the ore. Currently it's just vendor trash, and not even a particularly lucrative kind.

Saturday, July 26, 2014

Wenibe and Angel quest finished

I reworked Wenibe and finished the angel quest. I actually did two weeks ago. I need to take this blogging thing more serious again.

Monday, June 30, 2014

AoE overhaul

I spent the whole Sunday with overhauling the code for AoE attacks. It is now much more extensible for different attack patterns than just points and circles. I also implemented attacks which target a ground location instead of a specific opponent, which works both for mobs and for players.

However, the procedural spell generation system doesn't create any spells with that feature yet. Both kinds of AoE attacks are now visualized by the client during their preparation-time, so players can dodge attacks more intuitively.

Wednesday, June 18, 2014

Little content todo list

I am currently working on content up to level 10. I made the dungeon which should bring the player to level 10, but it is still quite hardcore. Here is a little Todo list of stuff I need to add to prepare the player for it:

My shell is not complicated!

To get the current HP of a boss monster, you just have to use one simple, easy to remember, command:

/shell user.getMapInstance().getMobs().stream().filter(function(mob) { return mob.getName() == "Boss" }).findFirst().get().getHp();


I might need to work on this.

Sunday, June 8, 2014

Labyrinth generator

I experimented with procedural map generation. The maze below is created completely on the server based on a random seed. I might want to use this algorithm as-is in the finished game to create procedural dungeons, but for now it's mainly a proof-of-concept. I could imagine a lot more kinds of maps which could be created procedurally than just this one.

This, however, begs the question of how much I want to rely on procedural content. While procedural generation is a great way to create huge amounts of content with minimal work, it can never compete with the ingenuity of hand-designed content.

To send the procedurally-generated map to the client, I had to write my own encoding routine for my maps. I used to just forward the original JSON code from Tiled to the client. But because there is no Tiled file for procedurally-generated maps, I had to write a routine to encode the map data myself.

The same routine is now used for the maps made in Tiled. This has the advantage that I only transfer the information about the map which the client needs to know. This saves bandwidth and removes cheating opportunities.

Sunday, June 1, 2014


I've added a minimap. An easy to do but crucial feature.

Monday, May 26, 2014

Content Content Content!

The last days were all about adding content. I made the first complete quest, I made the biggest map so far, I balanced the existing mobs and I made a new tileset which I will soon use for the first real dungeon. But there is still a lot of stuff to do before I got enough content to go public.

Wednesday, May 21, 2014

Attack particle effects

My buglist is shrinking down to the "that code will be replaced anyway" and "freak accident which happened once during development" categories, so I started something new. Attacks now create projectiles which fly from the caster to the target. That makes combat a lot more immersive:

Monday, May 19, 2014

Mining system

Just a concept for now.

Resource gathering is an important part of every crafting system. An important resource would be ores and minerals mined from the depth of the earth.

It would, of course, be unthinkable for a wizard to take a pickaxe and perform manual labor to excavate minerals. Like everything in Pecosia, there is a branch of magic dedicated to these kinds of jobs: Geomancery.

Geomancery is the art of using magic to sense minerals in the earth and getting them to the surface. A geomancer hunting for ores needs two spells: A detection spell which tells him where the minerals are hiding and a mining-spell which gets them to the surface. More advanced minerals do of course require more advanced geomancery spells to find and mine.

Detection spells:


The first spell cast by a geomancer visiting a new location. It tells them if and which minerals can be found on this map, but not where.


Tells the geomancer if there are mineral deposits in range and how far they are away, but not in which direction. It does so by telling the caster the level of mineral radiation at its current position. The closer they are, the higher the radiation. However, when there are multiple deposits in range, their radiation adds up which could mislead the geomancer.


Tells the geomancer the direction of the next mineral deposit, but not how close it is. When there are multiple deposits nearby, the vector-product is created and the angle of that is shown, so again, multiple deposits in range can be misleading.


The Mining spell

When the geomancer believes that she found the deposit, she will use the mine-spell. It will reveal any mineral deposits in range and turn them into items which can then be picked up. The mine-spell is much more MP-costly and slower to cast than the detection spells. So while a geomancer which just casts it randomly might find a deposit once in a while, one which uses probe and sense will be much more successful in the long run.


All of this should not be hard to implement. But before I start I need to work on some bugs. I am using a spreadsheet for a while to collect any bugs I find but do not feel like fixing right away, and it has grown quite long. Some are of the we-can-live-with-that-for-now level, but there is also a very critical bug which makes the whole network system unresponsive under some condition which I definitely need to take care of before starting with any new features. There are also some worrysome bugs which are not that critical, but very hard to reproduce. Multithreading is hell.

Saturday, May 3, 2014

Fighting NPCs

I added the ability for NPC scrips to turn NPCs into mobs and revert them back to NPCs when defeated. This will be very useful for quest scripting. I want to avoid those cliché "Kill 10 rats" quests. I want quests which actually tell a story and are not just excuses for mob grinding.

I also did a first quest where you retrieve a stolen item. The player finds the thief and talks to them. Then the thief  turns hostile and fights the player. Well, that's the basic plot. The details are of course much more fleshed out (don't want to spoil).

Saturday, April 26, 2014

Shutdown procedure

Until now there was no proper way to shut down the server. The only way was to kill the JVM process, which didn't save any characters. I finally solved this by adding a proper shutdown-command which properly disconnects and saves all the characters, terminates all the map instances and properly finishes up all the other stuff which happens in the background. I also wrote a server-sided javascript which can be executed from the shell and shuts down the server after a countdown. This utilizes a new admin-broadcast feature I also implemented.

I mostly did the script as a PoC for server-sided scripts started from the console. This might come in really handy for special events managed by GMs.

Saturday, April 12, 2014

Choosing a wiki software

I am currently looking for a wiki software to use.

My should-requirements are:

  • Uses PHP
  • Simple to set up and administrate
  • Syntax similar to MediaWiki
  • Doesn't use databases besides MySQL and MongoDB

My can-requirements are:

  • Possible to hack in a way that it can share user accounts with my game


My first idea was the popular MediaWiki, but the "What is MediaWiki" section on their homepage says: 

"MediaWiki is geared towards the needs of the Wikimedia Foundation. The program is primarily developed to run on a large server farm for Wikipedia and its sister projects. Features, performance, configurability, ease-of-use, etc are designed in this light; if your needs are radically different the software might not be appropriate for you." 

I just want a wiki for my small little game, not build a million-article encyclopedia running on a dedicated server-farm, so this doesn't really sound like the right software for me.


The second software which caught my eye was PmWiki, pretty much the Anti-MediaWiki.

It is extremely simple to set up, because it doesn't even require a database. It saves everything in flatfiles. This might look strange in this day and age, but they are making a convincing argument. I tried it and the installation was indeed a breeze - just copy the PHP-files and it runs out-of-the-box.

But what really surprised me is that PmWiki by default does not even know the concept of personalized user accounts. In the default configuration, everything can be edited anonymously. When you don't like that, you can set individual passwords, but they are not bound to accounts. Anyone who knows the password can read or edit specifically protected pages.

There are, however, lots of addons which enable mandatory logins with username and password. Many of them are designed to use the user databases of other systems. That likely means that I could write my own which uses the accounts in my MongoDB.

Wednesday, April 9, 2014

MongoDB authentication

I used to run MongoDB authentication-less. I used to rely on a firewall to shield MongoDB against outside access and only allow access from within the server-network like early MongoDB guides suggested, but I know that my skills as a sysadmin are limited. So I decided to enabled user accounts and authentication for MongoDB and add support for authentication to the gameserver. Better safe than sorry.

Sunday, April 6, 2014

Password changing

I replaced the "Logout" button in the control bar with a new button "Menu". This button opens a popup menu with lots of links. "Logout" does the same thing the old logout button did. "Settings" opens a new window which allows the user to change their password.

The other options are links which will lead to various web-applications I still need to set up.

Thursday, March 27, 2014

Crafting interface implemented

I added support for crafting. NPCs can now display a crafting window. They can freely define how many slots to display and where to display them. The item script can also define a handler-function which receives the items the player dragged into the window. Each slot can define a "tag" which says which items can go there. Items can now have one or more such tags which define the crafting use they have.

The Java part of the engine does the ground-work of validating that the users input is legal (tags match the slots, user actually has the items).

The scripted function is then responsible for checking if the combination is a valid recipe, remove the items and give the player a new item. This function could also be implemented as a Java class. When I develop a more complex crafting system, I might opt to do so.

Java 8

I updated to Java8 and experimented with some of its new features. I coverted the admin command handlers to use the new lambda feature, and it really improves the code. The new Nashorn Javascript engine gave me some problems because some scripts no longer worked the way they used to, but I think I solved all the issues (wrote a Q&A on stackoverflow about it).

Tuesday, March 18, 2014


Last week I worked on ways to obtain some usage statistics.

The server now accumulates statistics about how much network traffic is sent and received for each message type. I added a command /traffic to access this information from within the game. This should tell me where I need to optimize my protocol. So far it seems like move-messages and map-layout messages are the traffic users number 1 and 2.

Both leave some room for optimization. The move-messages send the coordinates in ascii-encoded floating point numbers with a precision much higher than needed. Two decimal places should be more than enough. And the map information is basically the whole JSON data as it comes from Tiled. That's a lot information the user is not meant to see. It can and should be redacted.

But I need real usage data by real players to say for sure where optimization is needed most.

Another method to generate statistics are web-reports. I created a system to regularly export data as JSONP files and save them somewhere. A website can then use javascript to import this data and output it in a presentable way. Currently I have a list of current players and a list of active maps with player count. The JSONP technique makes the data available to anyone. This is intentional; I would like to see what the community can come up with to beautify my data.

I am thinking about archiving these reports in the database too. That would give me access to historical data.

Monday, March 3, 2014

Visible equipment

I made it possible for an object to consist of multiple sprites and to set these from the server. This in turn enabled me to implement visible equipment. When a player puts on and takes off equipment, this is now visible on their sprite.

Currently this only works with hats and staffs because I only have sprites for these yet. But that's just a matter of creating the content. The next step will be to allow differently colored equipment.

Saturday, February 22, 2014

Password hashing updated

I improved the security of the password hashing system. As a side-effect all my old character-accounts are now invalid, so I had to delete them from the database. I could have done it in a backward-compatible way and retain the characters, but why bother when I don't have a production server yet.

Wednesday, February 12, 2014

Some new tiles and height levels

I created some new tiles. The rocks look OK, but the bushes need more work.

I also experimented with adding height levels. Those you see on this screenshot are entirely client-sided and randomly generated. I am unsure if I will keep it.

First, I am not sure if it is even going to add so much gameplay-wise for the amount of work it would mean (routefinding etc.). Then there is the problem that Tiled can't do isometric maps with height levels. So I would either have to patch Tiled, find another editor or write my own map editor after all.

Thursday, December 26, 2013

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.

Thursday, November 28, 2013

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.

Friday, November 22, 2013

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.

Thursday, November 21, 2013

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.

Friday, November 1, 2013

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.

Sunday, October 27, 2013

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.

Saturday, October 26, 2013

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.

Tuesday, October 22, 2013

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.

Sunday, August 25, 2013

ToDo until public alpha

  • Mapping for Wenibe and surrounding
  • Scripting for some quests
  • Create and balance content for 20 levels:
    • Equipment
    • Mobs
  • 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.

  • 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.

Thursday, August 15, 2013


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.

Wednesday, August 7, 2013

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