Haven’t had a whole lot to say in the past week;  various potential (but not yet accepted) real-life-income-making details have been taking up all of my attention, so I haven’t actually gotten much coding done at all.

I was particularly surprised at the level of response I got to my earlier comment about master classes;  I’ve since been approached by a few different game design schools, and an Internet media group on the subject.  If I can manage to put together a few coherent topics, those things may start to happen in the near future.

I have also been toying with the idea of putting MMORPG Tycoon 2 to the side for a month or so (since it won’t be finished within that amount of time), and taking the time to make an iPhone game instead, to try to bring in a little extra income.  I mentioned a while back that I have a game design all prepped and ready for such a thing;  just a matter of coding it up, tuning it for fun/difficulty, and commissioning an artist to create some graphics for me.  Haven’t really made my decision on that yet, but it’s a possibility that I’ve been considering, lately.

Anyhow, no other real updates so far.  Hopefully I’ll have more I can say in a few days.

And finally, as a bit of a camera specialist, I have a personal note to whoever wrote the camera control for the game Enslaved:  Dude (or dude-ette, as appropriate), your dead-zone is broken on the right analog stick.  You’re clamping small values of the right analog stick to zero, but you’re not re-normalising the rest of the stick’s throw.  You need to do something like this:  “inputValue.x = (inputValue.x < 0.1)? 0.0 : (inputValue.x-0.1)/0.9;”  (obviously, I’m simplifying that code by ignoring negative numbers, but you get the idea).  Additionally, after fixing the dead zone, you really should square the values you’re getting from the right analog stick (while still maintaining the sign).  So like, if the stick is reporting a value of 0.5, square that value and feed it into the camera rotation code as 0.25.  This will give players finer control over low-speed camera movement, while still allowing fast camera movement to work at the same 180-degrees-per-second speed that you’re using now.  You know how the game control feels a little bit wobbly right now, how it’s difficult to run in a straight line?  A lot of that is because of exactly this issue, the camera turning faster or slower than the user intended, and taking the player’s “run” direction along with it.   If you made the two changes I’ve outlined here, the rest of the game control would feel a lot more steady.  (The bad “crossing-the-line-of-action” camera placements in some levels, of course, would still be a problem.  But that’s not your fault, and wouldn’t be as easy to fix.  I feel your pain, and will note that this is exactly why it’s so important to build your camera strategy together with (or before!) the levels, instead of placing cameras after the level mesh has been built.  Be sure to get this note into the game’s internal post-mortem, if it isn’t already!)  I hope you get this message and implement the changes;  you’re doing a lot of really neat cutting-edge camera stuff in this game, but it’s being let down a lot by these fundamentals.  In any case, I’m quite looking forward to seeing what exciting new things you do in your next game!  :)