I remember when I was a kid, we had a Commodore 64. My dad bought a subscription to a magazine, and every month, they had this little section of BASIC code that you typed in. After a few months, you had a complete program. I remember copying that program in line-by-line (there was probably a few thousand lines in total). I got all the way to the end of the program without getting bored. But after it was all typed in, and I finally got to run it, it did work! There were bugs!

I gave up at that point, but my dad was more persistent that I was. He must've spent an entire weekend debugging that thing, and finally got it to work. Of course, being only 9 or 10 as I was at the time, I got to take full credit for the program, even though I'd just copied it from a magazine and my dad had done all of the actual hard work, but I still count that as my "real" first program.

The program was a basic database/Excel style thing and used the Commodore 64's built-in record storaging facilities to store data to the tape.

I loved that Commodore 64. I had it for a long time - I think it would've been around 1993 or 1994 that I finally "upgraded" to a PC. I kind of regret now that we sold our original C64, but I guess that's the inevitable march of progress...

I was browsing the news sites today, as I do, and I came across this interesting one.

North Korea willing to hold talks with US

Now, the article itself is pretty standard stuff, but what I found interesting was the photo they have on the right. I assume that article isn't going to last forever, so I've grabbed a screenshot and I've cut'n'pasted it below:

Now, they make out that this is a South Korean soldier using binoculars to look at the North, as if it's some kind of high-tech military equipment or something... well, when I saw that photo, I thought it looked a bit familiar.

On my last trip to Korea, we visited Imjingak. It's open to tourists and there's a resturant, a lookout point, some statues and art and all sorts of stuff. There's actually this monument to a train which used to run from the very south of the peninsula right up to the north which (obviously) no longer runs. The inscription on the monument to the train is quite moving.

Anyway, here's a photo I took while I was there:

This is actually the best photo of the things I wanted to point out. If you look at the top of the photo, on the roof of the building, there's all these tourists. And what's that they're using?

Yes! It seems the tourists are using the exact same binoculars as that "soldier"! In fact, if you zoom in on the article, you can actually see the slot where you put the coins in the binoculars:

 

Now, my theory is that, in Korea, you're not usually allowed to take photographs of military installations. So I guess they just found a couple of off-duty soliders (even when off-duty, the soliders are not allowed to take the uniforms off) and took them to the tourist lookout to take a photo. It's kind of ruined the illusion for me, though. You often see photos like this and now I'll be forever questioning the legitimacy of them. A sad day for me.

...

Eh, I'm sure I'll get over it!

(This post is basically a duplicate of one I posted over on the gamedev.net forums, just for posterity)

I've been thinking about this idea for networking in Elium for a while. At this stage we haven't even thought about networking the game, so whether it'll become reality or not is something we'll have to see...

Now, the basic idea of the combat in Elium is that it's mostly fast-paced and close-combat: swords & shields kind of thing. You'd have basic attacks like slash left, slash right, stab low, stab mid, etc, as well as corresponding blocks: block left, block right, etc. You'd also have combos (left, right, slash for a spinning attack or something). Because this is fairly fast-paced, my initial thought was that this would not translate to client/server style of networking. You can't really expect to block attacks with 300-400ms of latency!

At this stage, we're only looking at PvE (not player vs. player). So I thought, why don't I just make it so that the client simulates the combat and simply broadcasts the results to the server. The server can do some verification that the fight wasn't totally unrealistic, but from the client's point of view, it'll be completely in control.

So just to go through some basic scenarios, I'll start off with the simplest and move on to more complicated scenarios. Under normal circumstances, the client is only sending movement information for the player under it's control to the server. NPC movement and control is normally handled on the server.

One player, one NPC
When the player gets "close" to the NPC, the server will send the client a message: "you're in control of this guy". So the control of that NPC will pass to the client. The client will get to decide whether the NPC becomes angry and start attacking the player, whether it runs away or whatever. As the fight proceeds, the client will send to the server all the movement information for both the player and the NPC. At this point, the server is in control of only two things: when the NPC (or player) dies, and whether control of the NPC should be taken away from the client.

Control of the NPC will be taken away if the player moves away from the NPC (i.e. if they run away). The server will be running the simulation as well and so it will calculate when the NPC dies and transmit that to the client.

Because the client is in control of the NPC, the combat can be as complex as we'd like: multiple attack moves, blocks, combos, whatever. Also, an NPC in a client's control will only ever attack that player. So if another player comes over to watch, the NPC will basically ignore them until the player it's fighting dies. If the watcher starts attacking the NPC, we get into the second scenario:

Multiple players, one NPC
This one seemed tricky to me at first, but I think if we just stick with the server passing control for the NPC to one client (i.e. the one the server deems the "most deadly") it'll still work out OK. The other players will be seeing a delayed simulation (because of the latency) but it shouldn't matter: the NPC will only be able to block attacks from one player at a time anyway, and if one of the players not currently in control starts to damage the NPC too much, the server can transfer control to that player's client, and the NPC will start trying to block his attacks instead.

This scenario is only going to be common with relatively weak players against a strong NPC, but I think in reality it won't be that common - certainly, we can design the game to avoid this situation and make the next situation more common:

Multiple players, multiple NPC
In this scenario, the server will "load-balance" the NPC so that each client controls an approximately equal number. That way, if 5 players attack 10 goblins (say), the server will transfer control of 2 goblins to each client. The way the AI would work is that when your client has control of an NPC, the NPC is going to attack you, so you'll have to fight off the first two goblins. If you kill them, then the server might decide to transfer two more goblins from one of the other client's to you and you'd have to fend off those.

One player against multiple NPCs is just a special case of this scenario.

Game Design
Now, the game will be designed such that the most common scenario would be the multiple player/multiple NPC one. The idea is that all characters are basically humanoid and you don't have creatures who are insanely powerful compared to the players (so there'd be no point ganging up on a single NPC).

Cheating would be alleviated by the fact that the server is duplicating the simulation, and NPC death is controlled by the server.

The advantage, as I said, is that the combat can be as complex as we like - multiple attack moves, multiple block moves, combos, etc - and the game is not affected by the client's latency to the server.

The downside is that there is a lot of extra uplink traffic from the client to the server when the client is in control of multiple agents. I'm not sure if it would be unacceptable, and I guess the only way to know is to try it out.

The other downside is that it requires a reasonable amount of CPU simulation on the server. Obviously, the server is only simulates a cut-down version of what the client sees (basically just for cheat detection and deciding when characters die, etc). But this is not going to be an MMO game, so I think that's acceptable.

So that's my basic idea. We'll just have to wait and see where it takes us...

At Codeka Consulting, we have an eye for detail. Whether you just need a simple website for your online presence, or whether you need a complete overhaul of your business's IT services, we have years of experience building, supporting and maintaining all kinds of software.

We will work closely with your business to determine your exacting requirements and then keep you in the loop all the way throughout the development process. You can always be sure you're getting exactly what your business needs to help it succeed.

Based in the Sydney area, Codeka Consulting can do work for clients all over New South Wales and Australia. If you are a looking to automate business processes, or you are looking to build an online shop-front, or even if you're just taking your first online steps, we can help you to build a solution that fits your budget and your requirements.

So contact us today for a free consultation, and find out just what we can do for your business!

"Soldiers in the field could carry their own fuel."

That's gotta be the quote of the century.

The idea is that it's easier (in terms of energy required) to release hydrogen atoms from urine than it is to release it from water. So if this technology could be commercialized, we'd need to re-design our toilets a bit so that the pee is redirected to a holding tank where it can be processed by one of these units and turned into electricity. I assume that the electricity required to release the hydrogen is less than the energy produced in the fuel cell, which is not true of the electricity required to release hydrogen from water, but the article doesn't make that clear.

It's totally brilliant, but I'd hate to be the technician who has to service the units...