Topic: STICKY: 2020 King's Field II port progress report (Read 111755 times)

Holey Moley · « **Reply #45 on:** November 01, 2019, 08:10:34 AM »

I've not said much here in the past months, so I'm just going to write something now.

This (https://www.reddit.com/r/KingsField/comments/dniw8b/death_mechanics/) Reddit post prompted me to return to agonizing on how to translate the "Dragon Fruit" item yesterday.

I'm doing a new translation of KF2. I think it's a serious game, so I want to give it a serious treatment. Writing for video games is actually quite difficult, because they are abstract entities, even when they pretend not to be. You encounter in them abstractions left and right. Because they don't exist in a real world language often does not apply.

Naming "items" can be very trying. Ideally you don't want the wording to feel forced. Putting a name on an item can be difficult because outside of things you would put on a grocery list we don't really speak about day to day objects as if they are "items". And when it comes to fantasy elements, if you just label them based on their parts, that doesn't work on the page either. Or at least not in English. Some languages (perhaps Japanese is one) do name things like this. They put together concepts, and sometimes have variable readings for those concepts. If you speak those concepts aloud it can feel like baby-speak in English. If you read Japanese like that, it does feel like baby-speak. But to a Japanese ear it probably doesn't seem that way. Plus Japanese is much denser than English. Video game adaptations of Japanese material often run out of room for their translation, and so must improvise.

So anyway, yes you can do a clunky literal translation of King's Field... but let me just say 1) That's not difficult to do in short order, so it's not worth losing sleep over nor praise, and 2) I don't personally see any value in it. So, anybody can do it if they want to. I probably won't do it myself.

As such, I truly agonize over how to label the objects in KF2's inventory. In the genre these things tend to look like "purple prose" which is something I'm very sensitive to. I think this quality overshadows the genre, makes it hard to take in and embarrassing too. At the same time, fans seem to almost relish this quality, or can't see why it's a problem for literary works. It comes off to me as second-rate media.

But KF2 is very much a beast of its day. Its "Dragon Fruit" item very much functions as an "extra life" and that is I think its essential quality. The game is not ashamed of this. It's an old-fashioned game. That can't be changed. If I can revive KF for SOM I would definitely implement this item differently, but that's another matter entirely.

Anyway, what it does is not actually of concern to me. If "Dragon Fruit" felt like an acceptable translation I would breath a sigh of relief and move on. Unfortunately that's not the case.

Likewise it took me a very long time to settle on how to refer to the "Healing Water" item. I think the English games call it BLUE WATER and DRAGON CRYSTAL. I like the simplicity of these game's translation, but I want to elevate the work more than it does. Its translation fits the context well. But today is a new context. You can see how its translation doesn't literally translate the Japanese either. And neither is "Dragon Fruit" a literal translation. Don't deceive yourself. In Japanese the concept is both more dense and more ambiguous.

In any case, I'm surprised I haven't written on the "water" items here yet. In the demo I put up I reluctantly called it something like Elf Water. I had to use something. But I've since changed it.

I'm confident these water items relate to a concept in alchemy (https://en.wikipedia.org/wiki/Magnum_opus_(alchemy)) and so had settled on naming the colored water that way. The "colors" are Pale, Dark, and Gold. There is a hidden color that is red, or I call it Ruby. I think that is not in the game. But it's in the item table on the disc. The basic water item acts as an introduction to these. I settled on calling it Life Water. That is closer to Healing Water, and I felt relates to the esoteric concept of the water-of-life that seems to relate to King's Field's fountain network too. But it has a video game quality fitting the context also.

Although it often doesn't actually apply, my approach to naming things in King's Field is to assume the protagonist's knowledge of their world, and work out from there. Instead of assuming the player's knowledge, which, at the outset is presumably none.

But the game is very simplistic, so it often feels more natural to steer into simplifications or very prosaic applications of language. You can ask for example, how would someone describe something to another, versus what is their internalized representation of the same concept. Or what is a more technical label versus a more intimate or informal label.

If the Dragon Tree (not actually a tree, nor is "Tree" in the Japanese) fruit is actually a fruit (the character for this in Japanese is more open-ended) then Aleph (the protagonist) would probably know it by the name of a fruit. The closest thing to that would probably be a made up word in a made up language. It's not helpful to do that in this instance. But you see that some "items" work well like this. E.g. Verdite is easily recognizable as the name of a gemstone, and feels like it could be one, and we know what the root Verd- means naturally, and that is reflected in the color of the stone. Believe or not King's Field in many places makes creative use of language. It doesn't always translate from Japanese.

But Aleph is a prince, surely highly educated, and the dragon-tree phenomenon is something that must be well known to people of his day. He would recognize these things for what they are in other words. So I tried many permutations without success. I'm not sure what the demo calls it. Something I landed on temporarily (much like Elf Water) was "Dragon Eye". It was the least bad I could come up with at the time. I find myself wanting to use apostrophes, but the kerning on the fonts is often that they serve to introduce an additional space into the concept that I don't like. I may try to devise a technical fix for that later.

Anyway, I did a deeper dive into the subject matter. My instinct was if nothing else, the best would be to just call it "Fruit".

Part of the problem is I don't believe the object can literally be a fruit. Even though it looks like an odd drupe... it's transparent, and seems large, but I don't know if the scale is exactly accurate. Not a fruit in the sense that the thing in its middle is a seed that could be planted to grow a "Dragon Tree". Edited: I think this has implications (and flavors the narrative) but to be clear, I just don't like how it looks on the page. Or especially in the menu system. I hope this doesn't become a problem since KF has a lot of "dragon things". I feel like the emphasis is not appropriate here, and the phrasing is too unnatural. (It doesn't change what Meryl or the manual might say on the subject.)

The dragon tree doesn't seem to work like that. It's more like a vine network that grows up through the ground from the underworld. That is to say, you can't plant it on the top of the soil, or it seems that would be unbefitting its function. In KF3 the tree is set up to be intelligent, and I don't know, possibly an aspect of the earth god Valad if not Valad themselves.

And the "fruit" obviously has a weird quality of resetting a person's world. It's not even clear the fruit is consumed. Aleph would know about this. Unless when you reset via the fruit you reset into a world that is cut off from all others. I think that's overcomplicating it. Others must know of this experience. And so would many. In this quality we can understand that KF's setting is much more trippy than our own. This kind of thing is just part of life in its world.

Anyway, though I don't want to deconstruct King's Field within the games themselves, and I can't as long as the project is merely a translation, my sense of the dragon tree is at minimum its structure is a clonal colony's, that is not like a regular tree's, but closer to a fungus or parasite. So it doesn't work like a simple seed bearing tree. It reproduces asexually more or less, and if these fruit things have a purpose, it's not its own reproduction.

I settled on calling it a Fruit Body taking inspiration from this (https://en.wikipedia.org/wiki/Sporocarp_(fungi)) anatomy of fungi. It's a kind of organ that spreads spores. I want to hint at that, but I like the quality of the double-entendre here that suggests it's a new body, or extra-life. In its odd choice of words is the hint of something less conventional, that contributes to an overall air of things not being what they seem.

When/if I get to reviving King's Field my extended concept for this is that the dragon tree functions as a factory for making the monster population. Its offspring is the monsters. And maybe like a fungus it sustains itself on the dead that seep down through the earth into the underworld where it lives.

In the revived/revised series (not this series) I think that it will be called Dragon Fruit, but I will also have the opportunity to recontextualize it and change how it functions within the game world at the same time. In that case it may serve more like mana for the monster population, or have dual roles, but as a consumable object it will work more like a straightforward healing item. (It will make an earth "field" identical to how the Earth magic would. So it amounts to just a way to use the Earth magic without consuming MP, or without being able to otherwise.)

Holey Moley · « **Reply #46 on:** December 16, 2019, 05:53:47 AM »

Here is a teaser of getting the animation out of KF2. I'm trying to boost my excitement levels by way of having some personally meaningful model files at my disposal.

I don't think this software can work with sparse animations where not every single frame is represented by a snapshot of the mesh. In that case I will have to add something like that somehow.

EDITED: https://github.com/zturtleman/mm3d/issues/106

Conveying 3D model data is a real bane of these projects. It's never straightforward. I've written so many 3D model transformation programs in the past years since working on SOM and it feels like they never really get you very far.

I'm doing this with x2mdl by letting it do the heavy lifting and instead of outputting a MDL file convert the would-be MDL prepared data into this MM3D format. I'm working on developing it, so it puts me in a much better position than using any old software.

Holey Moley · « **Reply #47 on:** December 31, 2019, 11:09:18 AM »

I've progressed with improving the animation code to be able to work with the animation data. I quickly added some textures to the headeater just for this screenshot. I will have to do it again correctly later, after I have a more correct way to do this.

I had to play with the screenshot because KFII's textuers are super dark and low contrast. I tried to make it look more like it does within the game. I think they are that way to squeeze more dynamic color out of the PlayStation, after lighting calculations.

Even though this animation goes for about a second (I think) at 30fps (MDL/SOM default... I think) it's only made out of 3 or 4 frames. I think. I have to work on locking the time slider into the actual data frames yet. The first section of this animation is left blank because the unanimated coordinates are used instead. It took me quite a bit of work to make the code I had from the MM3D project more sophisticated. It really wasn't set up to do actual work with animation data. I think it was mainly used to visualize Id Software's file formats.

I guess I've been taking it slow and easy lately also. So I've been drifting through my days more than usual... usually I'm pretty much a workaholic, so I don't know if it's right to say "usual" but I don't know... I've been without direction a lot lately. I hate these weeks around Christmas when everyone kind of retreats and the world stops turning. It plays with my mood. Plus I'm a bit burned out.

Holey Moley · « **Reply #48 on:** January 02, 2020, 11:14:26 AM »

This version is cleaned up with no "photoshopping" but is still nothing like in the game. It's hard to describe what the game does to transform the color. I would be curious to know how it does it... like if all PlayStation games work like that, or if it has a few modes to pick from, or if it is able to do custom modifications on the pixels before they're committed to the frame buffer.

I know PlayStation games can read from the frame buffer, but I've read they can't directly modify it. Maybe they can "blit" to it to modify it. The end effect is it's a little like a custom "shader" compared to any built in graphics modes supported by the likes of OpenGL or Direct X prior to shaders. I.e. GPU micro programs.

FWIW I added anisotropic filtering to fix the blurriness, and the enhanced OpenGL specular model (KFII doesn't do specular calculations but kind of looks like it does) and tweaked the smoothing groups and brightened and added contrast to the textures. I don't do that with the real models used by the game, though that's kind of problem because SOM's stock models don't work like this, so you can't mix them.

EDITED: This gives me an idea to work on an animated GIF feature. There's already a (frankly odd) feature to make PNG or JPG slideshows. There is a way to make a GIF with wxWidgets that I think would be nice for sharing animations online.

Holey Moley · « **Reply #49 on:** January 03, 2020, 07:13:21 PM »

This (sorry for headaches induced or difficulty reading this page) is the result of working on a GIF creation feature.

It's interesting to note that the mouth never actually closes. I guess when you see this in first-person (from the direction of the mouth chomping down on you) it's impossible to notice, or might've even looked weird. Another possibility is this way there's less frame data, though I'm unsure about that myself. It's certainly less work for who animated it.

Holey Moley · « **Reply #50 on:** April 23, 2020, 01:37:36 PM »

Update on progress with animation editing/import

Note, I just noticed while comparing this to screenshots from KF2 there are blue colors in the headeater's body. That explains why it's on a different texture page. I will have to hunt down the alternative texture.

This is just a test mockup. Work on this is going slow. I'm going to have be very thorough about details every step of the way, and some questions I can only answer by locating/examining the animation code.

This image is of an animated model converted to an editing format (MM3D) and cleaned up and cross-referenced to its textures and then exported/imported into the runtime format (MDL) and displayed in the profile editor. The animation data is in there too, although KF2's animations are somewhat simplified compared to SOM and I'm not yet sure what to do about it. KF2 combines the idling and walking animations into one, or just maybe always is on the move instead of standing still. And its animations just walk where they stand from what I can tell. At least this one does.

~~I'm thinking of adding some custom code for an alternative center (cyan) CP that moves independently of the model data. If so its red component would be 1 instead of 0 maybe.~~

Something else I'm planning to do is to try to somehow mark new MDL files to use millimeters (1000) instead of binary (1024) to represent 1. It will make it more practical to be able to line up the animated coordinates. I'm somehow still planning on using a MDO+MDL system. A problem with MDL is it has very low precision texture coordinates that don't wrap/repeat, and it isn't an indexed format. It's just complicated to combine that with MDO. I believe they will have to be tightly married to each other. MDL has unused data among its vertex data, that is where a fourth component would go. Vertices are 3D, but there is room for a fourth. I think my plan is to store in there how many MDO vertices overlap that MDL vertex. (Alternatively it could be more complicated by storing an index into some other part of the MDL file that's not needed, since it wouldn't require lighting information for example. But that wouldn't mean it would be less coupled to its MDO file.)

I think generating new MDO files will help because x2mdo seems to break its MDO files up into chunks in a way that probably slows things down.

In theory chunks could be helpful for transparency sorting but I'm pretty sure it doesn't do that with the chunks. I want to implement a full BSP system to get perfect transparency ordering in the next year or two at some point. The MM3D code has a BSP system for this, so maybe I can just copy it. I haven't tested it, though I will find out if it does a good job when I get to the slime monster in not too long. I know SOM doesn't already have a system for this because the crystals and things in my demo currently cause weird optical illusions when they spin around because they do things the brain isn't able to make sense of. I think staying with low-poly gives us the benefit of being able to do things on the CPU that would be impractical otherwise. That means we actually are better quality, just less quantity.

Holey Moley · « **Reply #51 on:** May 02, 2020, 03:04:42 AM »

Lately I've been trying to transfer the NPCs and monsters from the disc data to SOM.

I've run into a problem because there are more than will fit. Part of this is because there are two layers and I made SOM to not put map elements in the layers, which I think is the right decision, but now I can't think of a path forward other than than to attempt to increase the limit.

There's no telling how difficult it can become. There's a small chance MapComp and som_db will just work. SOM_MAP has to be reprogrammed.

Holey Moley · « **Reply #52 on:** May 03, 2020, 08:36:54 PM »

I don't want to make a series of updates on this speed bump, just for the record, I worked all day yesterday on increasing the enemy limit, and how that shook out was I started testing MapComp and the player because if they didn't work out there would be no point in doing SOM_MAP (I brainstormed some other strategies too) and MapComp presented no problem, so I could test the map with the player (I hand edited the MAP file bypassing SOM_MAP) and that went about as well as I was expecting, meaning that it would require some of the most extensive "reprogramming" I've ever done for SOM.

Normally I wouldn't touch something so extensive, except KFII is a special case. At some point the original EXE files will be abandoned, simply because SOM should be cross-platform someday after it's established, which is why I don't think it's worthwhile to solve all problems with this version of SOM, because that's harder to do with a program you don't have source code for.

Plus, as seismic changes go, increasing the limits of map placements isn't so integral to be a major disruption, but it is something that touches so many places in the program that means to change it all references to these lists must be reprogrammed, which amounts to a lot of changes in the program.

To deal with the bulk challenge I added the ability to scan for a range of values inside the program instead of single values, which I'm surprised it took me so long to do this. Then I just went through them one-by-one taking down the addresses and making the necessary changes.

I think it's good to increase these limits now that there is a layer system, meaning that there's potentially a lot more real-estate to fill, and I think 128 was a very tight limit in the first place, going by how dense the spawn point placements in KFII actually are. (I sometimes wonder if From Software issued a directive to hamper SOM just in case it spawned a community that made From Software obsolete.)

At this point there are two things left to do. The next problem is SOM_MAP obviously, which I worry won't be as easy because the tools tend to use C++ style design, whereas the player uses C style. It's generally more difficult to make sense of the C++ style code. Normally I manage to do what I need to with the tools, but if the scope of this change proves to be an order of magnitude more great than the average change it can end up being a real slog.

Finally, I have a feeling the save file system will have to be altered somehow to accommodate the added enemies.

I've used a fixed buffer that can go up to 512 enemies, but the MPX files have a counter for this, but they tend to set the counter to 128 instead of the actual number of enemies present in the MAP files. I'll have to work out the details later.

Holey Moley · « **Reply #53 on:** May 09, 2020, 05:17:41 AM »

Update

So, it turned out SOM_MAP proved very difficult, but I've finally finished the last of it today. I had two or three days that I was unable to work or was in town. It was a solid 3 or 4 day job.

There is a map_enemies_limit extension that can go up to 4096 but is 512 by default. The player is unlimited. SOM_MAP can go up to 65536 but I chose to artificially limit it.

I still have to look at the save file. I don't know if anyone else has a use for this but I plan to make a release out of it in the next week since it represents a body of work. I may make it a demo release since I feel like maybe it should be tested more longer.

Holey Moley · « **Reply #54 on:** May 10, 2020, 05:00:40 AM »

As for save files there isn't flexibility there, which is pretty much as I expected.

My plan is to replace the fixed size map records with variable size chunks and to replace the BGM field with the map's file name in order to gradually open up the possibility to use more than numeric map names and more than 64 maps and potentially different file types from MPX.

These new save files won't work without SomEx. That goes without saying. But they will cause a problem too because som_db.exe doesn't check that the map number value is less than 64, and if not it overwrites program memory that is beyond the map data.

I'm thinking about calling them SOM files instead of DAT files so that if they are opened with SOM_EX they will start the game with that save file loaded. This will keep them from possibly being used with the old GAME.exe file...

There will have to be some metadata in the save files to locate the game they belong to since it's not necessary to keep the save folder in the game files, since the game files may even be on a CD-ROM although I think those days are practically long gone.

Note, there are already SOM files that are project files, which can be more than one in the project, however it's not difficult to tell these apart. Or at least in theory it isn't. SOM_EX can also technically open up PRF and PRT files but that's more of an unofficial thing. By "open" I mean you can associate the file format so when you double click on a SOM file it opens SOM To that project. With this new plan you can start save games this way too. It's not really meant for regular players since SOM files are more for developers. Developers have more use for managing multiple save files that jump into the project at different save points.

Holey Moley · « **Reply #55 on:** May 12, 2020, 01:49:50 AM »

Off the technical subjects, I finally found a word for the "dragon grass" for my translation. It's a botany term called Turion that I feel captures its more peculiar qualities.

I think that since it's a "grass" it must be just the tip of the iceberg of a connected underworld root system that I call the "dragon tree". Maybe KF3 translates it as a tree? I don't know. I'm not sure myself if I ever "spoke" to the tree in the elf temple in KF2. I mean, there are numerous trees before that one and I assume they don't speak, so I'm not sure it would've occurred to me to speak to it. I have no memory of it being called a "grass" in the English game.

But I've long known the Japanese name is grass.

A Turion (as best as I understand it) is possibly a separate plant or at least a structure that has all of the morphology of a plant, which grows from a bud. I imagine the dragon tree is underground and it kisses the surface making a kind of bud there that sprouts these surface structures.

I think keeping to the literal representation that this bud produces only a single fruiting spur that dispenses their magic fruit. I don't like the crystal structures from KF3. I imagine the golden structures from KF2 are mostly hollow inside and very light, like a dried gourd. That you could easily knock them down, they are delicate, not wooden, like weeds.

I think I will just call them Turion but explain their connection to the dragon tree. I'm not doing a literal (word for word) translation, but I'm not going off script either. The English game is pretty literal except where it spices things up or dumbs things down.

I'm not doing all this work to make something dull or droll.

As a recap I'm calling the "dragon fruit" (DRAGON CRYSTAL) a Fruit Body and the healing water I'm calling Life Water that is an allusion to the "water of life" but I don't want to use "of" and that's too on the nose and "life" just sounds like old school video game lingo. The "fruit" is literally an "extra life" but it can't be called that.

The water is actually very much like the "spice" in Dune that's called the "water of life". It's actually a bodily fluid of the worms in Dune. The spice like KF2's water causes death upon withdrawal. Arguably this element of KF2 could have come from Dune's spice. But too there is "alchemy" symbolism in KF2 and I know that the "water of life" concept is in alchemy too. I think that the trees in the villas are almost definitely a replica of the "tree of life" in the form of the sefirot, in which case the "water of life" is a natural pairing.

What I'm very wary of in my effort to translate KF2 is anything that "sounds like a video game" in its text. I want it to seem literary so it can be played without these kinds of distractions.

Holey Moley · « **Reply #56 on:** May 14, 2020, 10:33:33 AM »

Follow-up

The new save files are finally working... all that's left is renaming them and loading the game automatically at start up.

I'll likely publish a release tomorrow with details. There is an extension for setting the file extension so you can associate save files with your game when it's not running through SOM. And there's even an extension if you want to keep the old save file format. It won't work unless your game fits into that format.

The extension will be "som" when using SOM and this means you won't be able to see those save slots if not using SOM, which might be welcomed so you don't mix your development saves up with regular games you're playing. The extension is called "player_file_extension" and it defaults to "som" so there is no differentiation by default. The reason it's good to have is because you can't assume players have SOM installed. Plus the DLL versions can differ, and there are some slight differences with the taskbar and the splash screen.

The auto-load system uses a new LOAD variable in the SOM file that you can theoretically manually set to a save game you want to load at start up. After I figure this out I may add something to control what happens when you "die" so not to waste precious electricity loading the starting area.

Holey Moley · « **Reply #57 on:** May 19, 2020, 11:58:50 AM »

Today I looked at the monster data. It's pretty weird.

~~Some of the monsters appear to be ill-placed on the map. It's possible they are bumped into place by the clipping system.~~ I can't see that they are rotated on the map. It's possible they always start out oriented toward the player character.

Strikeout: While it's true that "Jose" the fisherman seems to be underground so that the floor must lift him up, the prime offenders for misplacement seemed to have been the krackens. I figured out that either I mixed up their body parts or their parts are placed on the map in the opposite order of the mosquitoes'. Another weird thing I've noticed is the rotation for NPCs seems to be reversed than what objects and items use. Anyway, that's the only way to make Jose face SW. Like I say later I think most monsters aren't rotated. But I know that some must be, like stonefaces.

There are 40 large records that are kind of like SOM's profiles (PRF files) but I kind of suspect it's more like there is one for every monster you can see, like if there are two mosquitoes on screen there is a record for both. That would mean they have to be strategically placed to avoid overlap. The other obvious difference is SOM_PRM covers the entire project, whereas these are unique to every map. I'm not sure exactly how I intend to deal with that difference. Right now I just have one profile per model. But at some point it will have to be specialized, at least on a case by case basis.

The double body monsters (e.g. mosquitoes and krackens) are actually two monsters apiece. There is no way to figure out which monsters are paired together that I can see. What I suspect happens is they just behave identically except the accessory part has a ~~smaller~~larger clipping shape. I think that likely an event is linked to the main part so upon its death it takes out the other, and the dropped item is in the other part. That way it never drops two items.

Strikeout: I want to chop this up to my seeming dyslexia. I remember vacillate back-and-forth in my head about which was which. I regret writing wrong information.

It's possible they are linked by an event that fires when they spawn, but it seems like it'd be unnecessary. I guess technically for that to work they'd have to have the same chances of spawning.

This seems like a very crude system. It may be that there is something like SOM's MAP and MPX files so that the map editor didn't have to work with such a crude strategy.

I'm intending to add a body part system to SOM.

KFII's monsters behave completely differently from SOM's. That's obvious with the flyers, that will require custom AI routines, but I think all of the monsters move laterally and rotate independently more like how you can control the player character. It might look a little cheesy but I think it probably works better overall. I don't know if it will be practical to try to make it look less cheesy anytime soon. But I think the headeater should move this way since it doesn't have a lateral body plan. So I will probably make the others use the same system.

They also seem to move more sporadically but that could be the irregular frame rate on the PlayStation and emulators. I can't tell if it's an intentional effect or not, but it feels less robotic than SOM.

I have a feeling a lot KFII's charms are just accidental stuff that would be hard to replicate with SOM. It's more of a worry. Like, I'm afraid I'll get everything in place and it still won't feel right.

I think in those 40 records there may be more positional data, and they may even have patrol routines in there. It's hard to tell. There is variable-length data that looks like it must be either 32-bit pointers (offsets) or 16-bit offsets that happen to come in pairs for which the other is almost always 0.

It's hard to think what that could be other than sound effects and particle effects data, but there is too much for that, so I wonder if it's event data or patrol data. I think it may be all of those things piped through a more low-level event system than SOM uses.

I really don't intend to investigate that stuff. Tomorrow I'm going to see if any of it makes sense for improving the map positions and I have to get scaling information too.

Speaking of scale, the kracken model is actually the same size as the giant one. So all of the smaller ones are technically scaled down, which is kind of weird. It means it must have started out as a "boss" monster. I have a feeling either the giant's pixels (texels) will be huge or the children's will be tiny compared to everything else, or a mix of both.

The texture mapping on the piers and bridges are not even square. I'm going to have to rebuild those textures somehow. I really don't like it when texture maps are rectangular or scale varies in games. It looks like very sloppy work. I see it in $60 video games all the time.

Holey Moley · « **Reply #58 on:** May 21, 2020, 10:34:33 AM »

So I'm at the point where the monsters/NPCs are positioned correctly on the maps.

So now I must focus on producing the animated models. As a first tonight I had an idea to use the "Merge animations" function from my modeling software to attempt to take a model that is prepared in Blender and combine it with animations that come straight from the source data, since Blender can't help with animations.

I just wanted to see if the mesh happened to be compatible. But it lost 2 vertices during conversion, so there wasn't a chance, and I reckoned it would probably be way off because I started with the kracken that has hard lighting facets on its lower body, so this means many vertices would be generated to produce that lighting, so what I ended up doing instead is something like what I'd considered doing to merge MDO and MDL files except I decided to do it in the "Merge animations" function in the modeling software instead.

What got me thinking this way is I'm going to have to merge the kracken and mosquito body parts anyway to produce a demo since I'd rather put the multiple body part thing off, possibly even until after my deadline, since it seems pretty nonessential.

I also am going to put off combining MDO and MDL if I can, just in case I run out of time, since the limits of MDL are the limits of the PlayStation and KF2's data is coming from PlayStation data, so the limits don't really come into play.

It's good to be able to use Blender also, since I can work faster with it, and some things I have to do to make the do_aa extension work are very hard to do without much better modeling tools than my custom software can do so far. It's also not as accurate as Blender, so I don't want to risk losing information, mostly around texture maps.

A big difficulty for do_aa is how x2msm slices up the models. That's a long term problem that I'm not sure how it will be addressed, but it will be after a much more mature art tool chain appears.

Especially with the secrets and traps that embed into the map geometry, that are animated, it is a problem, but this new "Merge animations" strategy will help with it a lot. I can chop up the object parts in Blender and then it's easier to fix their animations after than to do the chopping in the custom software.

The "Merge animations" function didn't support soft animations, so I had to implement it tonight, and that meant I could implement it how I needed it, which is to compare the positions of the vertices in the merged models and apply the animations from the animated set to the overlapping vertices in the unanimated data.

Tomorrow I'm going to see about merging the two halves of the kracken into one model, so that's out of the way, and from here on out I will mostly be working with the model data until everything is in place. If it gets tedious I'll switch over to a programming project.

For the next demo I want to publish, I want to get the way KFII's tiles have different ambient light levels working, and I want to get the weapon/arm animations working. It won't likely have sound effects, and the monsters will probably not walk around. I might try to get a simple idle sound effect working for each monster. And I think I want to get the compass in there and matching HUD display. Doors, etc. should be working.

Since you can see every single monster I think it would be too crazy to have them walking around at the same time. There aren't as many monsters as I originally thought because the double body-part monsters were two monsters before I knew what they were. Also for some reason there were some monsters that look like they're probably junk spawn points. There model IDs were assigned to 254, which doesn't look like it could be a real number. It could mean they were deleted. I might think there is something to it, except they were all clustered around one room, which I don't remember being anything special in the game. So maybe they were a removed enemy type.

After removing the body doubles and these dummies and Jose the NPC, there are only 131 enemies on the map. It's possible there are more on the other maps, but had I known the number would be so close to 128 I might have held off on doing that two week job of increasing the enemy limit!

Holey Moley · « **Reply #59 on:** May 22, 2020, 03:03:08 AM »

The kracken behavior is pretty unorthodox compared to SOM.

To begin, the mantle part model isn't elevated to sit on top of the body part, so it must snap on according to some system, but I don't see that information in the data. I haven't seen records for the equivalent of SOM's "profiles" so it could be in there conceivably, but that could be hardwired into the program.

Its walking animation runs one frame longer than the body animation. I can't tell if it's designed to be out of sync, but 1 frame isn't a lot.

But the kracken AI actually switches the mantle between the walking animation and the attack animation, which kind of looks like breathing.

I think maybe it stops moving when playing the attack animation (when not actually attacking) to create the illusion of catching its breath.

Needless to say SOM's facilities are quite robotic compared to this. I'm not sure how to go about replicating this behavior, since it requires a quite complicated description of how to behave.

Also, I still haven't fully understood the animation format. For the kracken its walk/idle and hit animations weren't coming out right. I figured out a heuristic to detect the difference in its case, but it could just be nonsense that won't hold for other models. There's a lot of extra data I can't make heads or tails of. It's seemingly nonsensical. The only thing I can think of that it could relate to is if the animations are really softer than what I have, but I can't see that visually. The Sony system uses a much more CPU intensive blending of multiple frames, which could account for this extra data, but it doesn't look like that.

Edited: One time a kracken appeared without its mantle. I don't think it was defeated earlier, I think that sometimes they just spawn without one. In theory the mosquito may too.

simple machines forum

News:

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report

Author Topic: STICKY: 2020 King's Field II port progress report (Read 111755 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Archive (pre 2023)| Projects, demos, and games Information| STICKY: 2020 King's Field II port progress report

Author Topic: STICKY: 2020 King's Field II port progress report (Read 111755 times)

Sword of Moonlight|

Archive (pre 2023)|

Projects, demos, and games Information|

STICKY: 2020 King's Field II port progress report