Menu

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.

Show posts Menu

Messages - Diarandor

#991
Development / Re: Creating a custom jump
August 04, 2015, 03:53:17 PM
How do you stop the movement while keeping the jumping state?

I have tried with hero:stop_movement(), but the hero stays frozen. If I add hero:unfreeze(), I recover the control of the hero, but this also seems to stop the jumping state... :o Am I doing something wrong? The code I am using is:

function item:on_using()
  local hero = self:get_map():get_entity("hero")
  local direction4 = hero:get_direction()
  hero:start_jumping(direction4 * 2, 32, false)
  hero:stop_movement()
  --hero:unfreeze()
  hero:set_animation("black")
  --self:set_finished()
end


EDIT: I forgot to add the methods, hero:get_solid_ground_position() and hero:reset_solid_ground().
#992
Development / Re: Creating a custom jump
August 04, 2015, 03:34:23 PM
I have tested my solution and works fine (the only problem is to choose the duration of the jump).

Anyway, your solution seems better, so I will change my script again. Thanks!
#993
Development / Creating a custom jump
August 04, 2015, 02:22:07 PM
Greetings! I always wanted to script a jump like in Zelda games (the one given by the engine is too limited), where you can control the hero during the jump. I had an idea of how we could program this (although there may be other better ways).

The idea is, when using the item to jump, we first create a custom entity with transparent sprite and solid ground that follows the hero under him, and we start the jumping animation on the hero. (The custom entity would allow to move over holes, water and lava while we are jumping, because it has solid ground. It should have smaller size than the hero to avoid traversing walls.) When the jump animation finishes, we destroy the custom entity. It would be necessary to use the save solid ground function before the jump, just in case the hero ends in bad ground, and reset the solid ground function when the jump ends.

One of the advantages (or disadvantages) of doing it this way is that it allows the hero to jump over lower layers (in case that the current layer ends) without falling to the lower ones until the end of the jump. In other words, this would allow to jump between solid grounds on the same layer that have "empty" grounds (not holes!) between them without falling to lower layers. (I was planning to use this to make puzzles where you move boxes of the low layer to make a way on the middle layer where you can jump over the boxes without falling to the lower layer.)

I have not programmed this yet (someday I wil try it) so I am not sure if this will work as I expect. Anyway, I have hope in this trick to program the jump, so I wanted to share the idea.
#994
Are you using your own sprites for the hero? If that's the case, changing the origin of the sprite animations of the hero may solve this.
#995
I made a very silly video to show the carrying system of custom entities that I have scripted and show a bit of what will be the game. (It's just a bunch of test maps, with no dungeon or puzzle.) I think this game will take me at least 5 years of work (I am replacing all the ALTTP resources by others made by me, and that is too much work for one person), so be patient.

You can watch it here:
https://www.youtube.com/watch?v=iY-yckilRrg

PS: sorry for my English if it is terrible and if the quality of the video is not too high.
#996
If you mean that changing the hero should cost something that can run out, that would be a pain, and probably unnecesary...

Anyway, you have given me an idea about changing, not exactly the hero, but in chains of changing (trading) objects in the game (which is typical from Zelda games). I could make some areas accessible for some heroes so that it will make necessary to interchange objects from one hero to another (this will be done using the menu), since the hero that obtains the item in the trade cannot access the area for the new trade.

EDIT: I think I understand now what you meant. (Something like in Zelda Navis Quest with the tradings, I suppose.) But that is more an annoyance than a puzzle...
#997
Greetings! I'm working on a solarus game where you can control 3 heroes that have different abilities and weapons, and switch between them using the menu (or pressing space bar if they are in the same map). I have not worked much on the plot, but I will explain now a bit about the gameplay.

The main heroes will be:

-An archer, the only one who can jump over holes (and water and lava), and has a bow with wooden arrows, a crossbow with metal quarrels, a shovel (that can be used to obtain metal quarrels from the ground and the usual uses), a sickle that can be used to obtain wooden arrows from certain plants (which unlike the sword, cannot cut solid plants), running boots (that can be used with the ability of jumping), etc.
-A swordsman, the only one who can swim on water, and uses short range weapons like a sword, spear, shield, a magneto (that can be used to deflect the metal quarrels a certain angle, and other uses), etc.
-A mysterious wizard (with short range spells) who has lost his memory, that can throw fire (to burn plants, or to combine it with the arrows of the archer to produce fire arrows), throw electricity (which paralizes enemies, turns on machines, hurts water-type enemies, and also can be combined with metal quarrels to electrify them), swimming in lava, mind reading of npcs (and even the other heroes), teleporting all heroes to the entrance of the dungeon or certain place of the map, etc.

I have also finished the scripts to change control between heroes, but it remains to make the menu to change between them from different maps. In maps where one of the main heroes is left, the position and state of everything must be saved to avoid solid entities to reappear overlapping some hero (this is necessary, but easier than it seems).

Also, I made a script to carry custom entities (although I still have to solve some problems and improve it). These portable entities can be thrown from one hero to another (useful if there is a hole or thin wall between heroes, or if they are moving in platforms, etc). Keys will be custom entities that will be carried, which is something unusual, and will allow to make enemies that steal the key, or annoy in other different ways (like changing the color of the key, but I don't want to give more spoilers). A key will open only a door of its color. There could also be magnetic keys (to use the magneto with them), and other types. Some portable items can be used to push buttons, and they are always moved by platforms.

The symbol of the game will be a clover (instead of the triforce), there will be secret clovers in the island that can be collected for something good to happen (like the secret seashells in Link's awakening), and a dark/light magic clovers which will be part of the main plot.

There are huge possibilities for the puzzles in a game like this. But the hardest part will be to design the island (not the dungeons), since sometimes the heroes will need to take different paths to arrive to the same place, and other times you can cross some road if you take two or all the heroes at the same time in that way (cooperation between them is needed). There will be parts of the game when you don't have the three heroes (at the begining you only have one of them). Etc.

This are the main ideas for my game. This is maybe too ambitious, but it is possible, and the hardest part of the scripting is almost done, although it still remains to make most of the graphics and start making all the maps and dungeons. I would be grateful if someone wants to cooperate with this project or contribute with some more ideas.
#998
Development / Re: Trouble making a bridge.
July 30, 2015, 09:40:32 PM
There is something you must know (but I don't know if you know it, since it has not been explained here with all details yet). If the hero walks over an intermediate layer (or high) and the tile ends, he "falls" to the low layer immediately. (Maybe you already knew it.) I suppose that the purpose of the transparent tile is to keep the hero on the intermediate layer after his position is changed by the sensor on low (so the transparent layer starts above the sensor on low, covering it, and connects with the other intermediate layer tiles).

(I was thinking that the sensor above, which changes hero's position to the lower one, is not necessary at all, since the hero "falls" automatically in the border of the transparent tile.)
#999
Development / Re: Trouble making a bridge.
July 30, 2015, 11:17:20 AM
Hi! I was thinking that the bridge would not work correctly with enemies and thrown entities (like arrows). But if we use a custom entity with a collision test instead of the sensor, that could be done. (Anyway, this matter is not really important, since most of the players would not realize of the problem.)

EDIT: if the hero has a companion that follows him, it could be necessary to use the custom entity collision and not the sensor.
#1000
Development / Re: Assigning Hotkeys to Items
July 30, 2015, 05:41:26 AM
Yes, the script is loaded and executed. But as far as I know, you are not getting a solarus item entity that the engine can handle. That is why the function item:get_game() is not defined for your item variable (which is actually nil), and that produces the error in line 2.
#1001
Development / Re: Assigning Hotkeys to Items
July 30, 2015, 04:28:59 AM
I think you cannot get an item directly from its script, only the engine can do that, so probably this has no sense. Maybe, try using game:get_item(item_name).
#1002
If I am not wrong, it should be possible and not too hard (although I haven't tried that yet). I would use the event game:on_command_pressed (or game:on_key_pressed) to activate the item. You need to check that the item is assigned to the command (or key) you have pressed, and also if the hero is swimming (use something like "if hero:get_state() == "swimming" then ..."). Maybe you need to do something more, but you should be able to handle this (with a lot of work).

You should start by studying the scripts related to the hud (of Solarus dx for instance), which is used to display the selected items. Also, you will find functions for custom states or commands of the hero (which are independent of the engine) defined there that you may need to use. (It took me a lot of time to understand all of that, but it's really important.)
#1003
Development / Re: Enemy: Zora
July 29, 2015, 08:24:13 PM
Hi Chris!

I finally finished my scripts for the beam, which may also be useful. I made 3 different types of beams (with lots of parameters that can be customized):

-Curved beam (actually not a beam). It throws each time a particle towards the position of the hero. It can make a pause after certain number of particles are thrown.

-Straight beam. This always makes a pause after a certain number of particles is thrown. Each time this throws particles, these are thrown aligned, towards the direction where the hero was.

-Moving beam. This one is a bit different. This is a continuous straight beam (it does not pause, and all particles are aligned in the same straight line). The straight line points towards a moving target, which moves towards the hero at certain speed (when the line has changed the direction, which happens when the target moves, the particles' position is changed so that they still form a line).

The three scripts work using another script called beam_particle.lua, which creates the beam particles.

Again, I put the link to my repository.
https://github.com/Diarandor
#1004
Development / Re: Thought experiment: Beamos
July 29, 2015, 02:02:53 PM
Yes, you are right. I forgot to align the beam particles :o. I'll try to create new scripts for the beam.
#1005
Development / Re: Thought experiment: Beamos
July 29, 2015, 07:45:51 AM
Good news. I made a customizable script for the beam (using an enemy that throws "beam particle" enemies again and again). You can find them in my repository:
https://github.com/Diarandor

The main script is in data/enemies/projectiles/beam.lua.
It works using the other script data/enemies/projectiles/beam_particle.lua, which is used for each particle of the beam.

You can customize the beam.lua script easily. (It remains to add the sound and make the beam stop after a certain time.)