Messages

Excellent. Here's the other one, still have to do the starting island but I updated the link in the first post to the current build of the game, so if you run that one, a map should pop up when you press M.

Here's the first map I've gotten done- any feedback on it? I'm going for something that will give you a general direction without telling you exactly how to get there.

So, what exactly does this do? I looked it over, and I thiiink it will just one-by-one basically do game:start_dialog() for every dialog in your game so you can check them? That's cool. How would you go about calling this, just have an NPC that you delete later whose script requires this debug script and calls game_meta:start_dialogs_debug()?

Haha, I'm glad your cats are fine. People being lost has been my biggest worry, I think it's much harder than I thought to build a well-designed overworld that is easy to understand but still fun to explore. It's especially difficult since, as the designer, you can't help but know where things are. I try to forget but I have the maps in my brain : /

I'm starting work on making it so pressing M opens a map of the island you're currently on. It's going well, I've just got to actually make the maps, which which llamazing's amazing mapping script will help with a ton!

I'm also thinking about putting telephones around the world where you can call your sister, who will provide hints. It'll take a bit longer to implement that one though, and I'm not 100% sure what more that would do than the quest log. Perhaps since she'd be able to go into more detail than the quest log can, it might be more of a "cheating" thing, where she'd tell you exactly where to go. I'll think about it a bit more.

I looked it over, I like your generic projectile enemy, that's a smart way to do projectiles.

I'm looking forward to seeing how you do the throwing animation, I was making an enemy with a melee attack today and was having trouble with the sprite:on_animation_finished() event, so I'm looking for an example of that being used.

Those goblins  look fun to battle! Is their code for public use? I really like how you've got them walking around with their axes before you throw them.

Another way is to attach the timer to another object than the enemy (like the map).

I thought of this too- it will work great for bosses (you know what map they'll be on). I plan to trying this method out a couple times in my game, I was just curious if there was a more obvious way that I was missing.

Thanks for the feedback, guys!

Hello! I don't speak french, so someone else might be able to better communicate nuance in my response, sorry.

Your project is a cool idea, and I hope it goes well! I have a little advice- I have been a part of game design forums for a long time. In general, very few people will want to spend their free time (most of us don't have a lot) on an unproven project. If you work hard on your project yourself for a while, and then present your request for help along with proof-of-concept things like a basic demo, art, screenshots, etc., you are MUCH more likely to get assistance. Additionally, when you show that you're trying to get started yourself, people are often willing to help you out with the smaller problems you will encounter. For example, I wouldn't sign up to an unproven project to be the composer, but if you were trying to write a song and wanted advice or feedback on your work, I'd be happy to provide that!

Based on my personal experience, I would never commit to a project like this that the director hasn't been working on for a least a year. I've seen many, many projects start and become abandoned, I imagine lots of the people who could help you have seen that also. Generally when you ask for help like this, someone who has seen the abandoned projects will give you this advice, but nobody said anything over the past couple days so I thought I'd be that person, haha. So my advice is, get started yourself! Maybe in a year or so, people will want to join your team if nobody does now.

On a related note, I see that you started a project called Explorer: The Atlantis Journey a couple years ago. How is that coming along?

Best of luck with your project : )

So I'm designing basically a Hinox enemy, who will throw bombs at you if you are within range. Everything is going great, and I just have a small problem that I'd like to know if I can fix a different way than I did.

Basically, I use map:create_bomb(), and then create a jump movement and "throw" the bomb toward the player that way. However, if I end up creating a new bomb before the old one explodes, the code "throws" the first bomb again instead of the newly created one, since the newly created bomb isn't called hinox_bomb, it's called hinox_bomb_2 since the first one is still around.

I got around this by just detonating the first bomb if it's still lying around before throwing a second one, which works well. But is there a better way to do this that anyone can think of?



The code for when the enemy throws bombs is this:

Code (lua) Select Expand


function enemy:shoot()
    --first, check if the hero is in the same region
  local map = enemy:get_map()
  local hero = map:get_hero()
  if not enemy:is_in_same_region(hero) then
  return true  -- Repeat the timer.
  end

  local sprite = enemy:get_sprite()
  local x, y, layer = enemy:get_position()
  local direction = sprite:get_direction()

  sprite:set_animation("shooting")
  enemy:stop_movement()

    --destroy an old bomb before creating a new one (mainly so we don't move the old bomb with our movement)
    if map:has_entity("hinox_bomb") == true then
      local bombx, bomby, bombl = map:get_entity("hinox_bomb"):get_position()
      map:create_explosion({x = bombx, y = bomby, layer = bombl, })
      sol.audio.play_sound("explosion")
      map:get_entity("hinox_bomb"):remove()
    end

    --now let's create a new bomb after we give the enemy a second to pull it out of his pocket
  sol.timer.start(enemy, 400, function()
      map:create_bomb({
        name = "hinox_bomb", x = x, y = y, layer = layer,
      })
    --and throw the new bomb toward the player
      local bomb_toss = sol.movement.create("jump")
      local dir_to_hero = self:get_direction8_to(hero)
      bomb_toss:set_direction8(dir_to_hero)
      bomb_toss:set_distance(dist_hero + 16)
      bomb_toss:set_speed(90)
      bomb_toss:start(map:get_entity("hinox_bomb"))
      sol.audio.play_sound("throw")
    sprite:set_animation("walking")

      --now the enemy can go back to what it was doing before it threw the bomb
      self:go_random()
      self:check_hero()

  end)
end



If anyone is interested in the whole code, I can post that for general use also if nobody's already made an enemy like this. It's based on the Solarus Team's scripts, and is actually pretty fun to battle because the best strategy is to pick up its bombs and throw them back. This could also be used for a "King Moblin" type enemy, which has appeared in a few Zelda games.

That makes sense. It seems like it has some limits to its ability though- for example, if the state you've saved is something like "charging", to charge up a big attack, you're potentially be able to keep the boss in its charging state forever if you kept attacking it and therefore restating the timer.

If there's no way to code around that, it's just good to know so I can design around it. For example, it seems like it might be best practice to cause enemies to attack right at the beginning of on_restarted() (if the hero is within range), rather than after a delay, and if you want the delay, have it be called after the attack instead of before.

I wanted to say this is really cool! I might look into using something like this for my next game. I'm most impressed with how readable it is, considering everything that is impassible is brown, be it cliff, house, tree, rock, fence, whatever, it's still easy to look at just the shapes and be like, oh, there's a town there.

It's interesting how it looks like stairs and teleporters and prickles (etc?) are their own colors too. That's cool that you've designed it to go into such detail, yet wisely omitted things like NPCs. I wonder if it would be configured to show particular NPCs- a person who's the object of your quest, for example, or if particular teleporters could be color coded differently to indicate they're the dungeon you're looking for.

I wouldn't personally want that because I like games about exploring, but it'd be an interesting take if you were interested in further developing this idea.

Small critique- I wouldn't go with purple for stairs, I'd go with white or something that looked more natural with the blue, green, and brown that dominate the colors.

Hey, question. So timers associated with an enemy are destroyed when enemy:on_restarted() is called. However, enemy:on_restarted is called when the enemy is damaged, right? Therefore, it seems impossible to create a timer that sends an enemy through phases without you interrupting the phases whenever you hit the enemy.

For example, how would we have an enemy that becomes invulnerable after 10 seconds? You'd need to start that timer in enemy:on_restarted(), but that timer would be destroyed and restarted every time you damage the enemy.

Has anyone done anything like this in designing enemies?

As for the tiles, you should be able to see in the corners on the mountains how the corners don't really round off nicely.

So, to be honest, I can't really tell what doesn't round off nicely and what's the way Link to the Past's cliffs look. They've always confused me- looked great in that game but are really hard to use. So are you taking about the top edges of the cliffs, because it seems like that's where  you've hidden corners with rocks? I tried taking out the rocks and it looked fine to me, there were a couple places that seemed slightly jaggy that I made some edits to fix, but I'm not sure if I can see what's bothering you.

Thanks llamazing! I took care of all of the typos and mistakes, so now I'll just have to figure that pause menu thing out.

I did some testing. One- you can force the hero to throw the object if you swing your sword, which fixes the problem too and your action button is re-enabled. Two, I think I've traced the problem to game:set_paused(false)

I think the issue is here because if I take the "continue, save, pause" dialog out of the pause menu so it's just D to pause and D to unpause and it shows the quest log, there's no problems, you can still throw the object. Also, I can force the player into a dialog with choices while carrying an object, and there's no problem, you can throw it afterwards without issue. So if the problem isn't with the dialog box, and the problem isn't with displaying the images on my menu, literally the only other thing my script does is call game:set_paused(false)

Is there any chance that the game:set_paused() method automatically returns the hero to a like "idle" state instead of whatever state they were in when they paused (ie, the "carrying" state)? Has anyone else seen this problem using game:set_paused(false)? This is basically the way Christopho's tutorials explain to make a save option on the pause screen.


Here's my pause menu script:

Code (lua) Select Expand


function game:on_paused()

  require("scripts/menus/pause_infra")
  pause_infra:update_game(game)
  sol.menu.start(game, pause_infra)

  --save dialog
  game:start_dialog("_game.pause", function(answer)

    if answer == 1 then
      game:set_paused(false)
    elseif answer == 2 then
      game:save()
      sol.audio.play_sound("elixer_upgrade")
      game:set_paused(false)
    elseif answer == 3 then
      sol.main.exit()
    end

  end)

end





Oh, and one last thing! Thanks for playing! Are you having fun with the game?

I checked, and when you click on an image on imgur, it comes up with like the zoomed-in screen, and there's a bunch of linking options on the right side. One is BBC code which works for me. I attached an image example code, because you can't type it out, because it will just try to make an image from it.


And yeah, you're spot on with the observation about the shallow water corners. It's totally just two sides overlapping, I didn't bother putting in the inside corner tile because I was trying to save a bit of time, I couldn't tell myself, but if someone else has noticed, I better do it properly, haha. You're also right in that I never made outside corners.

The plants being impassible isn't an error, just a choice I made early on and never thought about. I might go ahead and change them to passable now that you mention it.