Chemaria - Building and material-focused Terraria-like

Dev diaries
#24

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
#25

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
#26

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!
furnace furnace_lit_1 furnace_lit_2 gold_ingot iron_ingot platinum_ingot silver_ingot

5 Likes
#27

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
#28

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.

#29

Thank you for the summary and feedback! I very much appreciate it!

What do you mean by this:

Can you give me an example?

#30

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.

#31

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
#32

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
#33

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
#34

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
#35

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
#36

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. :slight_smile:

#37

@gamzwithjamz Iā€™m not sure of origin for that source code, pretty sure itā€™s not the official one. But for the big world, you wonā€™t get away with simple intā€™s, you need to use bitwise tricks - bit-shifting and bitmasks.
Hereā€™s a brief explanation about the topic in gamemaker forum. This is traditional bitwise calculations which I would like to have in LUA (LUAā€™s bitwise is not code friendly imo).

#38

Iā€™ve considered that as well for whenever the map would become unmanageable. Thanks for that resource honestly!

Eventually, once I release the base version for the game, I already planned on moving to Monogame for efficiency reasons in developing (Statically typed languages make developing and debugging a bit simpler) and for efficiency reasons (Like choosing the size of ints).

I will still release the source code for the base game in Defold because I want people to use Defold because it is honestly wonderful for small projects or projects you donā€™t care about having on console systems.

I have used bitwise operations in my logic simulator in Lua. Whatā€™s the problem you have with them? That it requires you to use numbers and not bools?

#39

I donā€™t like the thought of using ā€œbit.ā€ for each operation. I have some experience with c++ and Iā€™ve made platformer physics in Gamemaker (which uses C like scripting GML) only using bitwise calculations and tile collisions, so Iā€™ve grown fond of traditional syntax.
Just as random example, how tedious it would be in LUA to write something like:
a & (b << c);
or
a ? b : c;

It basically looses point to use bitwise for me. Maybe Defold use different LUA bitwise.

#40

As of Lua 5.3, Lua supports bitwise operators. I use these for my logic simulator, but I am unsure if Defold uses Lua 5.3 yet.

#41

We use luajit for most platforms, which has bit operations. For platforms that donā€™t use luajit we include a bitop library.
See documentation:

2 Likes
#42

Also, fyi, we want to keep the same Lua api between platforms, and since luajit is based on Lua 5.1, thatā€™s the version we support. It is unlikely that the luajit initiative will support any newer Lua versions any time soon.

1 Like
#43

So in Lua modules we write, we cannot use Lua 5.3 bitwise operators? Just replace those with the bit library instead?