GGJ 2015 – Pwrong


I was lucky enough to take part in my first Global Game Jam last weekend in Montreal. I had a load of fun, 0 hours sleep and finished a fun little game with my friends!

The theme for the jam was “What do we do now?”. Our entry “Pwrong”, is a 2 player game for Web and Desktop. The game is about discovery and surprise so I will not say any more here for now!

Go here to check it out here, have a friend (and maybe 2 game controller) ready and please, let me know what you think!

The Grid – A 2-Player thinking person’s board game.


In an effort to keep up with my goal of making a game each month, I recently finished “The Grid”. As usual, I love to get feedback on these projects to see what I can learn from them. However, making a good tutorial is time consuming and not always worthwhile for prototypes that may go no further. So, below is a (very!) small outline about the game. If you just want to play it, find a friend (or your imaginative alter ego), get the Unity webplayer (eurgh) and go here. Remember you can pause and see the controls by hitting “space”. If it doesn’t make sense then next time I see you we can sit down together and play it, or I’ll eventually get round to making a tutorial…


Each player is trying to hack into the enemies server. This means installing one of your pieces behind the enemy firewall, making it a server and then connecting to it. Alternatively a player can win by taking all the enemy pieces.

You can:

– Put pieces down

– Explode them!

– Reclaim them

– Turn them into traps or servers

– Connect to servers to install your pieces further ahead or win the game!

– Wait for traps to take an enemy out and then use it as a server

Below are some annotated image showing what is on the board. Thanks to @aubdev for the alpha art!

Enjoy!!!  (


Space Miner Unity Prototype


In an effort to start submitting my own designs for one game a month and to keep digging into Unity3D I recently completed a small 2D game. You can play it here.

It is called “Space Miner” and is about capturing and refining a particular resource called “Obtainium” (Thank you James Cameron). I wanted to make a game that forces the player into make split-second decisions that balance this resource collection with staying alive. I aimed to achieve this with the following:

  • Each token collected will slow you down a little
  • You can spend one token to perform a small dash for speed
  • You must process your collected tokens in order to score them
  • You must avoid being shot by pirates who will chase you down
  • You must avoid being hit by asteroids
  • Enemy miners will also turn up to try and get obtainium before you can get to it
  • You must also process (score) all tokens before the time is up

The player must weigh up his need to avoid pirates, weaving in and out of asteroids whilst trying to beat other miners to the obtainium before the time runs out.

The link leads you through 10 levels of sample prototype gameplay; you will need the unity web player to enjoy it.

Any comments or feedback would be most welcome, enjoy!

A guide to setting up C++ Lua bindings with Swig in Xcode4


Having written Lua bindings before, I decided it was time to explore more automated options. Binding for Lua isn’t too tough but as projects grow more complex in syntax and dependencies, I decided that letting a tool do it for me is just fine. I spent an evening getting a test for Swig setup in Xcode4 and nothing I found online was exactly spot on for me, so here it is.

Swig is a command line tool for compiling files of a certain form into C or C++ binding files. It binds to several languages, check it out here.

Lua is a fast, established scripting language commonly used for games due to its speed and flexibility. There are many arguments (often in my office) about which scripting language to use as hardware improves. For the scope of my current projects however, Lua is perfect. Choice made.

1. Setup. Install Swig and Lua. I advise using something like Homebrew / Macports / Fink. My current preference is for Homebrew. It is more modern and seems cleaner to use to me. But the end result is the same. You just need header files for lua in a known location (eg. /usr/local/include). Homebrew will set this up for you with symlinks as well as putting the dynamic libraries in /usr/local/lib/. The relevant binaries for command line stuff will also be done. If you want to look into building this stuff then it isn’t to tricky. Lua comes with a makefile and you just type ‘make macosx’ then sudo copy the files where you need them. Honestly though, use homebrew. Then it’s as easy as:  brew install lua && brew install swig

It can be found here

2. Headers. Start a new Xcode project. We’re aiming to bind C++ and we’re just getting things setup so I’ll choose ‘command line tool’. We need to get Xcode recognising our header files and libraries. If you used homebrew then they’ll be under /usr/local/… most likely. Where they are, you’ll need to click the project icon on the top of the file tree for you project. Go to “Build Settings” in the main window and make sure your mode is set to “All” NOT “Basic”.

Scroll down to the “Search Paths” section. You’ll see 3 search paths. Framework, header and library. Frameworks are a combination of dynamic libraries and headers (and other resources). In our case, we havent compiled Lua as a framework. Homebrew gives us the headers, dynamic libraries (dylib) and binary files for command line stuff. So we need to add the right paths to “Header Search Paths”. Remember where you installed them (/usr/local/include for me).

3. Linking. With the “Library Search Paths”, we also need to tell xcode where to look. With this step however, we will also need to tell our program to link against the library. This is because we need to know where to look but also what to link at runtime. This way we will actually be able to find all our fancy lua functions that we want to use. Simple go to your target on the left hand column of the build settings. Choose “Build Phase”. Open the “Link Binary with Libraries” and hit the plus button. Then navigate to your “liblua.dylib”. (Hit Shift+Cmd+G to get terminal-navigation in finder)

Once you have selected the lua library, Xcode will take care of the search paths too. You’re all set!

4. Test. Now you’re ready to test stuff out. As always, test in increments. Does Lua work? 

– Firstly create a file called “test.lua” or similar. With this in it  print("Hello Lua!")

– Then use the following as you main.cpp

– Hit Cmd+R to run you program and you should see “Hello Lua” in the console output.

5. Swig. Now for the meat in the sandwich. I’m going to bind the following class to Lua.

I’m keeping it super simple for now, I just want to get it set up and understand my workflow for Swig/Lua. The implementation is in a cpp file and I’ll leave you to fill that in, but make sure you have actually defined these symbols!

You can then create a ‘swig’ file called “TestModule.i”. When you do this, Xcode will probably set the file to compile. Go to your target build settings and make sure it isn’t in the “Compile Sources” list.

I’ve seen a muddle of reports on how this file should look. But here is the cleanest thing that worked for me.

Make sure you use both the swig and C includes. Without the latter, nothing will be bound whatsoever.

6 Final Test! Here is the check list for swig.

– You have you simple C++ class for binding. This include it’s header and .cpp implementation.

– You have you Swig file ready

– Run ‘swig -c++ -lua TestModule.i’ from the command line. This makes a TestModule_wrap.cxx file.

– Add the above generate file to your project. We need that to be compiled and linked for our bindings to work

– Change main.cpp to look like this:

– Change test.lua to

– Hit Cmd+R and you should see:

BOOOOOOOM! You’re all set.

Maybe you’re thinking ‘bu..b..but Pete! It didn’t work.’ I often read guides and get the same feeling. If this is the case, Google is your friend. If Google fails you however, get in touch and I’ll try to help if I have time.

Good luck. Have fun.

GSD Project 3: Breakin and the pitfalls of rushing code


A significant part of ‘Getting Stuff Done’ has been to write code quickly. This is not a prerequisite in general, for doing things, however, for me it has been important. I do not want to find excuses for not finishing projects or procrastination. With this in mind I launched into my latest project, a simple variant of ‘Breakout’ called ‘Breakin’. The idea was simple to build on the code written for my last project and see how quickly I could write the application code on top of the ‘engine’ I’ve started to piece together. It started out good, got bad and ended up ugly.

The Bad

I started out well. I re-factored some component code to be more generic, added a simple template class for a Grid data structure and a new sub system called ‘CollisionEngine’. With each of these improvements, my intentions were pure (of course). When it came to using them together with a new Entity type, things unfortunately fell apart. The reason for this is two fold:

  1. The engine code was written quickly and tested ‘on the fly’ (bad bad bad)
  2. The structure was not designed as much as it was stuck together with tape (see above)

Add to these a couple of ill-advised late night coding (hacking) sessions and I had a problem on my hands. I had progressed from the odd programming faux-pas to a sinful mess of pointers and nightmares. I dug about in the code and see the errors, the causes of memory slicing, shallow copying and other such badness. So I know what needs to be fixed and what I left out in my haste (and what never to leave out again). Having come quite far with the implementation, and wanting to ‘ship it’ I decided to work around it until the next project. Sometimes you just have to find a way to progress.

The Ugly

Workarounds are sloppy. In a production environment they are often, unfortunately necessary. Given that one of the aims of ‘Getting Stuff Done’ is to set deadlines, I had little choice. The result however, is a rushed body of code that just about functions and needs to be left to die a quiet death. But this is okay. When I started the project I had no plans to design a lovely neat system. As I progressed, the developer in me couldn’t ignore the code repetition and inefficiencies of hacking out 2D games. So I cobbled together a small system to help me out. I was happy to hack this and learn how far I could go. I dressed the mutton-engine up as a lamb-engine and made use of it. The key to the next step is to take what’s good about the code and roll it into a new system that is more robust and considered.

The Good

While I gained a tonne of knowledge from the flaws in my old code, this project did yield some important revelations from the implementation itself.

Firstly, I was able to implement a handy little Grid template class. This is a data structure that allows access to objects based on a cell index. This cell index also has mappings to world and object space. My implementation is super simple and will change and grow, but it was written in half an hour and served me well for project 3. Below is a snippet of the class, some of the implementation detail has been left out, but you get the idea.

Secondly, I implemented a CollisionEngine subsystem. Like the Renderer introduced in Project 2, this is a singleton instance that the Engine will update separately to the game logic. The actual implementation is not final at all, it will probably undergo a complete face-lift. The principals explored during its implementation however, have been revealing. Detecting collisions and responding to them correctly and at the right point in the update loop is key. When iterating over all of our collision bodies, we don’t want to respond to this collision and invalidate the iterator. If you do this, you’re going to have a bad time.

What Now?

So where does this leave things? Well, Breakin is a much less complete game than my first two projects and it has left the code base in somewhat of a limbo. So now I plan on doing a ‘Getting Stuff Done Mini-Project’. The aim here is to re-construct the engine code in a more robust fashion. In addition to this I want to reduce dependencies on SFML. Ultimately I just need to design what I have properly, with good, simple interfaces.

So that’s it. A small update but a key one. While work has been busy and the project tricky, it’s key to keep my goals clear and deadlines tight.

When the code is re-written I’ll slap it on github. As always get in touch and let me know your thoughts if you have any.


Breakin from Peter Smith on Vimeo.

GSD Project 2: Pong for Pongs sake and Entity-Component Design


For my next project I chose Pong and this ‘Getting Stuff Done’ task was a little more code focused…I’ll explain why in a second. For now let’s review the goals from last time: Make a fun game. Write nice, clean, well thought out code. Have a complete application to share. Set deadlines and work to them. Be proud of what I make. Post about the project and get feedback

After completing Project One I decided to review these goals slightly and here’s why. Choosing easy games to start with allows me a certain degree of confidence that I will see the project through, which in itself is great. I have deadlines, and work to them. I am proud of what I make and I get some feedback. The main loose end for me, however, was the code.

Like most of the code that I write during this series, some will be good and some will be… less good. With Project One, this was certainly the case. The main problem, however was that very little of the code was reusable. Having got some general feedback, I wanted to make sure that my design allowed for cleaner higher level systems in the future.

So why Pong? Pong is one of the easiest games to implement. I had the basics working in a couple of hours. This was perfect, and allowed me to spend time on some interesting design problems that will make my life a lot easier going forward. With a more reusable code base, bigger projects in the future will seem smaller. This echoes the main concept of ‘Getting Stuff Done’, start simple and build complexity. 

So my new goals:

  • Make a fun game
  • Make a nice, clean, reusable code base
  • Be mindful of competing demands between point 1 + 2
  • Have a complete application to share
  • Set deadlines and work to them
  • Be proud of what I make
  • Post about the project and get feedback

I won’t go into the game implementation for this one, there will be more of that in future posts. I will however, do a brief overview of the key parts of the code.



The above diagram shows a naive implementation of a typical game object. While for Tetris or Pong this may be sufficient, it quickly becomes a trouble to maintain. Object grow vast and update loops become impossible to read, this is something I picked up even when implementing Tetris. While the separate parts of the object may be encapsulated in the whole there are a some drawbacks, not least:

  1. Configuring similar objects requires complete re-coding
  2. Each of the constituent parts must be developed as part of one monolithic class
  3. The code quickly becomes hard to maintain as we lose track of the interactions between elements in the game loop

To simplify this further, we could break things down in the class and adopt a more functional approach.


Unfortunately, while this may tidy things up a bit, it still doesn’t abstract different logical blocks away from the particular object.

Enter the design pattern, Entity-Component. The diagram below shows the next iteration of our simple game object. (It’s worth noting that in practice we would split the ‘pos’ attribute further as is it common in all game objects)


And below in it’s final, encapsulated form.


In this system, the components are separate classes of object that, through a common interface are still able to work together. This allows us to develop each component individually whilst still being able to rely on the fidelity of the objects other components.

The key to all this is messages. The only thing that the Render Component needs to know about the Movement Component is when it moves. So all we have to do is give the object (entity) some mechanism for handing messages between its components.


The diagram above shows this in action. We provide each component with a pointer to its ‘owner’. We are then able to broadcast messages to all the other components via the entity. When our position changes, we can hand a “Point Moved” message from the Move Component to the Render Component. The render component can read this message, process it and will in-turn broadcast a “Shape Moved” message.

This does come with a small overhead of function calls, but if done correctly will result in a lot more good than harm. The biggest challenge here is how to send data with the message. I experimented with inheriting a BaseMessageData class, and using dynamic_cast (avoid!) for particular types of message. In the end though, I simply define a Message like so:

This allows us to determine type without using runtime type information (RTTI). This works nicely. No matter what we do the components will need to have knowledge of the implementation of particular message data. What this class allows is a simple way to get the data as the type you need and to start using it. It probably isn’t the best way, but for now I like it.

I used something similar for defining a SimpleEvent class.

The key difference in these two things is:

  • Messages handle internal component communication of an entity
  • Events are game-wide things that occur and effect the game state (e.g. Point Scored)

With the simple event implementation I am easily able to grab an instance of the event subsystem and dispatch events. All I need to do to catch them is register a class that implements the following SimpleEventListener interface.

I am convinced that there are better ways to do much of these things, but these implementation serve my architectural needs. If you’ve got suggestions, let me know. I always want to learn from the collective wisdom of other experienced code-monkeys!

The last thing worth mentioning is the role of engine subsystems. Whilst an entity is a type of subsystem with knowledge of all of it’s parts, entities cannot live in isolation. The game must know how to control them of course, but other parts of the engine need to know about them too. For example, in my implementation a Render Component has knowledge of how to talk to the Renderer (a singleton object). In the future, as I improve the code, interactions will work through a singleton InteractionEngine (in lieu of a full physics engine). It is clarifying concepts like these that will allow clean, modularised code going forward. This way my Engine class can simply get all the subsystems going and allow them to talk to each other as the game runs.


Check out the code here, as always feedback is most welcome. Getting your thoughts is always great. If you would like me to explain any concepts or terms further don’t hesitate to ask!

Project 3 incoming, good luck!

Game download (Mac OSX 10.8.2)

GSD: Project 1- Tetris Variant


For my first mini-project of 2013 I chose Tetris. I will be using C++ and SFML for all upcoming projects. To recap my last post; here were my aims going into it.

Getting Stuff Done, checklist:

  • Make a fun game
  • Write nice, clean, well thought out code
  • Have a complete application to share
  • Set deadlines and work to them
  • Be proud of what I make
  • Post about the project and get feedback

A fun game
Tetris is an old school 2D arcade game originally credited to Alexey Pajitnov (see the wiki). I’m going to assume you’ve heard of it. I take no credit for the basic idea. The choice of game was deliberate. My first concern is not design, eventually I will add that to the checklist above, but right now I’m focused on creating some kind of Tetris variant.

Nice Clean Code
Before starting a project, it’s difficult to anticipate how this might go, and as system design isn’t on my list I didn’t do any UML diagrams. Remember the aim here was just to get started, and more importantly finished.

Complete Application
I’ll link this at the end, needless to say it got done!

Set Deadlines
I set myself the deadline of only one week. The project is small enough and I decided that this would push me enough to make sure I was ‘on it’.

Be Proud
The proof is in the pudding, but if I meet my aim of getting it finished and making it fun to play, then I’ll be proud.

Post About It
Uh… here we are…

Getting stuck in

The first thing I did was shop around for game engines. This isn’t a bad thing to do, but I’ve got caught up in this before and lets face it, Tetris doesn’t require much tech. I started out using Cocos2d-x the multi-platform C++ cousin of Cocos2d. This was working out well, and it seems a very good option for developing mobile apps. However, after a little battling with keyboard input and other such things, I stumbled upon SFML. The C++, object oriented little brother of SDL. I chose to port very early on, which set me back a few hours but it was worth it. Keep your engine simple.

With several hundred code pounds shed, I moved on and thrashed out the basic game mechanics. I don’t want to go too deeply into this, there are plenty of Tetris clones about, feel free to check the code out later. The premise is simple, a tetrimino is made of blocks. We add a slowly falling tetrimino to a grid of same sized blocks and let the user try to arrange these shapes in a compact game-winning way.

During the early stages there were frustrating moments. You miss a value, or battle with your API of choice, but you get past this. After a couple of days with a basic, buggy version working; the game takes shape and so does the code. You begin to understand how your update loop should work, what order of operations you need, how to handle player input and why your bloody L-tetrimino wont rotate properly. As long as you have the basic features down, the rest is about iteration. A bug can be fixed or a decoration added. Design-fun can begin if you get a prototype done early.

A very significant thing that I was able to do was hand my early version to an honest play tester. She was able to give me a list of about 8 bugs or improvements that she could think of. This is invaluable! I cannot stress enough, if you have something that you think closely resembles you core game, show it to people! Sure, they’ll tell you about some bugs you knew about, but they’ll tell you a hell of a lot more useful stuff. Get people playing it early.

After addressing some of the core issues I was able to focus on some decoration that, in my opinion really marks the application as finished. I used GIMP and devised a simple icon to use. I used an evening of development to write some music and sound effects for the game. I also made sure to complete the game play experience by adding in high score support with classic 3 character name entry. It is these things that make a moving a bunch of blocks into a game. In whatever way you can, tie a bow round your finished gameplay.

Having come to a point of completion, I began to review, refactor and clean the code up. I am still not 100% happy with it, but that’s how it goes; I had a deadline. I have added some comments in the source suggesting improvements but instead of adding in more modular code for rendering and handling inputs, I decided to draw a line through the potential endless tweaks. In order for ‘getting stuff done’ to work, at some point, you just have to ship it.

So that’s it
As I promised myself I would do, I worked to a deadline and got it done. I’m not going to change the code any more. It is far from perfect, but it’s sitting there on my server, in GIT as a point of reference. My next project will draw on the code and lessons of this project and that’s fine. The point here is not to make the perfect engine or game.

The code can be found here. You’ll also find the audio resources and Xcode project files.

Note: I do not own any rights to Tetris, any code or products are intended only for educational/hobbyist purposes only.

Game Download (Mac OSX 10.8.2)

I would love to hear your thoughts on this post, the code or the final product; or all three. I am constantly striving to improve and produce high quality content, so please feel free to contact me via the links below.


Tech Notes and after thoughts

I recently had a chat with a friend about heap versus stack memory allocation. He saw my code and noticed my use of the heap allocation in the initalisation of objects. For a game of this size, running on a high RAM machine, it really doesn’t matter. I did think it worth mentioning here though, that if you’re developing for consoles, or machines with small amounts of RAM, you will need a custom memory allocator. There is a very good chance you’ll never need to look at a memset or memcopy function, but just be aware of it. For my purposes, worrying about fragmentation and other low-level stuff was overkill. For more see this and that.

Having re-read the code and shared it around, it quickly became clear that in a larger game, my design would collapse. The update method of Engine.cpp for example would become impossible to follow. For my next project I will be exploring the ‘entity-component’ design pattern and trying to leverage events to clean up my code and make things much more extensible.

Share this post around and get in touch.

Getting Stuff Done


At the beginning of 2013 I picked up an old idea. It’s a game that I have had a design for, in some form or another, for a couple of years. As I began to develop a prototype, I realised that without more resources, time or collaborators, it would be unlikely to get made. This left me frustrated.

It occurred to me that a lot of developers that I know share this frustration. We often struggle to balance our day jobs, ideas and actually finishing personal projects. Considering this, I recently kicked off a series of deliberately simple, achievable projects. The huge game designs can wait. For now, my aim is nothing more than to just get stuff done.

As developers we should try to write good code, design systems that we’re proud of and bring projects to completion. This stubborn ‘just finish it’ approach interests me a lot. Giving myself deadlines, fixed parameters and a set of requirements to work to is extremely effective. We should try to take the norms of professional development and apply them to personal projects. I’ll write more fully about this topic in the future, if only to warn a pubescent version of me how it all works!

For now though, here is a list of what I will keep in mind as I try to get stuff done. These are things personal to me. If you want to get stuff done too, write a list of what you want to get from your projects.

Getting Stuff Done, checklist:

  • Make a fun game
  • Write nice, clean, well thought out code
  • Have a complete application to share
  • Set deadlines and work to them
  • Be proud of what I make
  • Post about the project and get feedback

Note that game design doesn’t feature in this list. I am constantly thinking about games I want to make, or design choices made in games I play. What I am trying  with these projects is simply to finish them to a high standard. When you get going you realise that even the smallest games, in a single persons hands, can quickly expand in scope.

If you have more ideas than time, hopefully you can take something from the ramblings that follow. Good luck!



I recently saw a small algorithmic problem set that set the challenge of converting between Roman (XVI) and Arabic (16) Numerals. The problem itself seemed fairly straight forward and after a little brainstorming I was able to come up with a basic design. Perhaps the most significant part, however, was trying to keep things modular and use a unit testing framework and become more familiar with the standard and practices expected in a professional context.

The design

Below is a diagram outlining the desired workflow. It is essentially an input->comput->output model aimed to work very simply from the command line.

This design highlights the need for 4 Classes: Tokenizer, Translator, Numeral and Validator. In addition to these I was also going to need a class setup for unit testing.

Unit testing

I decided to use python for this task and found Nose the unit testing framework. Check it out here

There was no particular reason for this, only that I was referred to it by a friend. It allows you to setup a class with methods beginning with “test_” then from the command line you can run ‘nosetests’ on the unit tests you’ve written, it was very accessible and seemed robust.

As a side note, unit testing is used heavily in test driven development and has become widely thought of as an important part of modern development cycles. With a known input / output expectation for any given function, class or module we can assert a whole bunch of things about the state of our data at any given point in the codes execution. ‘nosetests’ comes with some neat features for jumping into PDB if it breaks and will also allow code coverage data. For a full explanation on Unit Testing see the ever reliable wikipedia


There were a few challenges to consider when tackling this problem. I will go over two of them.

Firstly the problem itself. How do we go from ‘MMDCLXVI’ to ‘2666’ and back again?

Roman to Arabic

In the simplest case Roman numerals are simply additive. We can take the value of each character from the left and add them all up to find our number. For example “LXV” represents “65” in Arabic numerals because L=50, X=10,V=5.

However, consider the following: V=5, VI=6, VII=7, VIII=8, IX=9

Often to save writing loads of symbols, we prefix a numeral with a smaller subtractive symbol. So “IX” is 1 subtracted from “X”(10). It is this feature that led to using a tokenizer. We have to be sure our data is interpreted in this way. The method for tokenising this simply involve checking the symbol to the right of the current symbol and collecting the necessary symbols together into tokens. During this process we can also validate for silly input like “IIIIX” where “VI” should be used.

Once we have these tokens it is simply a process of adding their values together at the translation stage.

Arabic to Roman

There are some nuances to tokenising and translating Arabic numerals. I will leave it to the reader to consider how the algorithm might look. A hint: remember Roman numerals are expressed as a certain set of larger whole numbers.


The second challenge I will mention here is the validator. There are already modules around for doing validation, they are almost certainly better than what I came up with, but the exercise was a useful and fun one. The main idea behind the validation class is that it should only define the mechanism that can be used to submit validation queries. The user should be able to add their own rules to it and call them later. It should also have some useful defaults.

The way I chose to do this was simply store a dictionary of strings->functions. In python this essentially means that I expect to object in the value field to be ‘callable’ (implement __call__).

The validator also expects these functions to have a certain signature. (data, kwargs). This allows me to guarantee that any call to validate() will allow me to safely pass through the required arguments. I enforce this using the ‘inspect’ python module whenever a new rule is added.

The code

The code will be going up on my gitHub and although parts are still a little messy it should display some of the concepts I have gone over above.


Ray Origin


I recently begun to write my own raytracer. The reason for this was mainly to explore an area of graphics that I haven’t attempted to program in before (there are many). Another interesting thing about raytracing is that it relies on a virtually completely different methodology to other forms of rendering I have played around with (Deferred and Forward).

This post is written mainly for reference and for anyone who is trying to get started with their own ray tracer.

So what is a raytracer?

Put simply, it is a simulation of the interaction between:

  • Light Rays from Light Source
  • Objects in Scene
  • The Camera (eye)

The intention of this method is to simulate the physical reality of how light travels and how the camera interacts with a scene. I will supply some suggested reading below, but here is my explanation about the basics.

Important Points

  • It is expensive in general and therefore not usually a viable option for real-time rendering. New GPGPU techniques have exposed the potential for real-time results however
  • Familiarity with OpenGL or DirectX is no real help as they do not natively support ray tracing
  • This method is widely accepted as the most physically accurate one that supple realistic images

How it works

A ray of light is emitted from a light source. This ray travels straight into the ‘world’ and hits an object. Some light is absorbed, some reflected (depending on the material of the object). For our eyes to perceive this object some of this light has to reflect and hit our eye.

Forward Raytracing

Many rays shot for each light with many reflections off objects

We can calculate the colour of an objects surface in the same way as we do with many other rendering methods. The reader may be familiar with GLSL shaders, where we take the dot product of the inverse light ray with the surface normal as a coefficient for the ‘shade’ of the surface. I won’t go into this calculation here, but for more lookup ‘lambert shading’ or refer to my previous post / papers on deferred rendering here

A large problem with this however, is that for any given light (and we may want many lights in our scene) we have to shoot rays out in all directions and test to see if they hit the eye (camera). This is called ‘forward raytracing’.

This is computationally expensive and thus not usually a viable option. This involves an arbitrary amount of traces (what we call tracking a rays ‘progress’) and is too expensive especially on high resolution images.

Backward Raytracing

As a result, an eye-centric method is used. Essentially we say “okay, what can we see with the camera? Now does any light hit that?”. In the most naive case, we simply shoot a ray out for every pixel of the image and when we find the first object along the ray we shoot a ray to our light(s) from the surface to see if it is visible from the light (or is in shadow).

Backward Raytracing

We shoot a ray out for each pixel and see whats lit or not


In an effort to improve this very basic method, we need to add some basic features.

An issue with sampling only once per pixel is that we could easily miss some fine detail like sharp changes in topology or material colour.

Poor Sampling

We miss the colour from the edges of the sphere

This subject is really one for a signal processing expert, (see Nyquist–Shannon sampling theorem) but the general idea is we need to sample enough to capture all the details of our scene. The first step to do this is to split each pixel into a subset; sub-pixels. In the diagram below I have shown each subpixel with a random offset, this ‘jittering’ can improve visual output and is included for reference.

Jittered Sub Sampling

Improved visual results by averaging many samples per pixel

This method is sometimes referred to in relation to Monte-Carlo Integration. This essentially allows us to integrate the change in values over a domain to find an average ‘under the curve’. In simple terms, sum all colours sampled and divide by the number of samples.

Adding Materials

To account for the different types of materials in the world we can calculate surface colour in a number different of ways. To start with, I will cover basic diffuse and specular reflection.


This is the most basic of materials. When we find our eye-ray has hit a diffuse object, we simply trace to see if it is visible to the light. If it is, we perform basic “n-dot-l” lighting. Taking the angle between the normal and light into account, mixed with the surface colour we can find out what the eye can see.

Specular Reflection

This process involves recursive raytracing. The basic premise is the find the direction of specular reflection and send another ray of the be traced for diffuse colour (although if we allow it, more reflective samples can be taken).

Perfect Specular Reflection

Mirror like materials are covered this way

The psuedo-code for finding the reflection ray is:




N is the normalized surface normal
I is the incident ray (the incoming ‘hit ray’)

This gives us a direction to trace down. When using this technique without any other contributing colour, we have a perfect mirror reflection.

Earliest Working Raytracer

A basic ray tracer

Implementation Notes

  • The whole system relies on ray-shape intersections. So scrub up on ray-sphere and ray-plane collision detection. When you get to ray tracing meshes you’ll need ray-triangle too
  • Remember, you have to do this all in software (on the CPU) to begin with. All your chosen graphics API will help with is drawing a pixel array to the screen. (you can even just dump out the values to an image file)
  • Get started by representing a sphere and a camera only. Shoot a ray per pixel into the scene and draw black for no hit, white for hit…then keep adding the cool stuff on top :)

To do

The work currently in the progress includes:

  • Depth of Field
  • Refractive Materials
  • OpenCL Computation

Recommended Reading

There are tonnes of resources around so I only list a few key ones



As always if you have any questions or notice i’ve made a mistake somewhere, please contact me!

The code that produced the above image is here and uses cinder for some basic things

Go to Top