May 2011 Line Count
It’s been a little over a month, we’ve gotten a lot of work done.
Compared to March, we’re actually increasing the line count. While more chunks of old, unloved code have been discarded, I’ve also been adding quite a few new modules and while they are generally smaller than the systems they replace, the unit tests that accompany inflate the line count significantly.
The 1.34 client is now fairly happily running under it ‘s new “Teul::Connection” derived API; this hides the gnarly bits of the ancient pure-C teulKit API and quietly hiding it behind a modern interface.
The best part of this sequence of development iterations is that I’ve been able to actually improve the networking performance minutely, as a result of much better use of it.
While clearing out the last cobwebs of the old “redirect” system, we killed “Mission Results Pending”(*), but I’m tidying up all kinds of “that would probably cause a CTHL” issues – not least the one where, if you logged out and in again, you’d get booted out of the server during your second login (locked personas/cthl during startup).
(* Caveat: Ok, there may still be times when your mission results pend, such as if your network drops out or the servers crash – preventing further communication with the servers; or if the client guys find some clever way to invent new flavors of it).
For me, the best part of all this work is that in lieu of opportunities we “could” follow up on, the code is increasingly oriented towards stuff we want to follow up on.
Becomes ever more possible, but I’m not specifically coding for it, and so my own recent code will need changes to support it. However, I’m writing the code in a consistent enough fashion that if/when it becomes an actionable feature, I won’t be thwarted at every turn.
Redo of scoring? (NOTE: This refers to in-game scoring and has NOTHING to do with CS&R)
Technically 1.34 is a massive redo of scoring. There is currently no scoring code whatsoever in the 1.34 servers. Instead, we push scoring events out to a network of scoring processors, and my work next week is to implement processors that crunch those events into point awards.
Right now I’m not aware of any significant player-visible changes apart from reliability: the old scoring system is somewhat timing dependent, and is generally calculated upon completion of the sortie. The new system will be calculated on the fly, further distancing us from “mission results pending” :)
But 1.34 itself will definitely open the door to lots of changes.
I always get asked, and it’s always on our minds. I’m not a producer and I am only answering in terms of 1.34 host changes I am aware of, which is unfortunately: none. In discussions with the producers several changes we’ve made have definitely turned on light bulbs for features we may be able to leverage quickly for improved naval game play, but they have a number of other dependencies that I’m not qualified to speak on.
You will, though, get better tracking of naval shells thanks to changes to the update system, so those long range naval battles should be a little less wtfworthy.
Nothing significant on the host in 1.34 I’m aware of resulting in noticeable features, sorry :( A couple of activities that previously only resulted in one score per sortie will probably become many-per-sortie scored.
Hopefully the update system changes will result in a little less lag over busy towns, but that’s still pending a lot of tuning.
The update system changes in 1.34 should result in much smoother infantry play.
Dynamic Missions (Origin/Target etc)?
The big hurdle to implementing that has always been the spawning system, and the way in which it disconnected you from the mission server. 1.34 has removed the obstacle, but it’s unlikely we’ll have opportunity to make changes that major for 1.34.0. Not least: we’d want to make some accompanying changes to scoring ;)
Lots of improvements there; the client can also deliver much better feedback on connectivity issues, if the client coders don’t do their usual thing of just making the game exit with a “network error” message… I can’t promise anything there =/
I’ve reduced the burden of client<->server communications to both the host AND client, but if you’re looking for frame rate improvements … you need to go find a client programmers blog :)