When I use singletons it's mainly so that I can easily plug in replacement implementations.

For example: Suppose that I write MyInputManager as either a singleton or a static-only class. Late in development I discover that although I will never want two of these at the same time, I do want two versions. MyPCInputManager and MyPhoneInputManager. With a singleton this is easy - I can make them both subclasses and all the calls in my entire codebase remain the same as before. If, on the other hand, I used a static class then I'm either going to have to change every function call in my code or do messy, complex things inside every method of the class.

It isn't really any harder to write singleton classes anyway. The only effort is in making sure your other classes have a pointer to your singleton, which is easily achieved with something like MySingletonClass.getInstance() if you don't feel like cacheing it.

You can provide multithreading in singleton

Although not in AS3, which doesn't have threads.

It's a great (lack of) feature, because users always think they need threads, but in reality nobody ever really needs threads. If you think you want to use threads, write a job handling queue in your main thread and have all your other threads queue jobs onto it (and nothing else).

Thanks for the suggestions, but is there a free utility I could download? I looked at ImageMagick but I couldn't find precompiled Windows binaries?

Code:

ftp://mirror.checkdomain.de/imagemagick/binaries/

(In a code block because SMF doesn't understand FTP and turns the above into a broken link!)

You will have to do some tweaking of Physics.gravity

You shouldn't need to change this value. If you find yourself doing this, it's probably because your objects are the wrong sizes. For example, if you find you need double gravity to make things feel right, instead leave gravity where it is and make all your objects half the size.

(Changing gravity may seem like the easier option, but other parts of the physics engine make less obvious assumptions about object size too.)

How do I check if the collider WOULD BE hitting something if I moved down from it's current position.

To be honest, that's all such simple geometry that I'd be inclined to just write my own collision checks by doing maths on the coordinates. However, if you want to use built-in functions you can always use raycasts downwards from the block's current position to work this out.

Nice game!

One minor criticism: the first time I played I scored 66K (54 tris) and died because the sun set and I ran out of power. Nothing in the game gave me an indication how this could be avoided on a future play. (I assume from the game's title that it can be avoided. I need to go faster somehow, maybe?)

Not code, precisely, but...

I'm about four hours in to debugging a particularly nasty timing problem. It's got to the point where I'm logging out all the keystrokes on a frame-by-frame basis to look for 1-frame discrepancies. So, I get the logging working, run the code for the first time and the bug happens straight away. The log says:

FFFFFUUUUUUUUUUUUUUUU

(F is 'forward', U is 'up'.)

I'd recommend that you avoid fighting against the way that Unity does things. Sure, you could jump through awkward hoops to make it more like the previous framework you used... but that's not generally the best plan.

The way to get collision information in Unity for handling collisions manually is to add Colliders to the two objects you want to detect collisions between. Then set isTrigger to true for each of them and add an OnTriggerEnter function to a script attached to one of the objects.

Generally there's no need to mess around with events or messages or anything like that. Just using function calls is fine. At least keep it simple for your first project until you're a bit more comfortable with Unity.

If you want to exercise control over execution order of (eg.) FixedUpdate calls, that's easy to do: keep a list of objects, then give whatever holds the list a FixedUpdate function and none of the others. From within FixedUpdate, iterate over the list manually calling a function of your own (effectively "myFixedUpdate", but you can call it whatever seems clearest to you).

I keep hoping someone will write a complete Blender for Unity tutorial. I've tried using it a few times now because people keep saying it works well and every time it's hours of pain and puzzling through strange, under-documented design decisions.

remove the "Export Text File" field and button and just tie that into the "Process Lip-Sync" button

I generally prefer this approach, because it helps to minimise the risk of accidentally losing data.

d,1.96 / IH,2.029 / k,2.099 / s,2.17 / AO,2.279 / r,2.498 / s,2.68"

dIHksAOrs?

I don't think I want to talk about Dicksaurs, thanks.

If you want playtesting from people who aren't in the same location, just put the game on a password protected web page and give the password only to trusted testers.

All the publishers on FGL are trying to do is avoid a situation where your game has effectively already been published and therefore the opportunity for ad revenue lost. It's easy to keep them happy: don't publish your game before you sell it to them!

I work as a sole trader in the UK and it causes no problems at all for things like profit sharing. Just keep your accounts properly and you'll be fine. Tax is based on income, not on money moving through your bank or PayPal account. If money is transferred to you which is actually someone else's profit share then just send it to them. It does not count as income for you.

Thanks for writing this up! Sorry things didn't go better for you, but hopefully you've learned lots of stuff which will be useful for future projects.

If you release paid initially you can always go free later... the other way around doesn't work well!

write your own, you will learn a lot. its actually pretty straight forward

I'm on my third version of DIY joint handling now... and I can't say I agree. The trouble is, the physics API just doesn't give you the control you need. You have two choices:

* Joints which behave correctly, but the jointed items interact weirdly with the rest of the world because their rigidbodies keep getting manually adjusted.

* Joints which flex about axes they shouldn't when subjected to high forces. (Not helped by the fact that Rigidbody.MovePosition(<location>) doesn't actually leave the rigidbody at <location> at the end of that FixedUpdate cycle, which is a ridiculous design decision.)

Unless perhaps you're suggesting I discard PhysX entirely and write my own physics system?

I am suffering from 3D physics rage.

Seriously - Unity's joint physics (or is it PhysX that's at fault?) is so bad I literally can't think of a single application its good enough for besides ragdolls.

Now rewriting King Machine's joint handling for the third time...

Just write your own fps counter.  Any active component with update can do it, then display it in game from OnGUI

That's easy to do naively - which gives 27 fps - although I could really do with knowing what the worst slowdown is like rather than average case performance.

Still, as expected, it's not good enough at the moment.

Update: So, I've now tried running the game with deferred lighting and it looks something like this:



...which I think is probably acceptable, although the lack of anti-aliasing makes me a teeny bit sad.

I'm having trouble measuring the FPS, though. Unity's editor has a built-in FPS meter which claims I'm getting 175-315 fps (yes, it varies that wildly). However, to me it feels slowish and I'd estimate I'm getting more like 20-25 fps.

More testing needed, I think.

Are you using the deferred lighting rendering path?

Yes. Or rather: no, but I will be!

If so, how big is the range ( compared to the scene ) that your lights cover on average?

It's impossible to generalize. Lights are, in general, attached to objects which the player may pick up and carry around.

A typical configuration on an unmodified level might have each light covering maybe 10%-20% of the scene except for one directional light which hits the whole scene. Perhaps 4-5 lights in total.

Could we see screenshots of some complicated scenes?

It's impossible to predict exactly what players might make, but let's say something like this: pile of cages as an example of something routine enough that it really mustn't cause performance problems.

I've never used them, but as far as I understand it those depth-buffer based shadows shouldn't slow down with multiple objects.

Oh, OK. So if I were able to keep the number of lights down somehow I should be able to just switch shadows on and get reasonable results?

(As you've probably guessed, I don't have Unity Pro yet but will be getting it before the project ships...)

Does the game really need multiple shadow-casting lights? (I'm assuming it's King Machine.)

You assume correctly. And no, it doesn't NEED them. Thing is, portable lights add a lot of atmosphere, so it would be nice to be able to support them. Portable lights that don't cast shadows tend to look a bit odd just because they shine through walls, but it isn't the end of the world.

As far as shadows go, I would be tempted to have one, vertical one to help with positioning, and leave it at that.

Luckily I won't need to rely on them for that. I long since added a kind of targetting frame that extends downwards from the object. It's more precise than a shadow and prevents annoyance with dropping objects in the wrong places.

I'm after some suggestions for how to set up lighting...

The game I'm working on generates all of its level geometry at runtime. This is a good thing except for one problem: it makes it very hard to light the scene acceptably.

The problem is that Unity likes to do a lot of its work at compile time. As such, tutorials on how to light scenes in Unity often revolve around baked lightmaps. Very pretty, but I clearly can't use this stuff.

Fortunately, shadows are good enough for me. But there's a problem there too: I have 100-200 moving objects in a lot of scenes as well as multiple lights. Setting all objects to both cast and receive shadows will slow some machines to a crawl. (Luckily I don't need to run on mobile, but even so...)

What other techniques are available to me? I have no strong feelings about level of realism, I just want scenes to look reasonably solid and easy on the eye.

During a healthy development process bugs come and go but they don't accumulate.

Known bugs don't accumulate, but undiscovered bugs almost certainly do.

* Is it possible to write code correctly every time? No.
* Is there some reason to suppose that the errors which result will be obvious? No.
* Is there some reason to suppose your test procedures will catch all bugs? No.

Even if your process is extremely meitculous and near infallible to the point of inadvisability (that is, you're wasting time and resources being too careful) you will still miss a lot of bugs because many are literally asymptomatic until some later modification makes them relevant.

Example: One of your classes fails to remove an item from a hashtable during deinit. This has no effect at the time at which the error is made, because instances of this class are only ever deinitialised when the class containing the hashtable itself is thrown away. Later an extension to the program means that the hashtable may live for hours with objects being continously created and destroyed. Even if there are zero bugs in the new code, the faulty deinit now becomes a bug that threatens game stability but will still only be found if you run a 40+ hour test or get extremely lucky.