slice hitboxes, slice collision
Moderators: marionline, SDHawk
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
slice hitboxes, slice collision
is it possible to check for a collision between a slice (the target) and any slice that fits a criteria?
I want to create a weapon hitbox (e.g. a grid) which has multiple slices
I want to check for a collision between the target and any valid slice in the "hitbox"
Is this possible?
Or does (slice collide) only check for collision between 2 specific slices?
for example, I am checking for a collision between a target, and a slice (any slice) with the lookup code (e.g. "weapon")
I want to create a weapon hitbox (e.g. a grid) which has multiple slices
I want to check for a collision between the target and any valid slice in the "hitbox"
Is this possible?
Or does (slice collide) only check for collision between 2 specific slices?
for example, I am checking for a collision between a target, and a slice (any slice) with the lookup code (e.g. "weapon")
Last edited by SwordPlay on Mon Mar 13, 2017 5:02 pm, edited 1 time in total.
"Imagination. Life is your creation."
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
also, on this topic, I tried creating a game with slice based collision detection, but now I'm thinking that I should remake the whole thing with better ordered slices.
Is there an optimal way to arrange slices?
specifically, it seems a good idea to make all weapon/attack slices in their own containers in a single collection, otherwise checking for collisions has to take place for each collection (not sure: i'm not a coder)
would it also make sense to make object classes share a single parent collection?
one for enemies, one for weapons, etc.?
I'm having trouble mapping it out in my mind.
I think it's due to the way that you can check for slice collisions.
I found "find colliding slices" in plotdict for example.
I think I would be better off arranging slices according to their classes, with slice archetypes arranged by collection.
I'm having trouble mainly due to the fact that I want
1) several slices per weapon hitbox
2) a weapon hitbox for each direction
3) more than 1 kind of weapon, all weapons having different hitboxes, composed of slices
Is there an optimal way to arrange slices?
specifically, it seems a good idea to make all weapon/attack slices in their own containers in a single collection, otherwise checking for collisions has to take place for each collection (not sure: i'm not a coder)
would it also make sense to make object classes share a single parent collection?
one for enemies, one for weapons, etc.?
I'm having trouble mapping it out in my mind.
I think it's due to the way that you can check for slice collisions.
I found "find colliding slices" in plotdict for example.
I think I would be better off arranging slices according to their classes, with slice archetypes arranged by collection.
I'm having trouble mainly due to the fact that I want
1) several slices per weapon hitbox
2) a weapon hitbox for each direction
3) more than 1 kind of weapon, all weapons having different hitboxes, composed of slices
Last edited by SwordPlay on Mon Mar 13, 2017 6:45 pm, edited 1 time in total.
"Imagination. Life is your creation."
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
It is possible to do hit detection with multiple slices, but you may have to call "slice collide" once for each slice in the collection.
Now, I am curious, can you show a screenshot illustrating what your weapon looks like, and why it needs multiple hitboxes
One thing that I sometimes do is to make an invisible container slice to be the hitbox. Then it can have as many visible child slice sprites as I want, which may fit inside it, or may spill over the edges a little.
I keep all my colliding hitboxes on the same layer, so that collision-checking is very easy. Is it possible that method could suit your purposes?
As for multiple weapon collections (and multiple directions of each) you could make each one in a separate slice collection,
or another option is to make them all in the same collection, but then give each one a unique look-up code. You could load the whole collection, keep a handle to it in a global, and mark it as invisible. Then your attack script can look up the appropriate weapon from the hidden weapon slice collection, reparent it to the hero or the map layer, or wherever, and then reparent it back to the hidden weapon slice container again when you are done with it (as opposed to freeing it)
Now, I am curious, can you show a screenshot illustrating what your weapon looks like, and why it needs multiple hitboxes
One thing that I sometimes do is to make an invisible container slice to be the hitbox. Then it can have as many visible child slice sprites as I want, which may fit inside it, or may spill over the edges a little.
I keep all my colliding hitboxes on the same layer, so that collision-checking is very easy. Is it possible that method could suit your purposes?
As for multiple weapon collections (and multiple directions of each) you could make each one in a separate slice collection,
or another option is to make them all in the same collection, but then give each one a unique look-up code. You could load the whole collection, keep a handle to it in a global, and mark it as invisible. Then your attack script can look up the appropriate weapon from the hidden weapon slice collection, reparent it to the hero or the map layer, or wherever, and then reparent it back to the hidden weapon slice container again when you are done with it (as opposed to freeing it)
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
I'm using multiple hitboxes for a diagonal attack, because collision detection is all rectangles (right?) so I made some slices lined up in a grid slice.
You can see them as black squares.
(I'm going to make it invisible to the player, and draw a different sprite. It's purely for collision detection, not graphical reasons, and is not intended to be seen by the player)
The orthogonal attacks are also made of more than 1 hitbox.
At the moment they are all under different collections.
I also had plans to include projectiles, with multiple components, each with their own motions, but now I'm reconsidering it :p
IMHO slices are vastly underused.
They have a lot of potential to open new avenues of gameplay and programming...
If only I could figure out how to use them! :p
You can see them as black squares.
(I'm going to make it invisible to the player, and draw a different sprite. It's purely for collision detection, not graphical reasons, and is not intended to be seen by the player)
The orthogonal attacks are also made of more than 1 hitbox.
At the moment they are all under different collections.
I also had plans to include projectiles, with multiple components, each with their own motions, but now I'm reconsidering it :p
IMHO slices are vastly underused.
They have a lot of potential to open new avenues of gameplay and programming...
If only I could figure out how to use them! :p
"Imagination. Life is your creation."
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
I'm not sure, but isn't it also possible to limit the movement of a slice, for example, by placing it in a container?
You could restructure the engine to run on slices, using containers to limit, control and define the path of various slices.
You could create a collision map using slices, or limit the player from moving through a slice type, or create slices to contain another slices movement.
Sounds difficult though! And at the moment it's all rectangles, and slices can't belong to more than one parent (?) I dunno tho, I'm not a coder
Making sure that slices are parented correctly and on the correct layer etc. is a PITA
It would be much easier if slices were modified to have more attributes that would make collision checking etc. easier.
Oh, and I have 8-dir movement, but diagonal presses only work when dir keys aren't being pressed. Any idea on how to do smooth 8-dir pixel based movement?
You could restructure the engine to run on slices, using containers to limit, control and define the path of various slices.
You could create a collision map using slices, or limit the player from moving through a slice type, or create slices to contain another slices movement.
Sounds difficult though! And at the moment it's all rectangles, and slices can't belong to more than one parent (?) I dunno tho, I'm not a coder
Making sure that slices are parented correctly and on the correct layer etc. is a PITA
It would be much easier if slices were modified to have more attributes that would make collision checking etc. easier.
Oh, and I have 8-dir movement, but diagonal presses only work when dir keys aren't being pressed. Any idea on how to do smooth 8-dir pixel based movement?
Last edited by SwordPlay on Mon Mar 13, 2017 8:20 pm, edited 1 time in total.
"Imagination. Life is your creation."
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Aha! I understand. Diagonal hitboxes.
Here is what I think I would do:
* Keep all the enemies on one layer
* keep all the attack hitboxes on another layer
* Keep the visual representation of the weapon on another layer
* Once every tick, loop through all enemies.
* For each enemy, use the "find colliding slice" to check an see if anything on the attack hitbox layer is colliding with the enemy, if so, damage the enemy.
Here is what I think I would do:
* Keep all the enemies on one layer
* keep all the attack hitboxes on another layer
* Keep the visual representation of the weapon on another layer
* Once every tick, loop through all enemies.
* For each enemy, use the "find colliding slice" to check an see if anything on the attack hitbox layer is colliding with the enemy, if so, damage the enemy.
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
Ah, yes, that makes sense.
I want to include fire and lightning and ice attacks.
Am I correct in assuming that they should be in separate collections which enemies should check for separately (leading to different effects, for example)?
Also, does the slice editor zoom? It's difficult to do pixel placement, for example.
I want to include fire and lightning and ice attacks.
Am I correct in assuming that they should be in separate collections which enemies should check for separately (leading to different effects, for example)?
Also, does the slice editor zoom? It's difficult to do pixel placement, for example.
"Imagination. Life is your creation."
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
Oh, and is it possible to expand and minimise lists in the slice editor? It's somewhat unmanageable as a long list of each slice.
If there were some tools to manage the slice trees and relationships, or possibly just a reordering tool, or the ability to make long lists hidden under their parents and expandable, or maybe a pane to display the contents of a selected slice etc.
If there were some tools to manage the slice trees and relationships, or possibly just a reordering tool, or the ability to make long lists hidden under their parents and expandable, or maybe a pane to display the contents of a selected slice etc.
"Imagination. Life is your creation."
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Putting fire and ice attacks in different layers is a perfectly reasonable way of doing it.
Or another way of doing it would be to give each hitbox a special value in one of its "slice extra" data slots to indicate what kind of effect the attack should do.
No zoom available in the slice collection editor. Maybe someday?
being able to collapse the display of child slices in the editor sounds like a very nice and useful feature. I'll look into seeing how hard it would be to implement
Or another way of doing it would be to give each hitbox a special value in one of its "slice extra" data slots to indicate what kind of effect the attack should do.
No zoom available in the slice collection editor. Maybe someday?
being able to collapse the display of child slices in the editor sounds like a very nice and useful feature. I'll look into seeing how hard it would be to implement
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
Thanks for the help and reply!
I just moved the attack slices to a single collection and updated the script.
So far so good!
Using extra data is SOOOOO useful! I was going to use it to contain damage value of weapons, HP of enemy slices, and stuff like that.... Too bad there's only 3(?) extra values... I can think of a lot of things to use them for!
But yeah, that's a good way. Thanks for the advice hamsterino
I just moved the attack slices to a single collection and updated the script.
So far so good!
Using extra data is SOOOOO useful! I was going to use it to contain damage value of weapons, HP of enemy slices, and stuff like that.... Too bad there's only 3(?) extra values... I can think of a lot of things to use them for!
But yeah, that's a good way. Thanks for the advice hamsterino
"Imagination. Life is your creation."
- Bob the Hamster
- Lord of the Slimes
- Posts: 7658
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Good news!
The feature to hide child slices in the editor was very easy.
it will be ready for tomorrow's nightly build
If the 3 slice extra data slots are not enough for your purposes, I know a hacky but effective workaround to get more space
give the slice an invisible child container slice with a lookup code like sli:metadata
You can easily look up the metadata slice of the slice you are working with using
And you can use ALL the properties of the metadata slice to store data in, not just the extra data. Since it is invisible, you can put data in x, y, width, height, and all four side-paddings
If you want an example of this, check out the scripts included with "Star Dartle 2000" under the section labeled "# Metadata"
The feature to hide child slices in the editor was very easy.
it will be ready for tomorrow's nightly build
If the 3 slice extra data slots are not enough for your purposes, I know a hacky but effective workaround to get more space
give the slice an invisible child container slice with a lookup code like sli:metadata
You can easily look up the metadata slice of the slice you are working with using
Code: Select all
lookup slice(sli:metadata, my slice handle)
If you want an example of this, check out the scripts included with "Star Dartle 2000" under the section labeled "# Metadata"
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
goodness me, seems awesome!!!
thanks guys!
I'm still having trouble figuring out slice collision however.
How do layers relate to collisions?
What if I want to check for collisions with hero sprite slices or NPC sprite slices?
Currently, I'm making parenting a slice to a NPC, so that it's unaffected by screen movement.
How can I Insure that slices are placed accurately?
the slice drawn on top of NPCs doesn't always seem to follow them, or is affected when the player moves the screen.
If I parent the slice to the NPC, how can I use collision checking etc.?
And what happens when I parent hero slice or npc slice somewhere else?
Does it break stuff? Am I missing something simple/obvious?
Sorry for the questions, I'm not really good at coding/scripting.
thanks guys!
I'm still having trouble figuring out slice collision however.
How do layers relate to collisions?
What if I want to check for collisions with hero sprite slices or NPC sprite slices?
Currently, I'm making parenting a slice to a NPC, so that it's unaffected by screen movement.
How can I Insure that slices are placed accurately?
the slice drawn on top of NPCs doesn't always seem to follow them, or is affected when the player moves the screen.
If I parent the slice to the NPC, how can I use collision checking etc.?
And what happens when I parent hero slice or npc slice somewhere else?
Does it break stuff? Am I missing something simple/obvious?
Sorry for the questions, I'm not really good at coding/scripting.
Last edited by SwordPlay on Mon Mar 13, 2017 9:37 pm, edited 1 time in total.
"Imagination. Life is your creation."
- SwordPlay
- Chemical Slime
- Posts: 966
- Joined: Sun Jan 22, 2017 9:32 am
- Location: London, England
- Contact:
I don't mean to be funny, but do you intend to add some visual confirmation that an entry can be expanded? such as brackets or a '+' next to it, perhaps on the left?
edit: oh I see you put the number of child slices on the right, forgive me.... maybe something on the left e.g.'+' might be more visually immediate?
edit: oh I see you put the number of child slices on the right, forgive me.... maybe something on the left e.g.'+' might be more visually immediate?
Last edited by SwordPlay on Mon Mar 13, 2017 9:40 pm, edited 1 time in total.
"Imagination. Life is your creation."