An important milestone has (finally) been reached by Sword of Moonlight by realizing the original King’s Field single environment experience of no “loading screens” after hopping into the game. This is something King’s Field fans always gloat about since it was pretty novel back in the day, and even to this day lately I’ve played a little bit of some PlayStation 4 games and am finding myself shocked how much of the time is really just spent on minutes long loading screens. In my opinion I would happily remove the high fidelity visuals in these games for practical seconds long loading screens. Of course, no load screens would be ideal.
I believe From Software published Sword of Moonlight so that it would be carried away by its public. This is a crucial facility no King’s Field Making Tool is complete without. I believe Sword of Moonlight would not have been published in this form except as a challenge to take it up. We should not forget that Sword of Moonlight is modeled on a sword after all.
I wasn't sure whether to make this a release or a demo because I still need to battle test it by building out a full 2 map system using my KF2 project (it's long over due for another map to be added to its demo on itch.io and I've been postponing that until it could properly replicate KF2's no hiccups experience.) Both because I was thinking of making it a demo and I kept shooting myself in the foot with patches to the current release, all the way up to today, I've decided to just write this blog post and refer it to the current patch, which I hope is finally stable. Below are links to the patch files. I'm also going to be posting any future patches to this topic/thread to mark a point of departure.
http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.6.ziphttp://www.swordofmoonlight.net/text/日本語/最新.zip (Japanese)
http://www.swordofmoonlight.net/text/English/Neutral.zipI've been working on this since the last weeks of December, last year. Although in that month I mainly did preliminary work (some studying/planning) by adding layer elements to events that take map coordinates. Technically I think it was possible to just refer to the base layer and set its elevation setting to coincide with a desired layer's elevation. I've tried to cover layers fully in the event system in this patch/quasi-release/project/task. This also includes new elevation limits and a rotation option for action based events and trip zone events. Note, I think in terms of activating things everything is now covered so that activation doesn't span "infinitely" above and below. IOW the default range is now limited to the object or character model bound to the event. (Also there's a "breaking-change" for the circle trip zone which had added its radius to said object's radius, which is no longer done. I've added an option to re-enable this, however I have a feeling the restriction to the object's base/height is more likely to break old games. I had a thought today to roll all of that together.)
One new event "module" (I think I'm calling these modules now, even though I have another plan for literal C# modules for SOM, but that will offer a plugin system for events too, so they will technically be modules too) was added, filling out the last remaining slot in the list (before it requires a scroll-bar) as if fated to fill in this slot (why was a slot left unfilled?) much like the layer system filled in the spaces left by the layer system From Software ripped out prior to publishing. Anyway, this event module/command/operation/instruction (call it what you want) sets a secondary map to start loading in the background. This requires a multi-core CPU. They've been standard for many years now and current Windows systems require them to function, so unless there is demand it will just be a minimum requirement from now on to use this. I did some timing tests and I think that a single-core CPU just won't be practical given how slow Windows is to access files (I'm a little surprised it can stream the BGM file, and this may be a bottleneck) at 60+ frames per second, so if demand arises the only likely thing I can do is add a way to disable this so that loading screens come back.
As a starting point this system functions just like the King's Field games would have functioned (I think all of them do so this way anyway) by connecting two maps at a time. Technically more than two "maps" (i.e. levels) will stay in memory for a few minutes, but two maps will remain in memory. Memory just means they're not on your disk drive. I'm pretty sure from what I've seen online that KF2 duplicates parts of its maps that intersect on the threshold. Currently this duplication is required with this existing system. I am interested in pushing it further down the road to actually display the other map against the current map. Logistically there is only one active map. Things like events only run on one map's events at a time. Under the current system the maps switch out instantaneously. If a more literal stitching system combined their images however, there would still just be one set of events. I do plan to try to carryover monsters, however presently, any monsters visible on map change will just blink out. This version isn't fully complete. To avoid that you can set up doorways (gates) like you will find in most KF games' inter-map corridors.
Edited: To get this new style transition working the new "relative" setting has to be checked on the map change event module. Technically this makes it so the "event" can cover every tile inside its trip zone, but it's also doubling as a "new mode" switch, since the old mode is limited to a single tile, almost like a teleportation booth. (I've thought about upgrading the old mode but it's not clear-cut that the new semantics can work with it without losing something in the process.) One other small thing is you need to rebuild the MPX file (compile/prepare it) since MapComp needs to add some new information to it. (What tile/layer things belong too. This is information it used to emit but was disabled.) Note, it now defaults to "relative" mode.
The fog and sky and BGM is smoothly transitioned, however there's a larger flaw in this version than monsters blinking out, that is there's no provision for transitioning lighting. I have a plan for this, but it's going to have to wait until later this year, and will be a big project. In the meantime there are some creative workarounds for this if someone is really keen on using this in the next few months. What can be done is map geometry can have its diffuse lighting component overpowered either by maximizing the "emissive" component or using the new per-tile ambient system my KF2 demo is using to overpower the ambient component. At that point you will be stuck with having to fake lights by baking any lighting into your textures. But this approach can create a liminal corridor which both maps (with different global lighting) can agree on.
The solution I have planned involves more per-tile settings for most of SOM_MAP's settings. Even ones you wouldn't expect like the fog and names and music. This system should allow for little pocket regions within the maps themselves. (Edited: There will be an option to set the sky model on a per-tile basis, but it will most likely only apply to the current tile/layer and so anytime the sky is swapped out will have to be obscured from view somehow. The sky transition system blends two skies, and if it were possible to blend per-tile skies there would be a "combinatorial explosion" and tiles are square, so it would be tricky to smooth out jagged diagonals between tiles. That said I won't completely rule out tackling this one day.)
Oh, one more small limitation is you should stick to WAV files for music. The transcoding system I set up a while back isn't super efficient, but it will no doubt incur a hiccup if you try to mix it with a new nonstop map transfer. I need to roll that into the new art system cache x2mdl.dll is using so that the conversion to WAV is done one time and saved until the cache is emptied. I will do that when I add sound effects to the art system.
Another little something worth mentioning is I've tweaked the opening movies to load the first map in the background so that the game will load faster, even if players just try to cancel it ASAP... it only needs a second or two, which it can take to do the fade out effect. I'm also going to add this to the Continue screen, but I haven't yet. It will need to start loading while its Yes/No menu is shown. Also if you use do_start/start_mode=1 ("KF1" style) it will load the first map as soon as the title screens begin. Ideally SOM can be a no loading experience like the old 16-bit consoles which used ROM cartridges
Edited: For the record, I want to take some time off to work on art for my KF2 project. So I'm not going to be working on SOM features for a while, and when I return to it I plan to focus on a few things that will make a new KF2 demo shine. One other odd thing that made it into this patch is a new way to turn off the menu system on the item pickup screen. This is how most of From Software's games actually work. SOM works differently IOW. But this new system still feels a little bit unfinished. Obviously it needs animation, but I wonder if it needs something else. (A sound perhaps?) Anyway, you can try it by setting it to Off in the Options menu, or pressing one of the auxiliary face buttons on the pickup screen. Even in an unfinished state it's actually good to get rid of the old Options setting, since it was totally nonsensical (and implemented completely wrong I found out) and so would otherwise be interpreted as the mark of unprofessional product.
https://www.youtube.com/watch?v=TgQUZcwd-JQ
