First two commands are one-time use; the variable is important; you have multiple options for last line like adding alias in shell rc, exporting variable in shell profile or creating .desktop file
zonkedHistory12
Recent community posts
Small issue: controller doesn't work with linux 64-bit version (possibly 32-bit version) at least in version 0.031.45 (haven't played newer yet, but devlogs don't mention it) - verified that controller is properly recognized as /dev/input/js0 and works in test program and some other games, mice & keyboard work; also small balancing issue (or not, depends if intended): right now bow has no cooldown between shots and staggers some enemies, so it's possible to oneshot rabbit girl
Dug up a log from one of the crashes:
While running game code:
File "game/900_GAME.rpy", line 31, in script call
call navigate() from _call_navigate
File "game/400_interaction/410_navigator.rpy", line 178, in script
call screen navigate()
File "renpy/common/000statements.rpy", line 569, in execute_call_screen
store._return = renpy.call_screen(name, *args, **kwargs)
File "game/screens.rpy", line 243, in execute
screen quick_menu():
File "game/screens.rpy", line 243, in execute
screen quick_menu():
File "game/screens.rpy", line 248, in execute
if quick_menu:
File "game/screens.rpy", line 248, in <module>
if quick_menu:
NameError: name 'quick_menu' is not defined
The performance hits probably occurred at the boardgame (running pathfinding, etc not ideally)
Yeah, that could use caching and similar optimization techniques and that's a kind of thing where you would really like to use godot or unity which come with set of already predefined functions for this and are better suited for the type of games you make and could speed up development significantly, however either requires some time to learn, but that's up to you; Anyways keep up the good work
My personal feedback having completed the game yesterday (Spoiler Warning)
Quick: enjoyable game (quality visuals), however it would do it good if you could apply some final polish (gameplay, game's performance - great candidate for 1.0 release).
In detail:
- story and characters were mostly spot on, maybe apart from Iliana being too agreeable, not malevolent enough and too passive throughout crucial parts of the story (the nightly mirror image seems not sufficient)
- gameplay economic aspects (played on normal) are not quite well balanced - early crafting and gold squeezing is fun (supply chest could be one time use, with everything x3), but after Nyx's arrival, acceleration is too rapid, to the point where there's plenty of story left and gold is mostly useless (shop prices are marginal), there's way too many gems and some items are positively dead (ex. fragrances, gold bars / nails); pity that some unique items from shop are not used at all
- dungeon gameplay is ok, if there were more floors (generic ones) with loot more spread between them it would help balance economics a little
- portal gameplay is unfortunately weak, as said before, way too many gems, so no point in moving them when you can always reinforce; personally think queen should be attacking (with appropriate power) from the moment she finds out about moves in portal space, this would spice things up, add depth, prevent excessive stacking before enemy contact (only lost some fields on the first night) and not make Gwynn's boosts such a power creep (they could also use a little tweaking down - all of them are a bit too strong); the gold chests are not really necessary and something like extra gem after takeover would be better
- extra puzzles - first two castle maps are ok, latter are too tedious (skip button used); riddles as riddles are - hit or miss, enough simple ones to get 4 of them right, but I think other type of puzzle would be better
- other gameplay aspects - Gwynn's researches unobtainable outside of storyline shouldn't appear in menu (wasted some time getting those extra scrolls); conditions for some events are a bit too specific and obscure (using walkthrough was necessary) so they could be broadened a little (ex. longer timespan) or mirror could give some advices in that regard (and not be mute as it is right now)
- game's performance - gameplay portions and some menus lag a little (nothing too unplayable) on my laptop (low-end one, however it doesn't have trouble running more demanding titles), and unfortunately this could mean that current game code needs some optimizations or just ren'py is sub-optimal for this game (I think godot would make a great alternative); I also crashed a couple of times on scrollback and quickloads due to variable 'game_version' (or some other variation of those words, sorry didn't copy the log) being used before its declaration in some 'if' clause
Anyways, thanks for making the game and take this feedback as something to hopefully help with your future game development.
That's a valid concern and I did miss the https://meta.miraheze.org/wiki/Dormancy_Policy but looking at it now there is whole section on exemptions from those rules, specifically for read-only oriented wikis, with a whole list https://meta.miraheze.org/wiki/Dormancy_Policy/Exemptions ; looking at them (there are some game wikis and even an eroge one), if asked nicely, ToA wiki definitely makes a valid case for an indefinite exemptio
Don't know if you're still looking, but anyways, here's a relatively big list of possible options https://www.mediawiki.org/wiki/Hosting_services and out of all of them https://miraheze.org/ seems to be the best fit (it's free, UK-based and should be ok for the most part; also I'm in no way associated with them I just want a nice wiki for the game)
Here are some links for your careful study with some thoughts after a quick read:
ToS - https://meta.miraheze.org/wiki/Terms_of_Use ; fairly standard stuff (nothing prohibited by UK law, no responsibility for incorrect info in user's content, some administration on their part, etc)
Privacy Policy - https://meta.miraheze.org/wiki/Privacy_Policy ; typical stuff for any hosting provider (stuff like sharing some rights to content to provide service), same as Fandom, non-registered content edits show IP address and registered show username
Content Policy - https://meta.miraheze.org/wiki/Content_Policy ; this should be most carefully scanned
- point 1. seems to target e-commerce, quoting "However, you can have limited fundraiser-type sales or provide an informational site supporting a commercial activity (for instance, a wiki describing characters from a commercial work of fiction)." so links to other platforms (ex. patreon) shouldn't be a problem
- point 4. someone has to admin wiki but I presume that was already a thing
- point 6. I don't believe game's ambigious on this front
- after point 13. default wiki content license is CreativeCommons but can be changed to non-permissive licenses etc, more here https://meta.miraheze.org/wiki/Help:Changing_your_wiki_license
- and very relevant section of rules for NSFW stuff
- main page has to have entry popup that wiki is 18+
- no explicit images on main page
- explicit images on side pages should be "where possible" collapsed by default (yay, no more blurred images)
- there's also sentence in bold font, that subdomains and site names shouldn't be explicit - I think both ToA or full name for domain shouldn't be an issue, as for side pages it shouldn't be too hard for admin(s) to set custom URLs that are safe