Tuesday, 26 April 2011
Move along there, move along, there's nothing to see...
Still thrashing out the server side of things (eg, you can now ban or kick players) so no pretty pictures to show you ATM. Keep checking though, I'll keep you posted!
Friday, 22 April 2011
Spaghetti Bolocscodi
*pant, pant* Finally managed to get the lobby system functional after much hair-pulling-out. At one point I actually had 5 IDEs all open at once trying to tie everything together. It works like this;
The player goes to the log-in page and is directed to a lobby applet. From here he can choose to join a game or start a game. If he starts a game a new game server is downloaded onto his machine and fired up, informing the central server as it does so. Now the player's machine has become a server, it appears in the central server game list and other players can connect to it by choosing to join the game from the lobby applet. If they do this, the client applet is downloaded from the central server and connects to the game server. Simple, no? *cough*
Fortunately the game server is very CPU light, so a player can both host a game and play in it without any problems.
The player goes to the log-in page and is directed to a lobby applet. From here he can choose to join a game or start a game. If he starts a game a new game server is downloaded onto his machine and fired up, informing the central server as it does so. Now the player's machine has become a server, it appears in the central server game list and other players can connect to it by choosing to join the game from the lobby applet. If they do this, the client applet is downloaded from the central server and connects to the game server. Simple, no? *cough*
Fortunately the game server is very CPU light, so a player can both host a game and play in it without any problems.
Monday, 18 April 2011
New server under test
Phew! The new server is now up and running and I'm currently combing through it looking for gotchas. It's much simpler than the last version, a whole lot faster and it uses less memory. So far, so good!
Saturday, 16 April 2011
Garbling with TCP
I'm still plodding along with the new server and tinkering with the landscape meantimes. I'm pretty happy with what I've got so far; a good variation in terrain with some nice scenery - like the valley pictured which I'm using as the new spawn location.
The new server will be TCP/IP+disc based rather than HTTP+DB, so it should be an awful lot faster.
The new server will be TCP/IP+disc based rather than HTTP+DB, so it should be an awful lot faster.
Wednesday, 13 April 2011
More terraforming
Given that I have to re-jig the server anyway, I'm restructuring the landscape generation code. While I'm at it I'm giving the landscape a bit more variation. To help me out I've knocked together a 'satellite camera' *ahem* for a good overview. In the game each of those squares is 320 meters across, so this part of the map is about 6km by 4km. What I'm looking for is a good mix of farmland, moors, mountains and seas, with plenty of interesting islands. Memo to self: Must add ships!
The moor the merrier!
I got tired of depressing test results - I guess I'm going to have to rethink the server - so to perk myself up I added some moorland. Farms on moorland are much less efficient than lowland farms, so there's a trade-off between building in the lowlands for good productivity or building in the highlands for a good defensive position. I also realised I could do some cheap texture smoothing which has reduced (a bit) the jagged edges between landscape textures.
Sunday, 10 April 2011
Further closed test results
Hum. It's looking like my current server setup is not going to work very well in the real world. It's OK for testing and fortunately I carefully kept the server logic separate from the network code so its not too hard to migrate to another solution.
The two major problems I've found are;
Latency - varies from 300ms to 20000ms. Yup, you read that right, a 20 second delay in the worst case. It only happened once or twice but that's still way too often.
Data integrity - occasional random losses of data. Never happens on the dev server, but occasionally on the deployment server a building or two will just vanish without reason. This only happens when there are no players logged on so it's not super serious, but it bodes ill.
The latency issue is the one that annoys me most. I can understand the server taking a few seconds to initially deploy itself, but a constant latency of 10-20secs? What the hell are they doing with my data? Bouncing it off Uranus or something? (mutter, grumble).
The two major problems I've found are;
Latency - varies from 300ms to 20000ms. Yup, you read that right, a 20 second delay in the worst case. It only happened once or twice but that's still way too often.
Data integrity - occasional random losses of data. Never happens on the dev server, but occasionally on the deployment server a building or two will just vanish without reason. This only happens when there are no players logged on so it's not super serious, but it bodes ill.
The latency issue is the one that annoys me most. I can understand the server taking a few seconds to initially deploy itself, but a constant latency of 10-20secs? What the hell are they doing with my data? Bouncing it off Uranus or something? (mutter, grumble).
Thursday, 7 April 2011
First closed test results
OK, we just finished the first closed test and it was an spectacular success, though not quite in the way I was expecting...
First off, the server crashed with a totally inexplicable NPE just before the test - not a good omen! I stuck a band-aid over the place and restarted the server. No further problems.
My co-tester, Mick, was half a mile away on a linux machine, I was using XP.
We started the test and all went well. We could both see each others units moving around. Though the ping was really bad (~500ms) the game was designed with this in mind and still ran smoothly. On to testing the chat system. Press 't', type chat and press enter. Flawless. Then disaster struck! Mick forgot to press 't' before typing a message. Unfortunately I'd forgotten to disable the hot-keys I use for testing, so when Mick hit the 'n' key a new enemy village began spawning right next to us and started attacking us. Despite using another hot-key to instantly spawn units we both ran out of gold pretty quickly and had to fight hard to keep them off. Then some bears attacked. Mick fled with his 6 remaining archers - straight into the path of another enemy's cavalry troop who'd come over to investigate. Doomed! I wish I'd videoed it now, it was very entertaining!
There's plenty of flaws in the thing still, (the most annoying is the way it gives you an extra king every time you log on) but overall I'm pretty pleased. It seems stable and playable.
My biggest worry was the quota usage. Setting up and running the test used a whopping 6% of my daily bandwidth quota. Admittedly most of that was the repeated ~5MB download of LWJGL, the game and its resources. This a problem which client side caching should much reduce when I enable it.
My CPU usage was 3% of daily quota for a fairly short test. This is a much bigger problem to fix. There's a lot going on in the game so it needs a lot of CPU, but I'm not going to worry too much. I wrote the code for clarity rather than efficiency so I'm sure there's a lot of optimising I can do. If I really have to I can buy more quota anyway. Let's hope it gets that popular!
First off, the server crashed with a totally inexplicable NPE just before the test - not a good omen! I stuck a band-aid over the place and restarted the server. No further problems.
My co-tester, Mick, was half a mile away on a linux machine, I was using XP.
We started the test and all went well. We could both see each others units moving around. Though the ping was really bad (~500ms) the game was designed with this in mind and still ran smoothly. On to testing the chat system. Press 't', type chat and press enter. Flawless. Then disaster struck! Mick forgot to press 't' before typing a message. Unfortunately I'd forgotten to disable the hot-keys I use for testing, so when Mick hit the 'n' key a new enemy village began spawning right next to us and started attacking us. Despite using another hot-key to instantly spawn units we both ran out of gold pretty quickly and had to fight hard to keep them off. Then some bears attacked. Mick fled with his 6 remaining archers - straight into the path of another enemy's cavalry troop who'd come over to investigate. Doomed! I wish I'd videoed it now, it was very entertaining!
There's plenty of flaws in the thing still, (the most annoying is the way it gives you an extra king every time you log on) but overall I'm pretty pleased. It seems stable and playable.
My biggest worry was the quota usage. Setting up and running the test used a whopping 6% of my daily bandwidth quota. Admittedly most of that was the repeated ~5MB download of LWJGL, the game and its resources. This a problem which client side caching should much reduce when I enable it.
My CPU usage was 3% of daily quota for a fairly short test. This is a much bigger problem to fix. There's a lot going on in the game so it needs a lot of CPU, but I'm not going to worry too much. I wrote the code for clarity rather than efficiency so I'm sure there's a lot of optimising I can do. If I really have to I can buy more quota anyway. Let's hope it gets that popular!
Tuesday, 5 April 2011
New enemy placement
In addition to the villages (mentioned in this post) I've added hamlets like the one shown here. I did this because villages are pretty tough to beat, but you can beat a hamlet with just two units - if you're careful!
Sunday, 3 April 2011
Oy! Referee!
Just like in real wars, there's a referee that tries to break it up when things start to get rough. And just like in real wars both sides turn on him and obliterate him before going back to killing each other.
Only kidding! Referees can't actually do anything except move around. They're there so players know that a moderator is keeping an eye on them. They're also very useful for checking AI behaviour without getting attacked!
Only kidding! Referees can't actually do anything except move around. They're there so players know that a moderator is keeping an eye on them. They're also very useful for checking AI behaviour without getting attacked!
Subscribe to:
Posts (Atom)