Well I guess with a title like that I should start with a little back story.
Many of you will already know this, but for the last 5 years my day-job has been as a developer for an MMO known as Omerta. It’s a small web-based Mafia MMO but it’s certainly been an interesting place to work.
After 5 years my journey there is about to come to an end. I have recently been offered a new job, with interesting new challenges which I have decided to accept. My time at Omerta will officially end on the 5th of March, after that I will no longer be involved in the project beyond occasionally offering a brief bit of guidance to the remaining development team.
It has certainly been an interesting few years overall. When I started at Omerta, I had actually never played more than a few hours of the game. I also did not know the language the game was written in all that well, but they gave me a chance to see what I could do.
It didn’t take me long to pick up the language or to learn about the game itself, I guess playing MMO’s for so long in general helped me there. As the years progressed I created and altered many features of the game as well as rising in the pecking order of the development team to my current position as the lead developer of the project.
One interesting feature I worked on in the early days was a flash shooting range for the game. At that point the game included a character stat known as kill skill, and the idea was that players would use the shooting range to increase that stat.
The reason it stands out in memory is that it was a challenge for me personally. At the time I had only been involved in the game for about 3 months, I was still brushing up on my PHP skills and I had NEVER played with flash at all. So having to make a flash application that linked into the games database was interesting to say the least. I kinda like jumping in at the deep end.
That feature was ultimately removed from the game in a later version due to the fact that we also removed the killing skill stat from the game. So many of the games bugs and balance issues were linked to killing skill there was just no way we could keep it.
Another time I jumped into the deep end was when I got assigned to the companies second game project Roswell BC. This was a very interesting project to work on as it was being built completely from scratch and this allowed me to get involved in the design side of the company. I had the opportunity to alter and guide certain elements of the games design.
Unfortunately that project is now on hold, but once it’s completed it will be great as there is still nothing like it out there.
It was around that time that work on the next major iteration (3.0) of Omerta was in full flow, so it was all hands to the development pumps, thought I did keep my hands in the design side of things. I had developed a bit of a bug for design. It was a mad crunch the final push to 3.0 but it was worth it in the end.
After 3.0 finally launched and we finally worked out the balance out all the changes and nailed down all the bugs, there was a bit of a lull in development. This allowed me the opportunity to really flex my design muscles, I came up with the ideas that would later become the core of the Deathmatch version of Omerta.
Deathmatch is however what I will remember most fondly, as this was where I had the opportunity to really use my design skills. Deathmatch had been a long running faster version of the game, but it was taken off-line for about a year. When the then designer left the company, I took over the role of lead designer and well as my role as developer.
It was then that I resurrected Deathmatch, but this time it was also to be the games public test server. Here I would launch several experimental features & test changes to already existing system, without the risk of disturbing the main game.
All of my experiences in design were blogged over the months in Thirteen1 Magazine and appear here on this blog. I will not bore you by going over them again, you can just look in the Game Design category if your interested in knowing more about that.
SO as you can see its has certainly been an interesting journey over the year and there are a lot of things I will miss, but times change and so do people. I am ready for a new challenge in my career and that is what has lead me to move on.
My new job is different, It will still be as a developer but on software for the Higher Education sector and not on games. While that may sound boring in comparison to working in games from the development standpoint it not all that far removed. All it means to a developer is that the database of facts and figures I will be manipulating will be a students personal details not the stat’s of a player’s character.
The design side of things may by a little dryer, but there is nothing to say that I can’t redirect my creative energies elsewhere at the end of the day. I’ve always had idea for other games running inside my head, perhaps now I’ll be able to get some of them down and finished. I have a couple of XBLA ideas that have been semi brewed for at least 2 years now.
So yes its the end of an era, but it’s also a very interesting looking future.
Happy New Year to all you Gangsters from Omerta, hope you all had an enjoyable Christmas break and are looking forward to what this year has to bring.
Obviously as I was also enjoying a well deserved holiday, there is not a lot to report on the design front this month (not that I feel is at a level that can publicly be discussed anyway) so I thought I would instead take a look back at some of the stuff that I added to the game last year.
One of the first changes that I tried was randomized events, little weekend long events where I changed certain factors in the game. These varied from vastly increased in-game profits to reduced travel times. The lesson I learnt from that one was interesting, the players like randomization but only to a certain point.
Some of my random changes went a little too far for them, causing complaints from the players that I was interfering too much in the gameplay. This was a fair point, change is good but without stability you can’t plan, and as planning is a such a key element of the game I put the weekend events on hold.
These were shortly replaced with a scheduled weekend event, now every weekend the players on Deathmatch receive a bonus to their rankpoints on a Saturday & to their profits on a Sunday. The bigger events will be making a return this year, but they will not be simply based in weekends.
However so that the players will be able to plan for them and enjoy them fully they will be announced further in advance, I hope to be able to announce a whole months events in advance.
The second thing that I changed was the Risk:Reward ratio on killing. It was a few months into my time running Deathmatch that I discovered something surprising. When in a earlier version another designer decided to remove Killing Skill (KS) from the game, due to its overall flawed nature, he removed it in an equally flawed way.
You see despite being completely flawed in the games back end, KS had a visual element that the users counted towards their characters progression. No thought was paid during its removal to the players loss of this visual element, the perceived loss of a reward for a killing other players.
This lead to a reduction in the number of kills, because the players believed that the risks no longer outweighed the rewards. So to attempt to redress that balance, I added a new reward to killing. Now kill attempts reward the player with extra rankpoints for kill attempts and to reduce the risk slightly I removed the family witness statements.
The overall outcome was a small increase in killing, which is what I was aiming for. I may be re-evaluating other elements of killing this year but for now I think its in a good place.
Obviously the biggest thing of the last year was the full rewrite of the family system, this proved to be a very complex monster to work on. It all started in answer to a previously made change to the family system, where the expanding system was replaced with families of static size.
This took away another large element of player progression. As a family got stronger in the old system it would get bigger, it would have to buy new HQ spaces to manage its members. In the earlier version however they were locked to set sizes which meant that a family never felt the growth that it had before.
So to add that feeling back into the game, I retooled the system to include a levelling system similar to the one experienced by the players themselves. For each action a family member now does the family will receive an amount of family rank-points based on that action. This will cause the family to grow in strength and as they pass each level they will unlock new features, such as headquarter size increases or better car crusher.
But it wasn’t the smoothest of starts, there were issues during development that caused the systems launch to be delayed and then after release there were balance issues. But after a few months of tweaking the system was in a state where almost all the player-base are happy with it.
There are still further plans for it, but they needed the system to settle in and show how it would work.
So it was an interesting year, but now its time to look to improve on those. Next month I hope to be able to explain exactly how I intend to do that.
This month has been a busy one for me. In the earlier part of the month a small bunch of disgruntled players decided to cause problems for the fair players.
When you are working with anything as complex as an mmo, it is impossible to find all the bugs. While we always try to stay on top of them when your dealing with many many thousands of lines of code, sometimes they do slip by no matter how hard you try.
On those occasions we rely on the players to tell us as they find them, the same as any other mmo developer. Thankfully more often than not the players do exactly that, however on this occasion the player did not.
One group of players found a bug that allowed them damage another players account, and decided to use it. Before we knew it the problem was spreading like wildfire. Quick work was done to solve the problem, what was really difficult was refunding all the players unfairly affected by the abuse.
Thankfully we found a way and that was all sorted.
Once we got all that sorted, I was unfortunately was called away from the office for Jury Service. When your registered to vote here in the UK, you can also be called up to serve on a Jury.
This means I have had little time for designing this month, however all that has gone on in the last month has made me think about the concept of crime and punishment.
Now being based in a criminal world, we overall deal with crime and punishment all the time. You can go to jail for almost any crime in the game and how long you will spend in jail differs based on the severity of the crime. Stealing a car can see you in for a couple of minutes, while a Organised crime can put you behind bars for hours.
But that’s not the context that I’m on about this time. Its cheaters and abusers in the game and the question of what to do with them.
Now at the moment we have a basic scale of punishments
Minor Rule breaking – we will remove a percentage of the players statistics
Major Rule breaking – we Admin-Kill the account
Repeat Offenders – we IP ban them from the games servers
Now these rules may be a bit harsh, but they are not taken lightly. We never go as far as Admin-Killing an account without being sure that an account has cheated.
This however had one slight drawback, that need for absolute certainty did for a while create a large grey area for cheaters to hide in. They would make their cheats look like fair (but high skilled) players.
We would still catch them however it would just need more effort. That is why when I took over Deathmatch, I decided to take a look at reducing that grey area, as well as looking at a new way to deal with them.
To cut the grey area I actually took a little gamble. You see the grey area they were hiding in was that of the skilled players, the ones that were at the very top of the game. If I tightened up here there was a chance that it would result in some genuinely skilled and fair players would get caught up and punished.
Thankfully this gamble paid off. We did actually hit a few of those players, but they actually were willing to accept the hit if it made the game fairer overall. That system was the online time limit, which has now be expanded across all the versions.
The second way of dealing with them was slightly different, that was to make them socially unacceptable.
Oh sure nobody in the game liked cheaters, but some families would turn a blind eye to the fact that a member of their family may have cheated. This was quite difficult to do anything with when I first took over, but there was always a plan.
You see, I had always wanted to make changes to the families in way that when a cheater was found in their numbers, they would all suffer in some way. When I overhauled the family system, I worked that concept into it from the start.
Now when a cheater is found in a family, the family will take a punishment as well when they are dealt with. This has lead to less families willing to turn a blind eye. Seeing as so much of the end game revolves around families, it is a very good social deterrent.
Obviously we are not done yet with cheaters, there are always new ways to route them out and get rid of them – but unfortunately we have come to the end of my write-up this month. With luck next month I will be able to get back to design talk again.
So another month has passed since we implemented the new family system into the DeathMatch version of Omerta and things are still going well. So well in fact that system has already been moved from Testing to Production. It is now active on all but one of the live servers.
Once again changes had to be made to the scale for family levelling. Seems that there is more difference between the servers than I thought, so things were a little slow for production. That was quickly solved.
Now last month I mentioned that there was still one element that needed to be taken care of, a bonus for smaller families. This is so that smaller families actually have a chance to make it to the maximum rank.
Now when I initially designed the system the plan was to have the bonus be a simple case of, if your family was below half of the maximum the family can be at that level you would get double Rank Points for your family.
So if the maximum size of your family could be 50 but you only have 25 members or less, then the bonus is active. However when it came time to put the test version out there I realised it was flawed and went away to work on a new version.
The primary problem with it was the simple fact, that while this bonus would have been useful in the beginning level by level this benefit would be steadily eroded into worthlessness. This would simply have been a side effect of how the scale of each level for the family itself grew.
A secondary issue is one of fairness, if I had made the bonus activate the way I intended, then a family with 24 members would get the bonus but a family with 26 members would be denied. This was not acceptable.
So what was needed was a bonus that would scale itself both in number of members and in relation to the level of the family.
I tried a few different experiments, that all showed that the solved one of the problems but not the other, One that even added a whole new one without fixing them. But that’s what happens occasionally in design.
However I eventually stumbled across the final solution.
The final solution was to make the bonus variable, but still based on the number of members and the size of the HQ they own, rather than the maximum amount of members they can potentially have.
The Basic theory was as follows
(Size of HQ – Number of Members) * Base Bonus = Final Bonus Value
This will make the bonus completely scalable, and will mean that a family missing only 2 members gains a bonus the same as a family missing 10 members.
It also gives families that are always going to be small, a reason for buying the HQ Upgrades they previously had no use for. This system means that upgrading your headquarters for small families is actually a upgrading their bonus instead.
For example: (These figures are an example – Not the final calculations)
Base Bonus = 1%
Family Members = 15
When the family has a HQ of 25, that would give a bonus of 10% (25 – 15 = 10, 10 * 1% = 10%)
When they upgrade to a HQ of 50, that would give a bonus of 35% (50 – 15 = 35, 35 * 1% = 35%)
So as you see that fixes the issues of it becoming pointless after a few levels as the increased bonus as the levels progress will fill in the gaps. Also it solves the some families getting it and some don’t issue.
Obviously I have not printed the exact calculations, that will remain hidden. However I have been carefully going over these calculations again and again to make sure that the bonus does not surpass having a full family.
Well I guess that’s it for this month. Right now I actually have to go do some development work, as much fun as designing this stuff is, someone has to implement it.
This month has finally seen the implementation of the new family system into Deathmatch, and I couldn’t be happier to have it finished. Thankfully the delays seem to have been worth it, and ultimately mean the version we’ve pushed out to the player base is a lot more polished than we originally hoped. So far there have only been a few minor errors in the system, which have all been fixed fairly rapidly.
However, there is more to any new system than bugs. Balance is another key factor, but it’s also one of the hardest to do in the design phase. The problem is that, no matter how detailed your statistics and how many scenarios you test, until they are used in the final system you will never exactly how things are going to work.
This is one area that I have had to pay careful attention to over the last two weeks.
When I first worked out the levelling scale, it was done using historical data. I used a simple calculation to work out the how many experience points a family would need at each level to reach the next. That Formula was, “Average amount of RP (rank points) a player can gain per day X Number of members the family can hold X Amount of time Intended for the level to last”
This gave me the first scale to work from. After making this system live in the Deathmatch version, it became readily apparent that something was wrong with the scale.
Thankfully I had implemented some statistics gathering with the live version, and after quickly checking those figures I realised my historical data had resulted in an Average Daily RP that was higher than what the players actually gained. This resulted in each level taking longer than intended.
So, taking the new figures into account, I made the first alteration to the scale. This made the levelling progress at the intended speed, however something was still wrong. Some levels progressed slower than others, and while it was ultimately balanced by the slower level been followed by a quicker one, it was by no means ideal.
This again took me back to the spreadsheets to work out exactly why it was happening. After looking over it carefully I noticed the jumps, and more importantly the cause. The cause, as it turned out, was the increase in the number of family members at certain levels. This was making the gaps between the previous level and levels that increased the family size seem unnaturally large.
Unfortunately, where the first balance issue was automatically solved by changing the calculation and generating a new scale, this would need careful manual manipulation. What I needed to do was smooth out the levelling curve for better rounded progression.
So, after a day’s work and manually moving a few rank points from one level to another, I had the scale running smoother. There was even a bonus benefit as a result of this change – it made the early levels of the family system faster at the expense of making the later levels slower. From a playability perspective this means that the early levels provide a must faster feeling of gratification for the players, something that is always good. Conversely, as the levelling slows down, it helps build the epic feeling of getting a family to maximum level.
All that remains for this system to be completely balanced is the Small Family Bonus. This bonus is supposed to help the smaller families and allow them to compete (to a certain degree) with the larger families. But in practice this has only worked for around two family levels.
As I haven’t finished working out exactly how to solve this problem, I think that would be a natural point to call time on this month’s look into my work on Deathmatch. Hopefully I’ll have a solution to the small family bonus to discuss next month.