f13.net

So, I ran into a rather large issue in my hobby project. I tried to make a fairly decent map and ran into 2 problems:

1: The drawing performance is crap
2: If you put a hill in the middle of a map, you can't see behind it. (Reminder: my game has a Tactics Ogre style map)

I was wondering about #2 for a while, then I realized that in every game I could think of the way they avoid this is the bottom part of the screen is always lower than the top part. High ground is always towards the top.

Now, I want my maps to be largely symmetrical, so that wasn't an option.

So I began looking into doing 3D stuff in Java. I spent a few hours looking into Java3D, it appears to be kind of crappy, with a bunch of scene-graph management garbage that I don't need (or want) and it lags behind OpenGL. I got bogged down trying to figure out how to move my eyepoint properly and said screw it.

Now I'm looking into JOGL, which is a very thin wrapper around OpenGL. It supports extensions, shader language, etc, and is really as thin as you can get. All the methods have the exact same names as OpenGL and it is not object oriented in any way. (Yes, that's a good thing in this case)

The demos are impressive - nice performance with real time shadows, dynamic lighting, etc. Plus I already know OpenGL. (Although it's been 5+ years since I've done anything with it)

So it looks like I'll be converting my sprite based map into a fully rotate-able 3D extravaganza.

FYI, they avoid #2 by having the camera at an angle to the ground, and have every hill with a slope less than that angle, or else with a peak small enough so that it doesn't overlay with the tile behind it.  Another option is to allow rotation of the camera, and leave just enough of any figures poking up from behind a hill so that you know to rotate it.

Glad to see this is still going on.

I myself tend to use OGL in my graphics projects, because I'm familiar with it from school.  But I tend to write in C/C++, so I don't need the special wrappers like Java does, nor any pre-conceived ideas of using some built-in graphics lib.

Alkiera

JOGL is basically a very thin wrapper for OGL, it has a class classed "GL" that just has every GL method on it. It's not object oriented in any way.

It's funny because as I look at screenshots of isometric 2d tactics games, they all use the strategy of having the low ground at the bottom of the map, to avoid occlusion problems. Sometimes they do something sneaky like have a big pillar in the foreground but for the most part the topography is always high points towards the top.

I got as far as making 2 fairly distinct armies and an ok map. It has some water, two bridges, some hills, etc. It's pretty playable, although not very fun it does already take some strategy.

Army 1 has some splash damage ranged weapons and some flying crossbow guys, which have good offense if you can position them but have some negatives (splash damage hurts allies and ranged weapons have a minimum range req). The other side is pretty straightforward offense with no ranged attacks and less overall mobility. So the basic idea is player 1 tries to set up a fairly defensive position and control space while shooting from behind lines, while player 2 tries to break through.

Stupid question:

Last I saw, your game was using (I believe) rectangular icons to represent the armies.  For the final, are you planning to stick with the rectangles, or do the units as sprites or polygons?

Probably going to stick with the rectangles. It will just be 3D rectangles now. There is no way I can create sprites or 3D models in any large number.

Ah, 'Programmer Art'.   I'm well familiar with it.  I've made quite a bit of it, myself.

Alkiera

/em signs up for beta

Are you diametrically opposed to using a game engine of any sort? T2D would be an amazing baseline to use for a game like this, and there are several tutorials already available for RTS style games that would adapt nicely. If you are moving to a different environment already, might make sense to take a look.

I think he was doing this to try to learn Java.

No, I know Java very well. It's my day job. I also know C/C++ and Torque. (I own a license, although I haven't looked at T2D much) I am not using T2D because I don't want to build on an existing engine. I want to write my own.

It would be faster to use T2D, and probably better as well, but this is a hobby project. I just like writing things from scratch.

I seemed to remember you saying that, which is why I wanted to confirm!

The main reason I brought it up is that your work so far would make an excellent demo for T2D, and we're in the process of selecting the GDC demo's we want to present, so it made me want to ask!

The fact that all my artwork and sound effects are cribbed from various places would probably make that a bad idea anyway.

If it makes you feel better, I have been dissatisfied with the camera in every tactics game.  In my opinion, you could get away with the old four-position rotation scheme.

Four position rotation was actually exactly what I was thinking. I will probably do more so I can mess around on a debug level but as far as for the end user being able to swing around to one of 4 vantage points sounds fine, maybe with a bit of zooming as well. Especially if the underlying map is basically grid based, there really isn't any reason to view from more than 4 angles.

Random update: Sp JOGL seems pretty good. I know OpenGL but it's been 5+ years since I've done anything in it, but it is coming back to me.

I had a map in 2D before that had 3 levels with brick, water and grass. Now I have the same map in 3D with green, blue and grey blocks. It looks a bit funky because the normals on my bricks are weird and each brick face only has 2 triangles in it, so the shading looks a bit weird. (Rather than a smooth surface it looks like a bunch of individually lighted bricks thrown together)

I also have a rudimentary camera working, can zoom in and out and pan around.

In a couple of days I should have the map looking somewhat decent. Then I have to put the unit markers on the map again and then do all the 2d stuff like the cards and the battle screen, although I will probably change it to be more 3d-ish by having the two guys who are battle sort of turn and face each other a bit or something like that.

I always made blocks out of quads in OGL, instead of triangle pairs.  Quads are easier to texture, too, and might help with your lighting issue.

I also can't recommend using display lists for your blocks enough.  That way you define them once for each different block, and the video system only has once copy of the definition, no matter how many are actually on the screen.

Alkiera