Okay I'm back and this time with a new question about what someone suggested for me. Summary: I want to make a 2d *isometric* RPG with SNES-style art, but with the sprites and objects able to have pixel-precise collisions in 3D (not tile-based). So they can jump and walk over rounded hills and stuff. And pixel-precise shadows that bend around objects just like in 3d. (I'm no programmer, which is why I'm asking if it is possible to code this kind of game). Here is the previous topic. I also want my game to be rotatable every 90 degrees (not 360 like real 3d games). But this means we can see all around the objects (of course I must design all 4 sides to every object). Here's an example pic of a shadow bending on a 2d object: Using the above image as well, an example of a 3d pixel-precise collision in 2d would mean that, say there was a 2x2x2 cubic object, and a 40x40x40 cubic object. The big object would not be able to crawl under the short stubby branch that protrudes from the trunk, but the little object will. And when it does, the shadow of that stubby branch will pass overhead! Someone told me a voxel engine would be too taxing on computers. Then a friend told me about height maps. He said I could make grayscale maps for every object/tile in my game that told the comp how high the object is. Since I want my game to be just like 3d (and we can rotate to see behind objects), I figured just height might not do it because a 2d image can only show the front of an object, not the back. So I'm thinking RGB values to signify to the computer x, y, and z, width, depth, and height values. Here is a pic of my idea: The blue values signify height (z), the red signifies x, and the green signifies y. I gave their values in increments of 15 (15,30--225). The first multi-colored diamond (upper left) is a tile of the flattest height (so blue value=15 for everything), and at the very left is red=15, green=225. At the very right is red=225, green=15. At the bottom is red=225, green=225 and the top is red=15, green=15. Then in the upper right we introduce an object with height. A simple cube-like box. Now, the blue values are being changed, so we can see the height of the object. At the top of the cube, all blue values are 120. This way the comp knows at what x,y,z position each pixel is at. Now the hard part is if I wanted a crevice in the cube. Because if that crevice were facing the other way so we couldn't see it, and an object were to crawl into that crevice from behind, but we only gave RGB values for the *front* of the cube, the computer must somehow be told there is a crevice that the small object can crawl into. So I drew a cube with a little crevice. To tell the computer there is a hole inside that cube, I figure the only way to do it is to (in the bottom right of the image) make slices of that object, and then the computer must compile the slices together, to form the complete 3d object. So if I make my 2d art and apply these kinds of RGB gradient masks for each slice of every object, for every frame of every animation, etc, do any of you think that would be able to allow the 2d art to mimic 3d behavior? In other words would there be any way that code could take these images and compile the slices, mask the REAL artwork images with it all, and make 3d collisions/shadows work? (Not 360 degree rotations or zooming in and out though). And if yes, would this be just as taxing as voxel usage? I'm expecting to take decades here, if this works. I want to steer clear of using polygons for my game hehe! [Edited by - Sylon on November 6, 2006 2:45:56 PM]

sounds like too much trouble than its worth...

sounds like you're trying for "Voxels"(look that up)

but if the camera is limited to fixed ortho positions... you can probably save a lot of work
maybe have a separate Voxel representation for collision detection from the actual sprite graphics?

Also, Voxel (or as you call it pixel-prices collisions in 3d) is kinda... overkill
you sure you can't just get away with having bounding box collisions, just make the boxes smaller than the tiles for added detail?

Hi guys!

Ultimape--

Does that mean you think the method will can work, only that it would take a lot of work to complete? And do you mean it would take the programmers a lot of work, or the artists, or both? Because if it's just the artist, I'm more than willing to do all that work LOL!

Anon--

Yes the camera in my game would be in a fixed ortho position and I was considering making a voxel mask to represent the collisions of each 2d image but someone told me, like you, that they're "overkill," anyway. So do you think this RGB method is "just as overkill" as using voxels anyway? Because if I could use voxels to make the masks I would be happier!

I read somewhere that voxels are better than polygons for a few reasons, but that polygons are majorly supported by 3d graphics cards and whatnot, while voxels aren't, which is why voxels tax the computers.

Anon, I was also thinking of using bounding box collisions, smaller than tiles, and cylindrical/spherical bounding "boxes" (though I heard they are harder to code), but then this would mean to toss out any irregular shapes...If it's a last resort I could consider it--but I want to learn my options.

My goal here is to figure out primarily, if my theory is valid. 1. Can a game be made like this? And if so, 2. Would it require too much computer power? And 3. Would the programmers have to do too much extra work? Or just the artist?

Also, I've thought about using voxel models themselves as the artwork, and I think that idea is also out (it would be too complicated to explain why unless someone wanted to know, but it has to do with aesthetics).

[Edited by - Sylon on November 6, 2006 7:06:31 PM]

Hi Traveler! Thanks for joining in.

About the pixel-precise collisions. Yes, I've thought about this through and through for an isometric 2d game. Once again I don't know code or coding languages but I have a vague idea of game mechanics. I assumed the kind of trouble you're pointing out here was already tackled but I'm just a little too hasty. I realized how tough it must be to code.

There is a game called "Head over Heels", a remake of a classic, made by a team called retrospec http://retrospec.sgn.net and if you download that game you'll see that the single programmer was able to calculate 2d isometric collisions in 3d space. The characters can jump all around each other and objects. If there was a tree (there isn't though), the character would collide with the trunk of the tree, not as his sprite touched the tree sprite (leaves or branches or whatever). The thing with HOH is that the objects all have cubic bounding boxes--the boxes were pixel-precise but...how I'd say, I guess...the boxes weren't true to the form of the 2d image. So yes as you've said, it's possible, and you're right I bet it's difficult but I've seen pixel-precise collisions work with cubic bounding boxes so I'm spoiled. I'm wondering if there's a way to take it to the next level--pixel-precise bounding "boxes" that conform to the 2d image how we'd like it to, instead of just cubic or simple cylindrical bounding boxes.

About the translations of the sprite, wouldn't it just be a sprite offset function? I know in HOH height was apparent. The problem was that nothing was sloped, just all cubic blocks the characters would stand on/jump on. I'm gunning for slopes in my objects.

About the shadows. In HOH as well, there were precise shadows coded. The problem was that they bent only around the cubic collision boxes of objects, but they fell and rose in height accordingly in 3d space. The shadows were transparent images that followed the character and were offset in position when they hovered over an object with a different height.

So I was thinking that say, if a single pixel of a shadow image collides with a pixel with RGB values assigned to it, that pixel of the shadow would be offset, just like in HOH. So blue values signify height. If a shade pixel was on a pixel with a blue value of 15, then the object moved over a pixel with a blue value of 120, the shade pixel under that object would be "told" to offset by however many pixels upwards. This way it would "jump" from a low height to a higher height instantly.

Besides the fact that this all is difficult to code, is any of it impossible to code (because I don't know)?

Let's look further about collisions in the RGB model.



Remember I arbitrarily chose increments of 15 for the RGB value differences between each pixel.

In the bottom left, there is an arrow symbolizing a sprite moving towards the cube. As soon as the sprite's own bounding box collides with the pixels that have a blue value of 30, it should stop moving. In other words he is traveling on pixels with blue value=15. So anytime he comes into contact with a pixel of a greater blue value than the one he is currently on, he *should* stop.

Another example. On the top of the cube the blue values are 120. Let's say the sprite follows the arrow direction towards the cliff edge (along the x [red] dimension). All of its green values will be the same as it follows the arrow, but as it moves, its red values will change. At the cliff edge, the red value is 180. As the sprite continues moving past that, the NEXT red value in sequence is 195, which is down below. Those pixels with red values of 195 have a blue value of 15. The sprite moving along that x dimension would collide with pixels that have a change in their blue value (from 120 to 105), and since the next pixel in red's sequence (195) is down below with a blue value of 15, that is where the sprite should fall. Calculating gravity would be another issue I suppose.

Seriously to me this sounds like it means much less work for coders and more for artists, as long as it works. I hope.

I've been looking for someone to verify to me that this is a valid theory but, I guess, maybe I should look for someone who'd like to test it? Maybe all it needs is some testing?

[Edited by - Sylon on November 7, 2006 11:53:54 AM]

Honestly it doesn't look impossible, just fairly difficult (especially for someone who doesn't know any programming languages).


The colored blocks you're posting images of are voxels. If you want to do slopes (not just different heights) then it's either voxels or 3D texture mapping. If you're ruling out voxels, then you'll probably just do linear texture mapping. At that point, it'd probably be easier to just switch to 3D and maybe constrain the camera angle.

Collisions will be a programmatic pain in the ass. First of all, I'd be very careful in your map design. The example given about the tree can be avoided if you make sure there are no hills as tall as trees directly beside trees. Your example about the crevice is very difficult. 3D programmers have long sought after an easy way to do overhangs with collision detection, and you're wanting to do it isometrically. I would personally make the crevice tile a special case tile that actually has three tiles: one for the top of the tile, one for the roof of the crevice, and one for the floor of the crevice.

This post has gotten me thinking about a very special (and very computationally expensive) kind of isometric engine; a voxel isometric engine. Basically it would be layer upon layer of tile. You could effectively dig down through the ground that way, unearthing new tile layers. Might be sweet!

Anyway, what I'd like to know is: is someone going to code this for you? Because that person should be intricately involved in the design of the game. Artists sometimes don't realize the complexities of programming things like this

Traveler--

Yeah I've played iso games with that kind of design. Well, I guess, if I was to edit maps with "my method", it would simply be that there would be a bottom layer in each room, of just flat tiles. Above them would be cubic dirt or rock objects which you stack on top of each other to make hills and mountains, and at the top of those stacks are objects shaped like lumps (for hills), or stones, grassy tiles, etc.. And within each stackable object will be these invisible RGB masks that tell the computer what their xyz dimensions are.

The computer will draw the objects from back to front, and apply the offsets.

That's my idea anyway, I guess!

Funky--

You mean the individual pixels in the multicolored dioramas are exactly how voxels are made? Voxels use RGB representations for space?

I guess the bottom line would be that, with the crevice example and all, it would be as if every single pixel in the game was its own "tile", that gets drawn from back to front within the larger tile that it's in (say a 32x32 tile). The 32x32 tile would be the one that the level designers place in the game. I can't seem to get around thinking the RGB values should be enough to tell the sprites what is happening and where they should jump to (offset in height) or stop. Maybe I just need to learn to code.

What would be the most efficient way of learning what I need to for me to study this theory? Should I learn an ENTIRE programming language or just parts of it?

Funky I was planning on doing all the art first for a few decades and then finding some programmers to help me.