Further to Mocsan's comment, try using no framework at all.

Indeed, if this Flixel vs Flashpunk game-off happens, I'll happily throw my hat into the ring for the third approach: just use Flash itself. For all but the simplest games it's really no harder.

Programming is all about code.  Focusing on what you're trying to do is software engineering.

You have to realise, I'm a mathematician by training. As such from my perspective "engineer" is a word for student who wasn't quite clever enough to study physics and "software engineering" is a word used by corporations to indicate to me that I don't want their job. 

That counts, right?

That definitely counts. I'd argue programming isn't even about code. In fact code holds programmers back initially because they worry about stuff like syntax instead of focussing on what they're trying to do.

Last week I was walking my daughter (who is 9) through the Unity code I was writing. She expressed the view that my function was "really confusing", so I asked her how she'd do the same thing in Scratch and she had this whoooooah moment when she realised it was basically exactly the same.

And before that was the jump from Little Big Planet to Scratch. But it's all programming.

it doesn't like two multiple declarations.

Not quite sure what you're getting at there (the code fragment you've posted is too small), but assuming you're trying to define an XML constant you need to make sure what you have is a tree. So more like this:

Code:

var myXMLConstant = <some_outer_node_you_may_not_care_about>
 <Area type="field"/>
 <Area type="swamp"/>
</some_outer_node_you_may_not_care_about>;

(Which is exactly what st33d's doing in his code example above, you'll notice. His root node is called "root", but yours doesn't have to be.)

I use only InitialCapitalStyle when constructing class names. The main reason is that I find myself slowed down significantly when I can't tell classes, variables, functions and constants apart easily. Therefore no underscores are used in class names.

Also, for most projects I try to keep the names of the most frequently used classes shorter but allow obscure ones to get much longer. So it's fine to have a class called MenuItemSynchronousCallbackData when it's only used in two places in one other class, but CharacterPositionAndRotationData is right out and will more likely get called CharacterTransform even though that's slightly less descriptive. (I used to go even further and would have called it CharTrans, but have since persuaded myself that this doesn't confer enough benefit to be worth it.)

Not so much with my developer hat on as my player hat: It doesn't matter what's still to come and what's broken and what isn't. What matters is whether the game is fun right now. If it isn't, don't release a beta. If it is, players will point out to you the things they want fixed (or changed) whether or not you've noticed them.

Also: good luck!

There's a page on saving and restoring in the wiki for the ODE physics engine, which is maybe relevant

Well yes, in that this is all the stuff I'd like to be doing if Unity wasn't a black box!

So connectedBody has its transform set twice, once to inform the physics engine of the rest state, and once to inform it of the body's (therefore the joint's) actual state.

Good plan, I'll give that a try! I'm hoping Unity won't generate collisions for the first ("rest") position. If it does, I'll have to jump through an additional hoop involving disabling the colliders until after the second position is set.

(I'll also have to hope PhysX doesn't defer all the ops and then roll them up into one, which has caused some spectacular crashes in the past when creating and destroying RigidBodies in the same frame... but if it does I'm doomed anyway!)

run a bunch of iterations after saving and let it "settle" before serializing it.

Good thought, but game positions do not in general "settle" in this way. Running an extra time step is as likely to increase dynamic activity as decrease it.

simply setting all the joint and body properties as they were should be sufficient

Have I missed something?

I use transform.position to set both objects in their correct places. Then I use anchor and axis properties to place the joint relative to one of the two objects. Then I join them by setting the connectedBody property to the other object. How do I then set an additional (delta) position and rotation to define how deformed the joint is? I don't see a way. (I can't do it by setting the object's springs and motors, because those only operate with respect to the joint's own degrees of freedom.)

@altwebid - The basic problem you have is that the perceived value of "ideas" is low. By far the most scarce resource in game development is competent programmers. On the rare occasions when you find programmers who don't want to spend all their time coding their own ideas they will usually want to work with artists who have game design skills (or musicians, although I haven't seen that happen much).

Even if you do find someone prepared to work with you, there's the question of how much of the revenue you'd expect to receive for doing none of the work. This will be difficult to negotiate given that you (presumably) won't be able to reveal the idea in advance of making a deal.

All that said, I wish you luck. There doubtless are good designs which never get made because their inventors cannot develop them. Hopefully you can find some clever way to make yours happen.

Correct...ish. It's possible to store neutral-state data for every joint which then allows you to infer the geometry of the deformation, but this leaves two problems:

1) Getting from the geometry back to the forces involved is a very hard problem.

2) Even if you know the forces on the joint needed to cause a particular deformation, it's not clear to me that there exists a way to deserialize that data back into the state of the physics system.

So, for example, suppose I have a static wall with a pole sticking out of it at ninety degrees. This pole can rotate freely about the axis perpendicular to the wall. A plank is attached to the pole, which in its initial state is flat relative to the ground. A heavy object then lands on the plank from above and slightly to one side of the pole. Then, a fraction of a second later, the game state is serialized.

In the resulting serialized state the pole will be below its default position by (say) 0.01m and at an angle of -5 degrees. I can't just move it back to its default position, because doing that will have it overlapping the heavy object and the recorded angular momentum of the plank will now be wrong. However, if I leave it in its deformed position I have no way to say "you are unhappy here and want to spring back up", so I end up with a bent pole.

(In case you're curious, my investigations so far suggest that my only recourse is to turn the number of physics iterations up really high and then "correct" all joints to zero deformation after deserialization, hoping that the deformations were small enough for this not to break the game completely. This is a terrible workaround for multiple reasons.)

I have a tricky problem with a Unity project I'm working on. (But this problem is more widely applicable than just Unity, I think.)

Imagine two objects connected by a joint. Gravity acts on both and one is resting on the ground, so the net effect of gravity is to deform the joint slightly (because PhysX physics simulation does not maintain perfect rigidity for joints).

Suppose that I want to serialize (ie. encode) such a system and later reconstruct it from the serialized form. This presents a problem: I know the positions of both objects and the state of the joint, but the deformation of the joint caused by the forces acting on it isn't recorded anywhere. And in fact it wouldn't help if it was, because there is no way in the API to say "create these objects and these positions with a joint between them that is already under this compression force".

So what do I do here? I can't simply deny the player the option to save position any time there's any physics going on (which is basically all the time). On the other hand, I can't allow saves which don't restore correctly when reloaded. Repeated saving and reloading could then result in some severely mangled objects. Has anyone solved (or worked around) this problem before, either in Unity or some other physics-heavy environment?

(I've posted this on Unity Answers already, but as usual nobody has a clue if the question isn't covered in the docs.)

Before trying multithreading, you should at least consider the possibility of using coroutines.

Looks fun, but I'm a bit concerned that the graphical style will mean no sales. The rise of Flash games has meant that people typically expect to play things like this for free.

The odds are that almost everybody will be up to date with their JRE.

Erm... why do you think this?

Not that I'm an expert on the Java install base or anything, but I'd have expected most users to have out of date Java and a substantial minority to have no Java at all.

quick curved staircase, 438 tris, ~1 hour?, SketchUp7 rough -> FBX -> 3D Coat

Looks good! Would you recommend this approach? It sounds complicated, but an hour's pretty decent for an object like that.

I use text files, typically in formats just at the edge of human readability so that if I really need to I can hand-modify them.

For AS3 work I often opt for XML just for pure laziness reasons (the built-in XML support in the language makes it very quick to work with).

I fixed it by reworking it to only lock the couple of lines that needed to be locked and making sure I wasn't locking code that would lock another mutex internally. Seems to have worked.

Hurrah! Good work!

Steambirds was sold the ios & android versions while the flash version was sponsored by armor games.

And this is a model I think we'll see more of. Indeed, it's approximately what we used for UpBot Goes Up which has a free-to-play Flash version that's sponsored and an enhanced version on the XBox that has more levels and looks and sounds better. (We'll also have an enhanced iPhone version, probably later this year.)

I've been there, I know how important it is to get your definitions clear, crystal clear, holy crap if my code screws up then we lose 50 million dollars/Kill 100 people clear. If you've never been in that situation Boris, then you'd know that Average Software's nitpicking is the sign of a competent professional who takes his task seriously.

Leaving aside Average Software as an individual, the above is much less the perspective of a professional programmer as it is the perspective of a manager on such a project. Huge, huge amounts of work have been put in by academics on the subject of formal code correctness. It has its advocates, but the bottom line is that code correctness proofs and associated formalisms are at least as hard to get right as actual code.

Definitions - precise or otherwise - are no substitute for understanding. I get the impression that both Boris and Average Software understand the software side of this perfectly well and are essentially debating the canonical meaning of some of the written English used on this forum. Industry plays that game too, but the difference with internet forums is that when I get bored I can just walk out of the meeting!

on a new grumpy note: ugg I think I have a threading-related deadlock bug. URGH. Across 3 threads and involving at least 3 mutexes

edit: 4 threads actually

Pro tip: merge your mutex locks. The natural inclination of most programmers is to minimise blocking by having resources A, B and C protected by three separate locks. However, in cases where two threads both make use of two or more locks it often makes sense (and can make your program run better) to replace them with a single lock. No deadlocks ever again!

For more complex setups (which you should almost never have unless you're writing an OS kernel) you can get similar results by giving your locks a hierarchy. So for locks A, B, C you have a rule that any thread which ever locks both A and B at the same time must always acquire A first and B second. Similarly, B must always be acquired before C.

These sorts of designs may sound limiting, but if you don't take these sorts of steps it isn't the deadlocks you spot (never mind experience) which you have to fear... it's the ones you won't. You rely on testing alone, because some deadlocks will arise from (for example) race conditions that happen only on some machines and not others.