Messages - Max

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.

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.

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.

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.

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.

[code=Lua]Paste your code here[\code](Except use a forward slash, not a backslash!)It'll make it much easier to read for us : )

If you haven't changed anything in the game manager yourself on purpose, you should be able to copy the scripts from the 1.6 new quest into your current project. Or copy your current project's files into a new quest.

It looks like the problem is your main is calling game_manager:start_game(), which is not a function that the game manager you posted has. It looks like you might want to instead call game_manager:create("put the file name here")

local game = game_manager:create"save1.dat" sol.main:start_savegame(game)It sends a string, "save1.dat" to the game manager script to make a new game, or load one if it already exists, which the game_manager sends back as "game". Then we start that game with Sol.main.start_savegame

Yeah, when you apply a movement to an NPC, the engine knows you probably want the NPC to be walking, so it sets the walking animation, then automatically calls the stopped animation when the movement is finished.

I made this weapon last night, and thought you guys might want to put one together too. Basically, it's an item that when you use it, it creates a custom entity that can damage enemies, then creates a circular movement to swing it around your hero. I looked at how Christopho made arrows as a custom entity in his games to learn how to do this. I've started using this custom entity for a few new weapons I made because it's very versatile to have an entity that is basically just a weapon you can move.

For this recipe, you'll also need a hero animation called "charging", which is just the wind up before the hero swings the weapon. A useful animation to have for many weapons. Then it also uses the "hookshot" animation, which at least used to be required by the engine, for once you've swung the flail. You can change these to any animations you want, obviously.

-- Event called when the game is initialized.function item:on_started() item:set_savegame_variable("possession_ball_and_chain") item:set_assignable(true)end

-- Event called when the hero is using this item.function item:on_using() local map = item:get_map() local hero = map:get_hero() local hero_dir = hero:get_direction() hero:freeze() local x, y, layer = hero:get_position()

local MIN_RADIUS = 2 --leave this one local RADIUS = 64 --you can adjust this one to make the flail swing wider or narrower

--START CHARGING (because this is too powerful to not charge) hero:set_animation("charging") sol.timer.start(game, 500, function() --AND GO! ATTACK! --Start the movements and change the hero's animation hero:set_animation("hookshot") sol.audio.play_sound("boomerang") m:start(spike_ball, function() spike_ball:remove() end) m:set_radius(RADIUS) --you have to set the radius after the movement is started, or else the flair will start fully extended, --and we want a growing and shrinking circle end)

--end the movement if it doesn't collide with something function m:on_finished() hero:unfreeze() spike_ball:remove() item:set_finished() end

local game_manager = require("scripts/game_manager")Which means, now, in the main.lua script, whenever "game_manager" is written, it's referring to whatever the "scripts/game_manager" returns. Probably there ought to be a "start_game" function in your game manager, which would create or load a game.

What are you trying to run? A game you made yourself? Someone else's game? The default quest that is created when you go to file>new quest?

I tried it, and unfortunately, although you can resize stairs to whatever size you want, they only activate when the hero is exactly lined up with the position of the 16x16 entity. The rest of the large stairs entity just operates as an invisible wall.

Thanks guys. I followed Christopho's tutorials, and now I've got it so I only need five tiles which I can copy from my debug map each time and the event is handled with metatables, which isn't too bad. However it still feels a little hacked together, since a function as basic as changing layers needs such a complex solution when I could just use stairs before, haha.

But I never liked how the automatic stairs took control away from the player so that's nice that it addresses that too! Now to just do this for dozens of stairs in my game, hahaha........