I think it is possible to abolish the cell based graphics completely. We simply use sprites as textures on a 3d wireframe. This wireframe (very simple) must be included with the graphics (in a seperate file). This way we can simply build bigger graphics when otherwise many smaller tiles would be necessary. For example we can put many tiles that can only be arranged in a certain order in one graphics file.
The negative aspect of this design is that the program cannot simply tell what a sprite represents. It is not clear if it is a wall or a floor or an object.
Up to now, a cell had seperate images for the floor and for two walls and they were unambiguously assigned. So when a spell removes a wall, it simply cleares the wall image of the cell.
But I think that is not necessary and will never be used.
Another point is that we would need a seperate editor for arranging the sprites, but I think it would not be a big problem to include this editor in the normal client and simply switch between the two modes.
Awaiting your comments,
Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
those are good news, but it is not still very clear what does it imply.
Isometric view remains, OK?
If no tiles are used anymore, we can create larger graphics for the terrain, that's OK. But, what happen to sprites? Are they still restricted to the original cell size, or can be larger than that?
We could have a common, unmodifiable background texture, and over it, cell-specific sprites, (like the burned grass example, or walls, etc.)
Example:
The interior of a temple, with a larger-than-a-cell design of a big circle and a pentagram inside on the floor. Over it, large sprites of walls, columns, an altar, stairs, doors, etc). if the is a change that affects the floor (for example, a pit trap is triggered), and additional sprite over the cell with the trap could be displayed over the common floor image.
I assume that cells will remain at least for logic purposes, like movement, area of effects, positioning, etc. is that true?
Regards,
Jesus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, isometric view remains just as the cells remain (at least in the server).
All the graphics are unrestricted in respect of their size, they can be larger than cells. Only movable objects should be not larger than cells, because otherwise the collision detection fails, or at least the image would go through the wall if you stand near a wall.
Everything in your example should work except the trap door. I want to use a depth buffer for drawing and so I have to use real 3d coordinates for the edges of the sprites. When something is drawn over something else, it must also be before it. So you cannot overdraw the floor by something that reaches under the floor.
Regards,
Chrisitan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Understood! And for the trap door I was just thinking about a picture that *seems* to open a hole on the ground, but of course not a 3D hole, just the optical effect!
Good to hear all these, because we have great freedom for graphics.
Rgds,
Jesus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, if you do not want to fall in the trap door but only see it, then this is possible, although letting the trap door override the floor is not easy to do. Because it must be a little above the floor. OK, that is still no problem, the problem arises when you want to override the trap door again. You do not know how much above the floor it is situated.
But I think those situations will not occur.
So how big do you think should the invetory images be and should we enlarge the cells also?
Regards, Christian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
SH*T, the message I wrote produced an error and was lost!.
Well, in short, I will try different sizes for the inventory items and for the character sprites, as they will define the size of a cell. Give me a couple of days to test some possbilities and produce examples to help us decide.
Cheers,
Jesus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
I think it is possible to abolish the cell based graphics completely. We simply use sprites as textures on a 3d wireframe. This wireframe (very simple) must be included with the graphics (in a seperate file). This way we can simply build bigger graphics when otherwise many smaller tiles would be necessary. For example we can put many tiles that can only be arranged in a certain order in one graphics file.
The negative aspect of this design is that the program cannot simply tell what a sprite represents. It is not clear if it is a wall or a floor or an object.
Up to now, a cell had seperate images for the floor and for two walls and they were unambiguously assigned. So when a spell removes a wall, it simply cleares the wall image of the cell.
But I think that is not necessary and will never be used.
Another point is that we would need a seperate editor for arranging the sprites, but I think it would not be a big problem to include this editor in the normal client and simply switch between the two modes.
Awaiting your comments,
Christian
Hi,
those are good news, but it is not still very clear what does it imply.
Isometric view remains, OK?
If no tiles are used anymore, we can create larger graphics for the terrain, that's OK. But, what happen to sprites? Are they still restricted to the original cell size, or can be larger than that?
We could have a common, unmodifiable background texture, and over it, cell-specific sprites, (like the burned grass example, or walls, etc.)
Example:
The interior of a temple, with a larger-than-a-cell design of a big circle and a pentagram inside on the floor. Over it, large sprites of walls, columns, an altar, stairs, doors, etc). if the is a change that affects the floor (for example, a pit trap is triggered), and additional sprite over the cell with the trap could be displayed over the common floor image.
I assume that cells will remain at least for logic purposes, like movement, area of effects, positioning, etc. is that true?
Regards,
Jesus
Hi!
Yes, isometric view remains just as the cells remain (at least in the server).
All the graphics are unrestricted in respect of their size, they can be larger than cells. Only movable objects should be not larger than cells, because otherwise the collision detection fails, or at least the image would go through the wall if you stand near a wall.
Everything in your example should work except the trap door. I want to use a depth buffer for drawing and so I have to use real 3d coordinates for the edges of the sprites. When something is drawn over something else, it must also be before it. So you cannot overdraw the floor by something that reaches under the floor.
Regards,
Chrisitan
Understood! And for the trap door I was just thinking about a picture that *seems* to open a hole on the ground, but of course not a 3D hole, just the optical effect!
Good to hear all these, because we have great freedom for graphics.
Rgds,
Jesus
OK, if you do not want to fall in the trap door but only see it, then this is possible, although letting the trap door override the floor is not easy to do. Because it must be a little above the floor. OK, that is still no problem, the problem arises when you want to override the trap door again. You do not know how much above the floor it is situated.
But I think those situations will not occur.
So how big do you think should the invetory images be and should we enlarge the cells also?
Regards, Christian
SH*T, the message I wrote produced an error and was lost!.
Well, in short, I will try different sizes for the inventory items and for the character sprites, as they will define the size of a cell. Give me a couple of days to test some possbilities and produce examples to help us decide.
Cheers,
Jesus