Isometric multiple floors

smassa

I'm sorry but i still don't understand the need for setting a Z offset. (maybe i don't understand offset at all...)

However i appreciate your help!

I have already a stairs event, so i simply set a player and zombie variable to check the floor.

With that i'm able to determine wheter the zombie can see me or not, and if i can shoot them or not.

That works all just great.

The issue is that construct 2 is missing that i can IGNORE COLLISION OF SPECIFIC OBJECTS WITH SPECIFIC SOLIDS.

So no matter which way i choose, it's simply impossible unless i code my very own collision system.

Currently i've go everything to work.

• I can walk upsairs, the second floor will be displayed
• I do not collide with objects on the ground anymore ( and opposite )
• I do collide with objects placed on first floor ( and opposite )
• Zombie and Player floor check works for line of sight and shooting like a charm

So yes, i got it all working

But not for multiplayer and not for AI

Solids are simply lacking features. It's either solid or not, GLOBAL

That's it, and i can't find a way around that.

some "thoughts"

player variable:

z

iex player.y - 100 offset indicating first level

either use the 100, or a dedicated variable to determine level

z=0 set active level 0

z =100, set activelevel 1

z=200, set activelevel 2

etc

cupboards, doors, walls, spiders enemies, players etc etc, all belong the family allobjects, and have instance var, activelevel, and set them during development.

events:

allobjects on collision with player

player.activelevel = allobjects.activelevel

action:

do some bumpage

Level appearance and interaction mechanic, perform on peer and host

event

player.peerid = multiplayermyid

for each allobjects

sub

player.activelevel = allobjects.activelevel

action

allobjects opactiy 100%

allobjects collisions enabled

else

allobjects opacity 50%

allobjects collisions disabled

just sync peer's activelevel instance variable determined by the peer going up/down stairs

The peer will appear on other peers and host set by activelevel.

It can deduce the Z from the given active level, requiring less synching overhead

lennaert

Thanks for your "thoughts", that was actually quite interesting!

I've mainly done what you've listed down already.

Peer, Objects and Enemies do have a .floor variable to determine on which floor they're currently at.

But i've not determined the allobjects family.

I may give it a try.

And about your:

allobjects opactiy 100% 
allobjects collisions enabled 
else 
allobjects opacity 50% 
allobjects collisions disabled[/code:1jac6jlq] 
 
If i'm not mistaken then "collisions enabled/disabled" is still GLOBAL, so according to your code that would mean that all objects would activate and deactivate collision each time something walks into an object. 
[b]But you forgot one thing.[/b] 
Your idea says "allobjects on collision with player" 
well... collision does not happen anymore if it has been deactivated. Which means it would never trigger. 
The only way i could actually do this is to check sprite overlap. [b]But activating collision on overlap does NOT work. You will be able to walk through the first object you're overlapping.[/b] 
 
I'm also still not using any Z as offset at all. 
I've simply set a variable "peer.floor" to 1,2,3,4 etc... so that's already the minimum of data to be synced. 
(I still don't understand why everyone gets this offset stuff started. Is there anything special about it? I just don't get it)

@Everade [quote:160patav]can't compare x and y positions.

Because x and y can be exactly the same on both floors.

The 1st floor isn't that much higher that i could compare these values.

Just put them on separate Layers for each floor, and add the condition "if xy position and on Layer (Floor) X". You can have many layers without performance issues, as long, as you don't have effects on them, obviously...

You can then also just check, if Layer/Floor is identical, or which is above/below, so on... does this solve the problem?

You can also just disable Solids and even collisions for every other Layer/Floor, saving a tons of problems and performance issues... Only, if the enemy has to check collisions on his own floor, can be a problem, but that can be solved different, e.g. path-finding behavior. Once set, no need for solids. Also you can register not solid objects to be obstacles.

lennaert

Thanks for your "thoughts", that was actually quite interesting!

I've mainly done what you've listed down already.

Peer, Objects and Enemies do have a .floor variable to determine on which floor they're currently at.

But i've not determined the allobjects family.

I may give it a try.

And about your:

allobjects opactiy 100% 
allobjects collisions enabled 
else 
allobjects opacity 50% 
allobjects collisions disabled[/code:1k5sla8t] 
 
If i'm not mistaken then "collisions enabled/disabled" is still GLOBAL, so according to your code that would mean that all objects would activate and deactivate collision each time something walks into an object. 
[b]But you forgot one thing.[/b] 
Your idea says "allobjects on collision with player" 
well... collision does not happen anymore if it has been deactivated. Which means it would never trigger. 
The only way i could actually do this is to check sprite overlap. [b]But activating collision on overlap does NOT work. You will be able to walk through the first object you're overlapping.[/b] 
 
I'm also still not using any Z as offset at all. 
I've simply set a variable "peer.floor" to 1,2,3,4 etc... so that's already the minimum of data to be synced. 
(I still don't understand why everyone gets this offset stuff started. Is there anything special about it? I just don't get it) 

The collisions would be activated per activelevel. IE it would activate all collisions on where the player would reside.

Looping the objects while filtering player.activelevel = allobjects.activelevel, sets each collision individually continuously.

Ofc the above code is just some basics, more would be required to keep things in check en pretty.

The not triggering collision would assist in players wanting to walk underneath something above them, for the view of the other party (other peer or host)

I never use the offset too really

MultipleChoice

lennaert

Thanks a lot for your constructive feedback and ideas.

I will try your ideas and will let you know if it actually worked.

I still don't think that your idea will work thought lennaert. From what i've tested so far the collisions were always global, no matter what i've tried.

On my previous tests, ones a Peer walked to the 1st floor, all deactivated collisions of objects on the ground were set.

So there's no way that any other peer could colide with anything placed on the ground anymore, unless with the activated objects on the 1st floor which shouldn't happen.

Also not by filtering using "pick Peer where Peer.UID = Peer.UID"

But i will give my best and just test myself through your specific example.

This may take some days weeks, but i will reply within this topic and let you guys know what i've achieved

Everade : Since I actually never did an isometric engine, I found it interesting to try out, if my proposal works fine.

So here it is:

* No Variables needed

* Good for you to Layout, since you can build your floors on different layers, or even using more layer per floor

* Complete Floors will set to solid off, and if you even switch off collisions of those families, you will save a lot of performance (way less collision-tests)

The only issue you have to solve is when the player turns around after colliding with the stairs (on the stairs, without entering the top floor. Now that messes up the right floor actually. That can be fixed of course, but since its way beyond your issue...

Take a look at the capx-file and Enjoy!

If you insist on using collisions I would suggest using the projection method.

Collisions for iso squares is going to be a little iffy...

MultipleChoice

lennaert

Thanks a lot for your constructive feedback and ideas.

I will try your ideas and will let you know if it actually worked.

I still don't think that your idea will work thought lennaert. From what i've tested so far the collisions were always global, no matter what i've tried.

On my previous tests, ones a Peer walked to the 1st floor, all deactivated collisions of objects on the ground were set.

So there's no way that any other peer could colide with anything placed on the ground anymore, unless with the activated objects on the 1st floor which shouldn't happen.

Also not by filtering using "pick Peer where Peer.UID = Peer.UID"

But i will give my best and just test myself through your specific example.

This may take some days weeks, but i will reply within this topic and let you guys know what i've achieved

I made a working example, its easier then expected, I even got the host/multiplayer movement restrictions/limitations worked out

But I am not fond of the way my stairs/elevation object works :

As the solution which I used, the key lays in the overlaps check.

Both player and wall have solid, and only the player has pushout solid too.

events:

for each wall

wall overlapping with player

sub

wall.activelevel = player.activelevel

action: wall set solid enabled

else - action wall set solid disabled

global mylevel (prevents having to pick)

event:

for each allobjects

sub:

allobjects.activelevel = mylevel

action: set opacity 100

else

action: set opacity 50%

event:

player.peerid = multiplayer.myid

action

mylevel = peer.activelevel

The only thing more needed is the stair (going up or down) action, to set the players activelevel.

Running these on both peer and host, will determine how each player responds to colliding with a wall.

I have 2 small platforms somewhere in the top middle of the map of my tankwars game see it working here

it actually works ;:O

you're awesome!

Gonna try to implement this on my game now

About the stairs, upon my testing it seemed to be the best idea to create 2 overlap sprites, one for going up and one for going down. The distance of these 2 should be big enough so that it's impossible to overlap both at the same time.

With that you can ensure that you're always on the correct floor.

Like my sketch on my very first post

That worked perfectly fine for me.

In my example I used 2 sprites, but I used an approach that required there being a moment of both overlapses and some booleans set ... got ugly after several attempts, gonna think about it, there's likely a better way to achieve that. will let ya know if I find something better.

Gonna use this same approach in some of my games too ^_^

I see we have a same interest in game type

Got a couple of these games in the pipeline.

seriously can't find anything related to "pushout solid"

where is it ?

--------

Update:

Nevermind... found it within Custom Movement.

"sigh" if i knew that earlier ^^

Everade, lennaert, newt

Just for fun, I enhanced the layer solution. Now the "engine" has all features you need.

• You can easily register any new elevation type (e. g. ladder, as I already added, or elevator)
• Different types of walls or furniture (with any size)

Of course the same can be done with overlapping, but I restricted collision-checks for the 8-dir-behavior and collision checks in the code as much, as I could.

What do you guys think about it? If there is any part, that can be solved better, still working correctly, I would be keen to know!

> Everade, lennaert, newt

Just for fun, I enhanced the layer solution. Now the "engine" has all features you need.

- You can easily register any new elevation type (e. g. ladder, as I already added, or elevator)

- Different types of walls or furniture (with any size)

Of course the same can be done with overlapping, but I restricted collision-checks for the 8-dir-behavior and collision checks in the code as much, as I could.

What do you guys think about it? If there is any part, that can be solved better, still working correctly, I would be keen to know!

That looks pretty good, hard to actually read them formula haha.

You should try it in a multiplayer scenario, and test the peers extensively.

EDIT:

for those wondering, the pushout plugin can be found under custom movement or from rex's plugin manager, the pushout solid behavior.

lennaert

I've implemented your idea and tested it under most conditions.

But it's interfering within a very specific scenario, which actually could happen quite a lot.

Well, it really depends on the situation and how you do the collision check.

For my test i've created a rather big sprite on the Players position.

It's my OverlapMask which should check if i'm currently colliding with any object on a specific floor.

During my tests, i wasn't able to get it to work without using any Overlap Masking, since it seemed that the player was never really able to overlap anything as it was colliding already... i don't know what's the exact issue on that.

Whatever...

Let's say Player#1 is walking into an object or a wall... Now the OverlapMask is always in touch with this specific solid which has the same .activelevel instance as the player.

Which means, it would trigger "Solid Enabled".

Now if Player#2 on a different .activelevel comes by, he will collide with this solid because it will stay enabled as the Player#1 is still overlaping this object.

Player#2 will be able to walk through as soon as Player#1 stops walking into the object, other than that it will stay solid forever.

Do you have any idea how this could be worked out?

I really wasn't able to get it to work without this overlapmask (which isn't solid by the way)

In your Tank Game it seems like you weren't using anything to overlap, but for some reason it triggers properly for you while for me it doesn't.

Or are you having the same issue?

[attachment=0:kynm8sgq][/attachment:kynm8sgq]