Home
Creators
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

Devlog - July 10th - V1.40 Integration Testing Complete! (Patreon)

Published:
2024-07-10 12:04:16
Edited:
2024-07-10 12:13:15
Imported:
2026-06

Content

Hi,

today I completed the Integration testing for V1.40 suvccessfully. Tomorrow I will focus on finetuning the ending.

BETA 12th July looks ok

VIP Early Access I 17th July

Upper Tier Early Access II 24th July

Patreon/Substar Official Release 31st July (depending on EA) 

Plan is valid if BETA runs without major findings.y.v.

Files

Comments

Jimbo

Great. Looking forward to it.

John Perry

guess after 1.40 ,game over.

y.v.

There will be at a minimum Expansion 1.50 ("Adventures in Krell Space) after 1.40 :)

waffel

Will you consider making the expansion savedata compatible from a safe savearea or something like that. One thing is the main game, it would be nice not having to start all over again because of the expansion :)

y.v.

To even attempt that the software design right in the beginning should've been different. I don't want to change high-level architecture at this point. In my next game, this may be an idea, but it would still require that all save anywhere features are permanently disabled and there's only one save point for example overnight. I'm not sure whether players would like that, but I can have a poll.

Tansi

You could allow free saves, but also "compatible saves" in addition that are a lot more limited, for example overnight. Then transferring the second type of saves would become possible. You could also do something like "import last overnight save" and then player lose at most one in-game day. I am sure there are other options. I do understand that changing SJX in this regard is not realistic. I think you should try to find some solution for this question in the future. The publishing style in increments is quite at odds with having to start from the beginning with each increment. Does not have to be perfect. But I have seen people complain for other games that do this and personally, I will probably wait for 1.50 to play again.

y.v.

Maybe possible (though I think technically unlikely) but I would have to rewrite a lot of the native renpy code. I'd rather spend my time developing content than fiddle around making a custom game engine variation tbh.

waffel

That is why I'm just voicing my thoughts, I hope you will consider them in the next project. Mind you, you have started making bigger scale projects, making this need more profound for us players. The best take I have seen on it in another Ren'Py project is that batshit crazy project called INSight of you. He converted the old saveformat into the new one when you loaded an old save. I don't know how much effort that will take, because the save format of Ren'Py is as crazy as iNSight of you. Consider asking him, mano a mano.

y.v.

I have a look at the code, might be interesting.

Akis Daakoneum

It's just my IHMO based on renpy games code I saw, but you can include game version in save and when load save from older version just make game create new variables which didn't existed in previous version and update old/renamed ones ones Most implementations I saw is chained, so as example current version is 5, save from 2. Updater on load "upgrade" save as chain 2 > 3 > 4 > 5 version, in my opinion it's fine only when implemented from start, it's quite a hassle to remember what variables was changed if you trying to implement something like this midway (and may be possible only if version included in saves from start)... So even if author adds this system with 1.40 it'll be compatible only with further versions, not old ones

Akis Daakoneum

a bit more techical side of example: in load function exists version checker and if save_version != current_version launching updater with save_version as argument. updater have chain of ifs and functions like update_2_to_3, which have call of next update_3_to_4 inside, and ifs catch save version and start chain from correct place, after updater chain it should have all variables/switches as ya loaded current version save...

Akis Daakoneum

or another example which I saw in Another Chance - it have cycle while save version != current it launch class tied to update from one version to next and return next version as save version... If ya wanna explore their realisation it's in 1000_base_game.rpa/1000_base_game/game/save.rpyc, under "upgrade_game_version" label