Messages

2. Make a your own quest that's simple and doesn't require much scripting

I can't agree with this enough! Some solarus devs were talking about where to start a while ago, and I think we all agreed that making a couple maps without any scripting to familiarize yourself with the editor's interface and map entities is the best place to start. I'd recommend making something like a town first. Then maybe a dungeon that doesn't have a dungeon item. I think it's a really good idea to do these before you start trying to make your game, or implement any quests.

The one place I disagree with llamazing is that I think the biggest limitation is each developer's commitment to learning. Solarus is a great engine, both powerful and easy to use, but it does take time to learn lua and the solarus API. I think a big obstacle is people jumping in, trying to make their dream game, and getting bored and discouraged. You might not be creating complex branching quests with unique mechanics in just a couple months. But if you persist, you totally can do that with solarus!

Also, let someone know if you can't find the link to the discord server, I think between all the solarus devs, one of us is on there at just about any hour of the day, haha : )

You're not wasting anybody's time : )

So you just want to show two consecutive dialogs? Why not just show the second one in the first one's callback?

Hey, so I coded this custom entity that's a lot like the iron ball from A Link to the Past's Eagle Tower- it's an object the hero can pick up and throw, and then pick up again and keep on throwing. You can even carry it to other maps and keep smashing it into enemies faces. I can it "toss_ball", haha.

You can set the properties "weight" and "damage" on the custom entity, which by default are 1 and 6. When this entity hits an enemy, it'll try to call enemy:hit_by_toss_ball() , so if you want certain enemies to exhibit different behavior on being hit by this than being damaged, define that function for those enemies (if, for example, you wanted an enemy to have its shield destroyed, or become vulnerable when hit with this or something.). Note: hit_by_toss_ball() will be called whether the hero throws the ball into the enemy, but also if the enemies runs into the entity while it's on the ground.

Code Select Expand


local entity = ...
local game = entity:get_game()
local map = entity:get_map()
local DEFAULT_DAMAGE = 6


function entity:on_created()
  entity:set_traversable_by(false)
  entity:set_drawn_in_y_order(true)
  entity:set_follow_streams(true)
  entity:set_traversable_by("enemy", true)
  entity:set_weight(1)
  if entity:get_property("weight") then
    entity:set_weight(entity:get_property("weight"))
  end
end

local enemies_touched = {}
entity:add_collision_test("sprite", function(entity, other)
  if other:get_type() == "enemy" then
    local enemy = other
    if not enemies_touched[enemy] and enemy:hit_by_toss_ball() then
      enemy:hit_by_toss_ball()
    end
    enemies_touched[enemy] = enemy
    sol.timer.start(map, 1000, function() enemies_touched[enemy] = false end)
  end
end)

function entity:on_lifting(carrier, carried_object)
  carried_object:set_damage_on_enemies(game:get_value(DEFAULT_DAMAGE)
  if entity:get_property("damage") then
    entity:set_weight(entity:get_property("damage"))
  end
  carried_object:set_destruction_sound("running_obstacle")

  --landing, and therefore needing to create a new toss_ball
  function carried_object:on_breaking()
    local x, y, layer = carried_object:get_position()
    local width, height = carried_object:get_size()
    local sprite = carried_object:get_sprite()
    local direction = sprite:get_direction()

    if carried_object:get_ground_below() == "wall" then y = y + 34 end
    carried_object:get_map():create_custom_entity({
      width = width, height = height, x = x, y = y, layer = layer,
      direction = direction, model = "toss_ball", sprite = sprite:get_animation_set()
    })


  end

end



If you see any errors or mistakes I've made, please let me know so I can fix them! Have fun using this, modifying it, whatever you want.

Lua is all cool with decimals, but I believe game:set_value() will round to the nearest integer, as will most engine functions like set_life.

I'm vaguely familiar with the dialog box script, I thought that maybe this was a variable you set in the script? Like how you set "top/bottom/auto" for positioning.

Yeah, of course! : )

Lots of that kind of different perspectives and ideas just comes from familiarity with the toolset of the API, it'll come in time!

Hey, gman. From a cursory glance, it looks like vine:overlaps is a function you're trying to call, but it isn't defined anywhere?

Either way, this is kind of an odd way of going about what you're aiming to do, I think, or maybe I just don't understand it.

How I might handle vines I want cut with the sword is to make them an enemy that isn't traversable and doesn't damage the hero, with a life of 1. Or you could make a destructible that can be cut, but can't be lifted. Is there any reason you want to make these a custom entity?

If so, I think there's a better way of writing the collision test. The sprite collision test has a callback function where you can check what the colliding sprite is, see if it's the sword.

Finally, use

Code Select Expand


[code=lua] your code
[/code]
These tags add lines numbers and syntax highlighting for Lua.

Yeah, there's one here:

http://forum.solarus-games.org/index.php/topic,1229.0.html

Ah, I misunderstood "hard version of ALTTP". Good choice, I think, and a great way to learn. If you didn't already hear, there's a discord many people are active on if you can't find any answers in the forums : )

Nice, looks like a great start! You've already got a lot of things working, looks like you're coming along!

A little feedback I have is that a remake of the entirety of ALTTP is quite a lot for a first project. Smaller projects, in my experience, are more likely to get finished.

Look like you've got a function called start in your HUD script. The first argument is a table, when it needs to be one of the listed things. this shouldn't be breaking anything, but if you want more help maybe post your HUD script? Or at least the start function.

There is a quest elsewhere that will tell you where the keyhole is. If you've finished it, it will tell you where the keyhole is to make that statue go away. Message me for more details if you want.

I'm also only 90% sure the next area was even done last time I put any demo out, hahah.

Yeah. When you open up the command prompt, it will likely already be in your home directory (for example since my user's name is Max, it's C:\Users\Max for me), but if not, you can navigate there by typing "cd C:\Users\Max" or if you name isn't Max, whatever your home directory is. Cd stands for change directory.

Once you're there type "mkdir .solarus" as Alex says. Mkdir stands for make directory.

Just though I'd add in some more details as a windows user.
Let us know if that works out.

Hey, thanks! Just fixed it : )

Yeah, those are really good points! Trapping the player in a room is honestly great. The player is absolutely forced to demonstrate their understanding of a mechanic to progress. While it can be overused, I think it should be required for situations where the player needs to know "oh, I can DO that?"



Visual cues are definitely worth going into. Light and Shadow is a good one for all visual mediums. What you mention with tapering the room is also really good, and one way to use visual hierarchy to direct the player.

Many of the techniques architects use to direct people's attention and guide their circulation through a space are perfectly applicable for level design too. You are doing the job of an architect, just for a virtual space instead of a physical one.

A taper or triangle naturally draws attention to its corners. A circle naturally draws attention to its center. People's eyes will follow straight lines from end to end. Eyes are attracted to detail, and will pay more attention to busier or more sense areas. Symmetry always catches our eye. We also are hyper aware of patterns, and will even try to make them where there aren't any. All of this should be leveraged to either direct the player toward something you want them to see, or used to distract the player from something you don't want them to immediately notice.



Another thing I didn't mention is that not only should paths be at least 2-3 tiles wide, they shouldn't be too wide either. Then it doesn't feel directed. All of that falls under the principal of scaling your space to the size of the thing moving through it. When people need to decorate a large room, they'll usually section it off into smaller areas by arranging their furniture into partitions, so that each little "room" in the room is scaled to human size.

But all of that falls more into a different topic than designing dungeons' challenges as lesson plans.