itch.io

Absolutely superb style and layered gameplay.

Meow, good game.
I went through to see all the routes and variations.

Apparently when I go “Back to start” I may not remember what I saw the last time when I looked between my legs; But Lily will not let me forget the one time I’ve fallen over. (unless I restart)

<<unset $panic, $calm, $vag, $cock>>

Appreciated; 

But I did wonder if anchoring  sets of controls to the appropriate corner could have worked better without scaling (down-sampling) the art.

I downloaded the scary .exe but was unable to play as my screen is 192 pixels too short (720 vs 960), and Godot automatically limits (crops) the window to the native resolution instead of allowing scaling or scrolling...

Were there any assigned keys that did anything (other than 'r') ?

Just finished playing through, liked the depth of your writing,  but noticed some minor bugs:

Data Corruption:

• "Remove Consumable" if $Consumable_Update_Position is 19 or 28,  doesn't include 

  <<set $Inventory_c_slots_filled to $Inventory_c_slots_filled - 1>>

• "Zipper Arm Cannon Modding" Smartlink Integration overwrites mats with tek.

  <<set $Player_crafting_mats to $Player_crafting_tek - 1>>

Missing function:

• "Monster Pen Corridor 1-2" is missing the <</link>> tag from the statement 

  <<if $MS_Calibrations_My_Dear gte 5>> /%...%/

• "Special Attacks Weapon" looks for 
  $WSA_$WSA_Homing_Blast instead of $WSA_Homing_Blast
• "LEVEL CAP" enforcing a cap of 10 by setting $Player_exp_max 's magic number to 0, ignoring $level_cap set to "Disabled"; .

Momentary confusion:

• "Inventory Consumables2" and "Inventory Consumables3" show the value for the next 'stack' in position 4 ($I_C_{15,16}_S and $I_C_{25,26}_S respectively).
  (I used a script to generate a replacement, see below)

No-effect/Code-style:

• "Inventory Consumable Move Left" sets "I_C_Swap_S"

Suggestion:

•  <<If>>'s instead of <<switch>>'s

  <<if $Player_success gte 1>>
    <<if $Player_element_effectiveness is 0>>
    <<else>>
      That $Actual_damage_type <<if $Actual_damage_type_2 isnot "unaspected">>and $Actual_damage_type_2 <</if>>attack was <<switch $Player_element_effectiveness>>
       <<case 1>>effective 
       <<case 2>><b>very</b> effective 
       <<case 3>><b>incredibly</b> effective 
       <<case 4>><b>overwhelmingly</b> effective 
       <<case -4>><b>pathetically</b> ineffective 
       <<case -3>><b>incredibly</b> ineffective 
       <<case -2>><b>very</b> ineffective 
       <<case -1>>ineffective 
       <<default>>
      <</switch>>against <<= $Enemy_article>>!<br><br>
    <</if>>
  <</if>>

• I rewrote my local copy to replace collections of mutually-exclusive <<if>> statements to use <<ifelse>> and <<switch>>.  (mostly for optimization reasons)  But I didn't notice any other bugs that might have written over.
• Arrays, Datamaps, Datasets  parallel how your data-scheme/names are organized, but can be used with SugarCube's  <<for>> iterator(s) instead of unrolling/pre-writing every variation (or generating code the Wikifyier).
• <<widget>>'s might be able to make procedurally generating repeating elements less human-error prone.
• UGH, Itch.io or Chrome auto-corrects corrupts the SugarCube code I try to paste here.
  Was going to share a piece of fancy code that uses a template without changing your data-scheme to use an array or maps. . . It was built around <<for>> loops with something like this:

  <<print "$i_c_"+$smart_bandage_position+"_d">> 
  

• Instead, here's Javascript that (pre-/re-)generates the SugarCube code for "Inventory Consumables[...]" so that you don't need to worry about searching for  typos:
  

  _m = "";
  for(_jjj=0;_jjj<=20;_jjj+=10){
    _m+="<<link [img[$Inventory_Left_Arrow]]>><<set $inventory_page to $inventory_page - 1>><<include \"Inventory Page Turner\">><<replace \"#inventory_replace\">><<include \"Inventory Base\">><</replace>><</link>> Consumables Tab $inventory_page <<link [img[$Inventory_Right_Arrow]]>><<set $inventory_page to $inventory_page + 1>><<include \"Inventory Page Turner\">><<replace \"#inventory_replace\">><<include \"Inventory Base\">><</replace>><</link>>\n<b>@@#tooltip;@@</b>\n<<nobr>>";
    for(_jj=0;_jj<=5;_jj+=5){
      if(_jj==5){_m+="\n<div class=\"Consumables2Div\">"}
      for(_j=1;_j<=5;_j++){
        _i = _jjj+_jj+_j;
        _ii = _jj+_j;
        _m+="<<if $I_C_"+_i+" is \"empty\">><<link [img[$I_C_E]]>><</link>><<else>><<mouseover>><<link [img[$I_C_"+_i+"]]>><<dialog>><<include $I_C_"+_i+"_D>><</dialog>><</link>><<onmousein>><<replace '#tooltip'>><<= $I_C_"+_i+"_T>>:<<=$I_C_"+_i+"_S>><</replace>><<onmouseout>><<replace '#tooltip'>><</replace>><</mouseover>><</if>><div class=\"ConsumableI"+_ii+"Div\"><<if $I_C_"+_i+"_S is 0>><<else>>$I_C_"+_i+"_S<</if>></div>";
      }
      if(_jj==5){_m+="</div>"}
    }
    _m+="<</nobr>>\n";
  }
  _m

Meow; looking forwards to see where this goes.

I decompiled the code and found that it's correctly set for the collectable item, but not the active runner.

I did a sort then copied the missing lines over, and this seems to have solved that problem.

draw_self()
switch ore {
     case 130:
         spr = s_ore_icon_iron
         break
     case 500:
         var spr = s_ore_icon_coal
         break
     case 711:
         spr = s_ore_icon_tin
         break
     case 748:
         spr = s_ore_icon_titanium
         break
     case 803:
         spr = s_ore_icon_tungsten
         break
     case 980:
         spr = s_ore_icon_copper
         break
     case 1007:
         spr = s_ore_icon_gold
         break
 // meow - begin patch
     case 255:
         spr = s_ore_icon_lead
         break
     case 277:
         spr = s_ore_icon_lithium
         break
     case 376:
         spr = s_ore_icon_silicon
         break
     case 490:
         spr = s_ore_icon_silver
         break
     case 740:
         spr = s_ore_icon_nickel
         break
     case 750:
         spr = s_ore_icon_zinc
         break
     case 849:
         spr = s_ore_icon_sulfer
         break
     case 1196:
         spr = s_ore_icon_aluminium
         break
     default:
         instance_destroy()
 // meow - end 
}
draw_sprite(spr, 0, x, y)

Also, the ..._pocket_furnace_... code didn't decompile nicely for me, so I was unable/unwilling to determine if it was the patching/modding tool, or an existing problem that was causing crashes when I saturated my drill with portable furnaces.

___________________________________________
############################################################################################
ERROR in
action number 1
of  Step Event0
for object o_drill:
DoSub :2: undefined value
at gml_Script_anon_DrillPart_pocket_furnace_gml_GlobalScript_drill_misc_data_2413_DrillPart_pocket_furnace_gml_GlobalScript_drill_misc_data
############################################################################################
gml_Script_anon_DrillPart_pocket_furnace_gml_GlobalScript_drill_misc_data_2413_DrillPart_pocket_furnace_gml_GlobalScript_drill_misc_data (line -1)
gml_Script_anon_DrillPart_gml_GlobalScript_drill_part_data_8236_DrillPart_gml_GlobalScript_drill_part_data
gml_Object_o_drill_Step_0

I hope this helps.

Missed one. It must have snuck by you in the last update.

Also, now you can make slag with Titanium and Lithium too!

Sort of. (Not the dev) I decompiled the code (looking for recipes when I noticed the list here was incomplete, and) found that the dev set it correctly for collectable item, but that not for the active runner.

I copied the missing lines over (edit: w/ a modding tool), and this seems to have solved that problem...

draw_self()
switch ore {
     case 130:
         spr = s_ore_icon_iron
         break
     case 500:
         var spr = s_ore_icon_coal
         break
     case 711:
         spr = s_ore_icon_tin
         break
     case 748:
         spr = s_ore_icon_titanium
         break
     case 803:
         spr = s_ore_icon_tungsten
         break
     case 980:
         spr = s_ore_icon_copper
         break
     case 1007:
         spr = s_ore_icon_gold
         break
 // meow - begin patch
     case 255:
         spr = s_ore_icon_lead
         break
     case 277:
         spr = s_ore_icon_lithium
         break
     case 376:
         spr = s_ore_icon_silicon
         break
     case 490:
         spr = s_ore_icon_silver
         break
     case 740:
         spr = s_ore_icon_nickel
         break
     case 750:
         spr = s_ore_icon_zinc
         break
     case 849:
         spr = s_ore_icon_sulfer
         break
     case 1196:
         spr = s_ore_icon_aluminium
         break
     default:
         instance_destroy()
 // meow - end 
}
draw_sprite(spr, 0, x, y)

...but afterwards I noticed that saturating my drill with portable furnaces was causing crashes -- and the ..._pocket_furnace_... code didn't decompile nicely for me; So I was unable/unwilling to determine why (when I could just avoid using them instead).

Art is so easily misunderstood.

Absolutely;

It's a matter of public safety.  XD

It's not as if these customers 'always' check for traffic before running across the road(x) when they have one thing on their minds. 

(x)Or other-times mass-dog-piling into a recently vacated seat, like it is a game of musical chairs or something... realistic, but can be inefficient.

I just noticed that there was an update that includes images that work for me (chrome).

Try again?

vA031-Win64

So the 'victory' condition is to fill the score bar by creating combo's (sequences of two or more identical pairs) before.

The instability bar fills up every time 'junk' is made by mismatched pairs, or a pair's cut off.
And the instability bar is drained (the same amount) the score is increased.

Every time 'junk' is ejected from the sequence, the strand collapses, potentially creating more combinations.

So the eco. is deciding if making junk to enable larger combo's will fill the score bar faster than the instability hits its limit.  
Generally I found myself that making combos of size 2 while setting up to make sets of three *almost* worked. Cheated to reduce the junk penalty and started having more success. (Fake ease/easiness due to practise?)

---

feedback: 

(UI/visually) have 'instability' and score extend from opposite ends of the same bar, to make the two literally oppose each other. 
Try to make the instability less static/friendly so that it's meaning is clearer.
( ie: increasing instability grows tentacle like strings over the score meter. The tips/growing end of which thins out instead of pulls back when the instability is driven back.  A (hidden) bead marking displaces the tentacles at the tip of the score bar, for clarity.  I think this can be accomplished with a layered sprite and masks, avoiding actually calculating splines, though splines *would* allow the tips to wiggle...)

(UI/criticism) I kept getting confused that the next piece wasn't shown above, even though I 'know' that it's represented by the colour of the cursor. 
I like the idea of showing a ghost/shadow of the piece about to be placed.

(criticism) combos didn't feel that rewarding. And I was often confused why this resulted in mismatched pairs sitting in the sequence after.

(UI) make the cursor mouse driven (or tracking). This would make placing the next piece following a combo much easier.

(gameplay) make the remnants of completed combos eligible for stronger combos. Be it a ladder like 2048, or just a +1 length bonus for every time it is used in another combo.

(gameplay/visually) Add a ball/motor that is pulling drags the end of the strand at the bottom into the cutting enzyme. Then on combos make 'it let go' and kick it up the strand where it will then descend (at its normal speed) until it reaches the end of the strand again.

(gameplay) make the different 'junk' affect the instability value differently to increase final complexity. 
( ie: unstable mismatched pairs cost 5, cut-off single bases cost 3, cut-off matched-pairs cost 1? )

(criticism) Early on, too often I found myself unable to place a piece and had to wait to lose. Later I'd get screens without a match for any of the pieces I held.
(gameplay) perhaps allowing players to pair and 'eject' the piece they're holding with the one in the cursor as "an advanced" strategy would mitigate this.

Found a bug in the WebGL version: the game is only adding "///" pieces to the board, trapping me in an infinite loop [edit:]soft-lock with no way I can find to forfeit/skip to the map screen.  I let it climb to 20k before closing, but I've wanted to skip the level end bonus points for a while now.

I enjoyed this- Particularly how consistent and simple the interface is.  The stated goal of being able to play without seeing the screen has clearly informed the rest of the design.

Is an expansion/followup planned?

Also;
I noticed that 'Wraith Wail' doesn't actually set player.defense = 0 when "You lose all your defense."  Was this a bug?

I seem to be unable to breed humanity far above 🌾 975.60 Qiunt without it their stats rolling back down to 🌾 1.

(After testing with the debugger) If I limit my breeding pair's "farming" attribute to (🌾 975609756097560700000) then there can be no 1's, but then autosell won't empty slots containing humans rated above that;
But the higher I allow the stats to climb, the % of lone humans increases.

Is this because of extreme inbreeding?  Using the debugger to make a breeding pair with 🌾 1.45Z projects 🌾1-1 offspring.

I'm not an equestrian, but only brushing from the root to the tip seems like a good way to cause all sorts of tangles.  Makes me wonder if there's a simulation game about brushing hair.