I just wrote this:

Code:

textText.text = text;

...then paused to fully savour the absurdity of the fact that this was actually clearer than last time I wrote code to do the same thing.

Is this something too hard for tech heads in TIGS?

Not at all, you're just not defining it as a technical problem. "Like Mario Galaxy" may be your objective, but the next step is to formally write down all the behaviours you expect that to involve.

What's going on with the loop-the-loop case is that you're adding an additional constraint that the forward direction on the controller must always move parallel to the camera view. Well, OK, that's easy enough:

Code:

if (Vector3.Dot(Camera.main.transform.forward,myPlayerCharacter.transform.forward) < 0) {
 // We're facing towards the screen, so flip controls
 flipControls = true;
}

Read this flag when interpreting controls, something like this:

Code:

if (flipControls) {
 myHAxis = -Input.GetAxis("Horizontal")
 myVAxis = -Input.GetAxis("Vertical")
} else {
 myVAxis = Input.GetAxis("Horizontal")
 myVAxis = Input.GetAxis("Vertical")
}

And probably you have other requirements too that you haven't fully understood yet.

If what you're really asking is not so much "How do I do this?" as "What are the terrain following rules in Mario Galaxy?" that's not really a technical question. Sit down with a piece of paper and play some Mario Galaxy!

1. I push forward on the controller (repeat for any direction)
- what happen if i'm running on side wall (prince of persia style)

The character moves forward along transform.forward (same as always).

- what happen when i'm running from flat to up/down a wall forward me

There's nothing special about a "wall", it's just a sudden change in the landscape surface. You need to be able to deal with arbitrary surfaces anyway. (I'd do it by casting rays down and forwards, but there are plenty of possible approaches, such as analyzing collision contacts.)

- what happen when I run a ceiling

The character moves along transform.forward (same as always).

- what happen (most importantly) when these case are combine in slightly slant surface.

The character moves along transform.forward (same as always).

2. In every of these case when I jump or fall (no more sticked to surface) and the character align back to the world:
- How i'm sure that visually the movement and direction of the new alignment match the old direction  without nonsensical behaviour, especially by keeping momentum.

The objective to to align the character's local "down" with the world "down". Unless the character is precisely upside down, there is a unique shortest rotation between these two vectors. So rotate in that direction, scaled to a suitable rate. (And if the character is precisely upside down, rotate a little bit about transform.right instead for the first frame.)

Trying to do this properly with strong typing is way beyond the scope of a forum comment, I suspect. When I played about with making a language (some years ago now) I quickly decided that it would adopt the general approach of Tcl, with everything in prefix notation and with variable numbers of parameters and a type system in which type conversions happen silently and automatically and nothing is typechecked (or type safe) unless it has to be.

It's not that I'm not a fan of strong typing - it's great - but the kinds of uses that home made languages are best for benefit from a small, elegant language implementation and don't really need sophisticated type handling.

What kinds of reformatting of the atlas do you need to support? I'm finding it quite hard to imagine a solution that would let you do that without breaking everything.

How you set UVs in the editor depends on how your game handles different tile types. What I'd do is just do everything in software. Use the tile number to calculate a set of UVs and then apply those to the mesh for the tile. Personally I'd just do this at runtime, but if you need the editor for some reason you can always put the same code in an editor script. You could even get the script to make prefabs and work that way if it's more convenient for you.

What I'd do is this:

* Don't keep a gravity vector. Instead, use the character's Transform for everything.
* Continuously adjust the transform based on the collision normals.
* The only adjustment you're allowed is to rotate by some angle about the transform.right vector. (Measuring the required angle way require a bit of geometry work.)
* When the character turns (left/right) it's always by rotating about the transform.up vector.
* Gravity is always applied parallel to the transform.up vector (negative, obviously).

This way, whatever happens you always have a consistent set of info to base character behaviour on and you can focus your efforts on making the changes to the transform feel nice. For example, there may be cases where you want to implement smooth transitions.

I'm trying to write a function to work out how much noise a falling object should make on impact. The only thing I'm sure of right now is that my current algorithm is VERY WRONG.

When I've seen this happen it's usually because of some cumulative problem which the code doesn't incrementally fix. The classic example is when memory allocations are handled by a garbage collector, which then suddenly decides to do a massive spring clean causing a huge delay which then makes you miss a frame (or even more than one frame).

Sometimes the delay isn't even in your own application. If whatever you're running in the background has a sudden need for resources it can make the difference between fitting your processing into one frame and not quite fitting it in one frame.

I work as a one person team. If I need something done that I can't do I contract it out to someone, but so far I've only needed to do that with audio/music stuff. In the past I've worked with small teams, but never more than three. I always prefer email for communication, because it's asynchronous and automatically results in a permanent record.

Further to ThemsAllTook's recommendation, if you're using Unity you can do a sneaky thing where you use your old (non-deltaTime) easing formula in the FixedUpdate method, but instead of moving the camera you just keep track of the position in a variable somewhere. Then in the Update() method, move the camera to the current position held in the variable.

Can you give me a link to some documentation on that?

Unity's docs don't have a walkthrough of these settings, but it's really easy. Goes like this:

* Place your .blend file into your project hierarchy somewhere.
* from within Unity, select it.
* In the Inspector, look down the various headings until you find "Normals & Tangents".
* Normals will probably say "Import". Change it to "Calculate".
* I think Tangents starts on "Calculate" anyway, but if not then change that too.

Incidentally, it's worth making sure you understand how normals, lighting and UV mapping interact before concluding that any of Blender, Unity or exporting are not working correctly. ChevyRay's "edge split" solution isn't fixing a bug so much as it is requesting that Unity add vertices to ensure that different faces don't have to share normals. "Real" cubes don't share normals, which is why this sometimes looks better, but as Boris points out that's not always the case so you should see this as a design decision rather than a bugfix.

(I hope that doesn't come across as condescending. I put it that way because this stuff horribly confused me six months or so ago when I ran into it. Indeed, I still hate pretty much everything about how UV mapping works.)

Regarding the actual proposal concerning paying for lives: the appeal of this for me as a customer would depend on when the game killed me. It could work really well in a game where I have good control over the level of risk I experience. So, for example, I can take on a boss monster that has some treasure I want, knowing that if I mess up I'll die and need to buy another life.

If the game ever just randomly killed me or I ever died in a fight or from an event that felt unfair then that would be bad.

Incidentally, I assume the player would always be free to start a new game without paying?

If I'm coding tricky stuff then only silence will do, but usually I'm not doing anything particularly tough - just grinding through implement/test/debug cycles. So most of the time I'm listening to this sort of thing: my current Spotify playlist ...usually on shuffle.

Just some more questions, have you tried the game on another computer to see if the same thing is happening there?

I haven't, because this is a commercial project, so having it fail like this for some users isn't OK even if it doesn't happen for others. I probably should, though, if only to discover how graphics-card-sensitive it is.

I just found out that deferred rendering is only available in Unity Pro, so I might not be able to recreate the scene. :/

Ah, yes. Thanks for trying, nonetheless - greatly appreciated!

[EDIT:]

EDIT: Also, is it possible for you to use an alternative lighting solution rather than directional? If so, have you tried it?

I've tried some alternatives, but I wouldn't like to assume I'm even aware of all the possibilities.

The shadows do have some game relevance though, since the game's about building things (in 3D), so they help to give an accurate sense of space and position. All the game's content is generated at runtime, so baked lightmapping isn't an option.

(Some further discussion of context in this thread.)

I have a simple Unity scene with a single directional light and deferred rendering enabled. Unfortunately, at some positions and orientations the shadows seem to fail. The results are pretty horrible. Here's a short video clip of the effect:





Does anyone know what's going on here? (Hint: it isn't anything that can be fixed by messing with Unity's shadow quality settings.) Even better - any ideas how to fix or work around it?

I need to find the angle of the edge of the wall that the player is colliding with

That's not too difficult if everything is just 2D rectangles. The only possible separating axes are parallel to rectangle edges. As you check each one, if it fails make a note of the negative separation and the corresponding edge normal. At the end of the entire process, if you've failed to find a separating axis then the negative separation of smallest magnitude is the overlap you want (and the corresponding normal vector gives you the direction).

It's part of how ECMAScript works, it is not a C++ convention.

It pretty much is, because the problem arises from the idea of using boolean operators to denote short circuit evaluation. If you think about it this is just stupid, because other than the fact we might sometimes use the same English word for both there is no connection between these concepts.

(To be fair, I don't know if C/C++ were really the first languages to do this or not. They certainly popularised it.)

Aaargh! Even when I'm not writing in C or C++ the stupid, broken conventions of these awful languages continue to cause trouble...

Code:

var face1:int = faces && 0x00FF;

Why for the love of sweet zombie Jesus is that not a compile-time error? No part of the expression is a boolean! There is NO sensible scenario in which a programmer would ever type something like this and mean it.

the majority of the indie developers who live off their work target iOS / Android

I doubt very much that this is really true. A lot of the top mobile devs are very active in the games community and iThings are much talked about because they're a new thing and (according to some) the future is mobile... but there aren't many successful mobile devs at all compared to PC.

Even a lot of the really well known mobile devs whose names you hear all the time are making shockingly little money. Like all of gaming there are isolated stories of people making a small fortune, but they're really not representative.

If you're going to pick one platform, PC is a great place to be.