Development Blog

One of the most confusing parts for me was pointers versus references. In C++, pointers act pretty much like an object in Blitz3D

 

When I realised that about a year suddenly pointer made sense. I saw that everything in Blitz3D was just a number. Armed with that new knowledge

 

1. client-side prediction is inaccurate and wrong, 2. It was originally designed for 56k modems

 

But still when the server has a large number of entities to track it starts to fall over. I'm generally of the opinion that clients are always dishonest and the server should authoritatively do as much as it can, there are some things that you have to offload to clients, debris for example.

 

Whilst we have a much higher data rate than we did 10 years ago, we also expect our games to handle a much larger load than they did at that time. One of my brothers' final year uni project was to build a small multiplayer game in Blitz 3D. Although he promised client side prediction, it wasn't there for the final submission. On a local subnet it was fine, and this was still so when played on the wider local network. As soon as it hit the Internet you could see occasional stutters.

 

That told us that a relatively high end home connection (20 megabit cable) connecting to a server on the SuperJanet network still needed a little bit of prediction to make it as smooth as it was on lans. And If you're wondering, SuperJanet has a throughput rate of about 40 gigabits per second, it's certainly one of the fastest private networks in this country, if not one of the fastest world. I'm sure there are some that handle terabits per second, but no one here is going to get their game hosted on one. But that certainly make me wonder about no prediction coupled with the much lower throughput rate of most dedicated server providers.

 

I did not like the direction Microsoft went with Windows 7, and the new OS has finally put me in a place where I am willing to try something new.

 

Oh come on Josh, you there was another option...

I can see why you might be annoyed having paid so much for 7 Ultimate...

...But paying even more for a mac is not the way

I'm still not sure why you are giving up BlitzMax for C++, as you are productive enough in it, to be a threat to the bigger engine makers.

 

If it is for cross platform compatibility, I guess it is a good enough reason. If it is for something else, I don't get it.

I'm in favor of just letting the server handle all interaction, with no client-side prediction because: 1. client-side prediction is inaccurate and wrong, 2. It was originally designed for 56k modems, and 3. Onlive has proven that player response lag can be minimal even when streaming graphics in real-time. The design I used in the multiplayer tests I conducted a few month ago was certainly good, and the results were responsive enough as long as the players were on the same continent.

 

I have to agree with mumbles on this. Client side prediction is still a must have for multiplayer games, and ignoring that for the only reason I can see is because it's complicated to do correctly is a big mistake and will make the netcode a joke in the engine community.

 

There are a few reasons it works for OnLive: 1) They have many "hubs" around the US. 2) They are only offering this in major cities. 3) They have special logic built in to control where their hops go.

 

Networking is easy, but networking correctly is complicated. If you are serious about adding networking functionality that is really usable then you would hire someone who knows how it's supposed to work.

We wouldn't leave home without cubic spline interpolation, between Bangkok and the UK we couldn't. In the real wold outside the US and cosy net services the internet weather can be a little rough. We send more data than just positional, since our entities don't make sudden changes positional updates can rely on client prediction between those updates to allow state data through which potentially can change faster.

 

It's your opinion of course, I've had time with commercial sims like Empire Interactive's Apache Havoc and the networking was a disaster. Assumptions on letting the transport layer handling problems is just doomed to failure leading to complaints about performance. Nobody will end up using it.

Client prediction is a must, although I don't know if it's up to the engine to handle it. I would surely like it though.

You send UDP messages with the "reliable" flag disabled, and add a counter to each one. When the client receives the messages, they discard any that have a lower counter than the last received update. We actually saw 100% smooth and accurate physics over the network, something that I've never seen before. Compare that to any game using the Source engine, where the physics are constantly stuttering and bouncing around.

 

Maybe we will implement a cubic spline prediction for physics bodies, but it needs to be silent, automatic, and in the background.

 

I'm still not sure why you are giving up BlitzMax for C++, as you are productive enough in it, to be a threat to the bigger engine makers.

I can't sell BlitzMax source code to professional studios, and BlitzMax won't run on the XBox or PS3. I've had a number of offers to buy source licenses if the code were C++.

 

Oh come on Josh, you there was another option...

Linux is only free if your time is worth nothing.

"Linux is only free if your time is worth nothing." hehe I like that. I suppose like most things, if you're skilled in it it's second nature but made me chuckle though.

 

I just want to add that I love seeing a Roadmap. Streaming terrain and is something we started to look at using GROME as an editor, it has powerful scripting features and the ability to slice up huge maps. But of course it's breaking LE in two which is fine, cherry picking is part of creation process. The prospect of staying 'native' is quite appealing.