Looking at Things from a Different Perspective

I often read that as a programmer you often have to approach problems from a different perspective in order to find the most elegant solution. Well I was made to look a right idiot the other day when I was arguing a new feature was going to increase the scope of the project; only to find out it wouldn’t. Worst of all it was a designer that came up with the solution!

The game we are working on has many complex systems built from components. In the game components control the generation of resources, the trading and transporting of resources and the consumption of resources. One of the main system loops involves a farm growing crops over a period of time and employees are dispatched to fetch these resources periodically. Each farm is a field in which the crops are grown and people collect the crops from the farm. Effectively the crops are a single resource.

The designers wanted to add a system in which the player could grow and harvest trees instead of crops.

Me: “Brilliant; we already have a system for that. We will just create a new farm type that grows tree crops. Pop on a producer controller and a fetch controller - job’s a good ‘un”.

Designer: “Yeah, yeah something like that. Except that trees can grow anywhere across the map and employees must visit each tree, in turn, to obtain the wood, and once the wood is obtained the tree takes time to regenerate, and the trees aren’t really owned by the farm because employees can gather from any tree. But other than that it’s just like a farm”

Me: “So…nothing like a farm. This will require a whole separate system in which field and farms are separated, in which employees work their way through every crop in a field. Each crop must have its own state to manage individual regrowth. Is it really worth all the extra time?”

Designer: “Hmmmmm…”

Designer: “Why not just make each tree a farm?”

Me: “Excuse me a minute… stabs pen through eye

Two Languages in One

I stumbled across this blog post the other day describing a new programming language called “Glow” and thought the premise behind the language design was really interesting. Unlike most programming languages that have a consistent set of rules, “Glow” consists of two major programming paradigms. The two rule sets revolve around, what the author describes as, “big programming” and “small programming”. At a high-level i.e. objects, systems, components, etc, you want a strict rule set: explicitly specified types, immutability, no side-effects; but at a low-level i.e. functions, tasks, etc, you want the flexibility of dynamic types and to keep the code minimal by inferring types rather than explicitly specifying them.

A two paradigm solution to application design could be really beneficial as it better describes the approach taken when planning and designing code. The “Glow” language enforces this via a “piping” system which controls data flow, access and mutability. Going forward with my programming language I wonder how I could integrate some of these concepts.

I plan on investigating further to see if any similar languages exist and whether users find they reduce code complexity, bugs and side-effects. Also I wonder what other coding complexities could be reduced by hybrid languages

Creating my Own Language - Functions

In my spare time I have been working on creating a new lightweight, general purpose programming/scripting language. I have no real intention of doing anything with the language beyond experimenting but I find that trying to create something can often help you understand why things are the way they are. I really wanted to create a syntax that embraced modern programming features (such as type inference, lambdas and concurrency) as part of the language’s foundation and not as boilerplate additions.

Originally the syntax for my functions looked a lot like a hybrid between Python and Actionscript (The language is optionally type inferred so the explicit types are purely there to fully illustrate the syntax formatting):

func Add(const x : s32, const y : s32) : s32
	const result : s32 = x + y
	return result

I was pretty happy with the syntax as I like the enforced coding style of Python with the syntax of Actionscript and I felt there was consistency between the variable/const declarations and the function declaration. However, once I started thinking about lambda functions (i.e. anonymous functions) I felt that the consistency between functions and variables started to break down. In most languages (C++ and ObjC in particular) the syntax for lambda functions is horrendous and I wanted to avoid the discord between function assignment and variable assignment. So I started to think of functions more like variables, constants or expressions (which are frequently passed anonymously). That train of though lead me to this syntax:

Add : func = (const x : s32, const y : s32 -> s32)
	const result : s32 = x + y
	return result

The above syntax is very similar to creating a variable or constant and it should be very clear how to use anonymous functions or how to assign functions:

Add : func = (const x : s32, const y : s32 -> s32)
	const result : s32 = x + y
	return result



SetDelegate((const x : s32, const y : s32 -> s32)
	const result : s32 = x + y
	return result)

By encapsulating the entire function signature inside the parenthesis it is now very easy to add support for multiple return types:

GetAuthDetails : func = (-> string, string)
	return "username", "password"

const username, const password = GetAuthDetails()

My next big task is to address concurrency and multithreading.

There's More to This Than Unity

Over the past year in particular many of the graduates applying for programming positions at Tag Games have portfolios that consist, in their entirety, of Unity 3D projects. It seems that many of the applicants coursework, games and out of hours projects are made solely using Unity.

Now I like Unity; it’s a great tool and when used in the correct scenarios allows for rapid development of 3D games and prototypes. However Unity also has its flaws (like any tool) and despite popular thinking is not always the best solution for every single problem in game development.

What worries me most is that some (not all) of these potential candidates’ programming and game development knowledge starts and stops with Unity and even more alarmingly the industry seems to be encouraging this.

A couple of my colleagues attended the recent Develop conference in Brighton and one of the main themes of the seminars seemed to be use Unity for everything; it’s cheap, it’s powerful; why use anything else? Is the mobile industry becoming overly dependent on Unity? If Unity was pulled from the virtual shelves tomorrow what impact would that have on the App Stores? This may seem a hypothetical question but this kind of scenario has happened before most notably when RenderWare was bought by EA . Recent rumours even suggest that Unity were subject to a bid from Autodesk; imagine if Apple bought Unity and only licensed it to Apple developers, does that sound so far fetched? Imagine the huge blow that would deal the Google Play Store literally overnight! This isn’t just true of Unity, but the risks are magnified as many companies entire livelihood is dependent on a single piece of closed-source software and one that doesn’t have many viable alternatives. It’s one of the reasons why at Tag Games we have our own in-house engine that often wraps different middleware tools from FMOD audio to Bullet physics. If for any reason we need to switch middleware we can without have a huge impact on our game code (however that doesn’t stop us using Unity if the task requires it).

Obviously I am not suggesting that every developer should create their own engine; one of the main benefits of using a standard tools is that new employees are often already familiar with the tech. However the fact that so many companies use Unity is possibly one the reasons that so many graduates spend so much time learning the engine. In my opinion this should not be at the cost of general, core programming techniques. Unity should be a tool that people learn much in the way you would learn SVN and GIT or C++ and Python. If Unity no longer existed a candidates entire CV should not be reduced to nothing more than scrap paper.

When presented with a portfolio recently that included a lighting demo in Unity one of my colleagues asked what was so impressive, “doesn’t Unity do that for you?”. He really wanted to know if the applicant understood the algorithms for calculating lighting and the skills for programming an efficient shader but ultimately all the applicant had learned was how to add a light component to a Unity scene. Unity should be used for demonstrating high level achievements such as making a game or for showcasing techniques for which rendering is just an aside (if you are creating algorithms for mimicking realistic smoke you don’t want to spend 20% of your time creating a particle renderer).

Another issue with only developing in Unity is that candidates often only have a knowledge of C# or Javascript. Personally I like applicants to know a wide variety of languages and ideally with different methodologies (functional, procedural, statically typed, dynamically typed, etc) and I have no issue with them demonstrating only managed languages as long as they understand the pros and cons. I often inquire about why they prefer C# to C++, expecting answers such as it speeds up the development process; instead the most common response is that “you don’t have to worry about memory management” (*alarm bells*). Newsflash…when developing for mobile you ALWAYS have to worry about memory management (read this article if you disagree). Garbage collection is not a silver bullet it is simply one method of memory management. Even Android Java developers (as mentioned in the Android documentation) have to be careful with memory allocations. With languages, like every tool and engine, it is important to pick the correct one for job and to play to its strengths. Managed languages are great at reducing development time but at the cost of performance (particularly on mobile). Selection is always about trade-offs.

So continue to use Unity to make games and tech demos but also understand what it is doing under the hood. Understand the basics of rendering, shaders, scene management, etc and remember that contrary to popular belief not every company is using Unity. In-fact I’d wager that most games are still written in C/C++. I just wonder whether the mobile industry should be investing more time in open-source technologies in case EA decide to get their wallet out again!

As an aside I wonder if Unity themselves are finding it difficult to hire candidates with the appropriate skills?

The Unimaginarium of Dr Downie


For a long time I have wanted to make something cool. Something useful and unique that people would use and say “Wow, I’d never have thought of that”. Something truly special. In short I want to make the coding equivalent of Reggae Reggae Sauce.

However I have come to realise that I am an unimaginative, code monkey; and worst of all I’m OK with that!

This weekend I set out to make a quirky and elegantly simple game for the Ludlum Dare game jam and for the life of me could not come up with a single achievable idea. Much to my chagrin, one of my work colleagues produced a beautifully addictive and simple little flash game and most horrifyingly it is not the first time he has done so. I, on the other hand; can only seem to think iteratively. Take some existing idea and make it bigger and better. Even during the Tag game jams (one of which my team emerged victorious) our ideas are always creaking under the burden of their own feature sets and inevitably the time required to read the tutorial far exceeds the original development time. I seem to be much more “Zoom Zoom Zoom!” than “The car in front is a Toyota”.

Yet give me an idea or a design and I can provide simple, elegant and innovative coding solutions and derive a great deal of pleasure in doing so. The world needs artists and ideas but it also needs mechanics and brickies.

So until I stumble upon the next best thing has anyone got anything they need me to be getting on with?