Wyrframe

Eclipse; an editor and build-management environment.

 

JVM: Java Virtual Machine: the program, implemented differently for different platforms, that runs the java bytecode created by the compiler.

 

JRE: Java Runtime Environment. Usually the Oracle or GNU implementation. Contains a JVM and the standard library implementation, but no editors or compilers. It's meant to provide a complete but only sufficient runtime environment.

 

JDK: Java Development Kit: the JRE, plus a compiler.

Your game state should be fairly simple to encapsulate; if it isn't, you should do that before you attempt any sort of AI. The complete representation of a board game's state should be a simple, relatively shallow object (ie. containing at most some arrays of basic data types) with a copy constructor.

 

For instance, a checkers game can at its simplest be represented with three 32-bit fields; the 8x4 valid board positions is 32 places, and the three fields store black's pieces, red's pieces, and kinged pieces. Your AI will need this "gamestate" object to evaluate options, and if your AI is recursive (some not-mutually-exclusive alternatives being strategy-based, heuristic-based, and table-based; but you can combine all four types easily) it will need to make at least one copy of this gamestate to recurse upon and evaluate its choices.

That "small issue" is happening because you haven't sorted your transparent objects to be drawn from back to front. You're drawing the one in the foreground first, and even though it's transparent there, it's still nonzero alpha, and so it makes writes to the z-buffer. When the one behind it is drawn, it is not drawn "overtop" of the nearer geometry.

While I'm mentioning it, opaque objects (those with no alpha whatsoever) should be sorted to draw from front to back, to take advantage of Z-occlusion, instead of being repeatedly overdrawn and wasting shader cycles.

Edit: filled in the rest of the tiles, including dots to visualize the underlying data. This should provide a good illustration of how it all fits together.

Last edit: added some more desert tiles to show more transition logic. And it's kinda fun drawing such lo-fidelity tiles.




So note: of the 81 possible combinations (3^4), there are 3 tiles which need no extra rotations (all grass, sand, water), 3 tiles which need only one extra rotation (two values, opposite corners, as at row 3 column 2, above), and 19 tiles which need 3 extra rotations, but some of those are flips of others (I'm not doing the math on it; in the second demo, above, you can see that row 1 column 4 is a flip and rotate of R2 C3, which itself is a rotate of R4 C5).

Not bad, for 3 mutually adjoinable values. You can add additional tiles easily, though if you allow them adjacent to all three of these existing terrain types, your 81 tiles explodes to 243. If you want jungle, perhaps you can allow it adjacent to only grass and water, not sand, thus adding only 52 more tiles (that's 81 minus the already-existing grass tile, water tile, and grass/water transition tiles), amongst which you will again have lots of rotates and flips.

I followed wyrframe's advice, and I've more or less finished the transition from water to desert. This looks nice. I've also begun the grass to desert transition.

Example:

Um. I'm not sure you did, if that's the system you came up with. The technique HoM&M uses only works because they impose a few limits on terrain generation (that is, enforcing non-transitional terrain to be paintable in 2x2 splats). You can make a set of transitions for water bordering grass... but if you want to generate only 5 transitions for the sand-grass-water combination (plus rotations), you must enforce that rule.

If the terrain you are showing there is an example of the look you are after, then I suggest an entirely different technique: an offset tile grid, sometimes called "vertex-painted terrains".

You've been referencing (as linked in the original post) Artifact's terrain system, which works because they don't have "transitions"; they have their terrain layered, in a strict ordering, with all terrain types simply drawn transparently over whatever terrains underly them. This won't work for your demonstrated art style, so you might consider this article instead: http://playtechs.blogspot.com/2007/04/tileset-design-tip.html

As this article says, without constraints like HoM&M used, a square-painted terrain has to determine what tile to use based on nine tiles; itself and eight neighbours. But with vertex-painted terrain, every tile is determined by just four vertices; its four corners. You can get the exact same results (graphically) using only (# mutually adjoinable terrain types) to the power of four, instead of to the power of nine.

OverWind; you should look at how Heroes of Might & Magic does it. What with having 12 different terrain types, they have to get away with a lot of flexibility.

So what they did was, each terrain type only had one or two other terrain types they could transition to, but where two "incompatible" terrains are adjacent, they both use a transition tile to a common compatible terrain. Notably, only sand can be adjacent to water, and always fills its entire tile; it has no edge transitions to other terrains. Instead, water has edge transitions to sand. Wherever a terrain is painted adjacent to water, it uses its to-sand transition, and the adjacent water uses the to-sand transition.

To reduce the number of tiles they have to make, with any terrain other than sand or dirt (the two "common" transition terrains, which have no in-tile transitions themselves), you cannot have a 1-tile-wide line or single-tile peninsula; the terrain has to be drawable using overlapping 2x2 splats. This way, there's no U-shaped transitions, or opposed corners; only full fills, flat edges, inside corners, and outside corners. This means only 12 transition tiles for one common terrain, or 12+12+8 for two compatible common terrains (12 each, plus straight-edge transitions where both common transition terrains are adjacent)

Note here the grass transitioning to sand, and the water transitioning to sand. There's no full tiles of sand here.


Note in the bottom-right corner here the transitions from lava field to dirt, and then dirt to rough.

http://roguebasin.roguelikedevelopment.org/index.php/Category:Articles

Several of those articles are about dungeon/level generation, as specific to roguelikes, but easily adaptable to your medium. Just be creative.

I especially like "Abstract Dungeons"; it specifies how to divide level generation into several distinct steps, letting you add huge amounts of flexibility in each one.

Wierdly enough, it was nothing expected. Apparently ByteBuffer.allocateDirect() gives you a buffer in network-endian setup by default; I discovered on the LWJGL forums that I had to either use org.lwjgl.BufferUtils.createFloatBuffer() or call FloatBuffer.order(ByteOrder.nativeOrder()) on my buffer before passing it to OpenGL.

So... an endianness issue of all things. That was dash strange, but at least it's working now.

What you're implementing is essentially a cellular automata. Each cell will transition to a new state, based on its current state and that of its neighbors. Automata get a little more complex when you introduce supplementary data such as the "fertility" value you mention, but it's still possible. Let's assume you have a single integer value "F" for each cell in addition to its state "S". The F-value can have different interpretations depending on its state; say, for city tiles F would be population, and for farmland tiles F would be fertility.

In these terms, you need to define the transition function that takes as input current S, current F, and current S of each adjacent tile, and outputs a new S and new F value. Now, in whatever ways you like, you need to work out your rules and define the transition functions. Keep them simple, and have them generate a large lookup table.

Finally, because a cellular automata updates atomically from one step to another, you need to keep two copies of your grid; one "current", and one "updated". After updating, swap them, making the "updated" into "current" and vice-versa. Now you can have any number of worker threads running on your grid, in whatever order ends up being best optimized; they cannot interfere with eachother, because they all read from one grid and write to non-overlapping portions of another grid.