I’m not finished yet. I’m not even halfway through. I’m sure I’ll still need help from you awesome people!
It is absolutely a good idea! I joined (or tried to join) three jams and even though I failed to make anything worthwhile each time, it pushed me a lot more than if I was just coding at my own pace.
1 Like
Well, I don’t take too well stress from being lost in documentation emptiness.
But I guess when a jam is gently pushing my limits, it could be fruitful.
Now, I’m trying to make sens of the collection proxy component.
This is a test based on this loop:
I wrote this code:
function init(self)
msg.post('.', 'acquire_input_focus')
msg.post("#title_proxy", "load")
self.state = 'title'
end
function on_message(self, message_id, message, sender)
if message_id == hash("proxy_loaded") then
msg.post(sender, "init")
msg.post(sender, "enable")
end
if message_id == hash("load_game") then
msg.post("#title_proxy", "unload")
msg.post("#game_proxy", "load")
end
if message_id == hash("load_title") then
msg.post("#gameover_proxy", "unload")
msg.post("#title_proxy", "load")
end
if message_id == hash("load_gameover") then
msg.post("#game_proxy", "unload")
msg.post("#gameover_proxy", "load")
end
end
function on_input(self, action_id, action)
if action_id == hash('action') and action.pressed then
if self.state == 'title' then
self.state = 'game'
msg.post('.', 'load_game')
elseif self.state == 'game' then
self.state = 'gameover'
msg.post('.', 'load_gameover')
elseif self.state == 'gameover' then
self.state = 'title'
msg.post('.', 'load_title')
end
end
end
But I got the following error:
The collection 'main' could not be created since there is already a socket with the same name.
What am I doing wrong this time?
If I want to create two instances of a game object from a factory, is it better to call factory.create twice or to send a message twice that would trigger a single call to factory.create each time?
This:
function on_input(self, action_id, action)
if action_id == 'start' then
msg.post('create_asteroid')
msg.post('create_asteroid')
end
end
function on_message(self, message_id, message, sender)
if message_id == hash('create_asteroid') then
factory.create(('#asteroid_factory', go.get_position(sender))
end
end
or that:
function on_input(self, action_id, action)
if action_id == 'start' then
msg.post('create_asteroid')
end
end
function on_message(self, message_id, message, sender)
if message_id == hash('create_asteroid') then
factory.create(('#asteroid_factory', go.get_position(sender))
factory.create(('#asteroid_factory', go.get_position(sender))
end
endFor the collection proxies, did you make sure your collections have different names? Click on the base of your collections in the Outline panel and check their name properties. You can’t have two loaded at once with the same name.
It is generally better to send fewer messages, for performance reasons. However, unless you’re sending lots of them every frame, it won’t be a problem, so it’s better to focus on organizing your code clearly. In this case it could be confusing if sending a “create_asteroid” message creates two asteroids instead of one.
1 Like
@ross.grams Awesome. I didn’t thought that the id of collections would make it clash. Now it works fine.
OK, I see your point. I’ll replace the message with a create_two_asteroids instead.
Thank you very much for the help.
1 Like
You could also do:
msg.post('create_asteroid', {count = 2})
and
if message_id == hash('create_asteroid') then
for i = 1, message.count do
factory.create(('#asteroid_factory', go.get_position(sender))
end
end
This would allow you to create an arbitrary number of asteroids with a similar call in the future.
3 Likes
@Klear Yes, very good idea. For this simple game where only one or two game objects need to be created, it may be overkill but the concept is brilliant. Thank you.
I struggled to make a script from a loaded collection proxy send a message to the bootstrap proxies manager game object then I realised I checked action_id == 'start' instead of action_id = hash('start'). 
Those hash systems are beyond my comprehension. I don’t understand their purpose.
I also struggled to animate the alpha value of a sprite (I did it in a former project but I wasn’t able to find the information again).
I finally found the information in this thread. I don’t understand why that tint property isn’t listed in the sprite API.
Anyway, my title screen is almost finished. I update the itch page. If you have ideas about improving its layout or design, feel free to tell me. I’ll consider if I have the skills/time to change it.
Now, I have to take care of those asteroids…
Just want to fill in on the topics above:
Hashes are used instead of string because strings are really bad when it comes to comparison and lookup (this is a general thing for all languages. Avoid strings as much as possible). It’s all about performance really. If you want to improve performance even more it’s a good practise to store hashes in a local variable and use the variable in the comparison condition instead.
I guess the reason why “tint” is not in the sprite API would probably be because it is a part of the shader. As you can create your own shaders and use/name the properties differently it isn’t really a constant thing and shouldn’t be a part of that API.
2 Likes
@andreas.strangequest Thank you. Now I understand the reason behind hashes. They still are a mystery though. I don’t really get what they actually are.
For the tint property, I understood what you wrote but then it leads to other questions. How a shader property is accessible from a sprite component? And wouldn’t it be useful to add an API section for that default shader for everyone to better use it? Basically, a sprite doesn’t have an alpha value. Wouldn’t it be simpler to give it that kind of property? I mean, ok Defold is highly customizable for the experts but not everyone is a master of shaders or rendering. No wonder there is not that many people using Defold. It scares the hell out of beginners. Standard configuration files is a step toward helping beginners learning Defold in a safe environment but there should have full documentation of properties they can access.
My advice is that you don’t worry about the hash thing. It’s really not important to know how the code works (… but it is useful to learn about the engine, platform, etc).
@flashjaysan
Sprites do have transparency. try go.set("#sprite", “tint.w”, 0) to make a sprite transparent. And by the way, this is actually included as one of the examples in the documentation. Look here: sprite section of defold manual .
The fact is that game development is complicated. There is a lot to learn. But what you mentioned (standard configuration files + full documentation) is exactly what defold has. Check the manual I have linked above to see what you can do with sprites (…really. you’re going to need to get use to reading the documentation. sprite transparency is the second example on that page).
I have made a couple of games with defold without ever worrying about shaders or what a hash is. Although i would admit that creating exciting graphics is a weakness of mine. But what I mean is that all that stuff can come later.
3 Likes
@88.josh i don’t know where to start…
- Maybe you’re a professional programmer but I am not. I’m creating games for fun. I’m no expert.
- I’d really like to not worry about hash things but they are all over the place in Defold. I never know when I can use a simple string and where I absolutely must use a hash. So, no, it’s impossible to skip hashes learning.
- When I’m looking for specific information, I first look toward the documentation so, “really, I’m already used to take a look at it.” However, I expect to find a list of functions and properties at the top of a specific entry (which is exactly how Defold documentation is laid out). Also, I skim through documentation to find information. I don’t read entries in full when I look for a specific information. Don’t tell me that you have ever read the full documentation of anything you use and that you remember everything. Of course reading in details documentation is much better than skiming through it but when you search specific information, you have to make some assumptions to be effective. I thought: “Maybe, the alpha value property is located in the Sprite API.” Looking at the methods and properties didnn’t help in that case. Finally you imply that I should read examples over descriptions and explanations? This is not logical at all. I want to understand my craft. Not find premade scripts to use instead of understanding the inner workings. So, no, that
tintproperty should be more visible than being in an example entry lost in the descriptions.
I’m not angry at you or anything but I don’t agree with those points.
However, you’re right about the complexity of game development. I’m often frustrated and it may alter my ability to look in depth to documentation entries. Doing it all alone is not simple and the forum is a major help in addition to the documentation.
Also, thank you for the link to the example. At least, I’ll better remember where it’s located from now on.
Learning a game engine in the context of a game jam may be a good thing for experienced programmer but I think it was beyond my level and was in fact a bad decision. I think my current level is at knowing how to use constructs of a language but I’m not able to pass the next step: knowing how to use a library to construct full things. That’s another skill all together and I’ve been stucked at it from 15 years.
I’m an amateur programmer, just like you, but with 2 years experience now. For reference, I made do not open this suitcase and bikiniverse (both without ever understanding what a hash is!!).
Whilst I have been working with defold for longer than you, I am pretty sure our level of knowledge is similar (If you play bikiniverse, you will see how simple it is. dnots is more complicated, but not from a coding point of view).
here’s a quick lesson on hashes:
´true´ and ´false´ are booleans
1 is a number
hash('start') is a hash
"start" is a string (and it’s different from a hash)
{ "yes", true, 1 } is a table with three entries: a string, a boolean, and a number.
For reasons that are a little complicated, computers prefer hashes to strings. But there’s a lot of other stuff to learn before that difference actually matters. The main thing is this:
-
hash('start')is not the same as"start" - the defold engine uses hashes for messaging and input, for that reason, so must you.
1 Like
The third entry in the Sprite API documentation page which I already linked to tells you how to set a sprite constant in about 150 words, and gives you an example of tinting a sprite red. And when I say an example, i mean three lines of code, not a “premade script” as you said.
it would be really useful if the same entry mentioned how to make a sprite transparent, because I think that’s much more common than wanting to make a sprite red. But learning to use the API documentation (not just the manual!) is going to become a really important skill as you go on.
edit: I agree that the manual (not just the API doc) should mention tint and briefly give an example of how to make a sprite transparent/not transparent using go.set("#sprite", “tint.w”, 0) as that is something pretty important in many very basic games.
1 Like
You’re absolutely right in all that last message. I’m also guilty in not putting enough effort to decypher the API documentation. This strengthen my point about making a game when we don’t know enough of a game engine.
OK. I got collection proxies swap working. I got asteroids spawning. I got score. And I got many bugs ! 
My project is a mess and I feel like browsing in a wasteland of files. However, the game starts to feel funny if not fun. I’d really have liked to have someone to help me organise my project.
1 Like
Yes, project organisation can be a pain in the ass on your first project. But congratulations for finishing your first game! It’s looking good.
1 Like