SimulX

A remote possiblity

2012-04-04T14:23:00.000-07:00

Being a team lead is never the easiest job in the world, you are generally expected to function as a mentor, job assigner, task tracker and resident expert, all while doing your normal, day-to-day coding. But what if you had to do all that remotely? What if your team was located in an entirely different time-zone to you? Is it possible? Could it even be optimal?

Lots of people have talked about the concept of a remote team, but the one thing they tend to have in common is that the rest of the team is just as remote as they are, meaning that although the team lead may be in a different time zone from everyone, so are the rest of the developers.

Recently, I've been thinking about what it means to lead a software development team and what is expected of you in that position and I came up with a few key ideas -

Communication - Allows for a qualitative overview of the team and their performance

Making sure that you know what your team is doing and how it fits in with other teams
Getting your team members talking among themselves and with others
Ensuring that your team is clearly expressing themselves in code and in any task tracking systems

Metrics - Allows for a quantitative overview of the team and their performance

Recording task completion data (estimated vs actual time etc)
Measuring staff vitals (tasks completed, hours worked, focus areas etc)

Standards - Reduces the amount of non-critical traffic and assists the previous two functions

Forming a standard set of coding best practices and process flows that everyone can refer to
Developing induction packages for new employees
Using a standardised tool set (communication, development etc)

All of these requirements can certainly be put into effect from a remote position, but I would argue that a remote position gives you a distinct advantage - particularly if your development team itself is co-located.

Think about it, if you are in a different time zone then you probably have a limited amount of face time with your team, meaning that part of your day is solely focused on communicating with and tasking each member of the team. No putting it off until after lunch or handling it once you've finished this important thing. Communication happens right now.
Then of course, the other part of your day is devoted to development work, reviewing the team performance and improving standards and tools, all completely free of questions posed to you by your team. While you are doing this, your team can fall back on themselves to answer the easier questions and formulate the tougher ones more succinctly to you when you come back online.

Of course, there are disadvantages to not being co-located with your team. If a decision needs to be made, then you may not be available to make it, meaning either a 3am wake up call or someone else needs to take responsibility. That's not necessarily a total disadvantage, as long as there is someone you can trust and you back the decision, you end up empowering your team members and giving them a sense of ownership.

Another disadvantage is that it is much harder to build team spirit remotely, no more Friday after-work beers or regular catch-up dinners, but do these really happen that often as a team event? More likely they are mixed in with other teams, and while that's not necessarily a bad thing, it's not exactly a team bonding event. Even in this case, it can be turned to the advantage, so that when you do meet up (hopefully a few times a year), it is a big event - one solely dedicated to the team.

There are probably a number of other factors I am overlooking here, and I'm not saying that leading a team remotely is necessarily the better option, but I am saying that it is not necessarily unsustainable or impossible. Many teams do it even when none of the team are co-located and it is definitely an option to consider if it comes down to losing talent otherwise.

Designing for Developers

2012-02-20T10:40:00.000-08:00

There is a small problem I have noticed more and more lately - that is that there seems to be a number of designers who design a piece of technology with developers in mind. In itself, this isn't necessarily a bad thing, I mean, at least if you are designing your work for a developer then things must be more efficient, right? Well, yes and no.

Before the rage begins, keep in mind that I could equally have called this post developing for designers. The knife cuts both ways. A feedback loop of sorts develops, whereby developers start to push designers in a certain direction by only meeting the parts of the design that suit them and designers react to this by only designing things that they think the developers can get done.

The problem with this method of thinking is that it stifles creativity in an industry that runs on creativity. By designing for development and vice versa, you end up with a boring, over-simplified product that no-one is particularly happy with. Designers need to feel liberated to think outside of the box, and developers need to feel challenged to create amazing systems.

This kind of circle is actually even worse in my case, where a lot of the time I am the designer and the developer of a particular system or mechanic. I know the limitations as a developer and so I reduce the complexity of design. So how do I go about breaking this cycle of mediocrity?

Well I'm not going to tell you to aim for the stars, as great as that sounds we are all under time, budget or some other pressure to actually get something done. One of the best methods I've found for breaking this loop is being able to rapidly prototype an idea. Luckily, I work in an environment that generally allows for (indeed some would even say designed for) rapid prototyping of ideas into a playable concept, but what exactly does it mean to rapidly prototype something? I find this a particularly interesting issue among new people to the company, while they may be very skilled in a particular area, they are generally not very skilled in using our product. Oddly enough, this almost always leads them to trying to create a full working implementation based on the spec provided. It's not until they have been working with the company for quite some time before they realise that it's actually possible to simply knock something together to prove it could basically work. Once you see someone starting to talk in prototypes, not just words or written analyses, you can tell that they are starting to settle down into the product and really find their feet with the technology.

In the DICE 2012 keynote speech, Todd Howard (creative director for Skyrim) gave an excellent example of the kinds of amazing things that can come from rapid prototyping. In his speech, he shows some of technology that came out of a one week free-for-all that they had a Bethesda while creating Skyrim. No doubt that the examples he showed were some of the more successful and polished ones, but even taking that into consideration I was still astounded at the amazing things that were developed in a week!

The neat thing about rapid prototyping is that it frees your mind from the nitty gritty details that bog creativity. It allows you to simply see how something works without having to explain it (to yourself or others) so you can move on to bigger and better things. When you are prototyping, you don't need to worry about the issues that this piece of technology will cause when running in a Windows XP, multi-player game when a unit enters a vehicle, because it doesn't matter, you are simply experimenting. If designers can rapidly prototype a concept, not only will they get the developers to understand their idea better, but they will also get them thinking of ways it can be implemented. On the flip-side, if developers start to prototype their first-pass tech, they can easily highlight issues for the designer.

By rapidly prototyping your work you free your mind as well as anyone else involved and allow for bigger and brighter ideas to spread. You end up with cleaner, more polished products because you've been able to foresee the issues and you end with a better product at the end of the day because you were able to realise a bigger vision than you would have otherwise.

Moving Internationally

2011-08-25T13:48:00.000-07:00

Recently, I was offered a position in our US office. From a career point of view, the position offered was fantastic and was definitely a move up for me, not just a move across, but since I am currently living in Prague with my fiancée, a move to US was always going to be much more than a career decision.

When I first started looking for information about moving to the US, I found a distinct lack of practical advice about the kinds of things to consider in an international move. The few things I did find were generally highly focused on children, which is fair enough I suppose as moving kids must be quite difficult. However, after a while I managed to find a few useful tips which I'll try to detail here.

Compare your salary to other, similar positions

It's obviously good to know that your potential employer is fair in their offer when it comes to your new role. Knowing the value of your position is something that is quite easy to do in your home country because you know the market and generally know where to access this kind of information. When you move internationally for a job, it is often hard to know if your employer is giving you an offer that is better than your current salary, but not particularly great compared to other, similar roles for that country.

This is much easier in some countries than others due to the accuracy of online tools. When considering moving to the US it was particularly easy as there are some great tools like payscale.com and salary.com that allow you to quickly and easily compare against a reasonable baseline.

Think about the cost of living in the place your moving to

Ok, this one is pretty obvious and will most likely be the first thing to cross your mind, but it is quite a difficult question to answer, particularly for international moves. When we first moved to Prague we only really considered the basic cost of living, things like how much an apartment is to rent, how much is a standard meal at a restaurant, do I need to buy a car and those kinds of things. We may have even considered more detailed costs like public transport and clothes shopping, but the kinds of things we didn't consider are the things that I like to call 'secondary costs'.

Secondary costs are those costs that don't come out of you income on a regular or even semi-regular schedule but they certainly will at some point and are almost always the reason you scratch your head and wonder where all your money went at the end of the month. Examples of secondary costs for us in Prague have been things like the price of travelling outside of the Czech Republic (while I may get paid a good salary here, the currency does not convert so well in other countries), or the salary that my partner was likely to make and how easy it would be for her to get a job here as many companies will pay above market rates to attract talent internationally. Another example is currency changes, which will particularly affect you if you have expenses (student loans, home loans etc) in another currency. These are quite hard to factor in, but you should leave a very reasonable margin in your salary to account for them.

To help with this, there are more and more tools online to get an idea of what your living costs will be. One I found particularly useful is expatistan.com, which has some great information on cities all over the world.

Get your potential employer to tell you your take home salary

Most of the time you will be quoted a salary before tax. When you live in a country this makes sense as you probably have a decent understanding of the local tax laws and how you can use them to your advantage, or at the very least you will be able to work out your take home pay. When you are moving internationally however, it can be hard to know exactly what your tax and insurance (health, dental, optical as well as professional liability insurance) costs will be.

Think about the income you will be losing

This is related to tax and the like from the above point, but it's important to remember that your actual income in a certain country can be partly made up tax breaks and other benefits from owning an investment property or the like. Often, these breaks only apply if you are making a taxable income in the country where the asset is. Another income 'loss' could be in the form of added expenses, such as the need to buy a car if you didn't previously due to good public transport.

Think about lifestyle

It never even crossed my mind when I moved to Prague that there would be a significant lifestyle change. I expected a number of cultural differences from having travelled before, but one of the biggest surprises for me was the concept of eating and drinking out so often. It is a lot cheaper to eat and drink out in Prague than in other places, but it can have an effect on your wallet, not to mention your waistline after a while - all in the name of cultural integration.

Aside from this, many places simply do things differently to what you are used to. Different attitudes from people can make you feel out of place and it can take a long time to get used to. When I first moved to Prague, I thought that people in the service industry (restaurants, shops etc) were ridiculously rude all of the time. I at first thought it was because I couldn't speak any Czech but over time I came to realise that it is more of a cultural oddity than anything and that I should just deal with it.

Are you being offered any relocation-specific benefits

You might be moving to the next country or half-way around the world, but most companies will foot the bill for you to get there with your luggage. If you have a lot of luggage you either need somewhere to store it while you look for a place (if moving from nearby) or you need to factor in that it could take 2-3 months for it to ship there. Again, most companies will offer some short term accommodation to allow you time to settle in and look for a suitable place to stay for the long term, you should allow at a minimum six weeks for this, preferably up to three months or longer in some cities as this can be a tough task, particularly if you need to buy a place.

Other relocation-specific benefits are things like local language courses or financial and legal assistance. Again, you are likely to have to pay for these if your company doesn't and they could really be included as 'secondary costs'.

You are likely to want to go home occasionally

I mentioned before that the cost of international travel is something that you need to include, but on top of that you also should consider that you are likely to go home every year to 18 months. Most of the people I work with are expats and they all complain that they spend all of their holiday and a significant chunk of their salary going home each year or so to see family and friends. If you aren't moving very far then this isn't such a big concern, but if you have come a long way then it may be worthwhile getting your employer to include flights home in your before tax pay or at the very least to consider this cost when looking at your salary.

Is this a permanent move

I don't mean this in the sense of whether it is a contract role or not, I mean more in the sense of whether you, in your head or out loud, are saying that this will be a 'forever' type move or a 'just a year or two' move. This has a big impact on how you will spend your time there and your attitude towards the permanency of staying in that country will affect your ability to make make a home and find good friends. If it's going to be a permanent move, then you should keep in mind that many of the friends you will make will likely move on, particularly in countries that don't speak the same language as you do, as you are more likely to connect with people from your own country. If it's going to be a temporary move, then you should have an exit strategy to move all of you things back home (or wherever) or at least be prepared to stay for longer than you might have expected while you look for a new job.

How many other expats are likely to be there

This is one that people who are not familiar with travel are probably not going to understand at first. In your head you tell yourself that you will make friends with the locals, after all, why would you want to hang out with people from home? But the truth is that the local probably won't have a lot to do with you at first, they have built their own lives in the city and you are a newcomer, it will take quite a lot of time for them to get to know you. In general, 6-12 months is quite a short time before you can consider someone a good friend. In the meantime, you can either eat a lot of TV dinners or you can make friends with people who are in the same situation as you - other expats.

In all, moving to any new job is exciting, but moving to a new country is often even more so - as long as you have done some background research into the company and the country you are moving to. It's often really hard to gauge what a country is like until you've been living there for some time and by then it's probably too late! You should be prepared for lots of time and research on things that you might not have considered before, such as internet connection, mobile phones, bank services, visas etc. A good company will help you with these things but you will still find yourself confused and frustrated at the system and will need to put a lot of your own time in to understand it better.

A lot of the advice I have given above is quite generic, but that was my whole point. It is obviously better to ask someone who has been there before, even on holiday, if nothing else as they will at least have a few useful tips (feel free to ask me any questions about Prague or moving in general in the comments), but the reason I wrote this is for all those young professional singles and couples who have been offered a position they aren't sure whether to take or not. Most of the time, when you are moving internationally, the job is only a small fraction of a much larger equation.

Speaking the right langauge

2011-07-30T07:19:00.000-07:00

Last weekend I went for a long weekend with my girlfriend's family in Denmark. This was particularly interesting as there were seven people who went, and between us we were actively speaking four different languages (five if you count the Danish that we spoke to other people in the countryside). My girlfriend and her parents are Swedish (and speak English and Swedish) and her mother's family come from Poland (Polish, limited English and little Swedish) and my girlfriend and I speak English, Swedish and a little Czech (which we used as a translator as it is quite similar to Polish).

In all the weekend was a lot of fun and we generally had not too much trouble communicating, particularly after a beer or two, but some conversations we definitely like the old problem of the farmer with the chicken, fox and corn -

A farmer has to get a fox, a chicken, and a sack of corn across a river.
He has a row boat, and it can only carry him and one other item.
If the fox and the chicken are left together, the fox will eat the chicken.
If the chicken and the corn is left together, the chicken will eat the corn.
How does the man do it?

In the end, it is not a particularly difficult problem to solve but it does require some lateral thinking and the ability to go back and forth a lot. On the weekend we ended up doing a lot of translating between Polish and Swedish and Swedish and English with a little bit of Czech thrown in for good measure and we spent a lot of time going back and forth over the same conversation so everybody could understand. I am quite sure that a significant portion of what was said was often lost and at times the meaning was completely missed due to translation errors or cultural differences.

This got me to thinking about programming languages and communication at work. In our company we effectively use four languages for communication of ideas, with two of these used directly to implement features in the game. The four languages are,

programmer (c++)
designer (script)
tester (logical routines and paths to do things in-game)
English

Usually we develop things in our own languages within teams and there is a small amount of cross-language communication which is generally done in English. This works fine in most cases, but in a similar way to the chicken-fox-grain problem or our family weekend, it creates a large overhead in terms of repetition and much of the details involved in complex topics and even the entire point can be completely lost.

So what can we do about this? There are two obvious options, either create language 'translators' who can interpret between different departments, or impose a universal language to be used by all. Realistically, the two options have about the same characteristics as they do with real languages.

The quick and easy solution is translators as they are simpler to implement assuming you can hire or train the right people. This is like getting assistants to watch the farmer's items and is less efficient and likely to cause confusion as these assistants need to be communicating a lot with each other and their teams (equivalent to the items the assistants are minding). It is also possible to create programmatic translators that translate code from one form to another, but these are generally horrible for communicating ideas as the code ends up being computer generated and completely lacking in the syntax that human beings require to understand complex topics.

The longer term solution is to impose a universal language. This is akin to building a bridge for our farmer to get the fox, chicken and corn across the river. While it is more efficient it requires a much steeper learning curve as either the whole or part of the team needs to learn a new language or new team members who can already speak that language need to be hired, not to mention porting any old code/concepts to the new langauge. In addition, as with spoken languages, there is bound to be some form of 'cultural' loss as ideas which may have been easily formulated and understood in one language, may be lost in the complexity of another.

The third option is slightly less obvious but is actually far more natural and is what actually happens in companies that have more than one official development langauge. That is that, over time, the team members from different 'language groups' actually become multi-lingual and begin to understand the concepts and ideas from other languages. This is more natural as it is exactly what happens in the real world when people with different langauges interact. First they have no idea and rely solely on any common solutions, but over time they begin to understand more and more of the language that others are speaking. The team members that can communicate in different langauges become multi-skilled and are generally far more valuable to the company.

In the end, there are a number of ways to deal with multiple languages. Our family weekend used translators and a lot of repetition to move information between people. This is also possible with software languages but is vastly more inefficient. Unless you are lucky enough to be dealing in a single language, the best thing to do with software is to learn and understand what other teams are doing. The people that can, become much more valuable such that their value is greater than the sum of their individual skills, because when a company loses people like that, they are forced to go back to having high rates of repetition and the real risk of losing logic and complexity in the transition of ideas and information between language groups.

Office space

2011-07-16T05:36:00.000-07:00

It was a double public holiday in the Czech Republic last week. Two days off for every man woman and child in the country... except me. I had the great idea that I would stay in the office and take the days off at some other time when it suited me better, which is a fine idea until you realise that everyone else is off enjoying themselves while you are stuck at work.

Oddly enough though it really was quite nice. No-one was looking over my shoulder or asking questions and the fact that it was so quite meant that I got twice as much work done as normal!

I must admit I thought that if there was no-one else around then it might be easier to get distracted and I would probably end up messing around for most of the day, in fact, the complete opposite happened. I found that I could keep more things in my head and delve more deeply into them without even thinking twice about it. It's kind of strange really, our office is not super noisy at the best of times, but it really doesn't take much to get distracted when you are juggling different levels of abstraction and concepts in your head. Someone is usually asking a question or explaining something and even though they aren't talking to me, the idea that they might say something to me or that I could contribute to makes me listen at some subconscious level and distracts me at a much more conscious level.

Joel Spolsky has it right

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that's so comfortable you don't feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can't see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll.

So why don't we get our own office? Why aren't there unlimited beverages? Is it really cost or is it some deep seeded belief that people will work just as well without these things?

I can understand in companies that are run by business people, the MBA types that believe all businesses are basically the same and there is some kind of formula the applies to all. These companies seem to be run with the belief that the people actually doing the work are the least value and most easily replaced part of the company... so why should they get any extra benefits? But in a company run by and founded by software engineers themselves, there is no real excuse other than perhaps the thought that these things cost a lot and don't have a high return on investment. Well I would argue that doubling the output of an employee would pay for almost any layout and furniture changes that you could think of.

Why traditional design methods don't work in a software environment

2011-07-07T12:34:00.000-07:00

I'm sure we've all heard it before, a project was going so well until the customer/client/manager changed the requirements/design/scope on us at such a late stage that everything has gone to hell. I know I have, in fact up until recently I probably would have been one of the people saying it!

Tradition
You see I'm not actually a software engineer, I just kind of fell into this role as a software designer through chance and the lucky discovery that I actually enjoy it. At university I studied aerospace engineering which - in terms of how long it has been around for - is not that different from software engineering when compared to civil or mechanical engineering, but in terms of development methodology I find it hard to believe that it is anything like software. Now I have no idea what they actually teach in software engineering course, but aerospace engineering promotes what I would call a more 'traditional' development methodology, one that works similar to the waterfall model. This works great for aerospace because you really need to have all of your requirements, high level and detail design done before you can even think about beginning construction! I used to think that software engineering worked exactly the same way - you define exactly what you are going to make down to the smallest details, then you construct it, verify that it works and iron out any bugs and then deliver it to the customer who is exceptionally happy with their bug free product that does exactly what they expected and wanted it to do and everybody lives happily ever after.

The Problem
Unfortunately, every single project I have ever worked on, regardless of the development methodology, has never managed to refine the requirements and/or design work enough to avoid significant last minute changes. Have these projects been exceptionally difficult or multi-faceted? Not really, although they have all had their specific quirks and challenges. Have the clients have been particularly difficult? Not particularly, certainly not any more than expected. Is it because of the people (including myself) defining and designing the software? It's definitely possible. All of these are valid reasons for a project to lose it's focus and suffer requirement creep, but the main issue in all of these projects was not the process or people involved, but rather their understanding of what it means to develop software.

Software as Design
Most people think of developing software as the end point, or the construction phase, of the development process when actually, developing software IS the design phase.
Let me put it this way, when an engineer develops the specifications for a desk, they define some requirements

must be big enough to work at
comfortable height to sit at
solid enough to carry enough weight etc

They then do a detail design document, perhaps based on a prototype

four legs made from 40mm square timber
one 30mmx1.2mx2m bench top
16 10mm screws inserted into the legs at xyz positions etc

Ok so I have clearly never made a desk before, but the point is that this allows someone, either themself or a skilled labourer, to construct the desk, or construct 50 of them and they will function precisely according to the original requirements.

Now lets think of software development. First of all a designer creates the requirements for a web page,

have a splash screen introducing the company
have a contact form
work on multiple browsers etc

But when it comes to the detail design, how can you possibly create something detailed enough for a software developer to recreate that exactly once, let alone 50 times over?!

The answer is, you can't. Because creating software is a design exercise and the construction component is actually done by the computer itself, in the compiler and the linker. The computer accepts a rather rigid design document that must follow very specific formatting and have exactly the right inputs to achieve the desired output. This is similar to our skilled labourer from before, imagine the detailed design didn't specify the dimensions of the timber legs. At worst the labourer would be unable to create the table and at best it would probably not meet one or more of the requirements.

Agile development

So if the software is still being designed up until the moment it is complete, then why shouldn't the client, manager, designer, programmer or any other stakeholder be able to change things? And if they are restrained from doing so then how can they possibly know what the product will turn out like?

This is where the theory of agile software development comes from. Small chunks of work (design) are completed so that the stakeholders can see, understand and review the design without having to wait for the entire process to be complete.

Agile software development does not completely avoid the traditional method, rather it minimises it down to a manageable level, or as Martin Fowler puts it - a predictable level.

The key to iterative development is to frequently produce working versions of the final system that have a subset of the required features. These working systems are short on functionality, but should otherwise be faithful to the demands of the final system.

Iterative, agile development makes sense in the computer world. Isn't that how computers solve problems and perform all of the magical things that they can do anyway, through a series of iterations? But for so many people (in particular those like me) who come from more traditional backgrounds it is very hard to see things in this way without feeling totally out of control of the situation. The problem is that by limiting the entire project to what you consider to be a manageable or predictable scope means that you are assuming you have thought of everything in advance, while it may be possible for something small like a table, I guarantee you it is almost impossible to do with anything larger or more with complex requirements.

!programmer (~programmer)

2011-06-26T12:31:00.000-07:00

The above statement is true, which makes part of it false which makes the whole thing quite confusing. You see I'm not a programmer, but I need to understand a bit about how to write code as I work in an industry dominated by programmers. I'm also neither an artist or a manager of some sort. So what exactly is it that I do around the office each day?

Drink a lot of coffee.

Well apart from that I also fulfill a middle role known as a software designer. But what does that really mean? As a software designer I don't actually get in there and get my 'hands dirty' by doing actual programming work to make the core program function, but it is important that I understand what they are doing at a relatively detailed level. Nor do I build models and create textures like an artist, but again it is important that I know what they do.

A software designer is someone who basically brings the two elements of code and art together to make a functioning simulation. Programmers typically work best when they have a quite limited scope, they make a function work exceptionally well as long as they are given the freedom to largely ignore its impact on the product as a whole. I know of companies where the programmers are also the software designers, but a lot of the programmers I know simply don't think on that scale. They can see right through the code, down into the function that they are creating and its impact on the simulation, but it can be difficult (with good reason) to see how that affects the product as a whole.

A good software designer looks at the product as a whole; from the user experience, to the details of the UI, to the behaviour of different simulation assets and down to the functionality of individual game mechanics and functions to see what needs improving and what can be added.

Let me give you an example.

A customer requests a new scenario in an existing product that is capable of training units on the capabilities of the opposing force. As usual the customer doesn't really know what they want and it is down to the team to decide for them. Given that this will fit into an existing product, there is an obvious list of basic, new requirements; a basic interface, a large, multi-player environment, the individual functions of the players, the overall goal and scoring mechanism, any AI behaviours and reactions, new vehicles, terrain and unit types etc. Lets assume for a minute that all this work can be done by the artists and programmers on the team. So they go away and create all of these magnificent functions and models and at the end of it realise that the customer didn't pay for a bunch of raw models and functions, they paid for a scenario that people can play to learn the capabilities of the opposing force. So back they go to create a scenario that draws all of this together and quickly realise that any player interaction breaks the AI behaviour patterns, that the AI cannot interact with new vehicles in the multi-player environment and that because of the scale of the environment, the entire scenario grinds to a halt with all these new vehicles. To fix all of these bugs requires a base level redesign of the original functions and re-modelling of the vehicles and in the process the basic UI becomes so bloated and out of sync with the rest of the product that is essentially unusable. So we are back to square one (albeit with many lessons learnt along the way) and need to start again, or hack this off as a separate, difficult to support, product.

You could argue that this process broke down due to bad project management, the tasks were not identified correctly and bugs not caught quickly enough. You could also argue that this was a lack of communication between the programmers and the artists, or perhaps you might even be gutsy enough to blame the customer for their lack of focus and direction. At which point they may stop paying you!

What this process clearly needs is someone with the scope of the project and the current product in mind. At the same time that person needs to have enough knowledge of the functions that are created by the programmers and how the models are created by the artists to talk to them intelligently. This person is a software designer.

So that's what I do, I think about the project within the scope of the product and try to design it so it is functional from a number of different viewpoints, not least of all the end user. In my line of work, a software designer actually brings together these elements in a separate language used in the simulation. The language allows the designer to use programming functions and incorporate models in a way that is consistent with the product as a whole yet customisable enough to develop individual scenarios for customers. While you could easily argue that a whole new language is excessive, the critical role of a software designer is very hard to deny.

Playing Again (and again, and again …)

2010-09-13T13:53:00.001-07:00

You want to know what the games industry learnt years ago, that we in the simulation world are only just catching on to? Replayability. Or in other words replay value.

What do you see in the best games out there today? Typically that they last for a long time the first time round, and that you actually want to play them a second time because they are so much fun. The way I see it there are three key ways of creating a replayable game,

Randomise parameters
Create multiple play paths
Add true multiplayer

So what do I mean by that? And why would we even want to do it in the first place? I’ll start with the second part.

Why do we want replayability?

Have you ever tried to teach someone a concept using a simulator/simulation and seen that look of interest die in their eyes after they run through the scenario once and then the second time it is exactly the same? Or worse still, when a trainee ‘gets it’ because he/she can complete the training course in record time? This is because the simulation they are playing lacks replayability. Interest is a very real part of any learning process and it’s important that the simulation be at least challenging when the trainee plays it in order for their mind to keep working and understanding. Computers are excellent at repeating exactly the same thing time and time again, which is in most cases a very good thing, but a good simulation adds in an element of randomness to keep the user thinking and reflecting on what they are trying to do.

How to add replayability?

As I mentioned above there are three key ways of introducing replayability into a simulation.

Randomising Parameters

Things like randomly selecting where the player starts, what kind of things they have available to them and where the challenges are placed/what their solutions are make a big difference to how the game plays and to it’s replay value, but they can be very hard to add to a simulation after development. Easier things to do are to randomise the location/appearance of objects in the scene or to add in background noise/effects to distract the trainee. Many games currently do this very well.

Create Multiple Play Paths

Multiple play paths can come in the form of the traditional ‘choose your own adventure’ where one decision influences the next, or they can be of the style of independent paths from different characters or start-up parameters. Multiple play paths (particularly of the former type) generally have to be integrated into the simulation by design, but if the simulation is part of a wider training program then it is definitely possible to modify the training adjusting the players abilities/resources during other components of the training. One of the best games I have seen that does this is Fallout3, where you have not only a huge world to explore and many different, non-linear game paths but you can also play your character in different forms and end up being a tradition bad/good guy or even somewhere in the middle.

Add True Multiplayer

Ok, so this technically is a combination of the above two. True multiplayer allows for multiple play paths and randomisation by simply adding other human players. I say ‘true’ multiplayer as it is very easy to add multiplayer by simply allowing other players to connect and see what each other are doing. True multiplayer allows the players to interact and build a completely different game depending on their interaction. Again this requires dedicated thought from the design upwards and is particularly challenging as multiplayer really does add another dimension to a simulation, which can often be difficult to predict and control. A perfect example of this in the gaming world in World of Warcraft which is recognised as the biggest online gaming environment in the world.

Adding replayability is important to make learning fun and challenging and as long as it is considered in the design phase, it is not particularly difficult to integrate into the simulation.

Putting Simulation in Perspective

2010-08-30T12:29:00.001-07:00

I was looking at some Escher paintings the other day. I have always liked to look at them, every time I do I get something new out of them; this time it was just how important perspective is when you look at a complex system.

The same can be said about simulation, depending on your point of view you will see and expect very different things from the same simulation. An important distinction to make when it comes to simulation, is the concept of a simulation vs a simulator. It is generally true that a simulation runs on a simulator, but the two are not dependent on one another. It is a common mistake that people confuse the two because of the perspective that they view them from. I have detailed a few below.

1. Simulation = Simulator

This is typically the person/organisation who are looking to use simulation as a training tool. They look at simulation technologies from the perspective of a flight simulator. This is particularly frustrating from Defence clients, who seem to believe that there is little or no training benefit to be had without a $20 million simulator running the simulation. Conversely, the simulation = simulator crowd generally believe that there is no benefit in using simulation for analysis.

2. Simulation as a solution

Everyone in this industry has heard of attempts to solve an entire problem through simulation and consequently how it has failed miserably, so much so that it gets tiresome to hear/read about how we shouldn’t try to use simulation as a one-stop shop for our problems. People who employ this technique typically see simulation as a complex tool, so it should be used to solve a complex problem. Obviously things are never so simple.

3. Simulation as an exact science

This is similar to the ‘Simulation as a solution’ perspective, in that it entails a lack of understanding about what simulation is and how to use it. While it is possible to get accurate results to a particular problem using simulation, the costs generally rise exponentially with the complexity of the problem. In general, simulation is best used to narrow down possibilities, and refine results. A simulation that may find a few possible solutions out of hundreds or thousands of options will probably not be the best simulation to find the exact parameters that define a solution and vice versa.

4. ‘Simulation is no substitute for real life experience’

This is a clear perspective problem and it comes from people who expect simulation to exactly replicate real life. In one sense, this is partly propagated by the industry itself – as simulations get more and more realistic, so do people’s assumptions of what it must be capable of. In general however, simulations, for all their fancy graphics and computational power, are only as good as the design they were developed for. People/organisations are slowly coming around to the idea that simulations try to emulate key elements of real life, but not real life itself.

I think there are two key issues that the simulation industry as a whole needs to work on, to help give clients a better perspective -

Expectation management
Problem definition

By giving clients a better perspective on what simulation is capable of they can begin to more clearly understand how it can benefit them. By giving the problem the right perspective, it can give the client greater benefit. Otherwise, at the end of the day all you and the client are going to see are a series of technologies intersecting in odd and confusing ways, much like the staircases of an Escher painting.