I am in a maze of twisty little UI elements, all alike.

I'm looking for something that "automatically" works in any situation.

This is a good thing to look for, but be aware that sometimes this is a Do What I Mean problem. That is, for any given situation you have some intuitive expectation, but in fact there may be no simple, systematic rule that encapsulates all your expectations.

Example: I wrote a 2D game with a ball in it many years ago and initially had a very simple collision system, then across the game's two months of development the collisions got more and more complex as I found more and more obscure cases where I knew what behaviour I wanted and wasn't getting it. In the end my collisions ended up depending on ball velocity, the local geometry of the thing the ball hit, gravity and friction and required processing multiple collisions per frame in cases where a fast moving ball bounced off multiple objects in a single processing step.

I've just started looking into improving performance on my current (3D) project and, in the process, have learned about draw call batching. It is good. It makes things faster.

The one trouble is that in order to batch draw calls you need things to have the same materials. This is no problem in theory, but quite a few of the objects in my game have textures which vary at the borders. Imagine, for example, a wooden crate reinforced with metal strips along the edges and at the corners. The way I'm doing this kind of thing at the moment is to render a suitable texture at runtime (but once only) using 2D graphics to put the edge and corner textures in the right place. Which causes problems for batching...

The naive approach results in a situation where two crates of different sizes have different materials. I can be a bit cleverer about it and put the textures in a texture atlas, but if I do that then every time a new crate appears with different dimensions I have to add that to the texture atlas too and update all the other materials in the level. Ouch. A third approach would be to have the edges of the crate as separate objects, but that multiplies my game object count by nine, which I'm obviously not delighted about.

This must be a pretty standard kind of problem. What do people do about this sort of thing?

You can't get anything by paying gold farmers that you wouldn't be able to get by simply playing more. It's the same with tf2, lol, and magic.

Well, except Magic. I assumed I'd misunderstood your earlier post, but apparently not.

To be clear: Magic the Gathering Online uses a pay-for-unique-advantages business model. Starting players begin with no cards (or a pathetic number of bad cards) and the only way to get more is to part with money. To be clear: there is not a way to accumulate cards through play. (There are competitions with prizes, but since you pay to enter competitions these at best represent discounts.)

Magic is a worldwide game but has a very large US playerbase, so it's an example of a mutliplayer game where paying money for significant (even critical) in-game advantages is normal and accepted.

(The case against would be that only the existence of the paper game makes this model commercially viable. Could be true. I don't know enough to be sure.)

It's managed to remain an unspoken and very well-respected rule in multiplayer game dev that people shouldn't be able to directly or indirectly buy a unique competitive advantage.

<cough> Magic the Gathering Online

(Not that I recommend anyone follow their lead...)

I made a big spider robot thing!



(Click for video.)

Neat multiplayer concept - I like it!

Any chance of a video, or is it too tricky to capture?

Even if you release under a company name you can always put your name in the credits.

Programming is good for one's modesty I find.

Spending all day exploring the profound depth and diversity of one's own stupidity has that effect.

Today's bug rating: 

requires a version of autoconf newer than is present either on os x or in macports

Ah, that's the bit I hadn't considered. Ugh.

Not bad for an hour's work.

You did all that in an HOUR? Sounds like at least a day's work to me!

Code:

sudo ln -s /usr/share/automake-1.10/ /usr/share/automake-1.11

Whaaat?! Why would anyone do this?!

You can log a bug report in the hope of saving others time, though.

Yes indeed. (Did that before posting here!)

Thanks for the link.

I wonder if I can get away with invoicing them for wasted dev time?

Lone Survivor Indiecade teaser trailer:  http://www.youtube.com/watch?v=FI4drsfxdqE 

Very nice indeed!

The graphical style in particular appeals to me a lot.

[Quaternion.operator *]

This is one of those threads I'm always really reluctant to post because I'll end up feeling really silly if I've got it wrong... but it's worth it just in case I can save someone else a week's worth of nightmarish debugging.

OK, so the Unity docs for the Quaternion * operator say:

Quaternion.operator * 
static operator * (lhs : Quaternion, rhs : Quaternion) : Quaternion

Description
Combines rotations lhs and rhs.

Rotating a point first with lhs and then with rhs is the same as rotating the point by the combined rotation. Note that rotations are not commutative: lhs * rhs does not equal to rhs * lhs.

I'm writing a fairly complicated game at the moment with lots of 3D transforms in it and having spent a week failing to get hinges working properly I eventually get a little suspicious and run this:

Code:

print("Test 1 - " + (rot1 * Vector3.up));
 print("Test 2 - " + (rot2 * Vector3.up));
 print("Test 3 - " + ((rot1 * rot2) * Vector3.up));
 print("Test 4 - " + (rot1 * (rot2 * Vector3.up)));
 print("Test 5 - " + (rot2 * (rot1 * Vector3.up)));

And the output looks like this:

Code:

Test 1 - (0.0, 1.0, 0.0)
Test 2 - (0.5, 0.8, -0.2)
Test 3 - (-0.2, 0.8, -0.5)
Test 4 - (-0.2, 0.8, -0.5)
Test 5 - (0.5, 0.8, -0.2)

So do I need more caffeine this morning, or is that actually the opposite of what the docs say?

Erin Catto's Iterative Dynamics with Temporal Coherence is worth a read. Although you mention his GDC 2006 slides (which I'm not familiar with) and having read the Box2D Lite source, so I'm not sure how much of it will be new to you.

Nobody REALLY knows what the hell it is

That's really not true!

However much corporations may sometimes get the wrong idea, the basic idea is really very simple: get something really, really simple working and then move from one working, stable release to the next, adding features in increments that are as small as possible.

And don't get me fucking started on embedAsCFF="false"

Oh yes. So very seconded.

When I first ran into that problem, my reaction was pretty much: OK, so they made "broken" the default and you have to select "make this not broken" manually? Nice.

Yes, I agree with that part, however I feel he is oversimplifying what an engineer does somewhat. Yes, engineers often do more practical work, but they still have a lot of hard maths to contend with.

Just in case there were engineers reading who might actually have been offended, I should probably clarify that that was a joke. (It's a kind of universal stereotype that mathematicians see themselves as smarter than scientists, who in turn see themselves as superior to engineers, who themselves look down on arts students.)

The point about the "software engineering" label is that in the corporate sphere it's a label best loved by people who do not themselves write code and therefore serves as a kind of warning sign. But of course your mileage may vary.