>:XX

I've always been afraid that the government's silly filtering scheme would go ahead simply because the vast majority of Australians don't care enough to do something about it. In fact, I'd say the vast majority of Australians don't even know the government is planning to implement such a filter!

There has been a somewhat vocal group of IT professionals, privacy advocates and so on who have been opposed to the filter from the start, but nobody has really tried to educate the general public on the scheme, or why it's such a bad idea. It might be obviously dumb and unworkable to an IT professional, but the general public doesn't understand the technical roadblocks to such a system, and also why such a system is a fundamental block on our right to freedom of speech.

But now, there's some good news. A joint media release, signed by numerous liberties/freedoms bodies has just been made, where the body (including the Australian Library and Information Association, GetUp!, Civil Liberties Australia and others) have promised to start an advertising campain to educate the public on the scheme and try to get some media coverage in the general media (rather than just the tech- and IT-specific publications I've seen it in so far).

That's gotta be a good thing, right?

One of my big plans for War Worlds is that it'll be heavily multi-player based. I've recently hit a bit of a milestone to that end, and this is what I'm posting about now.

The basic architecture of the game is based on what I learnt from the "1,500 archers" post on Gamasutra some time ago. Basically, the game is "turn-based" but the turns are so fast that you don't really notice and it "feels" real-time. The "simulation", as it were, runs at a fixed 5 frames per second, and each command you issue to a unit is queued up on the simulation thread for two turns in the future. Then, at the end of the turn, it sends an update to the peers on what you're planning to do. Once all players have received notification, the two turns should be up and all players will execute the command at exactly the same time. And since all the simulations are the same, the game should (theoretically) stay in sync.

But before I got to that stage, there was a lot of ground-work that I had to lay. The first thing I did was create a simple "lobby" server, which is actually just an ASP.NET website with a database back-end.

So, when the game starts up, you get the main menu. From the main menu, if you click "New Game", you get the screen that I've shown in the following screenshot (I use CEGUI as my GUI framework - the skin is one of my own creation):

So, when you click "Login", it asks you for a username/password and once you've typed that in, it'll make a request (via cURL) to the lobby server to login and register the game.

Next, another player wishing to join your game would click on "Join Game" from the main menu, where the game asks for his username/password, and then it returns a list of all the games that are currently available to play. The following screenshot shows the game we started above as being listed:

So you click on the game you want (obviously the fields I've chosen in here are only temporary and will definitely change as the game develops!) and click "Join Game" at which point you get the "New Game", but now you can see that both "user1" and "user2" are there:

From here, you can see that you can chat with the other players. In the future, you'll be able to adjust things such as your player's colours, AI players and so on. You can also select the map (more on the maps in another post). Once you're ready, you click the "Start Game" button. Under the hood, the game communicates your readiness to the other players (you can see in the screenshot above that "user1" has clicked "Start Game" and is marked as "ready").

Once all players click "Start Game", the game starts up for real and the map is loaded.

Once in game, the simulations talk back and forth to each other about each turn and what commands the player has executed in that turn. As I mentioned, each turn lasts for 200ms (200ms = 5 turns per second) and the kinds of commands that are executed are things like "create entity" (e.g. create a new tank, new missile, new building, etc), "move", "attack" and so on. So when you click a unit and ask it to move, there'll be a 400ms (approx.) delay before it actually happens. In a real game, you don't actually really notice, because the unit will have a "moving" or a "yessir" kind of animation/sound effect.

The screenshot below is from within the game. You can see that graphically it's not that much different from the last time I posted about it, but obviously much of the work has gone into the lobby server, the UI and the underlying networking layer...

The communication layer in the game is built on top of ENet which is a pretty low-level wrapper around UDP and provides a reliabilty layer, unlimited packet sizes and a few other benefits.

Currently, the only commands that are implemented is a "chat" command (which you can see being used in the bottom of that screen shot) a "create entity" command (which is used to create the tanks initially - each player in the game creates one tank, and the "create entity" command ensures the tank is replicated to the other players. The "move" command is the most interesting at this point, because that's the main "mechanic" command that I've implemented. When you order a unit to move, it'll move towards it's goal on all player's version of the game at the same time.

It actually didn't take me as long as I thought it would to implement that feature (most of the work these last few months has gone into the UI and lobby stuff) but I'm quite proud of it. I'm sure there's plenty of edge cases and bugs (currently, the main problem it has is that if ping times climb above 400ms, the games will get out of sync, but that's something I can look into later, I think...)

Now the real fun starts and I can start implementing actual game logic. My plan first, however, is I want to port the lobby code to PHP so that I can run it on this web host (meaning the game will actually start to work over the internet, and not just on my development box...) then I can start looking at designing some buildings and unit-creation factories and stuff.

Exciting times! In the future, I'm hoping to talk a bit about the map editor that I'm creating along-side the game, a bit more about the network architecture, as well as my plans for how the game will be released (though that won't be for some time, obviously!)

This post has gotten quite long, and I guess that's my own fault for leaving things so long before I posted an update. But, as I mentioned before, I was overseas for a month (a lot of this stuff I did while I was over in Korea...) so it's been a bit tough to get online as much as I normally do.

I'm sure everybody's heard the news that Google is working on their own "operating system", which they're calling "Google Chrome OS".

They're making a lot of grand claims, such as (emphasis mine):

[A]s we did for the Google Chrome browser, we are going back to the basics and completely redesigning the underlying security architecture of the OS so that users don't have to deal with viruses, malware and security updates.

Which sounds great. All current operating systems have their roots back in the days when the internet wasn't even a glimmer in Tim Berners-Lee's eye, and we could use a fresh start. For example, I like what Microsoft have been doing with Singularity in that respect. But then, in the very next paragraph, you have this:

The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel.

Now, Chrome the browser was little more than a different skin on top of WebKit, and nowit seems that Chrome the OS is going to be little more than a different skin on top of Linux. Are they really just saying they're going to be releasing nothing more than Yet Another Linux Disto^TM? Maybe with Gnome replaced with something from Google?

That would be a major dissappointment.

I've just arrived back in Australia after a month in Korea with my wife. It was a fantastic trip, and I met a lot of my in-laws who I'd never met before.

I got back, though, to find that the forums had become overrun by spammers! Sometimes I hate the internet... Anyway, the spam is all gone and I've enabled email confirmation before you register (not sure why it wasn't there in the first place). I'm also hoping to recruit some more members of the community as moderators, though there hasn't been a lot of activity there in recent weeks. I hope all the spam didn't scare everybody off permanently!

I really want to try and skin the forums like the blog, but phpBB skinning is a bit of a pain. Maybe if I get a week or so of free time, I can give it a go. I think the first step would be to set up PHP on my laptop and get a test system running so I don't mess up the live forums. It also means I don't spend a lot of time waiting for FTP uploads. I think that was the main problem I had last time I tried skinning the forums.

In programming news, I am continuing work on Elium, the RPG game that I've been involved with. I've also done some work on War Worlds, my own pet RTS project. My plan for War Worlds is to build an online community of RTS players where we can hold ranked matches and online events and all sorts of things. Of course, that's still a long way off, but I'm hoping to have some extra news on that front in the coming days.

I'm hoping to blog more and more about my two projects in the future as well. I've been a bit slack, but I've always known that blogging can really help to give a sense of progress to a project. We'll see how we go anyway :)

Visual Studio 2008 Professional doesn't come with the built-in profiler (that's a feature reserved for the Team Suite edition). But that doesn't mean you can't profile your applications! Microsoft actually provides a stand-alone verson of the profiler, which you can use from the command-line.

Obviously, since it's a command-line program, it's not as easy to use as the GUI in Team Suite, but it works, and it's better than nothing. Here's some (very basic) instructions (this is for native profiling, but I understand CLR profiling is also available):

1. Obviously, you need to download the stand-alone profiler, it's not very big. If you have 64-bit windows, you only need to download the x64 version - it includes both the 32-bit and 64-bit profiler.
2. The next step is to enable profiling in your C++ application. In the properties, under Linker/Advanced, make sure "Profile" is set to "Enable". It's probably better to do this in Release mode as well...
3. Open up a command prompt, and set up the path to the profiling tools (it doesn't get added automatically because the path is different depending on whether you want to profile 32-bit or 64-bit). If you install everything to the default path, you can just run:
   
   set path=%path%;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Team Tools\Performance Tools
   
   Or if you want to profile a 64-bit application, append "x64" to the path.
4. Next, you need to instrument your application (I'm assuming you're doing an instrumented profile, sampled profiling is also available). To do that, you use the vsinstr.exe tool, like so:
   
   cd \path\to\my\program
   vsinstr.exe MyProgram.exe
   
   This will back up your executable to MyProgram.exe.orig, and spit out the instrumented version as MyProgram.exe.
5. Use vsperfcmd.exe to start the profiler. You should probably do this from an elevated command-prompt (so it can install the driver). Just run:
   
   vsperfcmd /start:trace /output:MyProgram.vsp
   
   This will start the profiler and write it's output to MyProgram.vsp
6. Run your program as normal. Make sure you let it run for a little while in the part you want to profile (so the slow part drowns out start time, etc)
7. When your program is finished, use vsperfcmd.exe again to stop profiling:
   
   vsperfcmd /shutdown
   
   You should see that it's written out the MyProgram.vsp file.
8. Finally, you can use vsperfreport.exe to generate .csv files that you can analyze in Excel (or whatever). For example:
   
   vsperfreport MyProgram.vsp /output:c:\temp /summary:all
   
   This will output a bunch of files to C:\Temp that you can load into Excel.

I won't go into details of how you can analyze the data (there'll be quite a lot of it!) but if you already understand profiling, it shouldn't be too hard.

As I said, the GUI in Team Suite is clearly better than using the command-line, but in a pinch, this method works, too.