Bay 12 Games Forum

@laurimann:
I imagine that to do this smoothly on a sphere, you may need to rethink your coordinate mappings, since you'll always have issues trying to map a method designed for a 2d orthonormal basis onto a sphere (cf. Hairy ball theorem), although that's not to say that 2d methods are useless, since most of us tend to use and design around flat maps anyways!

I thought of two ways of circumventing this issue. This first one/two I documented here http://www.bay12forums.com/smf/index.php?topic=76404.msg1957246#msg1957246 (though the stuff I put there is very informal; also read Nadaka's post directly following). The idea break the sphere into an icosahedron, and define a locally flat coordinate system in each of the 20 sub-triangles that doesn't have issues cropping up with poles and such. With the (r,c) coordinates I set up it is possible to determine the coordinates of all of the neighbors of a triangle grid without branching logic (unless the triangle is on a triangle boundary, but that is easy to determine as well), and it is possible to store the triangle grid data in constant-length arrays.

However, the triangle method is simply a different way of storing 2d data on a sphere that has nicer symmetries than other methods of putting data on a sphere. To actually solve the issue of plate tectonics however, you still need to deal with coordinate mappings, which I got around by simply reposing the problem as simulating plate tectonics on 20 separate flat maps that have boundary conditions imposed by the neighboring sub-triangles (i.e. how fast the plates should be moving, how much material is being added/subtracted, etc...). This method has the benefit of using the same exact mechanics (and if you're clever about isolating your coordinate system from your math, the same exact code) as plate tectonics on a 2d grid (but using triangles instead of squares), so methods could transfer easily (in theory) between 2d and 3d surfaces that can be broken up into a triangular grid (I can imagine fantastical objects like ringworlds with plate tectonics...).

An alternative method for dealing with the issue is to completely scrap the idea of using 2d methods on a 3d object and instead think of grid cells as points floating in 3-space that simply constrained to lie on a 2-sphere using constraints from classical mechanics. That is, instead of each grid point only having a 2d velocity, have a 3d velocity, and if the direction of this velocity vector is not tangent to the surface of the sphere, then apply a force on the grid point to bring the velocity back onto the sphere. You will still need to come up with a discretization of the sphere surface (such as the icosahedron discretization) but then there are no artifacts due to choice of coordinates (although there still might be lingering artifacts from discretization since it is impossible to uniformly put a grid onto a sphere, but I feel triangle artifacts are less jarring than rectangular artifacts since triangles form hexagons and pentagons, which feel more natural than right angles...). The previous 'z-axis' of your work can then simply be reinterpreted as perpendicular depth, and can be continued to be treated in much the same way (since the sphere is locally flat and so over small scales we can ignore curvature effects).

@AlStar:
Responding to your points in order,

This is actually a bit of dark compiler magic. Whenever you have identical string constants in a program, they are all assigned the same memory address (reference), so the == comparison works since they're all the same object. However, if you were to enter the string during runtime, then it would not work.

"Knight" is not a variable name. It's a string constant. Y is a variable name.

The benefit of making things arrays is that it's more easily extensible, i.e. if you wanted more or less slots you can just change a single number (i.e. declare a final int numSlots), and there's a lot less copy-pasting of code.

It's just a bad habit to not give actual names to your variables. It decreases code readability which in turn increases time spent programming. Especially if other people need to read your code. There are cases when you don't need to give variables descriptive names (such as index variables, when the variables follow natural english (i.e. equals(x)), or when using commonly accepted abbreviations (such as v for velocity). Otherwise, it'll just make code a pain to read and debug.

As for a condescending attitude, blame it on the internet. Imagine me reading them not in a haughty tone but in a helpful tone. I'm trying to be as straightforward as possible, so I am indeed being quite terse and unapologetic, which more often then not comes across as condescending without the benefit of body language or intonation.

I don't think that K is actually important. Any sort of 'breaking up' of the rubik's cube into lower-dimensional stickers which preserves the original structure of the cube won't introduce new allowable rotations, so the problem then becomes exactly the same as solving the original cube without broken-up stickers. Also, note that in the tesserect puzzle, each of the squares on each of the cubes that compose the 3-faces of the tesseract are exposed, so there really isn't a natural way of turning these cubes into normal rubik's cubes that would preserve the original structure of the tesseract (at least none that I can think of).

I've always liked the simple, monochrome fonts without special symbols (the Unknown 12x12 tileset used to be my favorite before I got a larger screen. Anyone else like this set?), plus one of the muted color schemes from the wiki (still deciding on my favorite). The muted color schemes really help reduce eye fatigue, and the simple bold lines that make up most characters lead to a really simple, uncluttered view of the game.

Personally, I just really like that the ASCIIcode page 437 is so simple and abstract it makes it easy to see what's going on at a glance. I would have to agree that sometimes it is annoying that all dwarves of the same profession have the same tile, especially since dwarves of the same profession usually work in the same (or similar) areas, but I use Dwarf Therapist to deal with Dwarves on an individual basis anyways, so it's never been much of an issue for me. And as for multiple creatures having the same tile, for the most part the creatures that occur in Fortress Mode come back again and again, so it becomes easy to identify which tile is for which creature after a little while with a fort, IMO.

I have a feeling it's because you didn't declare leftPressed and rightPressed as volatile.

You also are using Thread wrong; a thread should either be constructed with a Runnable object (i.e. Thread myThread = new Thread(myRunnable)) or should have an overloaded run() function. Call myThread.start() to start the thread. As a rule, constructors should never be used to run anything but initialization code.

the ascii of 1-9 is 1-9.

The ascii value of 1-9 is actually 49-57.

Actually, int nLeave(); is a declaration of an integer using the default constructor. For example, Object myObject(myInt); declares an object myObject and initializes it with a constructor from Object that takes an integer.

It should be noted that it's alot harder to screw something up in c++, or c, than in Java.

And anything you do screw up you should be able to find much easier.

While indeed you could conceivably construe this statement and the meanings of "harder" and "easier" to make what eerr said true, for most purposes it's a lot easier to screw things up in C/C++, and finding things that have screwed up almost entirely depends on programmer skill and what debugger/IDE combo you're using, not on the language you're programming in.