Friday, November 28, 2008

A new way to round - rand_round

So in grade school you are taught the basics of rounding. If the decimal portion of the number is < .5 round down to the integer so 5.3 becomes 5. If it is >= .5 round up, so 5.8 becomes 6.

This is well and good if you are doing something that has an even distribution after the decimal point. But lets say that you are doing continuous small adjustments on a value and it is unlikely to be an evenly distributed set since the calculation for the adjustment will typically be the same.

An example senerio that got me thinking about this is related to a game I am working on at constantsail.com. Every minute 1 food is consumed for each crew member on a ship, but I want to do a smaller time slice of every 6 seconds which is 1/10 of a food per crew for that interval. Food is an integer in the db, so it must be rounded off in one way or another. If we just used the round function in mysql, and we had two crew members, I would be subtracting round(.2) ever time which comes out to zero. What I really want is it to return zero 80% of the time, and one 20% of the time, so in the long run, it still ends up being 2 food consumed for the two crew for every minute.

To do this I take the result of rand() which returns a value from 0 to 1 and if it is less than D (which is the decmial portion of the value we are rounding) we add 1 to the floored value of our original number, else we just floor the value.

The equation is:

function rand_round(x){
D = x - floor(x);
if(rand()<D){
return floor(x)+1;
}else{
return floor(x);
}
}

Thursday, October 9, 2008

Head and tail - super large outputs and inputs

If ever you are dealing with a really large file in head (1GB+) and you need to grab a large segment of it (such as half the file), don't use -n option to get lines. Instead, do ls -l to find the the size of the file in bytes, figure out how many bytes you need (perhaps a portion of the of the total bytes), and then call head -c THE_AMOUNT.

The reason is, I discovered that if you try and do it by line count, head needs to read through the file and find ever new line marker before outputing. This locked up a pretty powerful machine for over a day, and still didn't output. Using byte count was done in a a minute.

UPDATE:
So one of the problems I am having is that head really doesn't start outputing until it is finished, so I create a php program do output the top portion of a file:

Monday, November 26, 2007

Politics And Small-Fry smashing in Massive Multiplayer games

Inselkampf is a game of diplomacy pretending to be a game of war. It mimics real politics in many ways. Small nations get trampled on so that the big get bigger, and the big nations have continual face offs that lead to few actual conflicts. When conflict occurs between big nations, there are massive casualties on both sides, lending itself to more future diplomacy to avoid such conflicts. In the end it is just a battle of who can be the most powerful without any direct conflict.

The problem is also inherent in all games of this nature. It is a massive multiplayer game where players join all the time and those who have been most active and join the earliest get a huge advantage. The losses of the big players going against each other is not worth the rewards and so the little guy gets trampled upon. If you took a game like StarCraft or some similar pure war game, and made it continuous and where thousands of players could join at any time, you would end up with the same thing.

You can even reduce it down to a 3 player war game. The usually result is the two players will team up against the weaker one, and whoever gets the most out of the deal will end up winning the final 1v1.

When you get enough players together, and put them at pure competition to each other, politics will always be the end result, as the one who gets the most players/power on their side will be the winner.

The only games where you will see a complete lack of politics is 1v1 games, and games where working together doesn't help each individual player. Poker is an example of that, but even then, if there was some sort of secret communications allowed, probably there would be a similar situation.

So this is a common problem in wargame design. The only solutions I can see if you were to design something is to limit how much players can work together, but that really is not much of a solution. Crippling players abilities to bake a game concept work is odious.

So lets start with a simple goal: make big players fight each-other rather than small fries.

One thing is to spread the world out so that the cost of traveling to the small fries gets larger as they join. This still doesn't help the infrequent player who joined early, but if they get knocked out early, they join the small fries off in the distance.

Another way to help the small fries, is to give them a military boost upon joining. So lets say the current average number of fighters per player is 1000k. When a new player joins they get that many units. This could also be set to the median if some players are enormous compared to others.

You could also hurt the players that have large stockpiles, by causing soldiers to die out if they are not used after a certain amount of time. A similar way to do this is to increase the cost of expanding. Civ4 does this with maintenance costs for far away cities and when you have too many cities.

Both the helping out of small players and the hurting of large players also have problems. It makes it so the fun tapers off for big players who can't maintain growth. Giving bonuses to small players creates an inflation factor where troops become worth less and less, and also new players will have huge armies that may be unmanageable until they learn the game better.

None of these tweaks will effect political structures that are formed to consolidate power, but only effect the small fry clobbering by individual players. Small coalitions of players will still be weaker compared to larger ones, and consolidations will still happen as the smaller alliances of players cluster together to make themselves not so much of a target.

I suppose this problem is as old as man, and probably older (multi-cellular vs single-cellular). A cluster of players working together will always crush the smaller players. The strong will always crush the weak. Any game design that goes against these principles will require endless hacks and tweaks to stamp them out, and the end effect may be a game that isn't much fun. The reason is that if the strong can't crush the weak, the weak will never aspire to be the strong.