Found another bug. When making a copy of a program to another CraftoMate, sometimes (but not always?) it seems to "copy by reference" instead of "copy by value", which results in the code becoming messed up if you edit either of the CraftoMate's code to make slight modifications.
... And another ... If you pause a CraftoMate, do a global game pause and then unpause, the paused CraftoMate becomes unpaused as well. You also have to click the CraftoMate's pause button _twice_ to pause it again.
More on the "copy" bug: It seems to affect (mostly, but I just had one time it affected me with no connectors) the connectors. I can reproduce it by chaining several in a row, copy to another CraftoMate, and then disconnect any of the lines connecting the connectors in the source or target Craftomate. If you go back to the other CraftoMate, the same line is broken.
Another update: Further experimentation seems to point not at the connectors themselves, but the connecting _lines_ between program elements (I mainly noticed it with connectors because I would place two connectors in a row, and then "break them" to cause the program to stop at a known point).
Hey @Casteele,
Thanks for your very detailed feedback! It's great to know that us and our players often share ideas on what direction the development process should take next: we were discussing many of the issues you've brought up internally.
It will take us some time to process your ideas and write a detailed answer, since our coder is on a little vacation after releasing the past update and a hotfix.
In the meantime, you're very welcome to join our Discord, if you're into this platform - we could use more people with in-depth view on tech games in our lovely little community of players with IT/programming background :)
In any case: thanks again for your very deliberate feedback, it's extremely valuable to us at this point of development!
Ok, Ivan the programmer is back and you can find his comments to your wonderful feedback below!
Have you looked in to making a bundle, like a "flatpak" (I think it is called?) that contains all the needed library versions? Most of the libs are likely (L)GPL licensed, so there should be no licensing issues. It would avoid other issues, such as my plans to upgrade to Debian 11 in the next 6 months or less.
Now this is not a high priority issue, I didn't dive deep into this question.
But I guess it can be done after release (would be an interesting challenge for me).
BTW, maybe it will be more efficient to do some work about compatibility with Valve Proton... We'll see once we have time to look into this thing.
The tutorial needs some work to make some things more clear/obvious. It is not always clear what to do next. Even with the highlighting, it is always easy to notice that something has been highlighted -- perhaps you could make it flash and make a red arrow point to it the first time it is highlighted. (I.E., use movement -- visually impaired people like me more easily notice movement than color changes.)
We'll try and add some moving animation to highlighted elements in the tutorials (it won't be complicated for all objects except for Craftomates; maybe will make some specific animation for them)
One of the first storage bins a player will unfreeze contains some kind of "eat" modules. But I cannot figure out how to make use of them. Even I give one to a CraftoMate, they simply hold it in their hands without doing anything with it. The only way I have been able to obtain the "eat" command is by working to give the command center the requested resources to get (upgrade points) to spend on both the "low battery" and "eat" upgrades. This is _very_ tedious to do as until I get those upgrades, it is hard to keep the CraftoMates powered-up to keep the bonfires burning.
Which leads to this problem: When a CraftoMate is holding two items, I cannot feed it anything to recharge it! This happens when i is holding two stones to create a spark, or a spark and a coal to create a fire. The only way I can get it to drop everything is to completely delete it's current program. Then I can feed it. But then I have to reprogram it. I suggest some way to allow it to eat without needing to do this, such as a drop area on the command bar for feeding.
That Storage unit with 'eat' commands is from the previous version, I forgot to remove it. It'll be fixed soon!
Regarding problems with feeding by hand, you can press the 'reset' button and make a Craftomate drop whatever they're holding, without having to delete the entire program (you'll find it between start/pause and copy buttons).
But I agree that we need to have more precise control. I guess in one of next versions 'reset' button will be changed into three (maybe more) buttons (i.e. 'drop from left/right hand' and 'switch to first step'), with a dedicated manual for using them.
The code editor... well, it sucks. It is hard to work with. I end up with lines going everywhere making the display cluttered and hard to read/follow. You might add some kind of option to "snap to grid" and/or choose direct connections instead of the curvy ones. I also suggest adding "labels" and a "go to" instruction (or a "jump", for those "anti-goto" people out here), which would only show connections if hovering over them. Looping instructions would also be helpful.
Hmm, a 'go to' instruction, which would only show connections when hovering over them is a great idea, we were discussing how we can fix this problem of too many lines just a few days ago. What you're suggesting might be a great solution, so thanks for that!
As for the grid or different lines style... That's not on our table right now, as we're rather early in development, but we'll consider something like that in the future.
Subroutines would also be helpful. More so with the "low_battery" event -- which could also use a "resume" instruction to resume where it left off, instead of needing to drop everything and jump back to the start.
Subroutines are currently in the works, we're planning to really get to them at some point during the summer
'Resume' instruction should be useful, but I can't figure out how it would work and look.
I.e. In C or C++ when you resume coroutine, or return from function, execution context is switched, and thanks to this (context saving and context switching) we are able to continue execution from the same step as we stop. But this concept is too cumbersome, for our game, at least… So at this stage I don't have a solution for this. Maybe it becomes more clear once we're finished with subroutines.
You might also consider export (save) and import (load) programs, which could then be edited by any text editor. (Format could be very simple, such as DOS batch (*.BAT) files, or TCL scripts ( http://www.tcl.tk ) -- which could embed a TCL interpreter.)
Yep, this is already planned, but not for the near future.
On occasion, I encounter glitches which cause items to appear on screen that cannot be interacted with (or removed from screen!).
Will be fixed:)
Logical constructs, such as "if/else", or finding, for example, which bonfire has the lowest level of fire.
'If/else' is also to be introduced soon. I'd really like the players to make a finding instrument by combining commands and experimenting, rather than having a built-in function for that :)
P.S. That copy bug will be fixed, too, thx for reporting!
Just a heads up about Steam/Valve releases: They work great on Microsoft Windows, and possibly Apple Mac OS-X, but with so many different Linux distro's out there... Even Steam has issues with varied versions and shared library support. Usually, I find static compiling everything in is the only way to work across many distros.
Re. the "Reset" button, I finally figured it out -- It took awhile because the button is marked "Clear", not "Reset". So to me, it seemed likely the same as "Delete".
Re. Resume (and functions, too!), a small call stack would be a workable solution (two to four positions would be enough for most users). You could even have the CraftoMates leave "trails" when stepping through execution: Where it shows the CraftoMate now, it can show an outlined/boxed CraftoMate wih maybe a "!" or a number to indicate stack position on it's chest to indicate where it jumped from and will return/resume from. I agree that it is a bit cumbersome to implement, but there is really no better solution that I know of.
This also goes hand-in-hand with things like "Go To" and Conditionals, both aof which are basically different constructs for control of code flow. Ever work with Assembly language? This is the heart of a CPU and what makes it able to do so many useful things! You will also need to do something like this if you ever add variables and such. (Am I holding zero, one, or two items? What types are the items?)
Technically, you do not even need a stack dedicated to each CraftoMate. A global stack shared by all would suffice, and a context indicator (which would be pushed on the stack when switching contexts, too) for each CrafoMate to know which stack entries belong to it.
Once such code is in place (and working and debugged), it opens up so many additional code possibilities (interrupts, conditions, subroutines, and so on), so it is worth the effort to get in place now, no matter how cumbersome. You can even extend it later with an event system. (I picked a Stone... What should I do with it? Ahh, yes, there's an event for "have stone", so execute it!)
I also finally figured out how the connector at the bottom of every element works -- it is to change code path to follow if the commend element fails! I started using this as a way to clear out what the CraftoMate is holding: I drop an Eat command, and make it loop back to itself, forever... But then I connect the Fail path to the next instruction to execute as soon as it has nothing left to eat.
Such code is already crude elements of many more "advanced" programming structures, as I noted above.
Re. Find: The above would also make things possible such as "code libraries", where a player could write a "Find" subroutine, load i to the Command Center as a library routine which any CraftoMate can "call" without having to "write" the same code to each CraftoMate individually.
To give you some ideas, you might want to check out the game "Colobot (Gold Edition)" ( http://colobot.info ), which is an open source game based around a "C/C++"-like programming language.
You might also want to check out Tcl/Tk. I mentioned it before not only because I am a Tcl/Tk fan, but because it is a surprisingly powerful scripting language for it's size (a compiled binary is a fraction the size of Perl, Python, Lua, etc., while being portable and powerful). [In fact, I have ported several games to Tcl/Tk (sometimes with additional C extensions) versions, including games such as Mindusry...]
Final notes:
At some point, the game will not save any further. I can go to the [Gear icon] and click "Save", and it switches to and becomes stuck at "Saving...", and never changes to "Saved". A page reload revers back to the last _successful_ save game state; Anything after that is lost. I suspect this is more of an issue with browser limitations (i.e., "cookie" size) than anything you can do.
Future releases might include procedurally generated maps instead of static and pre-known maps, enhancing game re-play-ability. I have finally managed to complete a game with growing a tree, and discovering all known recipes (except mushrooms, which you're removing from the game). I have not tried to melt all the ice due to the save game issue. Effectively, I have lost most interest in the game. :-(
Finally, re. Discord... I have Discord, but am not a fan of it. It is very resource intensive for all it's "features" I rarely--if ever--use. And given how often that causes it to overload and crash my browsing session, I have to repeatedly log back in and do the CAPTCHA several times a day/session. I might add this to my Discord as a side-thing, but I might not as well.
