# Author Archives: Herman Tulleken

Herman Tulleken is a freelance game developer, toolmaker, and co-founder of Gamelogic. He thinks computers are a necessary evil to make games, and sees frying a CPU or two in the process as a worthy sacrifice.

# Rapid Game Prototyping: Tips for Programmers

In November 2013, two colleagues* and I made 30 games. Although I have done some game prototyping before, working on so many games in such a short period gave me some insights I did not have before. As I said to a friend, it’s like watching a television series in a few days, instead of watching each episode week by week – you just see different things.

In this article, I collect some of these observations in the form of a set of tips. I kind-of assume you are already familiar with the classical How to prototype a game in 7 days, which describes prototyping from a more general point of view. In some ways, this is a programming-specific extension to the ideas presented there. Continue reading

# Geometry with Hex Coordinates

$$\newcommand{\bv}[1]{{\bf #1}}$$ $$\newcommand{\bperp}{{\bf perp}}$$ $$\newcommand{\bproj}{{\bf proj}}$$

There is surprising little information available on hex-coordinates, despite how many games use hex grids. In this article I will explain some of the math so that you can do basic geometry in a hex grid, and design more elegant algorithms for your hex-grid games.

# How to Choose Colours Procedurally (Algorithms)

Changing the colours of art can be a great way to increase the amount of content in your game, and add variety and richness. It is relatively easy to implement. What is not always as easy is to get a set of colours that looks nice. This article gives some ideas for choosing colour palettes that look nice. Continue reading

# 50 Tips for Working with Unity (Best Practices)

These tips are not all applicable to every project.

• They are based on my experience with projects with small teams from 3 to 20 people.
• There’s is a price for structure, re-usability, clarity, and so on — team size and project size determine whether that price should be paid.
• Many tips are a matter of taste (there may be rivalling but equally good techniques for any tip listed here).
• Some tips may fly in the face of conventional Unity development. For instance, using prefabs for specialisation instead of instances is very non-Unity-like, and the price is quite high (many times more prefabs than without it). Yet I have seen these tips pay off, even if they seem crazy.

# Implementing and Debugging the Perlin Noise Algorithm

One of the most visited articles on our site – How to Use Perlin Noise in Your Games – also caused the most problems. The pseudo-code contained an alarming number of bugs (one of the nastier ones is depicted above), which made it difficult to implement. Readers pointed out these in the comments, and so helped to make the pseudo-code progressively more correct. But even so, some operations remained unclear, so that I finally decided to replace the pseudo-code with real and tested code. I really hope that all bugs have now been squashed!

In the spirit of this extermination effort, this article gives some pointers to get a version of the algorithm up and running as quickly as possible. It is an extension of the original Perlin noise article, and refers to the code now presented there.

# Bézier Path Algorithms

In the article Bézier Curves for your Games: A Tutorial, I introduced Bézier curves and Bézier paths. In this tutorial I provide some algorithms useful for working with Bézier curves: determining the length of a piece of curve; interpolating a set of points with a Bézier path; and reducing a large point set to a smooth Bézier curve. (Image by snuffyTHEbear).

# How Are Puzzle Games Designed? (Conclusion)

Over the last month or so, Dev.Mag has published five interviews with indie developers discussing puzzle game design. In case you have missed the series, here are links to the articles:

In this article, I give you my take on the info we gathered in our five puzzle design interviews; a kind of distillation of the various ideas the designers presented. The discussion below is terse with almost no examples; to see how these ideas play out in the design of actual games, you will find the original interviews more helpful.

# How are puzzle games designed? (Introduction)

We asked five developers of interesting puzzle games how they did it: what they consider a good puzzle, what processes they follow, and how they zone in on fun and manage difficulty. We will publish these interviews in the upcoming weeks; this is just a quick introduction that sets the stage for the words of wisdom from the puzzle design experts.

# Desktop Dungeons: Design Analysis (Part 2)

In Part 1 of Desktop Dungeons: Design Analysis, we looked at the core game play, interconnected choices, and tension of Desktop Dungeons. We saw that, despite its simplicity, this “ten-minute, one-screen” game offers the player endless variety through cleverly stacked core mechanics. In this part, we continue looking at what lies beneath this award-winning game; how choices are given meaning not only through their complexity, but also through the role they play in structuring an experience — an experience that progresses with the player, an experience that speaks a story.

# Desktop Dungeons: Design Analysis (Part 1)

A little more than a year ago, Rodain Joubert, innocently, put his latest creation on the NAG forums for community feedback. Even the first, raw prototype was liked right away. It was immediately accessible, and surprisingly rich. The 10-minute games that were promised were inevitably stringed together into many hours of play.

And there was lots of feedback. New versions were released, and a good game was transformed before our eyes into something special. At some stage, the gurus Danny Day and Marc Luck from QCF Design entered the scene; more versions came out, and something special became something that was nominated for two IGF awards, and finally won the IGF Excellence in Design Award.

And right now, players across the globe are waiting impatiently for the full version.

Desktop Dungeons has been skilfully designed. Here we will look analytically at that design, and learn some lessons that we can apply to our own games.

Quadtrees are 2D data structures, useful for efficient representation of 2D data (such as images), and lookup in a 2D space (where are those monsters?) In this tutorial, we focus on the implementation of quad trees that represent 2D data efficiently; that is, where quadtrees can be used to compress data.

# Using graphs to debug physics, AI, and animation effectively

Anyone who has stepped through code or has waded through endless lists of variables or log entries knows that these aren’t always the best ways to find certain kinds of bugs. For example, when a physics-controlled object does not behave as expected, looking at how the values of variables change on every frame can be a painfully slow and frustrating process – if you are lucky enough to be able to break into the debugger at the right time.

However, when you display the values of variables graphically, you can instantly see trends and relationships. This makes it much easier to spot errors and to track down what caused them. Sometimes it can even highlight problems that you were not aware of. Continue reading

# Make your logs interactive and squash bugs faster

With modern debuggers and testing tools, the need for logging is not as great as it once was. But there are times when debuggers won’t do (for example, on players’ machines, or when hunting down bugs that occur sporadically). For these instances, logging can still be useful, and with modern web technology, you can build a powerful logger that is more than just an endless stream of text.

# Guerrilla Tool Development

I have a weak spot for cool game development tools. Not the IDE, or art or sound tools – I mean the level editors, AI construction tools – those that developers develop specifically for their games. Those that you know could help you multiply your content, and craft your game just a little bit better.