 (1).gif)
Now, I am having a lot of problems with having mobs spawn.
I tried with marking tiles as "spawn" and then doing a loop that in -init() does
function spawn_mobs()
for x=0,127 do
for y=0,63 do
if is_tile(spawn,x,y) then
spr(m.spr,x,y)
end
end
end |
This doesn't work
Any ideas on any other method to spawn monsters?
You've said that your code snippet is in _init().
As most of the time there's a cls() statement at the start of _draw(), presuming the cls() just stated exists, then any monster you draw with spr() in _init() will be wiped from the screen.
Also, spr() uses screen pixels for placement; your loop is presumably over the full map, so you would need to multiply by 8 for the mob/monster coordinates when you get to spr().
In the loop you have in _init() you could add(m,{x=x*8,y=y*8}), then later loop over m to get the pixel x,y, something like: for i=1,#m do spr(m.spr,m[i].x,m[i].y) end
(If anything written above is in error, please correct me. Thanks.)
The details of is_tile() and spawn are unclear to me from your code snippet; if my comments above don't help enough, perhaps you could post enough of your code to make is_tile() and spawn clear.
By the way, you have posted this thread in Tutorials, which is described as Tutorials, HOW-TOs, lessons and other teaching resources.
Although I understand that you may be asking for a tutorial, perhaps the Workshop area of the forum would be more appropriate, which is described as The never-ending workshop! Get help with any aspect of PICO-8 creation or using the editing tools.
To me, the tutorials sub-forum seems appropriate for people posting tutorials, and the workshop appropriate for asking for help. Getting things in the appropriate forum helps other people to find posts along the lines of what they are looking for. :)
Thanks for the comment @remcode.
Now it is taged workshop.
Also thanks for the comment about the spawning itself
Now, my problem is telling them not to move if the next tile is moving.
Just for prototyping, I made a loop that substracts 1 from m[i].x, so know, when the player moves, all mobs move to the left.
I tired to use my can_ move function , wich checks if that x,y coordinate is occupied by a wall tile, and if it is returns false, and if it isn’t then it returns true, but it didn’t work
function move_mobs()
if can_move(m[i].x-1,m[i].y) then
for i=1,#m do
m[i].x-=1
end
end
_upd=update_game
end |
So, that is basically that is the code for the movement. When the player moves, then it does _upd=move_mobs, so the mobs all move to the left. I will add the pathfinding later, but now all I want is the wall collision
Possibly this is a consequence of the mob move being in pixels and the map being in map coordinates. You may need to convert the former back to the latter when testing.
Edit: code removed, because it was very specific to moving the x-coordinate by 1 pixel; please see later post for a fuller solution.
If can_move is already doing \8, that won't be the solution though. It's probably better to do the \8 to the pixel x and y in can_move, rather than how I've shown it here.
Edit: correction made; hopefully. I'm not guaranteeing the above will work.
Thx for that @remcode, now it works.
But how do I mark as walls, the sprite itself?
This is what happens right now
As you can see, the mobs don't collide, but when they hit a rock, they overlap.
My system doesn't use flags to mark tiles as walls or doors but a list of sprites that get marked as walls (for exampel) and then, the is_tile function goes trough that list and returns of it is that type o f tile, so with sprites it wouldn't work.
Could you explain the edits better?
I am pretty new to lua and I don’t understand half of them or less.
The only other bit to explain, if you haven't seen it before, is that "Functions can be stored in variables (both global and local) and in tables, can be passed as arguments, and can be returned by other functions." Quote source: https://www.lua.org/pil/6.html
I have used this to put two functions - occupy and deoccupy - into the occupied table itself, while at the same time using the occupied table to store x and y coordinates of all the members of m.
This is done with code such as:
sometablename={
functionnameone=function()
--code here
end,
functionnametwo=function()
--code here
end
} |
These functions are then called as functions of the table, so in the code I previously gave, for example: occupied.occupy(m[i].x\8,m[i].y\8)
Or for the pseudo-code in this post: sometablename.functionnametwo()
Which would call the occupy function of the occupied table, with appropriate values for x and y.
Does the loop you added to set the mobs x and mobs y after spawning the mobs go before or after the original one?
It has to go after the occupied table has been created.
And after the mobs have been created.
Somewhere near the end of your initialisations.
EDITED
I'll set aside some time to mock up a fuller test of my code, but I won't be able to find the time until at least tomorrow (at earliest, about 18 hours from now).
ç
The result isn't what I expected
I keep bouncing so the mobs advance
I have deleted two and a bit of my posts above.
I coded enough of them to know that they work for the test you were attempting to make. However, they were attempting to work at the level of screen pixels (which are needed for placement), but I believe you need your movement check code to work more at the level of tiles. As such, although it worked, my code and your code were not well matched to one another - please don't use it because I believe it will only complicate things.
Edit: I'm going to attempt to make my code and your code fit better for a wider solution this morning; I will let you know how this goes shortly.
Your most recent gif with your player sprite bouncing off the rock indicates the code needs to check that the tile your player sprite is going to move to is available before it moves even one pixel in that direction. If it isn't available, then neither your player sprite nor your mob sprites should move even one pixel.
The check I suggested previously was a limited check for the situation you were testing - left movement. To move in another direction some small adjustments to the checks may be needed.
The coding of can_move is probably the best place to adjust this, as well as the best place to put the checks for the occupied table I posted previously. My trying to fit the checks into move_mobs which you had shown me, did not fit the overall situation well.
The bouncing is just to make the bouncing against walls more credible, more like you are bouncing, you can't advance here
@ExtrovertPlatypus here is a working version for detecting collision with other mobs; you may use any of it that you want; although I have used some of the same function names as yours, the code may be different.
This version makes it so that each movement is a full tile, and only then can a new movement happen. If that isn't what you wanted, you'll need to find a different solution (see the edited section below).
I haven't coded the bounce off items as I hadn't read that comment (see the edited section below for a further comment about that).
(There are other things I haven't coded, such as vertical animation, just because I didn't need it for my purposes. Anyone looking at this should note the wip at the end of the cartridge id - it's not intended to be complete.)
This is just the way I have coded it, still based in what was discussed above - there may be other ways to code similar checks that would suit your program and/or coding style better. It might be worth having a look at the code of some carts on the BBS that do similar things to what you want, to see how others have implemented it.
Edited to add:
Essentially what you are doing when you're looking ahead to see if there are other mobs there is collision detection. If you don't want it as tile based, you will need to look at other ways of doing collision detection, such as overlapping rectangles; see for example: http://jeffreythompson.org/collision-detection/rect-rect.php
Using a search engine to look for collision detection or collision detection rectangles should bring up more information from similar sites.
If you wanted to convert tile based checks to rectangle based checks, you would need to give what was previously checked a width and height in pixels, and map points would need to be multiplied by 8 (the width and height of a map tile in pixels). The x and y coordinate and the width and height, all in pixels, can then be used to form your rectangle.
To put a bounce animation in, probably it would be appropriate to give the player a state such as is_bouncing=true. So you can play an appropriate animation when it happens, while using the value of is_bouncing to control (with if statements) what else is allowed to occur while the player is bouncing. This would be similar to what I have already done in the code with ismoving.
[Please log in to post a comment]
