Sunburn/T2D and Networking ... it finally works!

I don't usually like to post two .plans in fairly quick succession, but continuing on from this .plan ...



Whilst this doesn't look all that much different from the shots in the last .plan, under the hood it's immensely different.

What you're looking at is two completely separate views of the same map data (generated on the server at game start). Map updates are now done dynamically as needed by way of NetEvents. If the client code was all hooked together properly, it would also do fog of war.

This represents just under a week (not consecutive) of pretty intensive debugging. It also required writing a lot of code without the ability to test it, hence the kludges that caused the map bug in the last .plan. I finally decided across the last couple of nights to just ditch the kludgey temporary code and just get it done properly and live with the masses of debugging it needed. I really hate working that way since I always end up with a mass of code I have zero confidence in and a nightmare to debug. That said, programming would not be fun without the serious challenges.

So, I now have NetObjects, NetEvents and Datablocks working in T2D. I also have most of my core game classes networked, as well as T2D Image Maps. Since my map class automatically manages the t2dTileMap, I'm not bothering to network tile maps or layers, and I'm not using anything else in T2D at the moment so most of T2D itself remains stock for now.

Why the hell are you going through all this effort for a TBS ?

It is true that T2D supports simple networking out of the box, and is generally considered sufficient for a TBS. The major resons for taking this route are:

Map updates are small and limited to only the areas that the player can see. When the game starts the player can see only a small part of the map (probably a little smaller then what's shown in the above picture), so the game loads really quickly. As the player explores, they get only the map updates that they need, which are also small and efficient. Fog of war updates come through the same events, minus the map data. This lets me update both the map and the fog of war at the same time with minimal overhead. Sure, I could do a similar thing with commandToClient(), but the overhead would be far, far bigger meaning slow map updates.

Scoping. TGE networking already has a decent scoping mechanism. SunBurn's visibility manager provides the data to do the game specific side of scoping in a really efficient way. Scoping not only provides more efficient networking, it also helps prevent cheating as the client doesnt know about units, etc that it can't see. Implementing scoping using commandToClient() would be possible, but easily circumvented and really messy. I also hate reinventing the wheel.

It provides the ground work for proper real time networking in T2D. This probably represents less then half of what is neccessary to get real time networking running for T2D in a generic and usable way, but its a start.

And now ...

I'm going to have a cup of tea and a smoke and celebrate finally getting the damn thing working. Then... we'll see ;)