Jump to content

DrDaxxy

Members
  • Posts

    14
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by DrDaxxy

  1. The PS4 version is definitely (natively) 1080p. Up to you whether you care about that...
  2. Alright, so we dropped the "one hour per day" and replaced it with something more flexible. We come from the SciADV fan community. Our image editor, Cypert, worked on the Spanish translation of STEINS;GATE (which was done in under a year), through port lead developer SomeAnon we're friends with the Russian translators of STEINS;GATE (which took about a year too), and TLC SnowedEarth is currently working on an unannounced medium-length VN translation project (which started in early October and is predicted to finish next August). These two aren't his first projects either. We don't have precise numbers for the size of the text original to Noah yet. But indeed, the larger part of the script was in the original Chaos;Head and is already translated. TLWiki lists 24k lines for C;H, 32k lines for Noah (though keep in mind there are changed lines too). So yeah, we think "under a year" is a quite realistic target. The routes are proper routes, with flags to set and changed scenes throughout the VN - it's similar to how STEINS;GATE changes depending on how close you get with Kurisu. The biggest differences are the endings, of course, but unlike S;G they're not the only differences.
  3. Thanks for the warm welcome, guys. We're glad you like what we're doing. Because of the port aspect? Or because it's Noah? Like with regular fan translations you'd still have to have your own copy of the game, we won't distribute that. Similar engine reimplementations (like OpenTTD, ScummVM, or in the realm of visual novels, RLVM) usually don't run into trouble. Chaos;Head Noah is pretty old by now; the developers have plenty of opportunities to bring this game to the PC/the West. It's also already readable (and pirate-able) on PC by way of the PSP version. So yeah, we don't think we're stepping on anyone's toes with this. Patches for console versions may follow, but we don't want to plan too far ahead. The Vita version in particular is unlikely though; IIRC it's based off the Muv-Luv engine (which is supposedly a massive pain to deal with). Sorry about that. Yeah, we realise how that looks. I also tend to roll my eyes at translation projects without a translator (or in some cases without anyone). But we're not ideas guys here - we're doing the port regardless of whether or not the translation succeeds (and we know we can pull that off). So we can definitely provide something of value here. Some of our members have worked or are currently working on translation projects, so rest assured we appreciate the effort that goes into translation and we're aware of what we're asking here. But in return, we can promise a pretty good chance that those efforts won't be in vain. Might sound weird to have a TLC when the translator position is still open, but the reason for that is that SnowedEarth feels he currently doesn't have the combination of time and efficiency to translate this in a reasonable amount of time. And that's what we're looking for, really. Someone who's good at it and can work often enough that we make steady progress and don't sink into quicksand, and long enough at a time that we don't take years to finish this either. The specific numbers for "how long" and "how often" heavily depend on the person, of course. Maybe "one hour per day every day" is a bit much, but we figured it's a good enough general guide. I'll bring it up with the others, we might reword that.
  4. Text hooking support is not our priority for a first release. Though it may work by accident, or in a future update. We're also open source so anyone else looking to add it wouldn't have to reverse-engineer anything. What you say about S;G 0 is correct. Someone made a patch that translates dialogue between font character indexes and "actual text" so a hooker can attach. S;G 0 (and in fact most other SciADV releases) isn't based on N2System though, but a completely different engine.
  5. Chaos;Head Noah (stylized as ChäoS;HEAd NoAH) is an updated rerelease of Chaos;Head, a 2008 visual novel by Nitro+ and 5pb. This version includes six new endings that were not present in the original; one for every main heroine. However, while the original version was only available on PC, the updated version was available on practically every platform but PC. We at the Committee of Zero intend to change that. The original Chaos;Head was translated on TLWiki years ago. We intend to build on this work, but heavily revise it and edit it as to match our writing style. Please bear in mind that we are not associated with TLWiki's team in any way, and this project is not related to their own abandoned Noah port and translation. Staff We are currently in need of: A translator with some amount of past experience and the availability and diligence to make steady progress over a few months to a year. Our core Noah team consists of: Engine Reimplementation for PC: SomeAnon, DrDaxxy Translator: [RECRUITING] TL Checker: SnowedEarth Editor: Kumin, Discontinuous Qualia CG Editor: Cypert Keep in mind that this list does not include everyone in the Committee of Zero. We have many members, including those who have done... zero work. Progress At the moment, not much work on the translation itself has been done. We've set up the basic workflow and are putting together an organization system, so once we finish our current side project, we should be all set and ready to jump on translation work no later than the start of the new year (assuming we find a translator by then). However, what this project currently lacks in translation work, it makes up for in porting work. Our technical team is building a complete reimplementation for PC of the N2System engine that the Xbox version of Noah runs on, and we've made substantial progress. Right now, the engine is capable of reading and interpreting the game's scripts (though it currently only displays backgrounds and plays in-game audio - nothing to show off yet). Notes By the way, SciADV fans may be interested to hear that we recently released a patch for the Steam version of STEINS;GATE fixing many of that version's shortcomings. We don't feel this warrants a Fuwa thread on its own, but we wanted to mention it. The port will likely be finished before the translation, and once that happens, we plan to release it, so Japanese speakers can read the VN on PC. If you're interested, and think you can help, then aside from this thread and my PMs, the best places to contact us are via e-mail at [email protected] or our Discord.
  6. Having lots of sex scenes would usually make a story worse. Erotic literature (unless it's short) isn't all sex either. Overuse it and instead of providing a striking emotional element it just gets boring. I could see comedy being an exception to that rule: If your story is already silly, I don't think throwing more sex in is gonna hurt it (especially if the sex scenes are themselves funny). But if your only reason for calling something a nukige is that it has particularly explicit/kinky sex scenes: I don't think that makes a difference. I mean, sure, you probably wouldn't bother with a good story if you just want to cater to "weird" fetishes, but there's no reason you couldn't do that just as well as in any vanilla eroge.
  7. Are you looking for help with a specific title, or are you trying to study how to take visual novels apart in general?
  8. Articles like this aren't gonna be anywhere near as useful to people who already have reverse engineering skills as people who'd like to get into it. Back when I started, I'd definitely have appreciated more resources like this. However, someone who wants to learn how to "hack VNs" (or "mod games" or "view .something files") might not know that reverse engineering is what that's called.
  9. Timing seems a bit off, to be honest. This sort of thing hasn't been very successful as of late.
  10. There's actually a Japanese company attempting something similar (a portal for reading VNs on the web, powered by an embeddable HTML5 VN engine that's compatible with Kirikiri and allows packaging individual VNs for release as Windows/Mac/iOS/Android apps alternatively or in addition to hosting them on the web). See http://novelsphere.jp/ and http://js.novelsphere.jp/ . The problem with having people download VNs from a (local-network or online) HTTP server into their mobile browser's caches is that browser caches are very limited. They're not gonna let you store hundreds of megabytes of assets. I don't know what mobile data plans are like in Japan these days, but in most of the West, the traffic caused by streaming assets over the Internet would make reading VNs on the go straight from the Web impractical. I don't think there's any way to get a generic VN reader on the iOS App Store, but perhaps there's a solution I haven't thought of. If you want to seek VN developer cooperation, then since you're Japanese you're in a much better position to pitch your ideas to them than most people on this forum, but I still wouldn't hold my breath. You're gonna have to put the target-engine-specific stuff somewhere - either in converter applications, or in plugins, or (like ScummVM) in an engine sub-hierarchy of the main codebase. And said main codebase could include generic functionality like a common virtual filesystem interface, a common image handling interface, implementations of common image formats (chances are you're gonna come across many titles that use JPEG for backgrounds etc.). But then you have uncommon things like some titles (including one I'm currently working with) using 3D environments (...in my case, a single cubic room with static lighting for a few scenes in which they wanted to rotate the camera, but still, it's 3D). If you can find a way to support all this functionality with a single format, that's great, but I imagine it'll get very hairy in the long run. Meanwhile, reimplementing an individual VN engine isn't all that difficult, especially once you've done it a few times, so I'd say a bit of duplicate effort that could be saved by a more comprehensive intermediate format isn't that big of a deal. That said (and I meant to write this in my original post but forgot), your approach is certainly more interesting than "do what everyone else who's tried this before did", and you do have a point when you say "everyone who didn't use an intermediate format failed so maybe we should try doing that instead", so I wish you luck. For now, I'd recommend formally specifying/documenting your .story format and setting up a process/workflow to extend it for functionality it's not yet well-suited for. Also, for your converters, you'll probably still want to write a common library providing VFS/Crypto/Multimedia/Encoding/etc. functionality. I'd even suggest settling on a parser-generator for input scripts. Hand-rolling a parser certainly isn't a bad choice, but you'll probably get tired of it if you have to hand-roll 10 of them, and want something more consistent. That would also have the added benefit that your grammar descriptions are basically specifications for all these obscure scripting languages that nobody's specified before.
  11. Makes it easier to develop it at all, I'd say. I don't think it's a bad choice either; hell, it's probably the best if Mikan is only supposed to be the reference implementation, as OP suggested directly above my post. You could probably throw in some auto-detection magic (...which ScummVM also has) then automatically convert new titles. Though I imagine the conversion process takes a while. Then again, a standalone conversion tool would be little more than an installer wizard from the user's perspective, except you may have to manually give it the input directory if it can't find it from a registry entry.
  12. Oh wow, me and a few friends have been considering developing something similar for a while. Though our project would've been more similar to ScummVM's approach of providing supportive libraries and common interfaces (for virtual filesystems, configuration, multimedia...) for engine implementations that still mostly do their own thing - as supporting a wide variety of weird and wonderful engines with capabilities that range from "scripting language with native functions no more complex than ChangeBackground()" to Kirikiri by transpiling to a single generic "VN format" seems like a daunting and messy task. But hey, I guess only time will tell. (We also would've gone for a natively implemented runtime instead of an HTML5 app, just because we feel the average VN should be able to run on a 10 years old laptop. Just a matter of pride ) Anyway, I haven't looked at the code in-depth yet, will check it out later, but I do have some constructive comments already: (I hope I don't start a flamewar with this but) I'd recommend against using CoffeeScript, for the reasons outlined here. Don't get me wrong, I do like the language, but IMO the situation it's in gives it some significant disadvantages. You can use things like NW.js/Electron or Cordova/PhoneGap to package your HTML5 app as a desktop or mobile application and get some APIs not available in a regular web browser (and be able to link in native libraries, or replace parts of your app itself with optimised native code). I've seen one (original English language) VN use NW.js, and some more (undemanding) games. For example, you could directly access the file system for loading assets. And maybe you'll want to use ffmpeg to decode media formats not supported by web browsers. Sure, you could compile ffmpeg to JS with Emscripten; I've no idea whether that's fast enough for any practical use, but it's definitely going to be slower (and consume more power) than a native build. With these tools, just build ffmpeg natively, write a binding, and use that where available, and fall back to Emscripten-built ffmpeg on platforms you don't have binaries (or the ability to load them) for. As far as I know, NW.js and Electron only support desktop platforms, whereas Cordova/PhoneGap was made for mobile platforms (not sure whether it supports desktop OSes these days). Not sure whether there's such a platform intended to target them all.
  13. In our case, softsubbing was actually the easier option (there's no free Bink 2 decoder - so you'd have to hack one together using a game's DLL - and no encoder either; there's one for Bink 1 videos which can also be played by the Bink 2 library, but reencoding to that would leave us with massive files and low quality). We also have time to kill on this project because we're waiting for something external, so we're kinda in the best position to do this That said, as far as the technology goes, almost every project that has a hacker should be able to do this, since they probably wouldn't have to work for the entire duration of the project anyway. For reference, the feature took me only a couple hours, and I'd estimate it would've taken me about 2-3x that with a less convenient engine. Huge exception being console projects. We're currently (privately) looking for someone to actually make the subs, but if we can't find someone our image editor's gonna do it, who'd also just have free time otherwise. Which leaves transcription and translation. Yeah, resources are always tight on that - all I can say is, songs are shorter than routes and it's fun to do lyrics every once in a while Which is precisely why I'm suggesting fan projects do it. It's one thing you definitely won't see in official localisations. I stand corrected.
  14. There are two points to this thread: First: A project I'm working on (that we're not quite ready to go too public about) uses Bink 2 for video playback, so last week I wrote and just published a proxy library to add ASS subtitle support to Windows games using Bink 2. Sub as fansubbers normally would (except you need to target libass (VLC etc.) rather than VSFilter), drop files into your game directory, done. Probably doesn't work with every such game, since there's a number of ways to use Bink 2 and I've only considered the one that my title uses, but it would be very easy to adapt to additional ones - if you're trying to use this and it doesn't work for your game, feel free to ask me about it. Wasn't sure where else (on the Internet) to post it - I'd happily take suggestions! Admittedly not a lot of VNs use Bink. While Bink, shipping as a DLL with a dead-simple C API, makes this extremely simple, a hacker should have little trouble doing the same for any other game/VN. Which brings me to my second point. I'd like to discuss the idea of subbing the opening and ending songs in visual novels. I'm surprised I don't see it very often - compared to translating the text it's a tiny amount of additional work, you can make it toggleable so people who don't want to see it don't have to, and it provides something extra to what you'd get with the Japanese original or an official translation. I don't really see a reason not to do it. Any comments?
×
×
  • Create New...