Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Max

Pages: 1 2 [3] 4 5 ... 16
Development / Object you can throw over and over
« on: March 15, 2019, 04:41:51 pm »
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]
local entity = ...
local game = entity:get_game()
local map = entity:get_map()

function entity:on_created()
  entity:set_traversable_by("enemy", true)
  if entity:get_property("weight") then

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
    enemies_touched[enemy] = enemy
    sol.timer.start(map, 1000, function() enemies_touched[enemy] = false end)

function entity:on_lifting(carrier, carried_object)
  if entity:get_property("damage") then

  --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
      width = width, height = height, x = x, y = y, layer = layer,
      direction = direction, model = "toss_ball", sprite = sprite:get_animation_set()



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.

Your scripts / Re: Simple Leveling up system
« on: March 09, 2019, 06:08:27 am »
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.

Development / Re: stop_dialog
« on: March 08, 2019, 05:34:51 pm »
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.

Bugs & Feature requests / Re: Cut Vines
« on: March 04, 2019, 07:10:59 pm »
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!

Bugs & Feature requests / Re: Cut Vines
« on: March 04, 2019, 06:12:18 am »
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]
[code=lua] your code [/code]
These tags add lines numbers and syntax highlighting for Lua.

Your projects / Re: The legend of Zelda alttp Taizo Demo
« on: March 02, 2019, 12:39:05 am »
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 : )

Your projects / Re: The legend of Zelda alttp Taizo Demo
« on: March 01, 2019, 04:33:48 pm »
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.

Development / Re: help with 1.6
« on: February 06, 2019, 04:09:31 pm »
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.

Your projects / Re: Ocean's Heart
« on: January 31, 2019, 06:56:19 am »
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.

Bugs & Feature requests / Re: Where are my savegames stored?
« on: January 30, 2019, 02:53:00 pm »
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.

Your projects / Re: Ocean's Heart
« on: January 29, 2019, 08:01:10 pm »
Hey, thanks! Just fixed it : )

Development / Re: Dungeon Design as Lesson Planning
« on: January 24, 2019, 03:42:18 am »
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.

Development / Dungeon Design as Lesson Planning
« on: January 23, 2019, 10:07:08 pm »
So, I've been thinking about my philosophy on dungeon design and was curious if anyone else has thoughts on it.

My primary goal is pretty similar to my goal when I've taught classes before. I want the player/student to explore the dungeon/material I've provided, think about the information I've given them, and use that information to solve challenges, thereby internalizing the information. Each challenge is a kind of test.

If you're a good teacher, you don't let the student ignore every assignment and test before the final exam. Then they'd go in and be frustrated if they hadn't learned how to solve the problems the exam was giving them.

Dungeons are similar. If you don't require the player to show they know how to solve small components of a big challenge, then they're likely to fail the large, complex challenge you give them later. I think failing to solve a puzzle or defeat an enemy because you're unaware of how or even that you can perform some kind of action is the most frustrating kind of problem you can experience in a game.

A well-deserved dungeon will have already required the player to prove they know how to solve each piece of a larger challenge before allowing the player to undertake the big challenge.

So what does designing a dungeon like this look like? You can go about it in a ton of different ways, but I'll outline my method. I'd love feedback on how you think I could improve or how you go about it.

First you need several sets of challenges that build on each other, like lessons. Your first challenges are to learn how to manipulate wind and that you can move some hampster wheels or whatever, for example. Your second set of challenges involve how your hampster wheels and wind interact with each other. Without proving that the player knows how to solve the earlier challenges, we risk putting them into the second set of challenges without them realizing they CAN move the hampster wheels. So how will we ensure the first set of lessons in learned before the second set can be taken on? And how can we make this interesting to explore as a dungeon?

What I like is to make x number of viable paths that must all be completed, but can be in whatever order. X=1 quite frequently, especially in earlier dungeons. Each of these paths involves a self contained challenge. Their completion order doesn't matter, because the lessons each of these challenges teach aren't required for the other challenges. Let's call this set "level 1 challenges", since nothing else the this dungeon teaches is required to solve them. (You can make the point that they player will need to understand other lessons- maybe how to use weapons or tools they already have. If this is the case, the player must demonstrate understanding of that in order to even enter this dungeon).

Now higher level sets present challenges that combine the tests presented in earlier sets. A level 2 challenge can assume you know how to solve any of the level 1 challenges, and so on.

The next step is to figure out how to prevent players from moving on to higher level challenges without first passing the tests of the lower level challenges. This is where lock-and-key style design comes in. You put locks of some type between the player and any higher level challenges than they've already completed. (As an aside, it is much more satisfying to find a lock, then find a key and excitedly travel back to it, than to find a key, continue wandering, then stumble across the lock. Try to place most locks along the player's path to the keys.)

This might look like a player getting a key from a challenge that requires them to move a log out of the way to get to a chest. They use this key before they can get to a challenge that requires them to know they can move logs to solve another challenge.

This type of design is also evident in dungeons where some areas are gated off by requiring a special item or tool. The player needs to prove they know some usage of a tool before they can be tested on that usage in combination with another mechanic.

So I try to arrange the first set of level 1 challenges in an interesting area. Completion of all of these challenges somehow unlocks the next set. This next set can be nearby to each other, or can be accessed from various places branching off the level 1 area. This is one place dungeon difficulty can be modulated. The further the distance between each component in a set, the more difficult it will be for a player to complete them all to move onto the next set. You can think of this as the axiom: the further the lock is from the key, the more difficult the navigational challenge will be. It's a very nerdy game design rhyme.

So we'll have several sets of paths. I try to arrange these sets of paths so that you can't go more than 1 room or so down a path you can't yet complete. The more difficult you want the dungeon to be, the more paths you leave open to allow the player to start down.

Perhaps in an early dungeon you have 2 paths the player can start down but won't open until later in their progression. In a later dungeon, there might be six paths they can start down, 2 of which will open from keys they find after completing level 1 challenges, 1 of which opens after a level 2 challenge is completed, which will provide the dungeon item and allows the remaining 3 paths to open.

The important part is that although satisfying navigational challenges can be presented to the player via many different closed paths they can start down, don't let the player go very far. Going through five rooms along a path before you find you need a key from elsewhere is not fun. Investigating five rooms, each the start of a path you can't yet take, is fun because it teases the player with paths they'll be able to fully take later, and adds satisfying challenge in remembering which path will open now that you've found a key of one sort or another.

The easiest dungeon only shows you the path you can take. A more satisfying but still easy dungeon shows you two-three paths, but only one is viable once you start down it.

Next I'll roughly figure out what I want as far as how these paths cross over each other, what I want to be loops, try to draw lines so the player isn't immediately dumped at step 2 once step 1 is completed, but there still isn't too much backtracking. One-way loops are very useful for this. It's not what I mean to focus on here, but self-contained paths shouldn't be linear- obviously the player will, upon completing the path, have to take it again backwards.

A perfect unidirectional loop is better, because the player completes a single path, and finds themselves immediately back where they started, ready to navigate to the next challenge.

A path that rewards the player with some type of key can loop the player back near to where this key's lock is located (as ideally, the player would find the lock first). However, if you loop the player back right to the lock's location, you remove all challenge the player might have of remembering and navigating to the lock- at this point it might as well be a linear path. This is another place you can modulate difficulty as a designer. The further away you give the player the key from the lock, the more difficult the navigational challenge. So you may want to loop the player back fairly close to a lock in an earlier dungeon, but in a later dungeon, design the loop so it deposits the player in an area of the dungeon that, while familiar, is far from the lock.

So at this point, you've got several sets of challenges, where each set teaches you the lessons you'll need to complete later sets. So you can safely know your player won't be frustrated by a challenge they don't have the tools to solve. My idea of how difficult I want the dungeon's navigation to be will determine how far geographically I want each challenge to be from the other challenges in the same set. That also determines how far I want the player to travel to get to the next set of challenges after they complete a set.

Now I start to roughly sketch out the geographic relation of all my paths and challenges.

One common design pattern is to have one, or several, hubs. Each hub doesn't have to be a single room, it could be a series of rooms. But each challenge or path in a set will be a spoke from this hub, and once the set has been cleared (this may be a good time to remind us that sets of 1 are common and fine), the next set will become accessible from the hub.

I personally find that, especially in later dungeons, three or four hubs work well. The first set of challenges are around hub 1 and unlock hub 2. The second set of challenges are around hub 2, and unlock a smaller hub 3. The third set of challenges are around hubs 1-3, forcing the player to remember previously inaccessible paths and return to them.

I have a few other stray thoughts on dungeon design.

First, I think it's very good design to make areas the player has to backtrack far to have a memorable landmark. If the player needs to backtrack across most of the dungeon to get to a puzzle they can finally solve with a new item or something, this location should be memorable. A unique graphic, room shape, enemy, or arrangement of elements in the room will help. This is why Zelda's boss doors usually have special graphics.

Rhythm is also important. Every room in a dungeon doesn't need to be an intense fight, or though puzzle. Having rooms where all you require of the player is to walk through is fine, and allows the player to take a mental break. Particularly for hub rooms, or other rooms the player will need to travel repeatedly, you shouldn't require the player to re-engage with a challenge. Challenges should only need to be solved once.

The difficulty of a dungeon doesn't need to constantly escalate. While the general difficulty curve should rise, having breaks between challenges is important, and those can be easier challenges. Besides challenging the player, you could also be making them feel powerful or clever.

Main paths should usually be at least 2 tiles, unless you have some reason for making them narrow. If you're often requiring the player to go through narrow paths to navigate, this will cause the player to frequently question if they're on the path the designer wants them to be. If you want them to take this path, why did you make it so narrow? This is mainly important in overworld design, but narrow paths in dungeons only make sense in caves or if the player feels they're exploring into an area the fictional in-world people who built the dungeon didn't want you to visit.

Is there any way I can share my whole data folder?
You could use something like gitlab or GitHub, they're designed for sharing exactly that kind of thing.

I don't know what might be causing that error- but maybe think about that you recently did before you got it.

The other day, for example, I was trying to call "hero:start_attack()", before the hero had the attack ability. The error I got was "Error: Cannot find sound file 'sounds/.ogg'

So it might be like, your code is looking for
"sprites/"..[a variable]
  but the variable is nil or equal to "", so it's trying to just use "sprites/" as a sprite, when in fact it's a directory.

Actually, thinking about those 2 errors, I think this explanation is pretty likely. Without seeing your code I couldn't tell you where, but probably somewhere in main, game_manager, or somewhere like that if it's being called as soon as the Solarus logo menu finishes.

Pages: 1 2 [3] 4 5 ... 16