mnakamura

Sorry for late reply, I haven't visited this forum for a while. Not really, but I can send you some links to the demos available in private message. There is no server part, it's all pure client-side, so you can probably just throw it into a PS Vita storage and load it from there, or deploy yourself it on any static HTML hosting, if it is http-only. The concept itself is solid. However, there's been no single finished VN released, playable from the beginning till the end, based on Mikan engine. There are a few important functions still missing (like loading / saving), but that's probably 1-2 days worth of coding to get that done. Unfortunately, current state of affairs is a result of combination of: several teams taking on some projects => I do reverse engineering and provide tools for them => they abandon the project and disappear => my motivation keep sinking I'm not really a great developer myself, I'm actually a malware reverse engineer, so I wanted to promote a concept and get more people interested in it to help me developing JavaScript engine; unfortunately, looks like I've failed I'm having constant troubles with free time lately, can't dedicate much time to do publicity work on Mikan That again, is totally my fault. Partially my lack of motivation and lack of continued community interest in Mikan is to blame, but that's all excuses. If you really want it and you're still up to it, we can try to revive the project and I'll promise that I'll finish that documentation and publish it. Looks like I haven't touched neither of them, so I can't really say anything here.

At the very least, there's not a single translation, but I know of probably at least 4 different teams or individuals beyond Yandere that announced that their work on that.

@liquidcrab Well, whatever gets the job done. I'm still there, in case you'd need me.

Hey, we've been working on it since July: We've already got all unpacking & porting to our new engine working. Let's join our efforts?

I totally feel you, pal, happened to me 2 or 3 times already. Damned Cloudflare Best luck with your reversing efforts anyway. Please share your progress with us — that's always very cool to see

Thanks for your appreciation It's really very heart-warming to know that someone (besides me) finds that stuff interesting Hmm, and I thought that I'm referring only to the most basic stuff in these articles. What do you need to know to understand them? very basic stuff about how computers work - i.e. files, hex numbers, bits-bytes, integers, characters - I guess most of the people nowadays learn that in mid school / high school the rough idea of string encoding - i.e. that "string" is a sequence of characters, and you need know somehow where the string ends - for that you either store a string's length somewhere, or declare that a string needs some "terminator" character basic knowledge of any modern object-oriented programming language (from those supported by Kaitai Struct) I supposed that basically anyone who spent like a weekend trying to pick up any progamming language (i.e. Ruby, Python, JavaScript, etc) would be ok with reading my tutorials. Can you elaborate more on what exactly is missing and what's hard to read/understand? Even if it's that "basic" stuff I've mentioned above - maybe it would be a good idea to write some quickie explaining it all in one place? Well, of course I do, but as you might have noticed, I'm kind of really opposing the idea. There's a whole world of reverse engineering that one can learn and hone their skills for the whole life There are several pretty distinct branches: analysis of execution (that usually As for books, I could really recommend https://beginners.re/ - it's a little slow-paced at some topics, but good nevertheless.

Hi, fellow VN hackers, Some of you might remember that I wrote the first part of visual novel reverse engineering guide a while ago. And now, lo and behold, today's the day that I've published the second part of reverse engineering tutorial - this time, I'm discussing the approaches to reverse engineer the script, find out what are the part it consists of, and extracting the Japanese text (to pass it to the translators, if you run a VN translation project). Feel free to ask any questions. Cheers

Probably, it would be fairly easy to write a VNDS -> Mikan converter then. As far as I remember, VNDS is based on NScripter syntax.

Um, sorry for the late answers — I've been unexpectedly busy with my real life and work and stuff, sorry. Actually, I'm also mostly using Linux for desktops, and that's one of the motivators for Mikan engine for me as well From the bird's eye perspective, it's like 4 steps: if there are any archives, extract their contents (90% of the time, there would be ready-made tools for it - check out usual stuff like Crass, GARBro, ExtractData, or collections like these). convert these contents into contemporary formats that would be widely accepted by browsers (i.e. PNG, JPG, OGG, MP3, etc) - many VNs use custom formats for graphics, animations, etc; again in 90% of cases, ready-made tools will help you find the script files and check them out; if they are compiled bytecode, figure it out (which opcode means what) and learn to decompile it (might be hard) convert script files into JSON used by Mikan (relatively easy, once decompiling is done) As far as I understand, Infinity was developed by KID and probably uses some variation of their engine. @Scorp mentioned that he has tackled these formats, so he might provide more info if you'll motivate him enough

I'm only human, so I can take only a handful of simultaneous projects by myself. If you want to help and port it - you're most welcome Alternateively, if and when this project will get some traction, probably someone (or me) will eventually port it.

I've checked out Private Nurse - it seems to be using the infamous SM2MPX10 format (AKA GGD, AKA Ikura, etc). I've already tried porting one of the games on that engines, that is 子猫同名, so it shouldn't be too hard. Besides, this format is already supported by ViLE.

Ok, added it to my (pretty long) backlog Do they both (Private Nurse and X-change) use the same engine?

Got the music working, only one minor flaw remains: there's no simple concept of "looping" in these .wm files. "Looping" is implemented just as yet another jump bytecode inside these files, and, what's even worse, there's not a single stream of bytecode instructions, but several distinct streams (one per OPL3 channel), every one having distinct position & jumps inside it. Still figuring out how to calculate that looping point.

No animations, no music yet. Converting music is pretty trivial, though time consuming: one has to rip any OPL3 emulator (from Anise, from DosBox, Nuked OPL3, etc, etc) and render OPL3 music with it into oggs or something.

Long time no news, Fuwan I'd like to share a new port of Ushinawareta Rakuen - that's an ancient VN by Silky's from ~1996. Thanks to support from @Zus and @Scorp , I've got kind of a minimal playable port to Mikan engine (ripping of lots of reverse engineering details from Anise engine). Without further ado, here's what it looks like now in its 640*480 glory: I guess Zus's team is looking forward to translating it. So far, I've just pinned the names of the characters.

Um, I see only a lot of macro definitions in that file. Have you investigated which macro does what?

Yeah, they do, although sometimes it would be much easier to figure out what does what just by looking at the game in action. Look for stuff like that in .ks files: or, alternatively: or sometimes they even declare embedded TJS scripts and resort to calling them: Sometimes there are clearly named files like macro_*.ks (even with comments in Japanese ;)), sometimes they're jumbled together with various system stuff. If you're really unlucky, macro-like stuff can be also defined in .dlls, which makes it pretty hard to decompile them.

Ok, then I propose to do the following thing: you analyze these macros and tell me what does what and I'll try to insert support for it in my converter. I'll try to publish it soon too. I guess it won't be a problem for you to run a Ruby script?

I've done some work on Kirikiri support already, and, to be honest, it's a fairly messy task You might have noticed that I haven't distributed any demos of games that run Kirikiri and that's for a reason Porting basically consists of 2 large steps: Unpacking of the game archives, extracting all the assets, converting images and sounds into widely recognized formats (i.e. PNG, JPG, OGG, etc) Conversion of the script into JSON .story format I see that you've mostly completed step #1. Probably you should convert BMPs to PNGs, and that part will be done. As for the script, typically there would be multiple .ks files. It's text-based and well-documented format, but the problem is that it is pretty low-level. To alleviate this problem, 95% of developers usually invent some form of macros (subroutines) which do high-level stuff. Take a look, for example, at this script from Imouto Ijime: It's easy to see dialogue text (it's always plain unmarked) and ";" always marks up comments, but everything else is somewhat complicated: [cpg] and [cpg1] are macros that ask for user's keypress to continue [OnName ...] is a macro that displays name of a character in text box, "num=X" is a character ID [pv s="..."] plays a voice file [ps se="se15" w=400] is a macro that plays sound effect "se15" and waits 400 ms for its completion before continuing And now take a look here, it's an extract from Kyoudai Hiai: You see, here we have completely different set of macros: [name text ...] for displaying character name [tp] for pause for keypress Another example, from Oppai Sensou: It's still the same Kirikiri, but it looks completely different: [CH_NAME_M ...] and [CH_NAME_A ...] show character name, but use some extra color effects, thus two different macros [VOICE voice=...] is used to play the voice file [SYSTEM_MENU_ON] probably is used for keypress In the example that you've posted it seems that: [P_NAME s_cn="Subaru"] - character name [P_FACE ...] used to show character's face [cr] - keypress [GL s_mo="1" s_fn="BG05c"] - probably a background image [TL s_po="c" s_fn="SAKI_T1"] - not sure, maybe a sprite? I have a half-written semi-customizable Kirikiri-to-.story converter written (although it's not public yet), but you still have to do separate processing of the macros for basically every KiriKiri game, as they all tend to be different (each company develops its own set of macros which they more or less copy-n-paste into each game). @LeonidasTan, can you tell me a bit about your background? Which programming languages do you prefer, would it be ok for you to contribute to converter written in Ruby?

Well, actually I can take a look, but first of all I'd check if someone else's already been doing anything on these formats. As I understand, Nitro Royale is not exactly a VN, but a fighting game?

Thanks for your suggestion! You see, I'm a very beginner writer (actually, it's my first article I've ever written for wide public), and I'm by no means a native English speaker. Can you recommend me what would be a better way to introduce such an article to translators / reverse-engineers-wanna-bes?

True enough. That's a good idea Maybe even we can go one step further: a server would not require users to actually upload their VN media files (and download converted results), but just to prove that they own it. This is where VN producer cooperation may come in really handy: if there would be a way for users to prove that they own legitimately bought copy of VN, they get their "converted for iOS" VN download right away. No uploading, no waiting, no wasting of server resources.

Actually, my main point was the simplicity and largest user base. Almost everyone can read and write JS nowadays. Everyone can run HTML+JS with only a browser. JSON is a super-popular interchange format. Etc, etc. I totally agree with those of you who proposed to dump CoffeeScript - and I agree that it was not a very good idea to begin with. Consider an average iOS user. Can you tell them to just "copy all the arc/bin/whaever" to their iPhone/iOS? I don't think so, 99% of them have absolutely no idea how to do that. Actually, iOS tries it really hard to make user forget what a "file" is at all. If they need any media - they have iTunes. If they need apps - they download them right from the AppStore (or whatever it's called, I keep forgetting). Anyway, it's impossible to put a DVD into the iPhone/iPad due to lack of the drive. So, you'll need a desktop with a drive anyway. And most of the time all such things will boil down to an "installer" of some sort that will just do all that "conversion" work under the hood, while for end user it will look like a "special application that will install a VN into an iPhone/iPad/Android". I totally agree with @Mad Pierre who pointed out that my current way to do ports (i.e. as a bunch of Unix scripts) is not really user friendly, but it's a solid base. You can always wrap GUI around the logic. It's not always possible to extract logic from GUI.

First of all, thank you for your kind words. It looks like the idea have been around so quite some time, I'm definitely not the first (and probably not the last :)) Both me (and half a dozen of other projects, like ViLE, Anise, RLVM, Asenheim, etc, etc) tried that road, and at least for me it's clear that it is not the way to go. The main problem with "emulate a separate VM for every VN engine" approach is the complexity. If you want to add some nice extra feature (like fancy UI, history tools, translation aid, etc, etc), you'll have to implement it multiple times, each time for an individual VM. That is, again, why unified format shines. You're more than welcome to implement additional runtimes in any way you want, it is should be relatively easy (current format spec has around a dozen of commands - that's all), rather than porting all VMs and file parsing stuff everywhere. Yeah, it's already been decided, we're moving to ES6. @Targenor is really shy and doesn't seem to like public discussions, but he's working hard on it now. Sure, sounds like a good idea to me. If you know NW.js or Cordova enough to implement it - you're most welcome to contribute

Maybe I don't know something, but last time I checked 010 had no concept of substreams at all, let alone applying common algorithms to it. It's kind of getting us nowhere. You keep sticking to your approach, that's fine with me by all means.