UberGuy

As far as I know, it has nothing to do with minimum size. And I tried it two days ago and it still failed.

I haven't read the whole thread yet, but this is incorrect. Mobs use exactly the same hit mechanics players do. They have different sources for some of the attributes they share with players, such as level- and rank-based accuracy bonuses for mobs under +6 to the player, but once all the attributes are collected, the final computation and random roll is managed identically for mobs and players, including the streak breaker.

I caught that too, and thought the same thing.

Eh, I think there are a lot of assumptions backed in that conclusion. Given that they've already done it this way, with two separate applications, I bet someone has to show significant return on investment to merge them. And of course, if they don't know know what future changes they will have to pay to make to the split applications, or how soon, that becomes an exercise in hypothetical scenarios with hypothetical costs, and how to choose among them becomes subjective.

I run into this a lot at work. Convincing people of things that you're sure is the technically and strategically superior option can be very difficult unless you can show them an unambiguously black bottom line.

Right, but then, if it's not going to change, what's cheaper and faster? Getting a cross-OS-pollinated development team who can engineer that 5-out-of-10 initial dual-OS build, or building two (probably smaller) teams of straws from the haystack full of developers who can hammer out two platform specific versions?

My guess is that the platform-specific ones look a lot cheaper, especially in the short term. And even if it's only cheaper in the short term, I find it's often hard to sell the strategic, long term solution to the people paying the bills. And who really knows what "long term" actually means here?

Heh, no offense, but I'm well beyond needing that particular bit explained to me. I've used many over the years. Most libraries you can use with them for Windows, however, are not especially friendly to anything most developers would consider cross-platform C++ development. By which I mean if you took your core business logic code and wrote it, say, on Mac or Linux, and then tried to fire it up in a Windows-based GUI-building + coding interface like Visual Studio and use that tool to attach a Windows UI, the results would be ugly. And I don't mean the UI would be ugly.

C++ Builder might come with libraries like what I'm talking about, but it's not clear to me that it would actually make the port of the Mac installer any easier - unless it compiles for Mac and lets you sub the Cocoa APIs for its own. From that the main page says, it's a Windows app builder, so I'm not sure it actually helps.

Even if NCSoft could lay hands on a good set of UI libraries, unless those libraries themselves were cross platform on Mac and Windows, someone would still need to write a platform specific UI abstraction layer, to absorb the widget API differences between Cocoa and Windows UI libs and APIs. That's typical of any cross-platform binary application, though.

Right, I knew the graphical elements were separate. But what do you replace them with? What's the equivalent on Windows, and how maintainable is it? Who produces commercial (i.e. supported if you find a bug) graphical widgets for Windows C++ applications these days? (That may sound snarky, but it's not - it's a serious question.)

On the Mac, those widgets come from Apple, via the OS's GUI APIs. Certainly Windows has GUI APIs, but building those into something nice looking (edit: using C/C++) is not trivial. Maybe it's not trivial on the Mac either, though I'd be a tad surprised if that's the case. But just because they did it once for the Mac doesn't mean they would to re-engineer the (Mac) interface on Windows. I could easily see maintaining a separate .NET codebase being cheaper.

I really think it may not be that simple. I'm not at all proficient in developing on a Mac, so maybe I'm underestimating the effort they had to put into getting whatever the Mac Launcher's interface looks like to happen, but I think you may be underestimating the effort (and expertise) required to port the UI components of that program to Windows.

The core business logic of the app I do speculate could be common with comparatively little effort. It's the UI I suspect is the deal breaker.

Absolutely true. However, the (league) "performance" factor is now layered on top of this. So now, if you have a "poorly performing" league, not only might your iTrial take longer to finish, you may also now be more likely to get a less valuable reward. It's a compounding factor.

I'm going on having run some 400 trials across 8 characters. I do run them for fun, and not just reward, but I am no longer interested in running them for the sake of running them. I want them to be fun and rewarding. Running them with people I know and who are generally capable players is my best bet for both. Is that also true of other content, like TFs? Sure. But I also haven't been running the same two TFs a ton for the last couple of months, and TFs don't have a "participation" system (thank God).

I'm aware of all this.

I'm not sure why you think I have this misconception. I only said that these runtimes can be embedded in a browser. That came up because of the mention of DCUO's launcher, and comparisons to HTML5. I use (Windows) desktop applications that have at least some components written in AIR.

Java is absolutely craptastic if you want to do anything OS-specific. I am exposed to this repeatedly in my work, because I frequently write OS and application management tools. Java's implementation of "write once, run anywhere" is a burden that makes it wholly unsuited to these tasks unless you are willing to extend it by calling native binaries or using native libraries via JNI, either of which harms the benefits of using Java to begin with.

I am not familiar with AIR's APIs, but I'm willing to bet it's better about this.

I hate to tell you this, but CoH is, first and foremost, a Windows application.

Also, .NET is not a "VB" library. It's a language agnostic API library that runs in VM concceptually similar to Java's JVM, which happens to be able to front-end a number of languages. (JVMs can too - see Scala.) I think VB is a pretty terrible langauage too, but .NET is not VB.

I can't see any significant, logical reason to base "trust" on this. I am hardly arguing that .NET is better than a cross-platform runtime, either in general or in this case. I don't have issues of "trust" with it over this, however.

It would also have taken longer to develop, taken longer to debug, and still probably have ended up more buggy. I say all this as a skilled C/C++ developer. I prefer C/C++ in most ways, because I am a code hacker at heart, but all managed runtimes are easier to use to produce more stable and well-behaved applications faster than C/C++. I work with lots of developers, and most of them still find ways to create resource leaks and invalid references in languages arguably designed to avoid them. The idea of most of them having to deal with pointers, memory allocators, destructors and the like makes me ill.

Writing the launcher in some managed runtime was the right, practical choice. Choosing .NET on Windows was a reasonable choice, given that CoH is primarily a Windows application, almost certainly with a predominantly Windows install base.

I'll bet you money that the Objective C code used on the Mac can't be cross platform, because it probably uses Mac-specific libraries. If you compile it for Windows, you have to use something like gcc, and you don't have access any more to any of the MacOS graphical libraries, which have no Objective-C equivalent available on Windows that I am aware of. So while it's probably leaner, it's probably not cross platform at all.

Really the only runtime we've talked about that sounds like it would work well cross platform is AIR. An AIR app is still going to have a relatively large footprint, and AIR has some of the same history of insecurity .NET does. (For a while I got security updates for my AIR runtime almost weekly.) That leaves that it's better simply because its cross-platform, which I don't argue. Why didn't they write it in AIR? I don't know, but I consider it likely that it was easier to find a .NET developer faster.

So, let's summarize. You have argued that you hate the launcher, and part of your hate for it is based on it being a .NET application. You've given a number of reasons for this, ranging from its footprint to its (in)security, but the truth is that all these things apply to all the other managed runtime languages. Writing it in a manged runtime language is arguably the sensible choice for any development shop that doesn't want to be debugging the thing constantly. (Note - depending on which version of Objective-C they're using, it may provide them some of these benefits despite being based on C/C++.)

So if the right choice from a practical perspective is to use a managed runtime, the the only valid complaint you've made about the launcher is that using .NET means it's not cross-platform. It looks to me like the only serious contender here was probably AIR, and it was probably just a practical matter that .NET developers are easier to find than AIR ones. Whether Objective-C developers are easier to find than AIR ones, I can't say for sure, but given that you can use Objective-C to write iPhone/iPad apps, it wouldn't surprise me.

I wasn't disagreeing with that part of your post, so my apologies for not being clear. I was disagreeing with the notion that the launcher/installer didn't have to be a "fat client", or more correctly, that it could be a thin client.

Long-winded exposition follows.

Where I come from a thin client is something that has minimal "business logic" because the guts of what the application does is actually hosted somewhere else. Amazon's online store and Facebook are pervasive examples of thin clients - the actual applications run on those companies' systems, and we just get a thin interface for looking at their applications' output and validating our input to those systems.

As a counter example, if you have any experience with the Dungeons and Dragons 4th Edition Character Builder application, you might know it's a Silverlight application that can run in your browser. It's anything but a thin client. It downloads a crapton of stuff when you launch it and uses that downloaded information to aid you in building your D&D character. Frankly I think this was incredibly stupid, and I don't (just) mean for writing it in Silverlight. It's a fat client you have to have an internet connection to use, instead of a thin client that just displays things that are calculated remotely.

Getting back to CoH, any game installer that honestly installs applications (and installing CoH is more than just copying files) on our computers can't be a "thin client" in the above sense. People sometimes think a "fat client" means it's a complex program that does a ton of things, and it's definitely true our installer/launcher is not doing anything deeply complex. At the same time, it's definitely not a "thin client, because everything serious that it does, like patch our game, it does 100% locally on our desktops. Even if it ran in a browser, like DCUO's, it still would not be a thin client in the sense I describe above. It's just a "fat" (non-thin) app that happens to be hosted in a local browser. And I agree with you that putting such an app in the browser using things like AIR is probably more of a pain for the developers than just letting it be a stand-alone application.

Snow Globe's objection to .NET seems to stem in large part from the fact that it is a desktop runtime. He trusts server-side and thin-client environments. Of course, Java and Adobe AIR are also desktop runtimes. All of them can run in a browser, but that doesn't always mean what they'll be used to write is "thin". Given that CoH itself is a fairly fat C/C++ Windows client that does tons of CPU/GPU-intensive work locally, I can't see anyone writing an installer for it that relies on the runtimes that Snow Globe trusts, barring Flash. (And I don't really trust Flash, though Adobe has made big efforts to improve its security.)

If CoH itself was a browser-based HTML5/WebGL application, all this would be different. In that scenario, it shouldn't even need an installer.

Just running in a browser does not make something a remote application. All this example does is make the browser a local execution environment. As you say, the sandboxing such runtimes have in the browser these days sounds like that could be painful. I am not an AIR developer though, so perhaps not. AIR apps don't have to run in the browser though. In any case, Until very recently I'm not sure AIR had any legs up on .NET for security. It's certainly cross platform.

The launcher is also the patcher and installer. It most certainly does more than launch the game.

The launcher is a fat client. It is more than a display. It executes business logic that can only function on the machine on which it runs. It cannot run elsewhere. Simply because it downloads content from elsewhere does not make it a thin client. What it does, it does locally. A thin client displays content that is processed and executed remotely. (Certainly the status and graphics it shows are "remote", but then again they don't really do anything other than send you out to your browser to display what they link to.)

Edit: To be fair, HTML5 applications are going to have the ability to straddle this divide. The goal is to make HTML + JavaScript a strong development platform for serious applications, obviating the need for things like Flash and Silverlight. Something like an in-browser game is going to be possible with it. Essentially, though, the browser is becoming "fat" when you do that. It'll just be a hell of a lot more cross platform than anything we've had so far. However, it's not likely to be attractive to write something like our launcher/patcher/installer in HTML5 because the CoH client isn't written for it. Whether it's written in .NET, AIR, Java, or whatever, right now the "launcher" has to update a legacy application originally written specifically for Windows, that depends on things that are basically Windows-specific like Registry settings, which the "launcher" (in its installer role) has to set up.

I know. I did it the very first day they deployed it. I used that technique and unlocked the wisp aura on my second account. I understand very well what the launcher does. Given what you've omitted, I rather wonder if you do.

That's fine, but your conspiracies are apparently formed for a situation that cannot possibly apply. You eschew a technology that's specific to writing desktop apps, armed with a background in writing thin-client apps, but we're discussing an application which must (based on the CoH application's own architecture) be a desktop app.

It definitely sounds freaky. Freaky enough that you might be able to ask them what's up with that. Consider giving them a call and making sure there's nothing they can do, and point out that you have it from other users in the same city have no problem.

If they're like most ISPs, asking for help on such a relatively low-level detail as access on a blocked port might not be the most painless experience, but if there's a chance it will help keep you able to play, it might be worthwhile.

If they have on-line forums, that might also be a decent place to ask, to see if there are more folks who do and don't have this issue. You might not find many CoH players there, but you might find out if port 80 is really blocked, and thus really the issue.

I find it amusing that you're up in .NET's grille and you list Flash as one of your core programming competencies. Until HTML5 gets vastly more steam behind it, essentially no one is writing serious desktop applications in HTML/CSS/JavaScript. In fact, I consider it more likely that no one will, and it will instead be the language of choice for interfacing to applications that run somewhere else entirely (i.e. the buzzword-overloaded "cloud"). If you're writing your Windows applications in C/C++, well, hope they really benefit from the speed, because you surely are taking a lot more time to develop and test them than you would be using a managed language like .NET or Java. Well, that, or your apps are probably a lot less stable.

Oh, and Java is no panacea of application security. Desktop Java is one of the largest attack surfaces out there after the various MS OSes and Adobe products like Acrobat and Flash. It's actually frequently recommended that people who don't have a good use for a JVM on their home machine uninstall it.

I'm a fluent (and professional) programmer in C/C++, Python, Java, and Perl, and much of that professional experience is not from a Windows environment. I have only hobby-level exposure to .NET, but I really don't grok the hate I see people have for it. It makes development of Windows-based, fat client applications faster, easier and usually more stable, just like Java does on multiple OSes. Java, however, is burdened with "write once, run-anywhere", which makes it poorly suited to things an installer needs to do with a native OS, such as making registry updates.