Librarys needed for a (2D Graphics + 3D Logic = 2.5D?) Game

Newbie & Debugging Questions
#1

I wish you a pleasent Morning, Evening or Day whatsoever…

My name is alex and I’d like to introduce my little game that Im dreaming to make someday.
I finally decided to use Java, cause i like the object oriented style.
I also thought about using C++. I have 2 books (Focus on SDL and Programming Role Playing Games with DirectX)
and great interest in having my game run on a GP2X :slight_smile:
Still, C++ seems to much of a hassle :frowning: so I decided to use Java instead.

Now that I have a language, it would be nice to have some libraries which could help me a lot,
but exgtremly cluesless what to use, because I dont know what I exactly need :slight_smile:

At first, my choice seemed so obvious: a 2d game library. But when I looked through some librarys (Slick, JGame, GTGE,…)
I rethought my decision… what do I really need? Not that I dont know what I want…
but I really dont know what i need… or how to do it :confused:

You probably know Legend of Mana* (PSX), Saga Frontier (PSX) or, a more popular one, FFVII** (PSX, PC)
If you dont, feel free to look up some screens on the net. Youll find some for sure.

So, when you look at the graphics of the various levels where you can
freely run around a normal map (FFVII: except world map), you will notice, that there are
no tiles, only a nice handdrawn background, but somehow, it gives you the feeling to run on a 3D surface.
Gameplay will be like Zelda, you see your enemy and slash him etc…

Thats exactly the thing i want to do, but i really don’t have a clue how.
The first Idea which came into my mind, and sadly the only idea, is:

  • to draw that level, no matter how big it is.
  • scan it,
  • display the picture,
  • try to manualy fit a invisible 3D layer on the picture to simulate the heights and stuff,
  • and finally: letting a 2D sprite run around this invisible 3D layer.

Well, thats my little Idea and thoughts so far…
Id be glad and gratefull if anyone could help me out and bash me into the right direction :slight_smile:
Any recommendation for any librarys and/or logic will be greatly appriciated.
(Physics and Eye Candy would be nice too allthough im not familiar with those topics :/)

thanks for reading

*Note: Legend of Mana doesnt fit as good as the others into my idea of what i want to do,
cause the key difference is that Legend of Mana has a fixed Camera Angel, thus,
the Main Character Graphic doesnt resize or changes in Size at all (depending on the level).
**Yes, FFVII has 3D Models for their Characters. Imagine it would be a 2D Sprite
and youll know how Saga Frontier looks like.)

#2

hmmm u mean games like silver or FF7 that the background is just an image and there’s this 3D character running in it?

those are 3D games with a 2D background…

#3

So do you have any library recommendations?

#4

If you want to change the camera angle, then you probably have to do everything in 3D. JavaMonkeyEngine seems to be one of the better and more importantly, quite active lib. HOWEVER - as most people in this forum with some experience will tell you - start simple! If you are just starting out with coding Java game, then think PacMan=complex and tetris is getting you close to simple. So stick to 2D to begin with. (I have been doing some hobby game coding since ~1980 and still haven’t really entered the 3rd dimension). Slick2D is in my opinion one of the better libs to start out with, cause it is really focused on simplifying and letting you focus on game logic. You could maybe do FF in top-down 2D a bit like Kev started off with (remove the multiplayer part of that project). Just my 2c.

Good luck!

#5

You don’t need to do anything with 3D. What you need is depth.

The easiest way to go about this would be to divide your graphics into:

  • a background. This contains the stuff far far away, stuff that are only there for looking nice.
  • objects. Anything that can be interacted with, be it bumping into them or just standing behind them

These objects will have Z-values (depth). When you get to the drawing process it will work like this:

  • draw the background image
  • draw all the other images (player, enemies, objects) sorted by their Z-values

Regarding the background image, if you want a picture that is hand-drawn then you will probably have to draw it or get it somewhere. If you’re good with drawing seamless tiles you would perhaps only have to draw the basic outline of the background and fill in the rest with the seamless tiles.

#6

jojoh:
The Camera Angel will not change… Well it depends on the level,… if you draw a background from a different perspetive
then theres a diffrent “camera angel”. thats what ive meant.

What I am planning to do is to start simple like youve said.
Id like to have a good solid and well thought through base… from there Ill extend from there with features…
My first Main Goal will be: to let a 2D Sprite run around a 3D surface
I think thats simple enough…

Dont get me wrong… I also thought about starting with a small game too… Ive read many timea about this topic… making a game…
but I just cant “force” me to program tetris… I dont realy want to do that… so it wouldnt be a good idea to even start like that…
instead… ill plan my game very well and start small and let it get bigger in small steps…
always keeping my eye on beeing flexible and extendable…

malberts:
Graphics divide thing: sounds good! i think i already noted that somewhere but forget about it :slight_smile:

Z-value: that sounds interesting, but i dont thinki cant give the player the same feeling as if it where
a real 3D ground he’s walking on, jumping or kicking a football on… I can just make so much more.
but drawing sorted by the Z value sounds nice,. ill remember that… thanks

Do you have a link to seamless tiles? it really sounds interesting but never heard of that,
on another point: I ll plan to make all the graphics by myself… maybe replace them with
professional ones later… but ill plan to get better drawing skills anyway =)

THANKS very much for your comments so far =))

Any special (game) library recommendations?
(It takes a long time to look into each so i thought I just ask…)

#7

The Z-values should only be used by the rendering part of your engine. Determining the Z-values is a different matter.

You don’t have to do any 3D coding for the scenery. It’s going to be a bit pointless to create a 3D engine thats not really going to use much 3D. Instead you must simulate 3D. Use only the necessery effects and translate them to 2D, if you really need to use 3D-specific code.

You can achieve the 3D effect by using these techniques:

  • collision masks. Every sprite has an extra black sprite that is not drawn. This black sprite is like the sprite’s shadow at midday. Now when you get to collision you can check whether the shadows collide. Old isometric games like Age of Empires 1 used this technique. Check the app Game Maker if you’d like to know more about the implementation of it.
  • screen regions. The late old point-and-click adventure games can also aid you. They used regions to define what areas are in front and behind the player, what areas can be used/looked/taken/etc. Also regions were used to simulate the player getting closer as he walked down by drawing horizontal regions across th screen. Everytime a lower regiom is entered the player is scaled a bit bigger. The problem with pure regions is that the regions map is stored seperately from the normal map and object data. So you’ll need to go and draw all those regions. Check out Adventure Game Studio for more info on this.

How much 3D logic do you intend to use? Because if you really need to do so many 3D-only things then it probably would be better to create a 3D engine for what you want to do. But I’m pretty sure that you will be able to simulate the 3D effects without needing to do anything in 3D.

Here’s a tutorial on pixel art which covers seamless tiles: http://mirror.motherhamster.org/tsugumo/default.html but they’re more suitable for SNES-like RPGs.

#8

But isn’t it much harder to simulate 3D than to actually use it? And if I use it, it would give a more accurate feeling if somethings happens around the playable character… for instance something falling appart or a football beeing shot around.
I really really would like to have physics in my game, thats the main reason I want to do it in 3D.

Thanks for the tutorial, but I think Ill stick to hand drawn levels instead of using tiles… (yea i know… much more work).

#9

Well that all depends on how much 3D logic you need. If you really need complete 3D support and full 3-axes physics then you must use 3D. By simulating I mean making the game looks like things are happening in 3D, even if the code you use is not the way a 3D coder would use it. You’ll have to decide how important real 3D is. You should try to read up on isometric type games. They can simulate quite a bit of 3D stuff without being in real 3D mode.

Drawing is more work, but it always looks better than tiles ;). It’s just a matter of time, resources and re-usability.

#10

for a 2.5 Dimensional rendering, JAI/JIIO has created PerspectiveTransform’s that enable perspective transformation on usual RenderedImage. Here’s a sample code I use to make a rotation effect :

/***/
    float[] scale = new float[]{1f, 1f};
    double[] scale_step = new double[]{0.1, 0.1};
    
    /***/
    public void drawLogo(Graphics2D g2, String logo, Dimension size, int hpos, int vpos, boolean fx) throws InterruptedException {
        Sprite logo_sp = getLogo(logo, size);
        Image src = logo_sp.getImage(this);
        GraphicsJAI g = Sprite.createGraphicsJAI(g2, this);
        g.setRenderingHints(Sprite._getRenderingHints());
        // screen postioning
        Point translate = new Point(0, 0);
        // (...)
        g.translate(translate.x, translate.y);
        if(fx) {
            float[][] scaleRange = new float[][]{{-1f, 1f},{0f, 2f}};
            // rotation effect
            if (scale[0] <= scaleRange[0][0] || scale[0] >= scaleRange[0][1]) {
                scale_step[0] *= -1;
            }
            if(scale[1] <= scaleRange[1][0] || scale[1] >= scaleRange[1][1]) {
                scale_step[1] *= -1;
            }
            scale[0] += scale_step[0];
            scale[1] += scale_step[1];
            if (scale[0] == 0.0 || scale[1] == 0.0 || scale[1] == scaleRange[1][0] || scale[1] == scaleRange[1][1]) {
                return;
            }
            // horizontal scaling
            AffineTransform tx = new AffineTransform();
            // perspective transformation
            ParameterBlock pb = new ParameterBlock();
                    /*Interpolation interp = new InterpolationNearest();
                    pb.add(interp);*/
            pb.addSource(src);
            float decalY = 0f;//(scaleRange[1][1] - 1f) / 2f;
            // x0,y0,x1,y1,x2,y2,x3,y3 quad coords clock-wise starting at (0,0)
            float y0, y1, y2, y3;
            y0 = (1f - (scaleRange[1][1] - scale[1] + scaleRange[1][0])) / 2f * (float)size.height;
            y1 = (1f - scale[1]) / 2f * (float)size.height;
            y2 = (1f + (scale[1] - 1f) / 2f) * (float)size.height;
            y3 = (1f + ((scaleRange[1][1] - scale[1] + scaleRange[1][0]) - 1f) / 2f) * (float)size.height;
            if(scale_step[1] < 0) {
                float switchY0 = y0;
                float switchY3 = y3;
                y0 = y1;
                y3 = y2;
                y1 = switchY0;
                y2 = switchY3;
            }
            PerspectiveTransform ptx = PerspectiveTransform.getQuadToQuad(
                    0f, 0f,
                    (float)size.width, 0f,
                    (float)size.width, (float)size.height,
                    0f, (float)size.height,
                    0f,decalY + y0,
                    (float)size.width,decalY + y1,
                    (float)size.width,decalY + y2,
                    0f,decalY + y3
                    );
            ptx.scale(scale[0], 1.0);
            if(scale[0] < 0.0)
                ptx.translate(-scale[0], 0.0);
            pb.add(new WarpPerspective(ptx));
            System.out.println("Target Quad");
            System.out.println((decalY + y0) + " " + (decalY + y1));
            System.out.println((decalY + y3) + " " + (decalY + y2));
            System.out.println(ptx);
            RenderedOp warpOp = JAI.create("warp", pb);
            RenderedImage warped = (RenderedImage)warpOp;
            g.drawRenderedImage(warped, tx);
        } else
            logo_sp.draw(this, g, new AffineTransform());
        g.translate(-translate.x, -translate.y);
    }

The ParameterBlock must add the WarpPerspective and compute the transformation with JAI.create(“warp”, (ParameterBlock)pb); where the returned RenderedOp can be casted to a RenderedImage and drawn to the screen like a bufferedImage. :smiley: the QuadToQuad perspective transform is the easiest : specify the source image Rectangle and give the destination transformed image Rectangle coordinates and you’re on !