Merry Christmas! And if I can interject, through my learnings I’ve concluded clearly that trying to make a dirty prototypes and successively making them closer to perfection through constant tests and ad hoc improvements in every iteration is far more effective than slowly trying to polish a diamond to perfection 
2 Likes
2/24/2019 (YIKES!)
A watched pot never boils…
My excuse to anyone watching the development of this devlog and hoping for it to have consistent updates. What could I have been doing for the past 2 months? Honestly, a lot of the lack of progress was from my own intimidation of the upcoming work on Chemaria being more art and asset-based. @Pawel was right though, I simply needed to jump in and here is the result!
Yeah, not that exciting. To be honest, this took me about 15 minutes to set up, and it made me feel stupid for not just jumping in and doing things the past bit of time, but no reason to focus on the past!
What has actually been accomplished?
Quite a bit actually. I found some various bugs when showing it off to people, fixing those. I also thought through some issues when it comes to adding non-placeable items in the game, crafting, and efficiency gains in all of these kinds of checks.
Honestly, all of these thoughts have brought up many smaller code-focused tasks for me to work on which is part of why I was encouraged to jump back in.
I created a few more issues on the repo. Finally got past my block in design and started to better define the sprite style.
I give all the thanks on this to my ceramics class this semester. Being forced to begin thinking creatively is helping me in many ways and is definitely going to bring some improvements to Chemaria.
Why a full two months?
In these two months, I have been busy with school, my senior design project, designing an entirely new 3D game with my roommate, starting to write an operating system with a friend, planning for my wedding in June, and general life things.
I have tried to stay involved in the forums even in this dry spell for me, answering whatever questions I can, and always paying attention to new topics.
I am fully back in business now though! Thank you for being such a generally wonderful and supportive community. Here is a relevant quote from Herman Melville I stole from a Google search:
It is better to fail in originality than to succeed in limitation.
8 Likes
3/16/2019
Randomized chunks and more blocks!
In preparation for implementing crafting, I have been focusing the past bit of time thinking about what kings of blocks I need and making them to have some examples once I implement crafting.
So what we have are these three new blocks
Sand, clay, clay bricks, stone bricks, and wood walls! I think in making these a direction in style is really being established. Hard lines, solid colors. Simple, sort of sterile, but I like it!
In the future, it would be nice to allow people to use their own sprites as well through texture packs? We shall see once that is in scope.
Also for now there is a very naive random generation of chunks occurring. The deeper you go, the probability changes, but for now it serves the practical purpose of providing a variety of blocks for me to mess with as I walk around.
Not as crazily big of an update as I intended because school has been busy, but I am happy nonetheless. 
5 Likes
4/8/2019
Automatic deployment, ores, a player sprite, and crafting!
Another month passes by and whaddaya know, a little more gets done.
I made a goal for myself that until I implemented crafting I wasn’t going to post a new update on here. Too bad I got distracted by so many various Chemaria side tasks, but in the end Chemaria is better for it!
I set up automatic deployment on my Gitlab repo, so now whenever a merge is made into my master branch, my game is automatically build and deployed to Chemaria’s itch.io page.
On top of that, some new blocks have been introduced:
Gold ore, iron ore, platinum ore, and silver ore are now in the game (yes, platinum and silver are hard to distinguish, I will be working on that). Most importantly though, a new protagonist has replaced our lovable rectangle.
As beautiful as they come, Dave is here to stay, albeit with some hopeful upgrades and just a little more jpeg.
The moment everyone has been waiting for, I promise, it is as disappointing as you expected!
And there it is!
Is the interface ugly? Yes.
Will I fix it? I am going to try my best! 
Thanks to everyone so far in this journey. It is a blast and I can’t wait to keep working on it as development is likely to surge with a lot of the changes I have made recently.
6 Likes
What’s your automatic deployment setup?
So to start with, I am using Gitlab, so I use their CI/CD system. My CI yml is set up to install the correct version and kind of java for Bob to use, but most of the magic is in my build script and deploy script. The build script is actually just a slightly modified version of your build script from an earlier post.
The deploy script currently uses itch.io’s butler tool to serve the executables up to the channels on my itch.io page.
3 Likes
Thanks for sharing your CI yml and deploy scripts. I think Bitbucket has something similar with Pipelines and Github has a marketplace with a bunch of CI options. Seems super useful to be able to automatically make builds and deploy them to itch/Steam/wherever whenever a commit is made. I’ll need to do some reading https://confluence.atlassian.com/bitbucket/configure-bitbucket-pipelines-yml-792298910.html
2 Likes
Bitbucket is great. I have used Atlassian at previous internships and the whole ecosystem is great when trying to run a team or multiple teams.
1 Like
We use Jenkins internally at King and I’ve had to wrestle quite a bit with declarative Pipeline build scripts. It’s really nice when it works, but it was a pain to get it set up.
I’m using Travis CI for sequential build jobs and it’s easy to use and fairly well documented. Travis CI offers parallel jobs using what they call a Build Matrix. I haven’t looked into it much yet though.
3 Likes
4/24/2019
UI Development
I have been in a bit of a dry spot with Chemaria, making sure I do not overwork myself on it, I have shifted a bit of focus to some other projects in hopes that they will inspire me independently to some nice solutions for the UI of Chemaria, and lo and behold I have done just that!
My issue was mainly that I was struggling to both develop a mockup for my crafting UI (that has been mostly solved now by embracing iconography) and I was struggling to correctly utilize the Gooey extension.
I think my struggles with Gooey largely come from my specific use case for my UI. My UI needs to be very responsive and there are a lot of swapping and changing elements all over the place. I am working on a small tycoon game with Monogame for one of my side projects, and in working on it I saw how simple it was to develop my own UI library from scratch. I do believe Gooey is both powerful and very useful, but only in more simple use cases, and I think Chemaria will ease some growing pains in the future if I develop my own UI system.
Timeline?
Plot twist: There is no timeline!
Since I need to make my own UI library, it’ll be a little bit till any meaningful update is provided to Chemaria.
Good news!
I have finished the API and library for creating and managing logic circuits, all in Lua and fully unit tested! For the time being, also enjoy a furnace sprite with animations and some ingot sprites!
5 Likes
Could you tell me a bit more about the UI? Gooey is more intended for simple menus, popups and settings screens, but maybe there are things that could be improved to support the kind of UI you need?
2 Likes
Sure thing! The main issue I’ve honestly found is just working with the dynamic list. In all of the call back functions, there is no access given to the self of the script (this is very problematic because otherwise you can’t access functions written for the script itself. A work around I’ve made is creating a SCOPED_SELF variable for the script that I set in the init() function, but this should not be necessary.) Another issue is that with the list, when an item is selected, I would prefer to get the whole item back, not just an index representing the item. This makes it more difficult for my use case where I want to fill and change the list based on what items can and can’t be currently crafted, where if I just got the whole item back I could send that off to my crafting handler.
It is small things like that which I find most of the issue with. Using it for buttons, check boxes, etc it is fine and I still plan to use it. I have not used the input element either but I assume I will end up using that.
After itemizing this to you, I guess my only main complaint has been about lists, but for me it is a pretty big issue because I need the lists to work a pretty specific way. I likely in making “my own” UI system will modify Gooey a little bit rather than starting from scratch.
If you are interested, I can submit a pull request to Gooey after making my changes. I would just hope to expose more control to the programmer in interacting with it through giving them the full selected items back, introducing self into the update functions, etc.
Thank you for the summary and feedback! I very much appreciate it!
What do you mean by this:
Can you give me an example?
Sure thing. In the examples even on github this problem is shown.
local gooey = require "gooey.gooey"
local function update_button(button)
if button.pressed_now then
gui.play_flipbook(button.node, hash("button_pressed"))
elseif button.released_now then
gui.play_flipbook(button.node, hash("button_normal"))
elseif not button.pressed and button.over_now then
gui.play_flipbook(button.node, hash("button_over"))
elseif not button.pressed and button.out_now then
gui.play_flipbook(button.node, hash("button_normal"))
end
end
local function on_pressed(button)
print("pressed")
end
function on_input(self, action_id, action)
gooey.button("button/bg", action_id, action, on_pressed, update_button)
end
update_button() and on_pressed() do not have self passed in, so you cannot access self at all. The solution would be to pass self in the gooey.button() function. This would provide update_button() and on_pressed(), with access to self.
Ah, now I see. Well, one option would be to do like this:
local function update_button(self, button)
print("update")
end
local function on_pressed(self, button)
print("pressed")
end
function on_input(self, action_id, action)
gooey.button("button/bg", action_id, action, function(button) on_pressed(self, button) end, function(button) update_button(self, button) end)
end
Another would be:
function on_input(self, action_id, action)
local function update_button(button)
print("update", self.foo)
end
local function on_pressed(button)
print("pressed", self.foo)
end
gooey.button("button/bg", action_id, action, on_pressed, update_button)
end
And a third option:
local function wrap(self, fn)
return function(...)
fn(self, ...)
end
end
local function update_button(self, button)
print("update")
end
local function on_pressed(self, button)
print("pressed")
end
function on_input(self, action_id, action)
gooey.button("button/bg", action_id, action, wrap(self, on_pressed), wrap(self, update_button))
end
But I’m not sure of the cost of those inner local functions or anonymous functions. It needs to be tested.
1 Like
So are those all ways it can currently be accomplished?If that is the case, maybe I will still try and use Gooey as it is now, but this kind of thing should maybe be explained/documented somewhere.
1 Like
Yeah, that’s what I could think of at the time. It’s typical stuff you can do with Lua so it’s in no way specific to Defold or Gooey.
3 Likes
Nice to see your project growing! I’m really wondering how your database will perform on proper size world.
If you have knowledge more than me, then you could find this useful for managing tile data - Terraria tiles
1 Like
Exciting about this. I really like these types of games but have never tried to create anything similar myself (well, yes a couple of “minecrafty” voxel engines )
Got inspired to try my own approach of it.
Maybe this weekend…
4 Likes
I was absolutely unaware that Terraria’s source code was available for educational use and that it was made with Microsoft XNA/Monogame.
I may reference that for some things relating to world generation, but when it comes to how my world will handle being larger, I have tried my best already to make each individual block hold the most minimal data possible. An int representing the type it is, and a vector of it’s position relative to its chunks position. And chunks only hold their position and the table of blocks. Currently, my main efficiency issue is in saving the world, but I have a plan to speed that up immensely. Stay tuned.