While getting the Patreon rolling, I’ve also been planning out code mods. Specifically I’ve been reading up on Python’s import machinery and different approaches to monkey patching. Monkey patching is a much-derided programming technique where you rewrite or add to portions of the code while the program is running. If this sounds crazy, it sorta is, but it’d really give modders the run of the place. It’d be a good fall back for situations where more formal extension hooks don’t exist.
I’m looking to give modders @before, @after, and @instead decorators that would let them hook their own functions into existing methods, but reversibly and in the load order of the mod list. I’d publish a list of recommended places to override, of course.
I’ve also been preparing the data definitions (character types, transformations, all that stuff) to make it easier to turn them into data that I can load from files. This is going to benefit both modders and myself because it’ll give me a more convenient way to maintain both a patreon version and a non-patreon version.
Here’s a progress update on Steam Workshop support. I’ve got Fleshcult connecting to the Steam API and fetching the mods you’ve subscribed to in the workshop. It took some fixes in the Python wrapper I’m using. As far as I can tell, looks like there’s one other person who’s using Steam Workshop from Python, so I’m further off the beaten track than I’d hoped. I’ll be sending the fixes upstream soon.
There’s still a fair bit to do before it’s usable. Uploading mods is much more complex than downloading them. It’s the game’s job to upload the files and attach metadata to them – descriptions and tags and so forth. Once I’ve got the uploader working, I’ll be able to test the whole process from end to end, and from there it’s not too far to releasing it.
EDIT: Done, moving on to hooking up the Steam Workshop API
There’s something I’ve been putting off, and I need to get it done before modders go writing any Python mods. Fleshcult is currently written in Python 2, which is no longer supported. There’s a code library I’d like to use to talk to Steam that requires Python 3, so upgrading is suddenly a priority. In any case, it’s better done sooner rather than later because I don’t want to break code mods.
Translating code from 2 to 3 is mostly automated, but it’ll require some manual intervention here and there. It’s hard to say how long it’ll take, but hopefully it’ll be a non event. As a spin off, it might be better behaved with unicode install paths – Python 2 is notoriously error prone for that.
I’ve been making a lot of progress building the mod system and adding HTML/CSS modding specifically. I expect I’ll have something for modders to experiment with before Christmas, but hooking it up to Steam Workshop will have to wait until the new year. Changing the underlying behaviour of the game will arrive later.
I’m mindful that after I expose something to modders, doing a big refactor on it will break everybody’s stuff. So whenever I delve into the details, there’s a pressure to get things right the first time. That said, I suspect the smarter approach is probably getting something rough out quickly and then reacting to what people actually need.
One thing I’m over-engineering the fuck out of is giving modders lots of ways to add their stuff without overwriting stuff from other mods. Maybe if I pull that off Fleshcult modding won’t be a shitshow of bugs and load order tweaking? Time will tell.
Remember how I was struggling to make a client-side version of Fleshcult? I’d settled on an approach, but it was still a significant amount of work. Now I’ve found a huge short cut.
There’s this thing called Python CEF and it lets me build a web browser engine into a Python program. I’ll get into the technical details below, but the end result is a totally self-contained version of Fleshcult that runs locally as an application. The downside is that it no longer runs on mobile, and making Mac and Linux versions will require some additional work.
I’ve been working on it for about a week and I’ve already made a lot of progress. I can play through encounters and recruit minions, but there are still of a lot of details to attend to. Hosting the server-side processing has been costing me about $60/month for the past 8 years, so I’m feeling pretty stoked to get that monkey off my back. It also opens up some interesting possibilities that I’ll get to in the next post.
My biggest regret is that Fleshcult is a server based game. You click a button, it sends a request to the server, and all the processing happens there in Python code.
There are several disadvantages:
- It doesn’t run offline. If the server goes down, nobody can play.
- There’s no easy way to keep multiple versions of the game live. I was always careful to keep saved games backward compatible because I know players can’t just fire up an older version, so my ability to make drastic changes was limited.
- Modding is completely impossible.
- I haven’t been able to do a totally unrestrained promotional push, because I know the server can only take so much before it lags out horribly or starts spitting errors. Server administration isn’t my forte.
This is all my own stupid fault.
Here’s how I’d do it gradually, instead making everybody eat all their veggies before dessert:
- Add content to the server version for a couple of months, all the while doing prep and fixing up code that translates poorly.
- Start work on Fleshcult 2 from the same codebase. Then can I start making really big changes.
What do you guys think? Technical details below the fold.
Have you made a RAGS Game?
You should check out Regalia. It’s an enhancement to the (unfinished) HTML export in RAGS Designer 2.4. You run the export, run Regalia on the export, and then nobody has to install the godawful RAGS Player to play your game.
It’s open source so there’s a pretty good prospect for it eventually supporting every feature in RAGS.
Wait, what’s RAGS?
RAGS is a graphical adventure game creation system that’s popular in several different adult video game scenes. Unfortunately it’s Windows only, tricky to install correctly, largely unmaintained, and has a couple of mutually incompatible versions.
The biggest source of the trouble is that the .RAG format is a renamed SQL Server Compact Edition database. This is an undocumented binary file format called SDF (no relation to signed distance fields). RAGS player relies on SQL Server Compact being installed in order to open the databases. That’s why you have to run two separate installers to install the player. Microsoft is dropping support for SQLSCE in 2021. The old installers will probably work for a while after that point, but there’s no telling when OS or .Net changes will break them.
.RAG files are a terrible way to distribute games and we should stop doing that.
Mandrill, my former e-mail provider, discontinued the service I was using and I botched switching over to a new service. Between 25 and 27 February any attempts by the game or the forums to send e-mails resulted in an Internal Server Error. I didn’t notice because I botched the error monitoring too. I fixed the game yesterday and the forums just now.
If you see any more problems, report them to firstname.lastname@example.org
Sorry about that. 🙁
This is the menu redesign I’m working on. I don’t have anything to release yet because I want to save it until it’s definitely an improvement on what’s already there.
You can see with Cast Loosen there’s a sub menu for the target. I tried out exposing all the arouse/heavy arouse (options #1 and #2) variations in a sub menu, but picking the variation isn’t an interesting decision so I’m going to keep that randomised.
I’m hiding the descriptions inside a foldable section. I figure those are things you really only need to read once. Maybe I’ll default them to unfolded if you’ve never seen an action before, or if you’re on a big display. I haven’t decided which.
Does anyone have recommendations for JS animation libraries? I need relatively simple tweening through a list of keyframes for a variety of CSS properties. Preferably something that runs OK on underpowered devices. JQuery is disappointingly bloated and sluggish.