hello, what version of OpenGL does this need and is it possible to build-from-source? I'm trying to get the game to run on my kids' Raspberry Pi 400s (where they learn about coding!) but we need box64 to emulate from x86_64 to arm64, and I think we only have OpenGL 3.1. Currently it is giving us an opengl error but I'd be grateful to know what dependencies there are before trying to fix.
I got it working now on Rpi, but there is an issue where the squares that are supposed to be snowy or frozen appear normal. Crafting etc and the overall interface seem to be fine it's just displaying those tiles wrong
hello there =) for some reason, when i install the game via the itch app, i am only getting the demo version
i can download the full version via the webpage just fine
(the page states that i purchased it and lets me download it via my library, but the game page itself does not turn the files for the full game into links) , but that means i will have to manually update, rather than getting them automatically
is that effecting anyone else? and is it something that can be fixed on your end, or is that something breaking on the itch side?
i give up. i have tried many time to get a good downloaded zip file, with no success, I also had to find the file and the download log because the downloaded filename gave no clue what it was.. just "x86_64-win32.0.69.2.itch.510,zip" which could have been a virus for all the name suggests...nothing to indicate this was craft-o-mation and not something else. i am really disappointed with the developer now--they took a great concept and working program and turned it in to utter garbage
Nice to hear from you, long time no see. Sad to hear that you can't download the game, especially with the fact that you have been here with us for a long time (and we appreciate it a lot).
Would you mind elaborating a bit on that so we can help you somehow? What happens when you click on the file here on Itch, what web browser and operating system do you use? Do you have any issues with downloading files from other websites? Is the web version here on Itch or Steam Demo work for you?
I just tried to download the game using Chrome and Safari browsers for all the platforms and it looks like all is fine.
As for the filename - good suggestions to put the title into the zip filename, I just renamed all the files here on itch and in our build system, thanks!
P.S. Please feel free to contact me directly if it's more comfortable for you, my email is - oleg.chumakov@luden.io
Just encountered a pathing issue after switching bots from regular code to pre-programmed functions. I switched out all of the fire-making code for a function that did the same thing and for most of the bots it was perfectly fine, but I had to re-reprogram 3-4 of them back to the regular code. They made sparks perfectly fine, but kept attempting to get coal from a source that was completely blocked off (all 3-4 chose the same one). The best part was that the coal they were trying and failing to get was surrounded by the largest quantity source blocks, so I couldn't make an opening for them to get to that block.
I had to change them from the function I made (which used "Find and Pick" for all materials) to "Pick From" with a coal source that they could actually access. I didn't have this issue in the previous update of the game that I played 7 months ago, and only a few bots were effected by the change. I don't know if campfire placement was an issue, because I only thought to check the campfire location of one bot, but that campfire wasn't placed very close to that coal or anything.
In case it matters, the unreachable coal in question was at the bottom of a vertical 3-block line of coal. It was surrounded on all sides, unlike the other 2 coal blocks next to it, which had at least one uncovered side. The other bots used the top one in the line, and maybe the middle (but I didn't think to watch for that). I had to change the problematic bots to pick specifically from the top one in the line. The rest of the bots chose that block just using the "Find and Pick" code.
Hey, thanks for your reply! I actually didn't notice the feedback sheet, sorry. That must be from someone else who had the same issue, unless I somehow did it and forgot. But if I remember, I might go back and reverse the correction I made (if necessary) and make a proper bug report later.
I don't know what to put here . I'm the low key geek. I love the game ,will likely play more soon , Its lit & got my brain Freezing and buzzing pretty fun , Wish I didn't have to go to bed soon but have to stop so good Night and thanks for the amazing game
It's got potential, there's a ton of game design balances that need to happen such as adjusting the length of time the fire burns (it's too short now), how long batteries last (too short - could be tied to a difficulty setting), and other QoL adjustments such as being able to drag to select multiple code-nodes.
I don't like how the connecting lines do that automatic squiggly look when connecting nodes. I do, however, like the idea of an node that doesn't do anything which allows you to organize the connections, make one of those that also works for the location data of variables and make the lines just be straight and that would be significantly better than it is now.
Will try to increse time fires burns, why not. B.t.w you can select a bunch of nodes with holded Ctrl, this feature should be introduced by some manual yep...
Iwe thinking about change link system to something closer to Linkitogame or tinkercad. But not shure about prioirity of this task.
An example : I had 7 or so robots, each doing a task. all of a sudden, the northern fire pits started to run off fuel. I looked for the robot in charge of feeding those to see what was wrong with its program but I couldn't find them in the crowd, and problems cascaded. From that point, each time there is something off, I hit pause immediately and hover every robot with my mouse to see their name. This breaks the rhythm of the game. My suggestion is to let the player change the jacket color of each robot as well as their name to differentiate them easily.
I get it yep, there is ingame method to color mates useing eatble dyes.
And you can rename craftomates as well.
All this solves problem for a part, but thats fact that we have some issue with navigating over Craftomates. Now thinking about some interface to grouping tham and navigate more convinient. Hope to implement in November.
Great idea but the beginning is incredibly annoying. The snow groing back resetting every progress in the area and freezing units is too much of a setback to actually enjoy the game.
I wish there was a better way to restrict the area, maybe with connection beacons instead of campfires, it does not fit the mecha-aesthetic visually nor does it make mechanical sense when evrything else is futuristic.
Too many things are happening at once and the floor is cluttered with items instantly. This game does not give the player the time to explore and make mistakes, it punishes and sets back the progress.
The UI is pretty and intuitive, especially the programming part. In the same vein there needs to be settings to change the sizes, at least for the font.
UI and graphic style are great, UX and mouse controls need to be tweaked. In my opinion the whole point of programing-style games is to make mistakes and find out new things with time. So far the gameplay loop seems made only for people already proficient with it, new players are going to pick games they don't feel frustrated because they forgot to supply one campfire.
I have not reached anything beyond the first couple quests but what annoyed me was that I lost space to work with every time a bonfire went off. The floor was littered with items (because I tried out new combinations) and the workspace was cluttered.
What I would suggest are ways to give players the chance to sort in a way before they reach dedicated storage units (to prevent cluttering) maybe via the ship so the player can hold a small amount of items they dont know what to do with.
Another way to prevent it feeling like a punishment for trying out new things is to slow down the rate snow grows back. As soon as I made a mistake the bonfires went out, leaving me with no way to reach the further still active fires.
To keep it short – losing workspace, progress and the connections is a bit too punishing for new players as far as I have experienced it.
You are not at sll annoying, its hard to explain via text. Ill try to take a couple screenshots and post them in the discord!
But to give a better picture, the floor was partially filled with items I collected when exploring the surrounding with the bonfires. Once I lost one bonfite I automatically lost valuable space to organize my items and had to move them closer to the rocket, cluttering the space even more. Like I said, this is only a critique at the start of the game when the player is making mistakes with the bonfires.
Giving the players a bit more space to create chaos at first could make it more smooth when learning the ropes. Boomers like me can easly get overwhelmed if I have to do more than focus on bringing back my old ActionScript knowledge :D
Hi Atih, I did see a youtuber grab one of the extra flames in the first bonfire and drag it to other bonfires. Temp solution of cause before we automate more and more, as in Autonauts, have a look if you want. Great game, I just started today, great time to be a gamer right?
C u in the Discord!
(could not find your name there, I'm called the same as here, find me if you want to chat ok?)
Oh, okay. I did notice somebody on youtube reset the program when it happened to them. They didn't mention it so I guess knew all about it! I didn't actually know WHY this happens, so thanks
Cool game! I personally find it lots of fun for a browser game - like a modern day Flash type of game that we never saw follow up on the deprecated support of Adobe Flash! Millions of children would open a browser in their school's computer lab and spend countless hours of lunchtime, free periods, afterschool and any free moments between classes playing their favorite Flash game by themselves or against their classmates! However, once Flash was discontinued, decommissioned, deprecated and disappeared, or whatever, from modern day implementation I feel like this once new found gaming platform was dropped and disappeared rather quickly without any eagre successor in line to make use of these newly unplatformed young gamers and the genre of browser games just sort of faded in to obscurity? (Not sure Zynga or Facebook really counts as an attempt at housing this population) Why another technology or company was not quick to take up the slack in supplying even the most basic crossplatform browser game engine or something I can't say - But with games like Craftomation 101 available and playable as it is, I find it even more peculiar to have felt browser games seem to have died out like they did because if games like this can be made I'm sort of surprised developers didn't just transition to whatever this is built on and continue the browser game genre I felt played such a big part in my generation's initiation with computers and internet technologies of the sort? ¯\_(ツ)_/¯
Dear friend, it was very nice to read such warm words about our game, thank you very much. We also started our gaming journey with simple but exciting Flash games, and sincerely mourn the passing of that wonderful era. But the world of business competition is cruel and unforgiving, and the good old Flash fell short of this deadly race, retiring in the prime of his life. Alas and ah .. Now we need to learn to live in a new era, with new game engines and new players who are already growing up and not knowing that there was once such a wonderful thing as a Flash player built into every browser. We will try to do our best working on this game, and always sincerely appreciate your inspirational support. \ (•◡•) /
How do you make wires? I have phosphorus but I have no clue on how to make wires. Surprised you didn't include it in the tutorial considering that batteries were.
Sorry for the late reply, thanks for the help, Though Figure it out around a hour after I submitted the comment. By the way, do you apply feedback received to the itch version, or are you saving it for the full version?
Thanks for reporting that crash, we'll look into it!
As for the lifetime of the Bonfires - that's something new: usually we get reports from people who managed to load so many Fires into Bonfires by using the robots, they run out of resources on the map.
The typical scheme would be to unlock Storage units and then divide CraftoMates into 2 parties: the bigger party would be busy crafting the Fires, while the smaller party of 1-3 CraftoMates would deliver those Fires to Bonfires.
i had three bots transporting fires to each 2 bonfire+having an emergency crafting in case they found none; and one bot crafting bonfires at a storage directly between stone and coal. the storage was always stocked, but they couldn't deliver it fast enough.
Don't you mind elaborating a bit? I am not sure if I understand the issue you are referring to 100% correctly, especially the part "they couldn't deliver it fast enough". What is current behavior and what is the expected behavior? (Screenshots are always super helpful for me to understand). Thank you!
fires go out and areas freeze before they can refuel them, even although the only need to pick up flame and deliver it. the fires only last a few seconds too short.
Whoops, seems I found a bug. When copying a program to another CM, the current program execution position does not get reset (I have not checked if run/pause state changes).
Most likely, the program position _should_ reset to idle and enter paused mode for the CM.
After being away for awhile, I got in to a discussion with someone on another game, and this game was mentioned. So I reloaded it to see what, if anything, the developers have done since I last played. I was very happily surprised to see they have done a lot of work on the game, ranging from general tweaks and improvements to adjusting and correcting previously reported issues, to adding user suggested features. Kudos to the developer, and two thumbs up (more if I had more thumbs!)
Nice to hear from you again! Doing our best. Funny coincidence but the next update will bring one of the most requested things :)) Spoiler: CraftoMates will become able to manipulate in new directions :)
(1) "Find and Pick" needs some more/better logic. Ideally, it should be able to include/exclude types, such as "From Box" (storage boxes), "From Raw" (I call those "piles" of raw/not-yet-mined resources), or even both. Perhaps even the ability to pick both but give a preferred type (Pick from Box, if available, raw pile otherwise). This is because I set up a CraftoMate (hereafter referred to as just CM) with a program to "Find and Pick", "Drop to" a box, then "To idle". But the result surprised me: It worked the _first_ time, but the second time it picked from the box it just dropped to (since it was now closest)! I adjusted to program to include a "Move to" first, but later in the game it caused problems when a) I had multiple storage boxes spread out on the map and the raw resources piles eventually became depleted. (Likewise, the "Drop to" might be able to only drop "On Ground" or "to Box".)
(2) Some degree of "look ahead" would be nice. I was trying to clear two adjacent Stone piles, so I had he logic of "Pick From" the first, and if that failed, it would "Pick From" the second. It worked, but every time it would move back to the first position, fail because it already cleared the tile, then move back to the second position. It should see that the first is already clear and go directly to the second, instead of wasting power moving back and forth needlessly.
(3) Related to (2), the "Warning" icon in the upper right that appears next to the pause button should not appear until the CM becomes truly "stuck". Every time it went to the first position and failed, the icon would pop up and then go away as soon as it went on to the second position. Not only does it create a momentary flash that distracted me, it also made it harder to be able to find and focus on the real problem areas/CMs which are stuck.
Some other observations and ideas:
-- I would like some detail/info on how variables work.
-- I kind of miss the old "Low Power" mechanics. I suggest that, instead of making it an "if/then/else" style operation, that you make it more like a sub-program (but not an exception that can occur any time -- only when instructed to check power). That is, create a "Low Power" label lower down like was done previously, and when the "Check Power" item executes, it will either continue to the next instruction, or "Jump" to the "Low Power" sub-program. This way, upon fixing the low power condition, we can choose to "Resume Next" which will go back to the "Low Power" check and continue on, or we could "Resume Idle" similar to the "To idle" instruction.
-- Make certain items not "eat-able". While experimenting, a flawed program made one of my CMs "eat" a seed. Oops. Also, some way of checking/testing _what_ if being held would be nice, to prevent accidentally eating the wrong item (especially when holding two items).
-- Related to the above, the ability of a grown tree to (sometimes?) "drop" a seed as well as wood would be nice.
-- Add an instruction to "Feed" another CM (as well as one to find one needing power). This way, we could assign one CM to "Stand By" the Battery Storage box, and when another CM needs power, the assigned one can grab a Battery and go feed it to the one needing power. (This could also be combined with my "Low power" suggestion to maybe add a "Call For Help" instruction, which would pause the bot until help arrives... or the player corrects the situation.)
-- Add the ability to pick up and move the "Current Execution" icon to any instruction in the current program screen.
-- A CM instruction to "Wait", which would make it wait (do nothing, such as "10 seconds", or until an even occurs, such as the "Feed" idea).
-- A "Give to" instruction, which could give to another CM. (Useful for things like "Feed"?)
Of course, I still hope to see:
-- Program labels, which could be targets of a "GoTo" instruction.
-- Sub-programs, which could be done with "Call" and "Return" instructions.
-- Real "if (condition) / then / else" logic. (Especially useful with sub-programs.)
-- Looping constructs. (Command Center wants 10 Steel Plates? Set up a CM to deliver exactly 10 then stop.)
Ufff such a huge abd cool feedback, lets starts from point to point.
(1)I think generaly smart commands is about "take less parameters, and make some complicated things" and in this case we dont need to add one extra parameter. Besides it generates some fun situations :)
Other reasin not to add such parameter is that usualy when you want to tell craftomate to "pick some element from storage" you talking about one specific storage, and for this case you have a "pick from"
Btw: we working on command that will dedicade a working zone for each craftomate, this should be usefull for your case
(2)This was some discussion topic for us. But currently our consensus is that this is works precisly like in real programming: "every data read event from isn't free (it costs time and energy)". But now "find and pick" brokes this concept down, so may be thats good idea.
Btw again: may be this problem can be solved by add "find" command: this is command that should save coordinates of coresponding element into variable (currently in work)
(3) Yep I agree Warning icon have outdated logic, we will rework it soon, thanks for reminder, I forget about that icon :)
Re (1), perhaps instead of an option, have different commands? "Find and Pick" to get from storage only, "Find and Mine" to get from raw resource piles only, and maybe a "Find and Get" which would get from either? As it is, it reminds me of how "Smart" phones like to "auto-correct" with the wrong correction... But at least with those you can choose to force it to your desired result.
As map size and game complexity grows. it will become less likely to have a single storage box dedicated to each item. Instead, transport lines will evolve: CMs will mine and deposit raw goods in areas where they are found, while other CMs will transport from those collection centers to different production areas where they are needed. (A true "ideal" would be a distribution "on demand", instead of "equally spread out"...)
In reality, a well-designed distribution is the opposite of "one specific storage", but a need to locate one of possibly many storage and staging sites with the desired item -- the lower cost of finding it outweighs the larger cost of walking across the map only to discover the single storage site is empty.
(2) That is not entirely true. A program can use logic to avoid wasted CPU or I/O. If a file is exactly 2 bytes in size, and you have already read 2 bytes, you know trying to read it again will give an EOF. Likewise, a CM knows if it is occupying the space requested, and nothing else is (or can, as the game is currently designed), it can skip trying to take take a step backwards to try to grab the space it just vacated.
A general "Find" feature would be a suitable alternative. But you can still assume that the CM has sensors (i.e., eyes) and can already know the command will fail.
"-- I would like some detail/info on how variables work." I guess we will add some wiki for all commands not soon, but precisely wil :)
"-- I kind of miss the old "Low Power" mechanics...."
I guess this is not "low battery issue" this is problem with not enough tools to generate some well structured code. I guess we need something like "goto" instruction, may be it will be...
"--While experimenting, a flawed program made one of my CMs "eat" a seed." oops.. ;)
"Also, some way of checking/testing _what_ if being held would be nice, to prevent accidentally eating the wrong item" you can use compare function for this
"-- Related to the above, the ability of a grown tree to (sometimes?) "drop" a seed as well as wood would be nice."
In early versions wood drops seeds periodically at random time... And it wasnt cool corse most of players dont understand where this seed appeared from. And other problem is that when you get 5-10 seed you dont need it anymore, and corrently we dint have any other vay to use it instred of planting. I hope we can take a second try for this mehanc when we will added second stage of crafting tree, but cant promise this
"-- Add an instruction to "Feed" another CM (as well as one to find one needing power)." Yep this is in plans.
"-- Add the ability to pick up and move the "Current Execution" icon to any instruction in the current program screen." This is also in our warklist but this is quate unordinary feature in technical side, so I dont sure we will implement it in close perspective
"Of course, I still hope to see:" We working on it)
Hello @dacapoday. We were totally unhappy with the resources situation you are referencing to. That's why the last few weeks we were in the biggest redesign of the map zones since the first Alpha. I can't wait to share the updated version with you.
As for hard ice - it's going to be changed a bit to become meltable and diggable. Probably you saw the Meltomate feature in our roadmap, you can consider it as a spoiler :)
Perhaps the resource positions can hold a variable amount of resources? The image used can vary by how much is currently available? (Right now, there are only two types of each, a "5 count" and "1500 count" version.) Possibly add some very high (maybe even infinite?) resource tiles, especially near the edges.
The ice might vary according to how much heat it is near. Adjacent to a heat source might make it melt (maybe within 2 tiles of a heater?) Likewise, some way to make ice from water might be handy. Could be an "ice machine", and/or a "heat shield" type placement.
Super addictive game. It is very nice, it was very fun until it was just trying to keep them all fed and to keep bonfire active.
I would suggest extending the bonfire lifetime, and maybe extending the food meter for the bots. I also struggled in the beginning to find the recipe for the storage, the icon for the storage in the menu is small making it miss-able. Maybe you could reorganize or even categorize the recipes to make them more logical.
Hello @ibrahimbeladi. Thank you for the kind words and for the suggestions. Just discussed all of them with the team :) Hope to roll out the implementation of them really soon :)
Will not execute in Debian 10 (Linux), with the following error:
./Craftomation101.x86_64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./Craftomation101.x86_64)
Also, in the Itch.io web version, if I right-click any time, the interface goes weird -- It moves the map around instead of picking up objects. The only way to fix this is by saving the game and reloading and starting the web page entirely.
Hi @Casteele. As for Debian - we'll try to find the PC with version 10 and make a test with an empty project. Also in this week's update, we are upgrading our game engine, so probably the issue will be fixed by it.
Just added the right-click issue is our bug list, will be fixed.
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.
I have noticed some other issues...
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.)
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.
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.
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.
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.)
On occasion, I encounter glitches which cause items to appear on screen that cannot be interacted with (or removed from screen!).
Some future improvements might include:
Ability to find nearest resource pile (and/or nearest appropriate storage) to get from/drop to. You would need separate ones for each, to avoid a CraftoMate infinitely getting an item from storage and putting it back in the same storage.
Logical constructs, such as "if/else", or finding, for example, which bonfire has the lowest level of fire.
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).
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!
Linux Mint 19 has the same issue because we have an older version of GLIBC. The game would probably work with Debian 11 or Mint 20 because we would be using the newer version of GLIBC.
The js-web version of the game works fine on Mint 19 and probably works on Debian 10 also, so I would just use that unless you upgrade your distro.
If you use the itch.io app, the html5 version of the game runs in a standalone window instead of running in your web browser, so it's not really any different than running the Linux build.
Playing the HTML/JS version is mostly what I have done. Tweaking some things and running in a sandbox jail with a few modified libs has had some success for me, except an occasional segfault or other crash.
Hi @conronro :) Thank you, it's a really nice idea! Already in our roadmap. We call it memcopy (it means copy memory which contains program from one craftomate to another).
Mushrooms is some kind of legacy from the previous versions of the game. Previously the game's goal was to create enough oxygen, water and food (mushrooms) to make the planet ready for humans living. It will be changed in the upcoming updates :)
Hello @Denzstrike :) Oh, we should make it more clear in the game, thanks for highlighting the issue. To charge your CraftoMates just drag-n-drop an element to them. They will eat it and get charged (a lot from batteries, a little from other things).
I love this game! But may I suggest allowing us to both program or give them jobs? I like the idea of jobs (that i got from reading Schifty's comment) But The programming is so much more personal
I love the "jobs" idea too and visual programming allows me to imagine extremely complex systems :) I don't know what is better, but let's talk when we'll roll out the huge update of the programming system with functions, loops, conditions, and all the things we programmers like :)
cool game - I would buy a full version on Steam! couple of ideas:
- instead of programming robots you should make 'jobs' and assign the robots to jobs as this would cut down on script maintenance!
- I don't use fire pits as they require coal and simple flames are free forever; you probably need 'ice levels'; higher ice levels can only be melted by stronger flames; or you can make fire pits revert to lower heat when not maintained
- add a checkbox "2x" to most nodes meaning a robot would pick up, eat, drop up to 2 items
- don't know if that was a bug or not but scripts should automatically trigger idle / restart if they are done; I currently have to build a main loop in idle and revert back to idle after 'low battery'
Its a good game but, its incredibly hard to keep the ice from coming back and every time you click on the robots, it pulls up their programing, another thing is that once you put something in a storage you cant move the storage anymore. That's the only stuff i got annoyed at, other than that, good game.
Thanks for the kind words and for the super detailed feedback, love it. Just discussed all highlights from your post with the team, some of them probably will be shipped in 0.26 this week :) Have a happy holidays season!
Just wanted to say thank you for bringing up the issue of the annoying auto-open programming panel. We've fixed that in today's update 0.28. Will be much more new stuff in future updates! Have fun :)
Hi @reopucino :) Thank you very much for the kind words, we'll keep updating the game! The thing we dream about is to read more responses in our feedback form to find the best way for the game to evolve :)
← Return to game
Comments
Log in with itch.io to leave a comment.
I made glass in the demo, but it showed I've made iron, weird
hello, what version of OpenGL does this need and is it possible to build-from-source? I'm trying to get the game to run on my kids' Raspberry Pi 400s (where they learn about coding!) but we need box64 to emulate from x86_64 to arm64, and I think we only have OpenGL 3.1. Currently it is giving us an opengl error but I'd be grateful to know what dependencies there are before trying to fix.
Defold 1.9.1 (engine we are using now), use OpenGL 3.1, so it should works (cant promice that it will goes fine on RPi:) ).
If you trying to start Linux build, you also need some extra "libopenal1" package
I got it working now on Rpi, but there is an issue where the squares that are supposed to be snowy or frozen appear normal. Crafting etc and the overall interface seem to be fine it's just displaying those tiles wrong
Oh, I remember seeing this issue on Android years ago when we were considering an Android release.
I think it might be an ARM-related shader issue.
Unfortunately, I don't have a ready-made solution for this.
Oh, looks critical, will check it asap
Oh,foget to text here :(
This is fixed ofc!
hello there =)
for some reason, when i install the game via the itch app, i am only getting the demo version
i can download the full version via the webpage just fine
(the page states that i purchased it and lets me download it via my library, but the game page itself does not turn the files for the full game into links) , but that means i will have to manually update, rather than getting them automatically
is that effecting anyone else? and is it something that can be fixed on your end, or is that something breaking on the itch side?
I'm seeing the same thing: The itch app downloaded the demo version, but the itch webpage has the full version for download.
hmmmm, it looks like we cant configure this (or I cant figure how to) :(
But as I see, file can be changed on download confirmation window. So this is the way you can download fuul game with app.
if you use the furnace you can melt the ice that is “not available in the demo” and gain access to some of the upcoming features
i give up. i have tried many time to get a good downloaded zip file, with no success, I also had to find the file and the download log because the downloaded filename gave no clue what it was.. just "x86_64-win32.0.69.2.itch.510,zip" which could have been a virus for all the name suggests...nothing to indicate this was craft-o-mation and not something else. i am really disappointed with the developer now--they took a great concept and working program and turned it in to utter garbage
Hello @Casteele,
Nice to hear from you, long time no see. Sad to hear that you can't download the game, especially with the fact that you have been here with us for a long time (and we appreciate it a lot).
Would you mind elaborating a bit on that so we can help you somehow? What happens when you click on the file here on Itch, what web browser and operating system do you use? Do you have any issues with downloading files from other websites? Is the web version here on Itch or Steam Demo work for you?
I just tried to download the game using Chrome and Safari browsers for all the platforms and it looks like all is fine.
As for the filename - good suggestions to put the title into the zip filename, I just renamed all the files here on itch and in our build system, thanks!
P.S. Please feel free to contact me directly if it's more comfortable for you, my email is - oleg.chumakov@luden.io
sorry, my health has turned sour (i had a crippling stroke), so this and other games have taken a back seat.
This is the best automation, and programming game ive ever played!!!
i managed to make the craftomates farm trees without the "Check plant" node lmao
im dying for the games release this is so cool
```i managed to make the craftomates farm trees without the "Check plant" node lmao``` Great achivment! "Like in ancient times"
Thank you (｡◕‿◕｡)
Eearly acces is soon :)
Just encountered a pathing issue after switching bots from regular code to pre-programmed functions. I switched out all of the fire-making code for a function that did the same thing and for most of the bots it was perfectly fine, but I had to re-reprogram 3-4 of them back to the regular code. They made sparks perfectly fine, but kept attempting to get coal from a source that was completely blocked off (all 3-4 chose the same one). The best part was that the coal they were trying and failing to get was surrounded by the largest quantity source blocks, so I couldn't make an opening for them to get to that block.
I had to change them from the function I made (which used "Find and Pick" for all materials) to "Pick From" with a coal source that they could actually access. I didn't have this issue in the previous update of the game that I played 7 months ago, and only a few bots were effected by the change. I don't know if campfire placement was an issue, because I only thought to check the campfire location of one bot, but that campfire wasn't placed very close to that coal or anything.
In case it matters, the unreachable coal in question was at the bottom of a vertical 3-block line of coal. It was surrounded on all sides, unlike the other 2 coal blocks next to it, which had at least one uncovered side. The other bots used the top one in the line, and maybe the middle (but I didn't think to watch for that). I had to change the problematic bots to pick specifically from the top one in the line. The rest of the bots chose that block just using the "Find and Pick" code.
oh, we made some pathfinding optimizations a few weeks agow, maybe this is a consequence of this...
Did you report it with ingame bug reporter?
Looks bad,not cool that we have that issue on release buld :(
oh, I think I see your report on feedback sheet, but it is after you fixed problem :(
Hey, thanks for your reply! I actually didn't notice the feedback sheet, sorry. That must be from someone else who had the same issue, unless I somehow did it and forgot. But if I remember, I might go back and reverse the correction I made (if necessary) and make a proper bug report later.
I think is didnt worth it, if this is an actial issue, I will recive many of feedback about it.
But just in case you meet yhis issue again report it please :)
Massive Doodle god vibes. i love this !
(◠﹏◠)
I don't know what to put here . I'm the low key geek. I love the game ,will likely play more soon , Its lit & got my brain Freezing and buzzing pretty fun , Wish I didn't have to go to bed soon but have to stop so good Night and thanks for the amazing game
That's so cool to know that our game resonating with you, this is the greatest reward for us!
Thank you for playing our game :)
this is so cool ngl
(｡◕‿◕｡)
It's got potential, there's a ton of game design balances that need to happen such as adjusting the length of time the fire burns (it's too short now), how long batteries last (too short - could be tied to a difficulty setting), and other QoL adjustments such as being able to drag to select multiple code-nodes.
I don't like how the connecting lines do that automatic squiggly look when connecting nodes. I do, however, like the idea of an node that doesn't do anything which allows you to organize the connections, make one of those that also works for the location data of variables and make the lines just be straight and that would be significantly better than it is now.
Will try to increse time fires burns, why not.
B.t.w you can select a bunch of nodes with holded Ctrl, this feature should be introduced by some manual yep...
Iwe thinking about change link system to something closer to Linkitogame or tinkercad. But not shure about prioirity of this task.
Amazing game! Really fun and addictive, and everytime my factory messes up it's my fault not the game's, and i know exactly what went wrong lmao
10/10 would craftomate again
Thanks ヽ(´▽`)/.
You will be able to craftomate more soon, when will be released in Early Acces Jan 24.
loved it. I would suggest to color swap the robots so you can spot them easily
Hi, can you clarify what you mean by "color swap"? Ability to change Craftomate's color?
An example : I had 7 or so robots, each doing a task. all of a sudden, the northern fire pits started to run off fuel. I looked for the robot in charge of feeding those to see what was wrong with its program but I couldn't find them in the crowd, and problems cascaded. From that point, each time there is something off, I hit pause immediately and hover every robot with my mouse to see their name. This breaks the rhythm of the game. My suggestion is to let the player change the jacket color of each robot as well as their name to differentiate them easily.
I hope my explanation is cleare
I get it yep, there is ingame method to color mates useing eatble dyes.
And you can rename craftomates as well.
All this solves problem for a part, but thats fact that we have some issue with navigating over Craftomates. Now thinking about some interface to grouping tham and navigate more convinient. Hope to implement in November.
Great idea but the beginning is incredibly annoying. The snow groing back resetting every progress in the area and freezing units is too much of a setback to actually enjoy the game.
I wish there was a better way to restrict the area, maybe with connection beacons instead of campfires, it does not fit the mecha-aesthetic visually nor does it make mechanical sense when evrything else is futuristic.
Too many things are happening at once and the floor is cluttered with items instantly. This game does not give the player the time to explore and make mistakes, it punishes and sets back the progress.
The UI is pretty and intuitive, especially the programming part. In the same vein there needs to be settings to change the sizes, at least for the font.
UI and graphic style are great, UX and mouse controls need to be tweaked. In my opinion the whole point of programing-style games is to make mistakes and find out new things with time. So far the gameplay loop seems made only for people already proficient with it, new players are going to pick games they don't feel frustrated because they forgot to supply one campfire.
Can't wait to see how this develops!
Thanks for so comprehensive review.
Can you clarify, is bonfires feels frustrating to you only on the beginning?
Or the whole concept of melting snow with bonfires looks weird to you?
Or it starts from some moment.
Beause beacons looks close to idea with bonfires.
May be some item like "thermal bomb" witch will temporary will melt snow on tile it droped to will solwe this problem better.
I have not reached anything beyond the first couple quests but what annoyed me was that I lost space to work with every time a bonfire went off. The floor was littered with items (because I tried out new combinations) and the workspace was cluttered.
What I would suggest are ways to give players the chance to sort in a way before they reach dedicated storage units (to prevent cluttering) maybe via the ship so the player can hold a small amount of items they dont know what to do with.
Another way to prevent it feeling like a punishment for trying out new things is to slow down the rate snow grows back. As soon as I made a mistake the bonfires went out, leaving me with no way to reach the further still active fires.
To keep it short – losing workspace, progress and the connections is a bit too punishing for new players as far as I have experienced it.
What particular mistake did you made :)
Im just trying to imagine a full scene, sorry if I'm a little annoying
You are not at sll annoying, its hard to explain via text. Ill try to take a couple screenshots and post them in the discord!
But to give a better picture, the floor was partially filled with items I collected when exploring the surrounding with the bonfires. Once I lost one bonfite I automatically lost valuable space to organize my items and had to move them closer to the rocket, cluttering the space even more.
Like I said, this is only a critique at the start of the game when the player is making mistakes with the bonfires.
Giving the players a bit more space to create chaos at first could make it more smooth when learning the ropes. Boomers like me can easly get overwhelmed if I have to do more than focus on bringing back my old ActionScript knowledge :D
Hi Atih, I did see a youtuber grab one of the extra flames in the first bonfire and drag it to other bonfires. Temp solution of cause before we automate more and more, as in Autonauts, have a look if you want. Great game, I just started today, great time to be a gamer right?
C u in the Discord!
(could not find your name there, I'm called the same as here, find me if you want to chat ok?)
Jake.
Ok I get the core.
b.t.w You can use in game bug reporter, it will send us save and screenshot.
Brilliant. Loving it. This is how kids will learn programming these days ;-)
Unfortunately it is quite a bit buggy. Hope you guys will continue working on it.
Thanks:)
Yes we are continuing, you can check our Steam page https://store.steampowered.com/app/1724140/Craftomation_101_Programming__Craft/
By the way, we are currently conducting a playtest, so you can try out the latest version there.
This game is my kinda jam. I'll probably never stop playing this!
Can't stop developing this!
P.S. Thank you for the kind words, doing our best and looking forward to the release :)
Awesome!!
Very glad to hear this (｡◕‿◕｡)
Could somebody please tell me how to fix my craftomate's arms? They're flashing red!
This indicates that the craftomate cannot execute the command because it is holding something inappropriate in its hands.
As example tryes to combine something uncombinable, or try to pick some item with filled hands.
Try to reset craftomates program with button on the bottom panel.
Oh, okay. I did notice somebody on youtube reset the program when it happened to them. They didn't mention it so I guess knew all about it! I didn't actually know WHY this happens, so thanks
Cool game! I personally find it lots of fun for a browser game - like a modern day Flash type of game that we never saw follow up on the deprecated support of Adobe Flash! Millions of children would open a browser in their school's computer lab and spend countless hours of lunchtime, free periods, afterschool and any free moments between classes playing their favorite Flash game by themselves or against their classmates! However, once Flash was discontinued, decommissioned, deprecated and disappeared, or whatever, from modern day implementation I feel like this once new found gaming platform was dropped and disappeared rather quickly without any eagre successor in line to make use of these newly unplatformed young gamers and the genre of browser games just sort of faded in to obscurity? (Not sure Zynga or Facebook really counts as an attempt at housing this population) Why another technology or company was not quick to take up the slack in supplying even the most basic crossplatform browser game engine or something I can't say - But with games like Craftomation 101 available and playable as it is, I find it even more peculiar to have felt browser games seem to have died out like they did because if games like this can be made I'm sort of surprised developers didn't just transition to whatever this is built on and continue the browser game genre I felt played such a big part in my generation's initiation with computers and internet technologies of the sort? ¯\_(ツ)_/¯
Dear friend, it was very nice to read such warm words about our game, thank you very much. We also started our gaming journey with simple but exciting Flash games, and sincerely mourn the passing of that wonderful era. But the world of business competition is cruel and unforgiving, and the good old Flash fell short of this deadly race, retiring in the prime of his life. Alas and ah .. Now we need to learn to live in a new era, with new game engines and new players who are already growing up and not knowing that there was once such a wonderful thing as a Flash player built into every browser. We will try to do our best working on this game, and always sincerely appreciate your inspirational support. \ (•◡•) /
my game isn't loading
Thanks for reporting, but in my PC it works fine.
What you mean? Game isnt loads at all, or it didn't loading your save?
And what are you playing on?
i mean the save wasn't loading and i play on a crome book
uff, unfortunatly we dont have a chomebook to check/reproduce that (on Win/MACOS/Ubuntu all works fine). Will try to use some emulator later.
One more time thanks for reporting :)
How do you make wires? I have phosphorus but I have no clue on how to make wires. Surprised you didn't include it in the tutorial considering that batteries were.
wires is stone + steel (a bit weird, yep) :)
Sorry for the late reply, thanks for the help, Though Figure it out around a hour after I submitted the comment. By the way, do you apply feedback received to the itch version, or are you saving it for the full version?
Demo now is frozen, so we only releases fixes sometimes. New content and some significant changes will be released as part of Early Access.
b.t.w if you are interested, sometimes we are posting a test builds with new content in our Discord server (https://discord.gg/ludenio).
good to know.
how to make magnet please tell me
Hey :) To make a Magnet you should combine Iron and Steel. Also, there is an in-game Wiki available with all the recipes. I hope it helps :)
game completely froze yesterday when arranging a program. i had to use Alt+F4 to close it.
the fires don't burn long enough. in most cases not even long enough to supply them by a production chain with dedicated jobs.
Thanks for reporting that crash, we'll look into it!
As for the lifetime of the Bonfires - that's something new: usually we get reports from people who managed to load so many Fires into Bonfires by using the robots, they run out of resources on the map.
The typical scheme would be to unlock Storage units and then divide CraftoMates into 2 parties: the bigger party would be busy crafting the Fires, while the smaller party of 1-3 CraftoMates would deliver those Fires to Bonfires.
How are you trying to approach this task?
i had three bots transporting fires to each 2 bonfire+having an emergency crafting in case they found none; and one bot crafting bonfires at a storage directly between stone and coal. the storage was always stocked, but they couldn't deliver it fast enough.
Hello again,
Don't you mind elaborating a bit? I am not sure if I understand the issue you are referring to 100% correctly, especially the part "they couldn't deliver it fast enough". What is current behavior and what is the expected behavior? (Screenshots are always super helpful for me to understand). Thank you!
fires go out and areas freeze before they can refuel them, even although the only need to pick up flame and deliver it. the fires only last a few seconds too short.
Whoops, seems I found a bug. When copying a program to another CM, the current program execution position does not get reset (I have not checked if run/pause state changes).
Most likely, the program position _should_ reset to idle and enter paused mode for the CM.
Oh thats not literally bug, but I agre that this is more logical behaviour, we will change it I guess.
After being away for awhile, I got in to a discussion with someone on another game, and this game was mentioned. So I reloaded it to see what, if anything, the developers have done since I last played. I was very happily surprised to see they have done a lot of work on the game, ranging from general tweaks and improvements to adjusting and correcting previously reported issues, to adding user suggested features. Kudos to the developer, and two thumbs up (more if I had more thumbs!)
Hello @Casteele,
Nice to hear from you again! Doing our best. Funny coincidence but the next update will bring one of the most requested things :)) Spoiler: CraftoMates will become able to manipulate in new directions :)
There are some other issues, however...
(1) "Find and Pick" needs some more/better logic. Ideally, it should be able to include/exclude types, such as "From Box" (storage boxes), "From Raw" (I call those "piles" of raw/not-yet-mined resources), or even both. Perhaps even the ability to pick both but give a preferred type (Pick from Box, if available, raw pile otherwise). This is because I set up a CraftoMate (hereafter referred to as just CM) with a program to "Find and Pick", "Drop to" a box, then "To idle". But the result surprised me: It worked the _first_ time, but the second time it picked from the box it just dropped to (since it was now closest)! I adjusted to program to include a "Move to" first, but later in the game it caused problems when a) I had multiple storage boxes spread out on the map and the raw resources piles eventually became depleted. (Likewise, the "Drop to" might be able to only drop "On Ground" or "to Box".)
(2) Some degree of "look ahead" would be nice. I was trying to clear two adjacent Stone piles, so I had he logic of "Pick From" the first, and if that failed, it would "Pick From" the second. It worked, but every time it would move back to the first position, fail because it already cleared the tile, then move back to the second position. It should see that the first is already clear and go directly to the second, instead of wasting power moving back and forth needlessly.
(3) Related to (2), the "Warning" icon in the upper right that appears next to the pause button should not appear until the CM becomes truly "stuck". Every time it went to the first position and failed, the icon would pop up and then go away as soon as it went on to the second position. Not only does it create a momentary flash that distracted me, it also made it harder to be able to find and focus on the real problem areas/CMs which are stuck.
Some other observations and ideas:
-- I would like some detail/info on how variables work.
-- I kind of miss the old "Low Power" mechanics. I suggest that, instead of making it an "if/then/else" style operation, that you make it more like a sub-program (but not an exception that can occur any time -- only when instructed to check power). That is, create a "Low Power" label lower down like was done previously, and when the "Check Power" item executes, it will either continue to the next instruction, or "Jump" to the "Low Power" sub-program. This way, upon fixing the low power condition, we can choose to "Resume Next" which will go back to the "Low Power" check and continue on, or we could "Resume Idle" similar to the "To idle" instruction.
-- Make certain items not "eat-able". While experimenting, a flawed program made one of my CMs "eat" a seed. Oops. Also, some way of checking/testing _what_ if being held would be nice, to prevent accidentally eating the wrong item (especially when holding two items).
-- Related to the above, the ability of a grown tree to (sometimes?) "drop" a seed as well as wood would be nice.
-- Add an instruction to "Feed" another CM (as well as one to find one needing power). This way, we could assign one CM to "Stand By" the Battery Storage box, and when another CM needs power, the assigned one can grab a Battery and go feed it to the one needing power. (This could also be combined with my "Low power" suggestion to maybe add a "Call For Help" instruction, which would pause the bot until help arrives... or the player corrects the situation.)
-- Add the ability to pick up and move the "Current Execution" icon to any instruction in the current program screen.
-- A CM instruction to "Wait", which would make it wait (do nothing, such as "10 seconds", or until an even occurs, such as the "Feed" idea).
-- A "Give to" instruction, which could give to another CM. (Useful for things like "Feed"?)
Of course, I still hope to see:
-- Program labels, which could be targets of a "GoTo" instruction.
-- Sub-programs, which could be done with "Call" and "Return" instructions.
-- Real "if (condition) / then / else" logic. (Especially useful with sub-programs.)
-- Looping constructs. (Command Center wants 10 Steel Plates? Set up a CM to deliver exactly 10 then stop.)
Ufff such a huge abd cool feedback, lets starts from point to point.
(1)I think generaly smart commands is about "take less parameters, and make some complicated things" and in this case we dont need to add one extra parameter. Besides it generates some fun situations :)
Other reasin not to add such parameter is that usualy when you want to tell craftomate to "pick some element from storage" you talking about one specific storage, and for this case you have a "pick from"
Btw: we working on command that will dedicade a working zone for each craftomate, this should be usefull for your case
(2)This was some discussion topic for us. But currently our consensus is that this is works precisly like in real programming: "every data read event from isn't free (it costs time and energy)". But now "find and pick" brokes this concept down, so may be thats good idea.
Btw again: may be this problem can be solved by add "find" command: this is command that should save coordinates of coresponding element into variable (currently in work)
(3) Yep I agree Warning icon have outdated logic, we will rework it soon, thanks for reminder, I forget about that icon :)
to be continue...
Re (1), perhaps instead of an option, have different commands? "Find and Pick" to get from storage only, "Find and Mine" to get from raw resource piles only, and maybe a "Find and Get" which would get from either? As it is, it reminds me of how "Smart" phones like to "auto-correct" with the wrong correction... But at least with those you can choose to force it to your desired result.
As map size and game complexity grows. it will become less likely to have a single storage box dedicated to each item. Instead, transport lines will evolve: CMs will mine and deposit raw goods in areas where they are found, while other CMs will transport from those collection centers to different production areas where they are needed. (A true "ideal" would be a distribution "on demand", instead of "equally spread out"...)
In reality, a well-designed distribution is the opposite of "one specific storage", but a need to locate one of possibly many storage and staging sites with the desired item -- the lower cost of finding it outweighs the larger cost of walking across the map only to discover the single storage site is empty.
(2) That is not entirely true. A program can use logic to avoid wasted CPU or I/O. If a file is exactly 2 bytes in size, and you have already read 2 bytes, you know trying to read it again will give an EOF. Likewise, a CM knows if it is occupying the space requested, and nothing else is (or can, as the game is currently designed), it can skip trying to take take a step backwards to try to grab the space it just vacated.
A general "Find" feature would be a suitable alternative. But you can still assume that the CM has sensors (i.e., eyes) and can already know the command will fail.
"-- I would like some detail/info on how variables work."
I guess we will add some wiki for all commands not soon, but precisely wil :)
"-- I kind of miss the old "Low Power" mechanics...."
I guess this is not "low battery issue" this is problem with not enough tools to generate some well structured code. I guess we need something like "goto" instruction, may be it will be...
"--While experimenting, a flawed program made one of my CMs "eat" a seed." oops.. ;)
"Also, some way of checking/testing _what_ if being held would be nice, to prevent accidentally eating the wrong item" you can use compare function for this
"-- Related to the above, the ability of a grown tree to (sometimes?) "drop" a seed as well as wood would be nice."
In early versions wood drops seeds periodically at random time... And it wasnt cool corse most of players dont understand where this seed appeared from. And other problem is that when you get 5-10 seed you dont need it anymore, and corrently we dint have any other vay to use it instred of planting. I hope we can take a second try for this mehanc when we will added second stage of crafting tree, but cant promise this
"-- Add an instruction to "Feed" another CM (as well as one to find one needing power)." Yep this is in plans.
"-- Add the ability to pick up and move the "Current Execution" icon to any instruction in the current program screen." This is also in our warklist but this is quate unordinary feature in technical side, so I dont sure we will implement it in close perspective
"Of course, I still hope to see:" We working on it)
Very short of stones and hard ice can't melt even around with fire.
Hello @dacapoday. We were totally unhappy with the resources situation you are referencing to. That's why the last few weeks we were in the biggest redesign of the map zones since the first Alpha. I can't wait to share the updated version with you.
As for hard ice - it's going to be changed a bit to become meltable and diggable. Probably you saw the Meltomate feature in our roadmap, you can consider it as a spoiler :)
Perhaps the resource positions can hold a variable amount of resources? The image used can vary by how much is currently available? (Right now, there are only two types of each, a "5 count" and "1500 count" version.) Possibly add some very high (maybe even infinite?) resource tiles, especially near the edges.
The ice might vary according to how much heat it is near. Adjacent to a heat source might make it melt (maybe within 2 tiles of a heater?) Likewise, some way to make ice from water might be handy. Could be an "ice machine", and/or a "heat shield" type placement.
Super addictive game. It is very nice, it was very fun until it was just trying to keep them all fed and to keep bonfire active. I would suggest extending the bonfire lifetime, and maybe extending the food meter for the bots. I also struggled in the beginning to find the recipe for the storage, the icon for the storage in the menu is small making it miss-able. Maybe you could reorganize or even categorize the recipes to make them more logical.
Hello @ibrahimbeladi. Thank you for the kind words and for the suggestions. Just discussed all of them with the team :) Hope to roll out the implementation of them really soon :)
Could you take the phone number restriction off of your discord please, I do not have a phone.
Hi :) I'd love to but it's a requirement from Discord to become a verified server.
Will not execute in Debian 10 (Linux), with the following error:
./Craftomation101.x86_64: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./Craftomation101.x86_64)
Also, in the Itch.io web version, if I right-click any time, the interface goes weird -- It moves the map around instead of picking up objects. The only way to fix this is by saving the game and reloading and starting the web page entirely.
Hi @Casteele. As for Debian - we'll try to find the PC with version 10 and make a test with an empty project. Also in this week's update, we are upgrading our game engine, so probably the issue will be fixed by it.
Just added the right-click issue is our bug list, will be fixed.
Thank you for reporting all of this!
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.
I have noticed some other issues...
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.)
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.
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.
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.
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.)
On occasion, I encounter glitches which cause items to appear on screen that cannot be interacted with (or removed from screen!).
Some future improvements might include:
Ability to find nearest resource pile (and/or nearest appropriate storage) to get from/drop to. You would need separate ones for each, to avoid a CraftoMate infinitely getting an item from storage and putting it back in the same storage.
Logical constructs, such as "if/else", or finding, for example, which bonfire has the lowest level of fire.
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!
Linux Mint 19 has the same issue because we have an older version of GLIBC. The game would probably work with Debian 11 or Mint 20 because we would be using the newer version of GLIBC.
The js-web version of the game works fine on Mint 19 and probably works on Debian 10 also, so I would just use that unless you upgrade your distro.
If you use the itch.io app, the html5 version of the game runs in a standalone window instead of running in your web browser, so it's not really any different than running the Linux build.
Playing the HTML/JS version is mostly what I have done. Tweaking some things and running in a sandbox jail with a few modified libs has had some success for me, except an occasional segfault or other crash.
could you add a thing in the program editor where you can store code parts, like a low battery eating part that you can transfer between CraftoMates.
also what can you do with mushrooms?
Hi @conronro :) Thank you, it's a really nice idea! Already in our roadmap. We call it memcopy (it means copy memory which contains program from one craftomate to another).
Mushrooms is some kind of legacy from the previous versions of the game. Previously the game's goal was to create enough oxygen, water and food (mushrooms) to make the planet ready for humans living. It will be changed in the upcoming updates :)
i love this game but how to but how to charge the battery when the battery is about to run out???
Hello @Denzstrike :) Oh, we should make it more clear in the game, thanks for highlighting the issue. To charge your CraftoMates just drag-n-drop an element to them. They will eat it and get charged (a lot from batteries, a little from other things).
I love this game! But may I suggest allowing us to both program or give them jobs? I like the idea of jobs (that i got from reading Schifty's comment) But The programming is so much more personal
jobs could be functions called in a bot?
Hello @GOD.exe
I love the "jobs" idea too and visual programming allows me to imagine extremely complex systems :) I don't know what is better, but let's talk when we'll roll out the huge update of the programming system with functions, loops, conditions, and all the things we programmers like :)
cool game - I would buy a full version on Steam! couple of ideas:
- instead of programming robots you should make 'jobs' and assign the robots to jobs as this would cut down on script maintenance!
- I don't use fire pits as they require coal and simple flames are free forever; you probably need 'ice levels'; higher ice levels can only be melted by stronger flames; or you can make fire pits revert to lower heat when not maintained
- add a checkbox "2x" to most nodes meaning a robot would pick up, eat, drop up to 2 items
- don't know if that was a bug or not but scripts should automatically trigger idle / restart if they are done; I currently have to build a main loop in idle and revert back to idle after 'low battery'
Hello @Schifty,
Thank you for the kind words and wonderful suggestions. Just discussed all of them with the team! Can't wait to share the next update with you :)
Its a good game but, its incredibly hard to keep the ice from coming back and every time you click on the robots, it pulls up their programing, another thing is that once you put something in a storage you cant move the storage anymore. That's the only stuff i got annoyed at, other than that, good game.
Hi @W1redChad,
Thanks for the kind words and for the super detailed feedback, love it. Just discussed all highlights from your post with the team, some of them probably will be shipped in 0.26 this week :) Have a happy holidays season!
Hello @W1redChad,
Just wanted to say thank you for bringing up the issue of the annoying auto-open programming panel. We've fixed that in today's update 0.28. Will be much more new stuff in future updates! Have fun :)
wow great game, It makes me play more than 30 minutes.
Hi @reopucino :) Thank you very much for the kind words, we'll keep updating the game! The thing we dream about is to read more responses in our feedback form to find the best way for the game to evolve :)
I can't believe we've published this :)