Changing the position based on the current velocity is a pretty damn trivial calculation. So is destroying objects. All you do is iterate over them once. The physics and collision detection are already parallel problems and handled in a previous phase. Adding to score? Are you serious?

Code:

score += points;

That wasn't so hard.

These are not easy things to do at the same time. score+=points obviously breaks if two threads try to do it at the same time. And the score might be effectively edited from anywhere in the business logic of the game, so don't go telling me to just do those calculations one at a time, like you've been answering half my points. The solution is simple - a mutex around the score -  but that's already a new concept you've had to learn.

The other examples get even worse. Again, writing a parallel loop over all objects to update their positions is not so hard (though again, you have to learn it somewhere first), but show me one which copes nicely with deleting stuff while you iterate over it. Moving objects is horrible as you must update your broadphase concurrently (see later). 

The abovementioned tasks like destroying objects certainly do not take 75% of the game loop. It's collision detection, pathfinding, AI and rendering that take the most time.

Collision detection requires a broadphase, a structure for efficiently storing the positions and sizes of all objects, and determining which overlap. You can easily write a parallel collision detector that doesn't use one, but there's no point, as the single threaded app using a broadphase would blow it out the water for most circumstances.
Similarly pathfinding. It's easy to "find the shortest path from A to B" in such a way that I can do several at once. It's not so easy to share calculations to actually take advantage of the fact you are doing many similar queries, though the same single threaded code is frequently obvious. Shared mutable data!

I think I already mentioned some problems with AI. On top of that, complex AIs are hard to write - compounding that with multithreading is just no fun (but as AI depends on pathfinding, so I guess you have to if you want any pathfinding gains).

Rendering, I got no complaint with.

Some things are difficult to parallelize, yes. But it doesn't matter. You don't have to parallelize everything, that's not what multithreading is about. The point is to just parallelize enough to make up for the overhead, and you're already profiting.

So you're saying multithreading is easy, as long as you don't use too much of it? Well, I can agree there. There's not much point just making up for the overhead, though, as then it hasn't paid you back for your time doing it. And that includes time debugging. I expect serious performance gains over a single threaded app, or I wouldn't bother. Don't forget Amdahl's law - it's certainly the bits you've failed to multithread that give you the bottle neck, even if it's a relatively trivial bit of code.

And I neglected to mention debugging before. Once something goes wrong, (which is does more frequently with multi-threading than without), it's as hard as hell to track down. Bugs are invariably intermittent, and frequently disappear when you get out a debugger. Many leave you with corrupt data structures. Most compilers are no help at all in pointing out forgotten mutexes, or (C++ excepted) assumptions of constness. I haven't even had time to go into the fun that is deadlocks, or the mysterious optimizations taken on non "volatile" variables.

For the record, I've been talking about (CPU) performance so much, even though I don't really believe it's all that important for most games nowadays, as otherwise i cannot see much point in multithreading at all for games (except an extra thread or two for UI responsiveness).


TL;DR:
Multhreading involves new concepts, and tricky bugs. It is hard to get the most out of.

Thanks. Though I should say I did not write the engine myself, I joined after it was largely done, and do the less glamorous parts. So you should really tip your hat to Erin Catto, who wrote the original engine.

[Zero]

I have been using Unity for about a year now and am being pressured by peers and others to learn to program "properly" I fear it becoming free will only compel them to argue further on its lack of merit.

Fuck those guys.

As a hard core programmer who does bitch about middleware, I feel I need to justify myself.

I complain mainly about game maker. It's clear there are many users here who are not aware what makes a good tool, or what they are missing in using game maker. Unity and Construct seem better, though I haven't evaluated them, so I whine less. It's not the use of other peoples game engines that I object to (in fact, you should), it's how much these platforms lock you in to only what they offer. Only their language. Only their graphics engine. Etc.

Secondly, there is a tendency for game to feel samey. Obviously, the skill of game design is to avoid that, but I find in practise what happens is that someone picks an element to innovate in, and then goes with the easiest route for their middle where in other aspects. I'm constantly amazed by how many innovative games use tile based levels, and platformer mechanics. It's like it's a base from which to explore from. But it isn't, it's just one of many genres, let alone inventing your own. Unity hasn't established a similar feeling with me yet, but I feel it will.

Finally, want to know how many completed games I have under my belt? Zero. I'm a developer for the Box2D physics engine. My coding and advice has enabled hundreds of games, saved people hours of time, and formed a strategic part of other more complete engines you might have used. Some games that have gone on to win prizes, earn people money. I don't think zero games produced means zero impact on the community, and neither should you, if you value getting tools like Unity in the first place.

</impassioned-plea>

I meant all game logic as an example of stuff needing to modify the data. You know, changing the position based on the current velocity, destroying objects that have been hit by bullets. Adding to the score. Physical interactions between bodies. I thought it was obvious enough to not go into detail.

Anyway, I think you might have missed my point. I'm not saying yours is a bad scheme, just that there are other schemes one might do that make multithreading hard, in order to eke a bit more out of performance, or to meet different requirements. Just because it is not hard in your app where you have little mutable shared state doesn't mean it is not hard in general.

I don't see a reason to, either. Say you've got 4 cores. There are a lot more entities than 4 that have AI in an average game. So all the threads will be working full-time anyway, regardless of how you section off the logic.

What? No. If you have discrete phases for each part of your game, and others are single-threaded and take 75% of each frame, then you are only using 4 cores for 25% of game time, and they are being underutilized the rest of the time. That's precisely why you need all your different jobs to be concurrent. Even if most of the phases are trivially paralizable, it's likely that it's the ones that aren't that quickly become the bottle neck.

Not to mention that AI isn't all that paralizable. Sure, you can write AIs that think for themselves only (like real life). But it might be better to share some calculations, such as path finding, or decision trees. Or for them to co-ordinate in actions, so they don't walk into each other, or act as if they are in platoons, etc.
Or what if you are writing chess, or an RTS? Now there aren't multiple individual AIs just a few big ones, and you must paralize inside their thought process.

You neglect to mention any phases that EDIT the game data (mainly the game-logic code). Clearly, that's going to be harder to paralize.

Also, you don't have massive amounts of multi threading if you have a game loop with discrete steps. You want to be working on AI for as long a period as possible because it is computationally expensive. Blocking it off while you do non-ai things is bad for performance.

But even so, games are very rarely going to break from the per-frame synchronization. Try to imagine a non-game program where this is no time at which everything "synchronizes", and they are all trying to edit the same data structures at the same time.

FWIW, the places I applied to didn't reply, except one which finds december too short notice, and is busy with the global game jam in jan.

I've never seen tearing in flash. Even in other peoples stuff. Perhaps it's more a bug in the player in some platforms?

Marching squares + a couple of premade tiles seems the most common way, thinking back on games I've seen.

Jason Bakker's way works too. You can use a texture map rather than an alpha gradient for finer control on how the fog fades.

They don't have to, from the zlib license (which is basically completely free). But Erin has recently consolidated the library to just things he claims copyright for, possibly with the intention of dual licensing future versions.

[Torque2D to use Box2D]

Torque2D to use Box2D

Discuss.

Look, 1e-6 is very close to 0. The only cases (i can think of) that will cause significantly different program output:
1) You use == instead of abs(..)<eps
2) You screw up rounding to an int, or other API abuse.
3) Chaos theory.

The first two are fixable, and the third is a property of your system that you need to embrace, not swear at when it doesn't go your way. It is generally not fixable, even by changing algorithm. It still sounds to me like you have missed something about the problem.

Persist always being called isn't a performance issue, simply because each one of those calls represents a significant amount of work in the engine, which is not optional. I.e. the cost of the physics engine is larger that of adding event handlers.

Bateleur: Are you saying that you are receiving persist events, just no add event? Because that sounds more consistent with other complaints I've (only ever anecdotally) received. There is no difference between add and persist aside from when they are called, so a check in persist sounds like a solid plan.

Rubbish, variable's with m_ ftw. I use this for private variables. To access them externally you'd foobar(), not m_foobar. Refactor safe, and readable. I'm particularly confused as to how you think m_foobar is any harder to refactor than foobar. It it is no longer a member variable, then the code is certainly not going to compile without modifications everywhere you referenced it, so there's no danger that people will leave in the m_ longer than necessary.
For structs just for data purposes, and other visible member variables, I have no prefix.

On the OP's topic: I, and most other people here, rarely bother to download, compile and observe the problem first hand, then dig into the code to debug it. That's a lot of work. It's hard to read someone else code without getting distracted by other issues (see above). If you describe what is wrong, and perhaps sample pertinent code, it would be more productive.

It's actually not. Unless I know what happened.

I don't think that

Code:

(16|14|13)-(16|14|13)=(-3.8147e-006|-3.8147e-006|0)

is a true statement. Especially because my vector/Int3D class usually works exceptionally well.

It's essentially the same as

Code:

16-16=-3.8147e-006
14-14=-3.8147e-006
13-13=0

I cout-ed all values, it's probably an extremely strange float problem.

This is a common feature of floats. They of course suffer rounding errors, and for some reason this can crop up even in the simplest of statements. Bottom line: Never compare two floats using ==, always abs(f1-f2)<epsilon, (or length(v)<epsilon for vectors).

Yes, it should show an add & remove. Try playing with various SVN versions. Try disabling continuous physics. Check that you can receive the event with the contact either way around.

I've stopped giving advice on the event system, though, the thing is just to byzantine. And I've definitely stopped trying to debug it. The coming Box2D2.1 has a revamped simpler event system. (you can try it out on SVN).

I hate to be a stick in the mud, but I have copyright concerns. As a programmer, I don't like the idea of using assets without explicit permission to do so - a random guy could come along later, make unreasonable demands, and scupper my project. E.g. I'd like to showcase a piece of work indefinitely after the contest is over. Equally, artists must be concerned about what happens to their assets after the competition. What if a guy goes on to sell his compo game?

Could you provide a license for assets posted. Everything has to be posted under that, or freer? As far as I care, it doesn't have to be fancy, just a series of bullet points detailing it to put my mind at rest. IANAL.

I'd recommend something like:
By submitting assets you grant the right to non-commercial perpetual irrevocable use of the asset for projects submitted within the competition.

People feeling more generous should use one of the creative commons licences.

Also, I'm keen, though it sounds like it's going to be hella hard to sort through all the created stuff. I'm reminded of early click and play days, where nothing in the standard library fit together in style or theme.

How about each particle is pre-blurred by being a bitmap with suitable alpha. That usually looks pretty nice, and gives you lots of ways to tweak.

Harsh. If you don't mind me asking, where are you from?
Are you aware that you can get sponsorship from someone you know in the UK, which can help. Also having a definite objective in mind, i.e. TIGJam, is surely a fairly solid help. We can produce "supporting documents" to this effect.

GML is certainly not focused on game development. The only game specific feature that I can think of is implicit loops over all objects in the game of a certain type. Other than that, it's a generic scripting language. Other than that, it has a extremely game focused library, but that's not the same. You can add a library to any language.

Actually, I cannot really think of any other game specific features I'd want a language to have. Perhaps OO and multiple dispatch, so I can easily express: when player collides with enemy, etc. And continuations (or at least co-routines) would be useful so you could write little animation scripts without worrying about timing. My god! I'm describing Lisp...

It's moot though. The industry cannot/will not standarise on anything, there's just too much variety. And if everyone uses all the same tools, the one who doesn't can stand out more.

Glaiel-Gamer: Processors work like like that internally, except the parallism is optimistic, rather than blocking. It's why assembler optimization is now essentially impossible to do manually - you have to consider what instructions that processor might be doing at the same time, and ensure that you don't queue give it ones that cause it to give up on the parallel approach. I.e. a well placed NOP can make the program faster, as it means one instruction won't request a value before it's been computed.