Sword of Moonlight > Devs

EXIT: Unleashing monsters

(1/6) > >>

Holey Moley:

--- Quote from: http://www.swordofmoonlight.net/archives/sword-of-moonlight/2020/05/unleashing-monsters ---It turns out King’s Field II monsters exceed the limit Sword of Moonlight imposes. I feel like the limit doesn’t make much sense, but From Software saw fit to limit it to 128 so-called enemies for a given level in your project’s video game. KFII treats its characters and monsters identically, and caps them at 200 on each of its two-story zones. SOM had a layer system that was disabled before it was published. I’ve since restored it, some time last year I think. It would have allowed each layer to have 128 more monsters, in which case its limit may have been 256 for a two-story level, which would have exceeded KFII’s limit.

When I restored the new layer system I decided to limit it to level geometry, so that layers don’t bring in new elements like monsters. That’s a better system because I imagined layers can be used to tackle the artistic limits of SOM’s grid based level design. I suspect not many game systems use grids any longer, but it’s something I feel is a great strength for SOM. I think there is lost wisdom in many of its anachronisms. By putting monsters on layers it isn’t clear what happens when they cross between layers or if that would even have been possible in the original system that got disabled. By artistic limits, I mean things like, you might want a layer to just be a ceiling for example, so you can have a lower ceiling on some section, or just have the elevation of the ceiling be independent of the floor. If you can’t do that you have great limits in design possibilities since the only other way to do this is to make new tile models for every combination of floor and ceiling. The new layer system can represent many things like a plane of water or mist or fog or just plug holes in the existing tile configuration. Anybody who’s ever worked with SOM runs into these limits.

But even on a single layer 128 seems like a very tight budget for video games. Monsters are seen as the sole purpose of video games, so it’s kind of bizarre that From Software set the so-called NPC limit equal to 128 also. Your average King’s Field game has many monsters and very few NPCs. And KFII’s maps are only 80×80 tiles as compared to SOM’s 100×100. In KFII’s levels the first thing you notice is how dense they are with monsters. These are really so-called spawn-points, which means that you never see this density in the game because they don’t all spawn at the same time.

I have all of these numbers handy because I’m working on porting KFII to SOM, and I could not make progress on that as long as this 128 limit remained, so two weeks ago I steeled myself to do whatever it took to overcome it. It was a grueling task as I knew it would be because monsters are a systemic aspect of SOM’s programs. Normally I wouldn’t work on this problem. I would wait until SOM is mature and I inevitably make a next-gen version of it, or write a specification for an interoperable media standard based on it. Luckily if you were to draw a diagram of SOM’s structure spawn-points would be out on the edge of the structure, meaning that they are self-contained and independent of its infrastructure, like leaves on trees. Because of this, even though they are referenced in a great number of places inside the program, they’re more like an ends than a means, or not foundational in other words.

Despite this, it still took me a long time to complete work on this. It’s a bit absurd because how normal software development proceeds if you do have fixed numeric limits imposed, it’s normally as simple as pressing the delete key on the number and inputting a new upper limit. But SOM isn’t like that, it’s like hacking a video game without source code. It isn’t always, but it is for anything like this. But since I’ve done it once, if there was cause to I could increase the limit for the other map elements. It would still take a lot of work, but less since it’s been done before.

Another aspect of this task is the so-called save file has to track spawning figures for the additional monsters. Enhancing the save data has never been done before now. I had to plan for future compatibility in addition to adding the new data, and because the new flexible save files can’t be used by old versions of SOM I’ve changed the file extension from “dat” to “som”. The “som” extension is also used by project files, which can be associated with the SOM_EX program to open them in Windows Explorer. Likewise the new save files can open the player component directly into the save game, bypassing all of the starting screens and menus.

I’m releasing this work and writing about it to mark the occasion even though most can’t see the benefit of relaxing the monster cap. The save file system is also included in this new release, but I caution to use it with care because it’s new, so I don’t recommend using it to play games. There is a way to disable it. I was going to put this release forward as a demo but I don’t think the extra work entailed warrants it. I just recommend maybe skipping it or waiting for patches. I have increased the minor version number since I think this version is going to new and exciting places, and I think there will be patches to this release for some time since there are some loose ends in the layer system that I intend to iron out with my KFII project very shortly. The new feature doesn’t require patching, but I think that I will just be slipping in little things here and there that will help fill out this important milestone release.
--- End quote ---

I'm penning this blog post at the end of a long day and it occurs to me I likely need to go over it again, but I don't have the energy or presence of mind to do it right now. But I want to go ahead and put this release out. Mostly these blog posts are just a formality. I do my best.

The new release is here (http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip) although I recommend updating with Subversion and using the updater software. I recently updated some of SOM's art files that isn't part of any release, just spur of the moment touch ups.

Other than the save system changes there isn't a lot to gain from this release, but I will probably patch it later with some new unrelated developments. This is kind of a trial release but I don't feel like putting it out as a demo.

I'm releasing it and writing about it because it constitutes a body of work that I want to document and it's a big development too I think, but unless you're working on a game project that stands to benefit from more monsters per map, it's not something you can do much with except to read all about it!

I'm filling tired right now... I hope it doesn't come through in my writing, but I can't wait to wake up tomorrow refreshed and finally not have to stare down the barrel of this unexpected hiccup any longer.

It represents one more step closer to realizing KFII via SOM. I really want to get to a point with my project before the end of the year that is semi-complete and worthy of sharing. I really hope there's enough time. I want to at a minimum have all of the content in the game and get to the point where it's in a playable state even if there's still room for improvement before December. I want to use December to promote it and not to work on it. But I have no idea if there's enough time or not. I'm not good with time estimates. And even when I can estimate time reasonably I'm always off by a factor of two or more.

Holey Moley:
Update

I completely scrapped what I wrote yesterday for the blog post, and did it from scratch. I've also patched the DLL to make it refuse to load newer save files than it's designed to.

I'm going to come back later today or tomorrow and write down the details.

Holey Moley:
Patch

It turns out this release didn't work for me with the "release mode" build, but the problem had to do with command-line arguments (to the launcher) so it's not something you're likely to notice, but this patch fixes it so it works with arguments.

Almost everything I do uses arguments, except I tested it before publishing through the new save file system, which doesn't have any arguments. With arguments you can make Windows shortcuts to everything in your project, so I don't go through SOM_MAIN or SOM_EDIT to do things. Because I'm always working on features that would be a nightmare, since I often have to rebuild the SomEx.dll file, which you can't do while SOM programs or games are using it.

Holey Moley:
Details

Sorry, I almost forgot to share some specifics.

The SOM_MAP enemy limit now defaults to 512 and can be increased up to 4096 with map_enemies_limit in the [Editor] section of the config file.

Technically this maximum can be 65535 but I soft limited it to 4096. It has to fit into a 16-bit CPU instruction, so it can't go higher. I don't think games need this to go higher on a 100x100 map. 65536 would be the more natural limit here, but it won't fit. Usually the limits are powers of two, but not always, like the item limit is 250.

The player doesn't actually have a limit, so if you could make your MAP file without SOM_MAP you could go until the game grinds to a halt or runs out of 32-bit address space.

The save file extension can be changed for standalone games (playing games without SOM) with player_file_extension in the [Player] section of the config file. This is limited to 15 characters. Extensions are usually 3 characters. The reason this exists is so you can "associate" your save files with the game and not have conflicts. I think if SOM is installed the difference between using it and not is negligible to nonexistent, but it may not be installed, so a properly published game would want to provide a default setting for this extension. It's in the Player section since ultimately end users are encouraged to change it.

Finally do_2000_compatible_player_file ([Player]) is an opt out just in case there's any reason to do so. It doesn't work unless the game can fit into the original save game format, and it forces the "dat" extension and removes extra information in the file name.

Holey Moley:
Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip

This is a fix for a loop that was still counting up to 128 enemies when loading layers in SOM_MAP.

Navigation

[0] Message Index

[#] Next page