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 ... 11
Your projects / Re: Vegan on a Desert Island
« on: September 16, 2018, 11:38:32 pm »
That sounds amazing : )
So, just an FYI, you trailer is ambiguous enough that I had noooo idea if this would be the kind of thoughful satire it seems like you're trying to do, or if it was just making fun of anyone who was trying to be thoughtful or less than selfish. I think it's a slight ambiguousness in what dialog you chose to show, or the way "parody" often, unfortunately, means "making fun of someone's sincere beliefs". Or maybe the internet has just primed me to except the most dis-empathetic qualities from people, lol.

Well anyway, best of luck with working on this, and keep up the hard work. I'll be rooting for you through development. Let us know if you have any questions as you're working. Thanks for sharing your project! : )

Your projects / Re: Vegan on a Desert Island
« on: September 16, 2018, 09:04:56 pm »
I've seen this somewhere else before too! Good job, looks like it's coming together technically, and all the parts seem cohesive. I couldn't tell from the video what the central ideas of the parody were- what's your like, elevator pitch?

Also I'm always looking for help with my project if anyone is interested it's quite a large scale for one person.

Just a little more unsolicited advice- if your game is large for one person, it's probably too large for you to finish. Just speaking for the experience of seeing many projects fail. If you're okay with not finishing, great, keep going as long as you can. But if you want to continue learning and developing more games, make a smaller one first. You'll learn WAY more doing a few small games that you would one big one.

Either way, good luck.

I'm not sure which part of your code was looping? The only part that should have looped was the check_hero() method, which loops every 1sec. That's why I suggested putting the freezing function in there.

On their own, if/else branches don't loop. They have to be inside a loop for that.

I'm going to reformat your code a little bit, like Diarandor suggested.

I also added some comments into your code. One big this is don't do something like:
if rupees <5 then
  some code
if rupees > 5 then
  some code

You should be using an if/then/else/end construction.
Look over that page. Also, elseif conditions are very useful.

Code: Lua
  1. local enemy = ...
  2. local game = enemy:get_game()
  3. local map = enemy:get_map()
  4. local hero = map:get_hero()
  5. local sprite = enemy:create_sprite("enemies/Redead2")
  6. local movement
  7. local IsPlayerFrozen = false
  10. function enemy:on_created()
  11.   movement = sol.movement.create("target")
  12.   enemy:set_life(8)
  13.   enemy:set_damage(10)
  14. end
  18. function enemy:on_restarted()
  19.   sol.timer.start(self, 3000, function()"Redead/RedeadMoan") end)
  20. --do you really want every redead on the map to moan 3 seconds after you enter the map?
  21.   self:get_sprite():set_animation("immobilized")
  22.   enemy:check_hero()
  23. --you will probably want your check_hero() method to freeze the player. As it is, if the hero is more than 80px away, the redead will not
  24. --freeze the hero, but then it doesn't loop. It won't try to freeze the hero again until you damage it. I think you probably want to
  25. --check if the hero is close enough to freeze constantly, or every second or so, which is what your check_hero() method is doing anyway.
  27.   if self:get_distance(hero) <= 80 then
  28.     if IsPlayerFrozen == false then
  29.       sol.timer.start(self, 3000, function() hero:freeze() end)
  30.       IsPlayerFrozen = true
  32.     end
  33.   else --instead of checking a condition multiple times, do an "if player isn't close", then "ELSE", which mean, if the play IS close in this case.
  34.       sol.timer.start(self, 5000, function() hero:unfreeze() end)
  35.       IsPlayerFrozen = false
  36.     end
  37.   end
  38. end
  42. function enemy:check_hero()
  43.   if self:get_distance(hero) <= 80 then
  44.     movement = sol.movement.create("target")
  45.     self:get_sprite():set_animation("walking")
  46.     movement:set_speed(28)
  47.     movement:start(enemy)
  48.   end
  49.   sol.timer.start(self, 1000, function() self:check_hero() end)
  50. end
  54. function enemy:on_dying()
  56. end

Yeah, most of my mistakes are me being like, why won't this work, I don't understand anything! And it's some simple syntax error like that.

I googled the elder scrolls engine, did you use their creation kit thing to make mods with their papyrus language?
Papyrus Introduction

If so, from my brief glance over this page, I bet you'll find a lot of ideas to be pretty familiar in Solarus, just worded differently.

Make sure you start you code with <code=lua>, not just <code> (square brackets, not <> signs.) This adds line numbers, which is SUPER helpful if I want to tell you there's an issue on line 19. Which there is. At least, I think it's line 19, but there aren't any line numbers, so....

Also, preface. You're clearly just leaning, and trying to take other people's code and make it work and don't know 100% what's going on yet, and that's okay. This actually seems like a pretty great code, especially for a beginner. You've just made a few beginner mistakes. But I think the ideas behind the code, that there should be an enemy that wakes up and starts playing miniboss music when he's first hit, and that once he takes some damage, he is replaced by an unarmored version, is a good concept. I assume the code for this basically works? It seems like it mostly should.

But, there's a couple issues and I'm going to give you a lot of information, hopefully it will help you learn and the next script you make, will be better because you'll know why you're making certain choices (not just "because it works").

I don't think "sleeping" should be a savegame value- for one thing, right now every Iron Knuckle in the game shares the same value if they're sleeping or not so they'd all wake up at once XD. That's just a mess. What you want is a local variable.

For example, "local sprite" and "local movement" are two local variables called sprite and movement. They're declared at the top of the script, but they don't have any information in them yet. Some code will put some information in this variable later in the script, and it will affect only this script. Local variables are local to the "scope" of wherever you create them. So, since they're declared just in the enemy script, they're only a part of the enemy script. Every enemy can have a local variable called "number_of_pineapples" and if you give a specific enemy six pineapples when he bumps into a pineapple tree, that will just give him six pineapples. If you have an enemy with code like
Code: Lua
  1. enemy:on_bumping_into_tree()
  2.   game:set_value("number_of_pineapples", 6)
  3. end
Then EVERY enemy of that breed would get six pineapples. You'd want:
Code: Lua
  1. local pineapples
  2. enemy:on_bumping_into_tree()
  3.   pineapples = pineapples+6
  4. end

Then the pineapples variable is just accessible by this script, not ANY script looking at game:get_value("pineapples")
So I think you'd want "sleeping" to be a similar way, where each instance of the script running has a local sleeping variable. Does that all make sense?

And speaking of local variables, you have these lines:
local sprite
local sprite = enemy:create_sprite("enemies/" .. enemy:get_breed())
This is redundant. It's like saying "I'm going to create a local variable, and it's going to be called sprite. I'm going to create a local variable, and it's going to be called sprite, and it's going to contain [the sprite of this enemy breed]". You definitely shouldn't be declaring variables of any type twice.

Better than that would be:
local sprite
sprite = enemy:create_sprite("enemies/" .. enemy:get_breed())
But that's still redundant.

The best option would be
local sprite = enemy:create_sprite("enemies/" .. enemy:get_breed())

Moving on down, your line "enemy:get_damage()" is getting the value you just set with "enemy:set_damage()", but... it's not doing anything at all with that value? You just get it and then ignore it and move on. It's like if in the middle of a paragraph I just wrote something unrelated. 12. And then kept going and never talked about it again.

I still can't figure out why self:set_pushed_back_when_hurt(false) needs to be self and not enemy. Maybe this is a bug? Someone smarter than me will have to help you there : /

Now, tell me if I'm wrong, but does sleeping = 1 mean it's asleep and sleeping = 2 mean it's awake?
If that's the case, you should use a boolean variable. Booleans can only be true or false (or in lua, nil, which acts a lot like false but basically means nobody ever bothered assigning it a value).
Basically, instead of saying something like
Code: Lua
  1. local sleeping = 1
You would say
Code: Lua
  1. local sleeping = true

Then you could have statements like
Code: Lua
  1. if sleeping == true then
  2.   movement = sol.movement.create("target")
  3. end

True/False is a LOT easier to understand than 1 or 2 for something that can only be true or false, like "is this enemy asleep?"

Finally, you have this mess here:
Code: Lua
  1. if game:get_value("Sleeping") == 2
  2. then movement = sol.movement.create("target")
  3. end
  4. if game:get_value("Sleeping") == 2
  5. then movement:set_target(hero)
  6. end
  7. if game:get_value("Sleeping") == 2
  8. then movement:set_speed(15)
  9. end
  10. if game:get_value("Sleeping") == 2
  11. then movement:start(enemy)
  12. end
  13. if game:get_value("Sleeping") == 2
  14. then sprite:set_animation("walking")
  15. end

pleasepleasepleasepleaseplease write that like this:
Code: Lua
  1. if game:get_value("Sleeping") == 2 then
  2.   movement = sol.movement.create("target")
  3.   movement:set_target(hero)
  4.   movement:set_speed(15)
  5.   movement:start(enemy)
  6.   sprite:set_animation("walking")
  7. end

Your way technically isn't wrong, but... it's very wrong.

I happen to have just started taking a computer coding course and the importance of writing code other people can understand is something we covered today. So we were encouraged to share our code and read other people's code, so this is practically studying for me, lol.

Quote from: max
Also giving your whole code is often helpful in case your problem isn't where you think it is
Quote from: max
You can just copy and paste the whole enemy script so someone helping you can see how things are related.

I've low key been trying to say that the whole code in this case is probably more useful for people trying to help you. If you're an experienced coder and you've been testing things and you know where the issue is, maybe you don't need to send the whole thing but if you haven't coded many enemies and you're aware there's a problem somewhere, it isn't too hard for us to take a look over the whole thing.

As far as I know, there isn't a discord or anything for chatting, but I think posting your code on the forum is a pretty good way to get help fairly quickly. I check the forum at least five or six times a day unless I'm on vacation, and we're pretty nice around here. While we aren't going to code your whole game for you, if you've tried a bit yourself, most everyone is more than happy to point you in the right direction. For example, "Can someone show me how to make a custom sword that shoots lasers" might not get many replies, but being like "I tried this code to make a custom sword that shoots lasers, can someone help show me where I've gone wrong" is more likely to get assistance.

One way to get much better at coding is just to keep trying. Figure out what steps are necessary to what you're trying to do, and then think about how a computer might be able to do those steps. Keep breaking it down into more steps, keep looking over the API for methods that do what you want, use the search function there, and when you've tried a couple things and things aren't working, ask. Make sure to watch Christopho's tutorials on youtube, and look at the Solarus team's code on GitHub. If there are things there you don't understand, feel free to ask.

With all that said, I just started taking a coding course at a school in my city. In two weeks, I've learned almost as much as I could teach myself over six months trying things myself. It's worth it to buy or borrow a book about coding. Even if the language the book is about isn't Lua, many concepts will be transferable.

Ignorance when you start learning is inevitable.
If you imagine I'm using [square brakets] instead of <> signs:
<Quote> quoted text goes here </quote>
<Code=Lua> your code goes here </code>
(And I'm just talking about on this website, not in your files, in case that wasn't clear).
Also giving your whole code is often helpful in case your problem isn't where you think it is, which is  more common when you're starting out.

Enemy:on_restarted is often a good place to set timers, because all timers with the context "enemy" are destroyed when the enemy restarts. So if you want a timer to restart when you restart the enemy (when it gets hit, when it is created, etc) create the timer there.

Keep in mind though, this might mean he'll create bats every time you hit him. If you don't want that, you'll want the context of the timer to be outside the enemy- set to the map for instance. I have the Solarus API open 24/7 on like two devices at least because I check it so much when I'm working, lol. Definitely reference it frequently while learning and trying new things.

I'm still wondering why enemy:set_pushed_when_hurt(false) didn't work though. Do you have your line declaring what the enemy variable refers to? Usually enemy=...(the dots mean, this instance of the code)

Using the tag code = lua inside square brackets is super helpful is people are looking over your code, so you might do that next time. Have you used BBC formatting like that before? You can just copy and paste the whole enemy script so someone helping you can see how things are related.

One thing it looks like in your create-a-bat code is that enemy:create_enemy() needs x and y coordinates specified, or else you're creating it up at 0,0: the top left corner of the map. Perhaps they're being created but you can't see them up there for some reason?

Also, when are you calling your timer? You should probably call the timer in the enemy:on_restarted() event, or enemy:on_created()
It doesn't look like you're ever calling the timer?

It could be a few things- post your whole code and use the code=Lua tag in square brackets to format it.

A couple things that come to mind for the sleeping animation thing are that your variable "Sprite" doesn't contain the data of this enemy's sprite, or perhaps there is another function that's almost immediately changing his animation back from sleeping to walking or something.

Congrats! Enemy AI can be a really fun (occasionally headache inducing) project. Have fun with your project!

Thanks. I'd like to do a series of articles leveraging my studies in architecture, but there is so much to do in life! I translated that article using Google a while ago, and it's very good advice. There were a few paragraphs Google didn't translate for me, but the main ideas came through clearly.

Hey Akamatsu. One thing that will help is putting some periods in your sentences what you ask questions, I was a bit confused trying to read that. But the take away is you're trying to recreate some of the freezing behavior of the redeads in Ocarina?

There's a couple things you'll probably need. The way I would do it requires a basic understanding of timers and some basic enemy programming.

For the freezing part specifically, I think you want the redeads to freeze link when he's close enough? You'll have to have your enemy script check the distance to the hero every several milliseconds, you can find a lot of enemy scripts that do that.

Once the player is close enough, you'll probably want to use hero:freeze() to stop the player moving. Then you'll set a timer and after  3-4 seconds, call hero:unfreeze().

If you have other questions, feel free to ask, I'm not sure if you've seen the documentation for Solarus, but look through there for timers and such.

Your projects / Re: Ocean's Heart
« on: September 02, 2018, 01:34:05 pm »
It's up to you- I'm planning a late 2019 release, so there's still a lot to do, but Christopho has done like 3-4 hours of let's play of this game on his channel, so there's at least that much. I can put out a slightly updated version late tonight if you'd like, it wouldn't go much further content wise but since the last demo I've made a bunch of small changes to things like the sword attack,small changes in the world, replaced most sound effects, etc.

Pages: [1] 2 3 ... 11