Board Thread:Game Updates/@comment-3502824-20170916104500/@comment-26461371-20170920134041

 AnimeFreak40K wrote: The real problem is how viewers like KC3 and KanColle Viewer act/behave. My understanding is that they work by taking a look at the code that is sent to your system (PC, mobile device, whatever), parsing it out and delivering it in the format that we know and love that makes playing the game easier and/or more manageable...which is done because of the very nature of how Flash works.

By moving to HTML 5, your concern shouldn't be whether or not you can access the game, I do not see a reason why you would not*. The issue is whether or not your viewer can give you the information it does at present and whether or not the folks that work on/maintain it are willing/able to make the changes so that it works with HTML5.

Partly true. I don't think the migration will have any effect whatsoever with viewers; as a developer, you'd want the migration to be as painless as possible, and one way to do this is to make sure that all API calls done in KC's back-end (i.e., the code you were mentioning) would be the same. I'm guessing that the devs would want to do that to ease migration to HTML5.

What this means is none of the back-end would change (save perhaps for some minor alterations here and there), i.e., viewers should be able to read data just the same as they do now.

The only thing that would change (I think) would be distribution of shipgirl CGs; right now, they're distributed in Flash files with all forms (normal, damaged, banners, etc) packaged inside. This makes it difficult for a normal player to get the CGs themselves, but not impossible.

Now that KC is moving away from Flash, how would they distribute CGs? I have a few guesses:


 * 1) As .png files with "encrypted" filenames. Just like how sound files are distributed now, this should make guessing filenames harder, but not impossible; the staff here at Wiki can get any voice line with the KC master data (which is loaded by the game when it starts up) and around three lines of JavaScript code.
 * 2) As encrypted assets. This is what we fear the most. Then again, deobfuscating the decryption code or getting the decryption keys might prove to e a trivial task; one game's asset encryption was defeated with five lines of code.