Unexpected Encounter – Tic Toc Tic Toc

All what I thought of would work, but I wanted something more elegant, less restricting and more encouraging, and after two days of intensive thinking the Muse of Gaming paid me a visit :) What if I had a period of time within which a player has to capture a Soul Gem or there would be some unpleasant consequences? I liked the idea right away, just needed to put a bit more thinking into it and figure out what kind of a timer it is and what consequences are, to hit the golden middle of not being too pushy, but still encourage people to advance further – and that's how the Astral Countdown emerged into the World of Undecima.  

The Astral Countdown will start ticking after a Town Class is researched for all new players (no point of restricting newbies) or on the next login for all existing players (if they have researched a Town Class already). I even thought of a little story behind it and here how it goes:  

"You have researched a Town Class and now your Town is bound to the World of Undecima. To keep developing your Town, you will need to capture more Soul Gems. The Time is ticking away and you can see your Astral Countdown in your Keep - by the end of this countdown, you have to capture one Soul Gem. If you fail to do it, you won't be able to do any upgrades or researches in your town and you won't be able to attack other players (unless they attack you first) until you do capture a Soul Gem.

With the steel of Might, the power of Magic, the spirit of Nature, or the light of Faith, prove that you are the worthy one."  

As I'm writing this post, the Astral Countdown has been implemented already and so far the response was good, even from the people this new feature was supposed to affect the worse (those big fat sitters who didn't want to advance further). There are some exceptions for people being attacked and for people returning back to the game after some prolonged absence as well. It's been running for a few days only and as the time goes, it may need to be changed and adjusted more, but all in all, the mission is accomplished and we'll see about the results later.

Unexpected Encounter – To Move or Not to Move

Jumping from the past to the present, I'd like to mention something that I completely did not foresee while thinking about the gameplay and of course it happened and I had to urgently find a solution for this problem.

 
The problem was unwillingness of some active players to advance to next levels. They would play, develop their towns, do their researches, attack either map objects (which was ok) or other players (which was not quite ok as it was pretty much farming, which I was trying to avoid in Undecima), and they would refuse to collect any Soul Gems to move on to the next level. The reason is understandable – it's easier to play on lower levels and there are more inactive and weaker players on those levels for raiding and flexing your muscles – but the result was not what I had in mind for the game and besides, it was putting off and even scary for new players to see fully developed towns with players that have 100K+ score located just a dozen fields away from them. 

After some serious brain wracking I had about a dozen of possible ways to neutralize this situation and encourage players to move on. Some of them included putting caps on development and research depending on your Map Level, isolating new players even more, adding restrictions on the number of troops you have on each level, or even advancing stronger players to the next level without collecting them a proper number of Soul Gems to activate a Soul Orb… But I did not like either of them.

… Will be continued next week :)…

The Gameplay - Part 2: No More Farming

Another big factor that was turning away people from playing, and especially new-comers, was blatant "farming". The "farming" in this context is constant attacking of a smaller player by a big player to loot resources of this player and possibly gain some experience by killing whatever defenders the smaller player can gather between attacks of the bigger player.

If this situation happens, the game for a smaller player is pretty much over. You can of course try negotiating a truce with the attacking player or try joining a clan, tribe, or alliance, but usually when you marked as a "Farm", nobody wants to help you or even deal with you and all you can do is to start all over again or just quit playing. 

To solve this problem, I decided to separate novice players from experienced ones. The first step was to place players in locations on the Map according to their score, meaning that if it's a new player and his or her score is 0, there won't be any strong players with high scores around, or at least in immediate neighbourhood. The same technique is used when players are transferred to a new level. The next step was to introduce multiple levels. If your neighbour developing much faster than you and keep harassing you, sooner or later he or she will collect necessary number of Soul Gems and will have to move to another level, leaving you along. Moreover, if you are a weaker, but still an active player, it's possible to create a considerable resistance using Mercenaries and advanced military tactics (i.e. Counter-Attacking and Intercepting) to show your stronger neighbour that farming you is not a good or at least a profitable idea. 

All these means did not eliminate the risk of being farmed completely, but reduced chances of it happening quite significantly, giving every player a chance to play and enjoy the game.

The Gameplay - Part 1: One Player - One Town

At the same time as I started programming and testing some theories on how the game will work, I was all the time figuring out its gameplay. The gameplay is the most contributing factor for the game's success and it was the only area where I could compete with big guys who had whole teams for designing, graphics, and programming. The main concept of any gameplay of course is that the game should be interesting. And this interest should last for a period long enough for people to get attached to the game, so they will keep playing even after it becomes a bit boring and tedious as anything does what we do on the daily basis.

 

One of the ways to do it was to eliminate as many annoying or unfair factors as possible. Something like an extensive macro-management of your empire, where you build your town; you develop it, colonize or conquer another place and then do it all over again, and again, and again. And after you do it twenty times, it's not fun anymore, but you have to keep growing as otherwise you would be destroyed by the guys who have more towns, villages, and castles than you and the game starts taking more and more time, giving you less and less entertainment. So, after a bit of a pondering about how to fix it, it was decided – one player can have only one town.

 

This decision presented a few new challenges to solve, but at the end I decided to split the whole area into cells with the size of 5 x 5 fields and each cell to be a domain for one player. All cells would contain the same set of map objects, but located randomly (as well as player's towns) to create a general picture of a random map, which would give at the same time the same opportunities for all players.

What's in a Name?

I don't remember now when exactly the name "Undecima" became officially the name of the game – it took me quite a while before I came up with it. I have decided right away that I'm not going with any "generic" game names like "The Age of Dragons", "The Clash of Giants", or "The War of Heroes" – there were too many variations of that kind in the Internet already and I wanted something unique. 

So, my next attempt was the "Middle-Earth" way – something like Elandor, Oarvind, or Meaneer – something that sounds like the name of a fantasy kingdom. Having together A and E (like Evealore) would make it even cooler as it would sound a bit more "Elvish". But again, all these names were lacking some substance; it wouldn't make much difference whether it's Evealore or Evaelour as neither mean anything to anyone.  

My last attempt was to use something from a different language; I played with some languages and gradually descended to Latin. At that point I already have an idea of separating the game into multiple levels, but wasn't sure into how many levels exactly. Again, I wanted to have some "unusual" number, and the first number that I couldn't associate with any other game I knew was eleven. I tried "Eleven" to see how it sounds in Latin – it was Undecimo - liked it, changed the ending to a feminine form and Undecima was the name.

The Heart of the Game

Deciding finally on the set of tools that I'm going to use was comforting but there was still a really big question, which I haven't addressed yet and which was really bothering me – how on the Earth all these games work? I mean, you start doing something in the game, you log off, then log in and it's all done. And presumably it's all happening in your browser without your involvement (updating later a database somewhere on the server). 

Well, I have to admit that if it is indeed somehow client-based, then I still don't know how it's done and what the secret is. Understanding that nobody is going to share this secret with me (but still unsuccessfully trying to Google it), I spent a lot of time wrecking my brain and trying to figure it out, but all to no avail… It was either extremely inefficient or just was not going to work at all. To let you understand better what it is all about, let's see an example: 

If you are sending your troops to attack somebody, it's going to take some time. When you launch this attack, a new task is created in the database and it's supposed to finish after some time. I don't want to wait all this time, so I log off, do something else, log in again tomorrow and can see that the battle happened when it was supposed to happen and your troops are already back home. The question is what made it to happen?  

The only way I could see it's happening purely on the client-side is to execute all pending tasks for a user at the moment when he (or she) logs in the game, back-dating all tasks with whatever date-time they were supposed to be executed and recursively iterating through tasks that depend on other tasks (e.g. returning your troops home). That would work in theory, but there would be so many complications, that in practice it would be totally inefficient.  

The only way I could see it happening is to have some external and independent mechanism that would be monitoring all existing tasks and when it's their time, pull them out of the database, execute them and update the database again. This mechanism will be controlling all processes happening in the game, and it will become ultimately the Heart of the Game. The decision was made again and I started working on the Undecima Task Manager. 

A downside of having an external application of that kind and why I actually tried so hard to figured out how to do it all on the client-side was the fact that now I'll have to hire a whole dedicated server to run this application and the cost of hosting this project would jump up hundred times comparing to a simple web-app that was initially in my mind.

What Language Do You Speak?

Before starting any actual development, I wanted to try and see if it was possible at all for me to create a game of that kind. It may sound very plausible for some people as I stated earlier that I was a programmer at that time, but there is a vast difference between commercial programming and game programming. I have created a few games before, but they were all desktop mini-games and hardly could help me in developing Undecima.

 

The first thing I noticed is that most of the browser games of that kind are written in PHP, which I knew very little and didn't like much. Every time I had an encounter with the PHP code, it looked to me way too messy, comparing to C# code. Maybe I just happened to see the work of messy PHP-programmers all the time, but that was my impression and even though I could read most of the PHP-code, I couldn't write it and starting a new language was not exactly in my plans.

 

Another argument I had was about databases – if I go with C#, then it will be MS SQL Server and if I go with PHP, then it will be MySQL. Two databases are very similar and use almost identical script language, but MS SQL Server is licenced (you have to pay for it) and MySQL is free. It is of course the matter of habit and preference, and in my case, the preference was clearly with MS SQL Server, which pushed the possibility of using PHP even further away.

 

So, after some consideration and finding more excuses for not starting with a new language that I didn't like too much, I decided to write a browser strategy multiplayer game in ASP.NET using my favourite C#.