Unity networking

Gave a guest lecture on Unity networking at the NHTV/IGAD. Show how to build a simple authorative server, clearly splitting the server and client code (not trivial in Unity). Check out the lecture here.

Unity and rotations, what about the rotation point?

I've been playing around with Unity for a while now. It's a great cross platform (pc, web, mobile) tool for developing 3D games (in C# or javascript). One of the things I had to get used to was rotations, and something called a Quaternion.

I won't go into the details of Quaternions here, there are plenty of good references such as wiki. However, there was one thing that took me a while to get clear, and for that reason I'll share it with you here.

All rotations can be represented by an axis and angle. If you think about this for a while, it seems reasonable. Pick up a matchbox, imagine sticking a pin through it (the axis), hold both ends of the pin and spin the matchbox a little. Voila, a rotation.

Now an axis in 3D math notation is a vector with 3 coordinates (x,y,z) and an angle is just a number, so a 4th coordinate. This gives rise to Quaternions, which are 4 dimensional vectors, as a way of expressing and carrying out rotations (I won't bore you with the details).

The point that had me confused for a while is that a 3D vector (x,y,z) is an arrow/pin stuck through the origin of the 3D coordinate system (0,0,0). But how does that relate to the matchbox. You can stick the pin through the matchbox from below or from the side, or squiff, or .... It seemed to me that you also need to specify the rotation point (place you stick the pin in).

Turns out this is true. However, you can still express all rotations with Quaternions. the idea is that you first move (translate) the matchbox so that the origin (0,0,0) of the 3D coordinate system is at the rotation point. Then, you can perrform the rotation.

So how does this all work in Unity? Well, all GameObjects have a (non visible) pivot point. When you call transform.rotate() the rotation is around this point (default space.self).

When you have a 3D model of a six legged alien, the location of the pivot point is a bit arbitrary. It also seems to depend on what kind of 3D content creation tool you are using (say Maya). For something simple like the default Unity cube, the pivot point is in the centre of the cube (seems logical). You have a button on the editor screen to show the pivot point (toggle pivot/center).

If you want to rotate around a different point, then you can use the Unity function tranform.rotateAround which requires you to specify the rotation point as well as the axis.

Small Side Note: rotateAround() always use World coordinates, whereas rotate() can use both local/self or World (default is self, so around the gameobject pivot point).

The mobile development scale from web to native

I remember the day when the only way to develop cross platform was Jave ME and Symbian (C++) was the biggest platform to target. Thankfully, those days are now long behind us and there are now many, many ways to develop apps for mobile platforms. I thought it would be usefull to arrange the various approaches along the "scale" from web to native, starting with the web end:

Websites (css/html/javascript/++)

All(?) mobile devices have a browser preinstalled, so all you have to do is build a website and the people will show up (wouldn't that be great).

Use HTML(5), css, javascript to build the webpages and for the rest of the web application, use any server side technology you like, be that php, python, .Net, Java, ...

There are plenty of great mobile frameworks that take the sting out of cross browser problems. Jquery Mobile (javascript), HTML5 Boilerplates, and Less/Frameless (CSS) to name but a few.

Phonegap (html/css/javascript)

Just a small step away from a website in a mobile browser is your own "native" browser app. Phonegap is a tool that allows you to develop apps using your front end developers: css, html(5), javascript. The resulting "web pages" are packaged into a native "browser" app which can run on Android and iOS (and probably more). You can of course use ajax to make web calls to your web application server if required.

In addition, PhoneGap provides a javascript library that allows you access to the mobile device. This allows you to use the mobile file system, accelerometer, etc...

The UI will not be "native" in that you determine how your app looks with css and html.

Marmalade (C++)

Develop once (in c++) and deploy to both Android and iOS (and more). Quite a leap from the web languages to c++, but you still only have to develop once to get multiple native apps. The native mobile UI is (partially) available via wrappers. Marmalade seems to be used alot by game development. Probably because it is so low level it caters to alot of (graphics) performance.

Marmalade also has a Web variant, which allows apps to be built using html, css, and javascript, in much the same way as for example PhoneGap.

Mono (C#)

Not quite fully cross platform, but certainly not native. Mono for mobile comes in two flavours, MonoTouch for iOS (you need MacOs to develop on) and Mono for Android (you can develop on many platforms). Mono allows you to develop you apps in C# against a subset of .NET.

The UI code(C#) needs to written seperately for iOS and for Android. The reason is that Mono gives you access to the native UI, as if you were developing natively. So on Android you will be creating Activities and using xml layout files, while on iOS you will be using UIViewControllers and the xCode interface builder.

You can build your business logic once and reuse across mobile platforms, just not your UI.

You will be able to access all (most) of the device functionality. The app will package and include part of the .NET CLR (only the parts required by your app), making the app a bit bigger than native apps.

Native (Java/Objective C)

Of course, you can always go native. That is guaranteed to give you full access to the device and the UI. No waiting on the cross platform tools to update their wrappers to the latest versions of the mobile OS etc. Native will give you the best performance and user experience, but will require the app to be built seperately for each platform.

Android development is in Java and Eclipse is a great IDE that integrates nicely with the Android SDK.

iOS is developed in Objective-C and requires a Mac to develop on. As I haven't had much experience here, I'll refrain from making comments.

What I did last year

I've worked for nearly 1 year now at my current job, as head of IT. Time to make a summary of the improvements I have helped achieve (credit goes to as much to the team and the company as to myself!):

• the team used have at least as many projects as there were people. Everybody basically worked on their own projects. I changed this by introducing two teams, one focused on front end work and one on .net project development. Every project was tackled by the team, not by an individual. The number of simultaneous projects became limited to a two or three.


• the IT department had a bad name with regards to completing work. In fact, it was hard to name a project that was completed on time and on budget, if completed at all. There were projects of a couple of months running for over three years. Together with the team, I introduced Kanban, focused on limiting work in progress, made sure small pieces of business value were delivered as soon as possible, made work in progress visible. The IT mission statement became "we deliver" and the team set a target for the year in terms of number of rolled out projects which they though was ambitious, but which they had already made after the first 3-4 months.


• Evaluations were a mess and severly demotivating for the team members. Basically, the former heads of IT would grade everybody once a year on 16 ill defined criteria, using an ill defined score between 1-10. That's 160 scores you have to give meaning to! I got rid of this pointless exercise by developing a 360 degree evaluation together with the team and carrying this out every quarter. This meant that team members gave each other a grade along with feedback, and also that the company at different levels gave feedback to the IT team as a whole. I as head of the department still give a grade on three criteria. This was a compromise as I would rather not have graded people at all, not even via 360, as grades are by definition demotivating.


• Instead of a yearly evaluation, or even half yearly as it has become, I sit with every team memeber in a 1-1 every three weeks. this gives short feedback times and ample opportunity to discuss how things are going. By the time the evaluations take place, there are no surprises for anyone.


• The salary increase process was unclear, there was no direct link to the evaluation process. I improved this process by making explicit what grade led to which salary increase, and by defining the various salary scales more clearly, especially how one moved from one scale to another.


• The IT department was primarily being outsourced to another company for development. Although the company claimed that IT was one of the three pillars, there was virtually no interaction between IT and the rest of the company. I started up a process of developing an IT strategy together with the team and company, and created projects that focused on automating manual work that non-IT employees did, as well as projects that directly supported the main business of the company and their customers.


• One of the main concerns the company owners had was that there were single points of knowledge/failure in the IT team. I resolved these bottlenecks by making everyone work as a team, doubling up the technical expertise, and promoting knowledge exchange.


• The morale of the IT team was low. By introducing team sessions, retrospective meetings, 1-1 sessions, team activities, trainings, and conferences, the morale has improved dramatically. The team has clearer goals, more control over it's own work and planning, and it's work is more visible within the company.


• I have grown the team from 6 to 8, with 2 people moving on in the mean time. I introduced a new interview process, consisting of a first meeting with me and HR, followed by a four hour hands-on workshop, and then a final meeting with the company owners. This process has served well to deliver good candidates.


• By estimating projects before hand using story points, by reporting on the used up budget during the project, and by evaluating the final used hours vs budget afterwards, the estimation process has become much more transparent. By enforcing that all estimates are made by more than one person, and by people who will do the work, the budgets are beginning to be met. Before, almost all projects went over budget, although nobody talked about it.


• The average grade given by company management to the IT team has increased by 45%


• I arranged that we are now Microsoft Silver partner, and this has sigificantly reduced the licensing costs of the entire company.

Book review: Mindset by Carol Dweck

This book is scary! If I had ever bothered to keep a dairy during my life, and managed to faithfully jot down my emotions and thoughts, then reflecting on those diaries now would I am sure have taught and shown me everything that Dweck has somehow managed to capture in her book. She has given words to thoughts and learnings I have only begun to learn for myself. This book has opened up a new world to me, a world that confirms more than ever just how similar we all are, and that feeling of being special is just an illusion we build to protect ourselves. It is an uncanny experience to read a book by a total stranger and to recognize almost every example in the book as something you have personally experienced. And yes, if you were wondering, I have a fixed mindset in many areas, or at least had to a high degree.

This is a must read for anybody who has ever been/felt a natural or a talent in some area. Most likely, such a situation will have fostered some form of fixed mindset thinking and most likely, this mindset will be blocking your further development in some way. This book will at least make you more aware of this, and hopefully give you a "mindset" to tackle and overcome these blockades.

This is not to say the book is The Truth. In fact, the simple split into fixed mindset vs growth mindset is I think a little over simplified. Personally, although I recognise most of the examples of fixed mindset in myself, I also recognise strong elements of the growth mindset in myself. Especially in different areas such as business, family, friends, etc different mindsets seem to apply, overlap, or flow into one another. For example, I tend to have a strong fixed mindset initial reaction to many things, but after some reflection and time, I tend towards growth mindset actions as a result. In short, it's not all as black and white as the book sometimes seems to suggest.

Book review: Management 3.0

"Management 3.0" is written by Jurgen Appelo, a dutch author with an active blog.

If you take a look at the blog, you'll understand where the book came from, most of the content covered in the book is on the blog in some form or other.

So, what is the advantage of the book over the blog? Well Jurgen introduces his 6 views on management and gathers/aggregates his blog entries under these 6 views, splitting each view into a chapter on theory and a chapter on practice.

The book succeeds in presenting alot of information, from a wide variety of disciplines such as chaos theory and agile. Quite often Jurgen gathers existing models and combines/modifies them to build his own model. Generally the thinking is good and gives some new insights.

I found the book hard to get through at times (and in fact I didn't quite finish it). There isn't that much of a "story" in it, and I find it could profit from some more real life examples to spruce it up. I do think it makes a great reference. If you ever find yourself wondering about this or that model, and how it all fits together with agile/leadership/managemment, then this book is a good book to pick up and flip to the relevant pages.

ADAPT and Switch

In Mike Cohns great book "Succeeding with Agile" he mentions the acronym ADAPT as the 5 steps necessary for an agile transistion in an organization(ie change). The letters stand for Awareness, Desire, Ability, Promotion, and Transfer. Very similar to Prosci’s ADKAR change model which describes the necessary phases for an individual to adopt a permanent change in their behavior and attitudes. The K an R stand for Knowledge and Reinforcement respectively. I guess in moving from an individual to an organization knowledge and reinforcement are replaced by promotion and transfer.

Anyway, I wanted to match ADAPT up with the steps in the great book Switch by the Heath brothers (see an earlier blog). So here goes,

Awareness

The reason why change is required should be clear (ie the problem that has to be solved).

This is related to "direct the rider", particularly "point to the destination". After all, the destination should be better than where we are now.

Desire

You may know a problem but still not want to fix it. Some unfinished chores in the house come to mind.

This is related to "motivate the elephant", particularly "find the feeling". Desire is after all all about emotion.

Ability

You may want to fix a problem, but simply lack the ability to solve it or make a positive change. Again, certain household chores spring to mind.

This is related to "Direct the rider, script critical moves"; after all, everyone can carry out simple instructions. But this is also related to "Motivate the elephant, shrink the change"; after all small changes are easier to carry out than big daunting overhauls. And finally, this is related to "Motivate the elephant, grow your people"; after all training, teaching and coaching will increase the ability of people and your organization.

Promote

In an organization, you need to motivate more than one person for a change to occur. This involves alot of communication (selling).

This is related to "Shape the path, rally the herd"; organizational changes require momentum to build up. Also, this is related to "Direct the rider, find the bright spots"; if positive change is working somewhere then celebrating it goes a long way to keeping momentum going.

Transfer

In an organization, having succeeded with change in one department, or team, or organization unit doesn't mean you are done. The rest of the organization will also need to adapt, otherwise organization gravity will simply drag the changed unit back down to the old state.

This is basically saying, iterate the ADAP steps again and again everywhere in the organization. In that sense, it relates to the Switch steps mentioned above. More generally, this relates to "Shape the environment".