itch.io

Sure I'd be happy to help. My main email is "rowanfr@gmail.com", you can send me an email there. If you want to send specific builds and questions there I can give you my thoughts. Fair warning though it will probably take 1-2 days for me to respond due to work, but so long as that's alright I'd be more than happy to help.

To answer the questions you have currently:

For the bit manipulation I would do what you suggested and mask it from the user, as most people aren't programmers and that syntax is something that's only familiar to them. Your correct that this would remove a great deal of the puzzle from the user so instead you could add complexity from creating the brew.

Their are 2 systems that I could think off, one which you put which is a tag system or a check-mark system. In essence it checks to see if you have applied certain processes, such as checking if something has been boiled or fermented, or if it's a gas, liquid, or solid. I don't think though that you should tag every element as that would be a lot of memory for every new element. I think tagging fundamental things like it's state or quality, or something else which would apply to many potions is good, but assuming you want a variety of effects tagging all of them would start to consume a lot or force overlap with other effects (such as 111* being confusion and 11** being slowness). One can get around this somewhat by using a priority system where certain effects are evaluated first but I'm not certain this complexity would be satisfying as one can't progress to discovery they instantly arrive at it or fail with no in between. Their is no close solution to what's requested which is really important for helping players learn, similar to most puzzles you want the player to get close to the solution so that they have something immediately to do and then let them work out the harder solution. (Credit where credit's due this idea comes primarily from Mental Checkpoint "How These Puzzles Deceive You" and you can also see a lot of this in GMTK "What Makes a Good Puzzle")

Another example example system would be that instead of a single byte with bit manipulation you could have multiple bytes represent axis in the game which you can manipulate in a greater variety of ways. Such as having 4 axes for fire, earth, air, water which could create a 4D graph (or 2D if you want to make it conceptually easier and have earth/air and water/fire be opposites) where you can have localized regions for certain effects, some positive some negative, which the user has to figure out by crafting brews. To alter the 4 byte brew one could produce something similar to what you have already made, just with more ingredients and more cooking methods which apply effects on those ingredients in systematic ways, such as fermenting amplifying the value on an axis. I think this would likely be fairly easy to implement (famous last words, I know) but create substantial complexity because one could include positive boons which they want to reach and negative side-effects which they want to avoid. The main downside is loosing the satisfaction and efficiency of bit-shifting but I think that if you want to open up a lot of effects you should do something which will allow that. Typically some systematic approaches that the user can build knowledge of to craft more advanced potions is satisfying, which is what made me think of that multidimensional system as it can be easily quantified and shown to the user while still providing complexity but it's not perfect. For one effects like confusion or invisibility will always have difficult recipes because it's hard for those things to have a defined composition of 4 elements, but the useful things about the axes is that one can give small context clues by how the in game character responds to the vector of a potion, such as the potion looks clearer than normal for the vector close to invisibility or upon smelling it gave a mild headache for the vector close to confusion. One could also combine systems like the tag system from earlier and others to make certain there is enough overall meat to the system. Another useful thing is that it becomes easier to add new axes by just adding another optional u8 to the brew struct (one can also isolate certain effect vectors to certain dimensions so that additional dimensions don't negatively effect information gathering for hard effects, such as confusion only being on the air and water axes).

Sorry if the previous 2 paragraphs are a bit large but this is at the core of the game and should be given the most thought as a result, no matter what system you chose to go with. Everything should branch off the core idea of the game which in this case is brewing. The main thing to take away from these paragraphs is not that you should use this multi-dimensional system, but rather that you should think of a system that would make the user enjoy thinking creatively while pursuing a specific goal whatever that system might be. Each brew request should be seen as a puzzle in some fashion, and engage the player as such. Whether it be in the procuring of materials, cooking, bottling, or some other aspect their should always be something that makes the player enjoy solving a puzzle or engage them in some other way (outside of the first few tutorial brews which should hold the players hand a little bit).

The mix of 2D and 3D is good so long as it is what is present currently, that being 2D menus are entirely separate from 3D assets. The main thing most would find jarring is 2D assets in a 3D world or vice-verse unless done intentionally.

For the world map first I would pursue it with time but first I would flesh out a store and have the current solution be you spend some resource at the store to get new items. You can add other systems to get more items such as Recettear where you fight in a quest to get them but I think creative generation of unique brews is this games focus, not questing or world exploration, so I'd leave that on the back burner until the main loop is finished and start with the simplest implementation of a shop's expansion.

No problem for the long reply, as you can see from most of my comments I tend to write plenty as well. I'm glad to have inspired you further, I was worried that my comments may have been a bit too much. Funnily enough going through your comment it seemed that most of what  caused problems were the typical dev issues of over-familiarity with the game that I personally guessed were the case (because I've had problems with that plenty of times). The exception to this was the fact that you knew about and prevented a soft-lock that I thought was in the game shows the though put into it accessibility, even if I didn't find it the first time around.

Thankfully, I think that most of the problems will have solutions that you can easily implement, and iterating on what one made in a game jam is a tried and true tradition. I'll keep the game in mind for when you update it

I think this game has an interesting idea to it, that being that placing towers has the side effect of costing health to the main base and local towers, which needs to be recovered at a later phase. I think that this game could do better with a scaling down of the number of enemies and an increased variety in the number of towers and enemies.

Additionally The tower placement probably shouldn't damage the enemies if one wants this to be a conventional tower defense game. It gets to the point where the damage from placing the towers is more relevant to enemy crowd control than their actual shots. I think if you toned down the number of enemies and had them come in wave, along with allowing the user to buy blocks that the enemies have to go around at the cost of health, you could have a fairly interesting tower defense game where their is a push and pull as to how many resources someone wants to play at the cost of their tower. The main reason why I recommend this pursuit in development is that the game eventually devolved for me to just repeatedly placing towers far away from my main tower (whether or not the damage decreases by distance or by number of enemies hit I don't know as their were always a lot of them) and the fundamental issue with this is it removes any element of strategy one might which is what many people who play tower defense games really like.

Overall it is a surprisingly fun game that I find myself trying to get a high score on (thus far 6127) but it lacks the depth necessary to make it engaging after the 3rd attempt.

I should have specified, the unusual movement is specifically for the cakes. I agree with you that the blocks move quite nice.

I think this was a good game, but their was a lack of a fail state (outside of the conclusion) and ultimately was somewhat grind filled to finish. Their should be some variety in acquiring past the second stage if one's trying to go for a cookie clicker style, whereas their should be enemies if one is trying to do a shoot-em-up style of game.

I want to give note to the graphics though as those felt astonishing to look at for a game jam game. It felt a few steps away from geometry wars. Overall it was a good game but it needs some failure state or variety to make it more engaging.

I think this was a very well done puzzle game with a lovely intro. The puzzles are good, though I'm not a substantial connoisseur of puzzle games. The main recommendations I would have for things to further develop is firstly a level selector. It's rather frustrating to have to repeat the same levels if I close the page. Secondarily, this might seem unusual to say but the animation needs a bit of work as the movement is unusual, but I unfortunately have no experience in animation and don't know how to resolve this. It just feels unusual.

Overall the story was fun as was the game play. I think it ended up being quite good overall as a game, well done.

I think this game struggled with having a scope that was too big for what could reasonably be finished in a game jam. Their were a lot of decisions that as I dev I understand why they were done in the short time frame but they caused the game to suffer immensely.

The most immediate decision I think should have been changed is the starting spawn camera angle, it should have been higher angled downward to the land so that it doesn't spawn the player in a manner that makes the game look bugged as shown below:

It should instead spawn you in a position as shown below:

This likely seems minor but you only get one first impression.  Aside from that the making of potions in the console is understandable for time constraints but in the future I highly recommend you make it more intuitive by adding a basic UI and translating player actions to those console actions so that way one doesn't need to understand basic scripting to play the game.

The main 2 final things to resolve are firstly their should be some benefit to turning in quests, either a new plant or some powerful item or even currency to buy either of those things.

Secondly It's a bit too easy to soft-lock yourself by cutting down a try early on with only ripe coconuts that can't be planted. This would be alleviated immediately with a shop of some kind where the sum parts of a tree can be sold for slightly more than a seed for that tree, making it to where it's hard to soft lock.

That's not to say its bad though (my apologies if I come off a bit harsh in the earlier section), its one of the only games with a lot of assets both in what one can grow and harvest developed in such a short time. It includes 2D, 3D, and icon assets that were undoubtedly hard to do all in 2 weeks.

Additionally it's a refreshingly different game idea with many submissions often being similar to basic projects this game took a risk on trying to develop something new.

Overall this game is hard to rate because it feels incomplete but it's also one of the only submitted games that isn't fairly basic. Their were lots of custom assets made in this brief time, a fairly fleshed out game idea went into this and ultimately it's one of the few games submitted that if refined over a few months I could see eventually developing into a real game. However as it stands it is a game without a fun game loop and complexity is not a substitute for the fun that a basic title can have. If I were to give advise on what to do I would say in future to focus purely on optimizing the game loop and hold everything else secondary. Their were many many different potions and effects but their was no incentive to do anything with them beyond turn them in without a reward. Focus on making the game loop good, which for this type of game would likely be creating potions, turning them in For A Reward, and then using that reward to make more complex potions/buy items/buy land/etc... Just have the loop beneficially feed into itself.

I know this might be an unfair critique given that this is a game jam and their was only 2 weeks to do this, but this are the main issues with the game. If they're resolved I think you'd have something good on your hands.

Great job on the artwork, the fluidity of it really draws me in. I don't mean to bother but do you include the aesprite files with purchase or whatever source files were used, unless you did everything raw (in which case that's very impressive). I haven't seen any mention of this so I just wanted to double check