Hello forum!

Hello forum!

Quick overview of my problem: All my assets are 2d, because the game is only viewed from the isometric-perspective.

But the game shall include height, which also requires that every isometric-tile exists with height, width and depth. Nonetheless, since the actual visible game is isometric, I'm struggling a bit with realising the 3d-part. All bounding boxes are meant to be cubes.

Currently I worked out the following plan:

- Do the 3d math in a orthogonal view (but in 3d).

- If an object moves, work with its physics-coordinates and check for collision etc.

- If a movement has been committed, transform the top-down 3d view to a 2d isometric view (use physics-coordinates to calculate the location for the 2d texture plane of the tile).

I'm still wondering whether this is a good way to do it or if there is anything that should be preferred? I personally assumed, that is way easier to work from top-down, because cube-collision should be easier and faster to implement, if everything is just straight.

Another question would be, what transformation-matrix should be used for this case?

Last but not least, how would a mouse-click be handled? My idea was to transform the mouse-coordinates from 2d to the 3d field and raycast it for collision?

Thanks for taking your time to read my post!

Edit: I assume this posts fits better in Math and Physics... sorry!

It doesn't sound bad.    Ray-cast is not so hard to code either - I believe it is a correct approach..

Is it your own game engine, and what is the physics engine that you selected? 

Will you implement the Physics yourself?  .... Beware that if you happen to need proper collision response (bouncing cube , not snap to grid), it can take a lot of time and there are a lot of problems on the ways.

On 10/14/2017 at 3:52 AM, Angelic Ice said:

what transformation-matrix should be used for this case?

I am not sure what you mean.   Is 4x4 matrix OK for you?

I researched a bit more during the last days.

I have no real physics engine because I thought handling the required physic is doable by myself: Collision between cubes and is one gravity-affected cube standing on a ground cube.

What do you mean by bouncing cube and not snap to grid? In my 3d world there is no grid, only in the displayed world, the 2d one.

I read about AABB and I think that is what I meant earlier. I want to do AABB for collision and then do an isometric projection to my 2d world and calculate the x and y of each plane, since there are no 3d models but 2d images.

By transformation-matrix I rather meant a way to transform my 3d cubes to the 2d images, I read about isometric projection and will probably use that.

I mean ... Do you want a thing like this :-  ?

If so, use an external physic engine (e.g. Box2D) would probably be more suitable.

If you just want a thing like :- 

It is not so hard to write physic engine yourself.  (But I will still use Box2D for this case.)

Just a random concern : AABB is not the hardest part of a general-purpose Physics engine.

On 10/16/2017 at 6:07 PM, Angelic Ice said:

By transformation-matrix I rather meant a way to transform my 3d cubes to the 2d images, I read about isometric projection and will probably use that.

There are a lot of different way to do it. 

It depends on format of your 3D transform and 2D transform ... and your taste. 

First, let try your approach.    It is not hard.   You probably don't need any transform matrix to do that.  

If you face any specific difficulty about it, feel free to ask more.

Actually, I have 2d isometric levels with grids. Players interact with a grid-logic only.

Originally I used a flattened vector to store grids, it worked out quite well but then I started to encounter an issue: If a character moves from tile 1 to 2, they have to lock/unlock their grids at some point, as in transitioning from one element to another on the vector. This destroys the flexibility of real-time checking. If the target-grid disappears, the player should fall down. If an enemy appears, they should be damages. But grid-logic left me kind of turn-based, which is not my goal.

So I decided to do AABB and go full 3d for the physics/real-time-feeling but still render in 2d and provide a grid-logic to the user. Box2d is 2d though, right? I would require a cube-object though. Anyway, I doubt doing cube-collision is that hard to do in AABB. I was not really sure if the transformation from AABB 3d to 2d display is common, but according to some research, it is.