Bark Diary – Design Theory

Published February 16th, 2013
Category BarkDiary, Blog, Development


Another article in the development diary of Bark.

In this article I’ve decided to do a more theoretic approach to the development of our game. It will include a few tips on how I tackle the what and aaaah moments I’ve had along the way of developing our game so far as an independent game developer.

I love ideas, I love lists, I love processes and things that have a plan behind the action. Design process, those are words of delight to the organized (or perhaps unorganized) mind.

So.. Let’s actually take a few steps back before we take one leap forward. In the beginning, any type of game or product is more or less always starting out as an idea in someone’s mind-boggling, overly-creative and awesome mind – this person sort of has a direction for the game/product and content, a bunch of things he/she wants the game/product to include, and a slight idea of how most of it should look and feel.

Yet it’s just an idea and nothing to look at and experience. The flowchart of my whole design process, or rather the design principle is what I want to discuss in this article, and it goes something like this




The idea phase, often referred to as the brainstorm process really is what it sounds like; a bunch of brains blurting out whatever kind of ideas they conjure, no matter how strange or out there the idea is. We then hack away at the full list until a core of ideas that could possibly work together are left to work on. This is where a technical lead often will set his/her foot down and say “No, that’s impossible!”, and the director or creative lead should reply “Of course it isn’t, I know you can do it!”.

Giving those discussions and ideas time to sink in and to be processed is important, don’t say no before listening to ideas – unless the whole team is sure of the idea not working because of whatever limitations your project is tied to. We’ve had a lot of these discussions in the initial phase of our development, and we still do, and usually we’ve come to a middle ground where every member who wants to give input has been given that opportunity – and listened to.

Although a lot of projects usually start out with the idea process, I wouldn’t advice anyone to let go of the reiterative way of thinking. Keep reiterating and bouncing ideas back and forth with yourself and in your team throughout the whole period of your project. If you have an idea, push yourself to assess the idea from every direction, look for workable and unworkable. Stretch it out, fling it into the wall and see where it lands! No, actually, don’t do that unless you’re creating the most elastic and amazing rubber-band in the world.


To make an example of it; You’ve decided to make a simple reaction game based on mobility and awareness. The faster you move your player around and the longer you stay alive, the more points you’re awarded with. You have the basic idea sketched out, but how should it actually work? You now move onto roughing out the flaws and making the idea a bit more refined and fun to play – your team tosses out ideas like obstacles, power ups, boss encounters, movable obstacles, animated backgrounds, animated and interactive objects.

By now you have a few more game mechanics to spin your idea around. So you decide to include obstacles, movable obstacles, and animated backgrounds – because you and your team have run through the ideas and realized you don’t have the required skills to make the rest or because it will be an annoying mechanic to the overall game-play.



Designs, or plans, and well placed decisions are vital to even get a team comfortably through larger and more content heavy projects. This element of the whole process is also something that is important to re-visit now and then, you originally start out with a set of mechanics, story, dialogue and concept design for a character – but over time, this might change depending on how your team works and how the project is evolving. Re-visiting a character, a level, a core mechanic, a story – this is all important, and as we’ve experienced in our own process it is something we constantly do and discuss within our development team.

In principal, the design phase is where every idea is taken from being on paper and into prototyping, testing and being hands on. You re-iterate original ideas and further improve on them until they are ready for production.

In a game project this could mean further improvement to core mechanics like those obstacles mentioned from the earlier example; Should they have different shapes and sizes? Should they affect the player in a negative/positive way? Should the movable obstacles be docked to the surroundings, or float freely in the level? In the end you decide that the obstacles should be rectangles, they should have a slight gravitational effect on the player, and the movable obstacles should be docked to the surroundings.


To use another practical example; The design phase is where I would do what level designers refer to as gray-boxing. Gray-boxing in Unreal Development Kit (hereby referred to as UDK) is a very comfortable and easy thing to do and you get quick results because of how the kit is based around for example a graphical node system for events (Kismet).

In Kismet you can visualize a flowchart of how an event is supposed to play out and relate to other actors and objects in a specific part of a level. I use gray-boxing as a way to quickly test out mechanics or ideas that will have a direct impact on the game we’re developing. The reason gray-boxing is a very good way to develop is because you don’t really rely on anyone aside from yourself to be able to quickly test out an idea and figure out how it should be set up inside the game engine to work, and you don’t ruin anything because you can make a new level and test it in an empty environment.



The production phase of the development, at least in video games, is definitely what’s the most rewarding and result driven. This is where you (or your team) will create something that you can look at, feel, and play around with. You can test your ideas and designs, and you can get others to test what you’re trying to achieve so you get a response on how it looks and feels to them.

Production is generally building and realizing the concepts and mechanics from all the tedious planning and designing previous to this phase. Explaining a production phase in a development project is, as I now realize, a quite difficult task to tackle – I think that has a lot to do with the fact that production is more action (doing) and less saying (thinking).

So instead of writing down a bunch of clever sentences and my own take on theory in production I’ll go ahead and walk you through the production phase that I went through from my experience when making one of many particle effects for Bark.


Idea – I started by pulling out pen and paper (would you look at that), writing down which nodes I thought would be necessary in Cascade (UDK’s particle module) to make the basics in a particle effect simulating small spheres/dust falling from the top of a mushroom.

Through the thought process I found out that the effect would need velocity for the particles to fall, a lifetime for the particles to live and die, a parameter for the spawn location (area where particles can spawn), a parameter for the color (and alpha) of the particles, and a small rotation and rotation over life to make the effect a little more interesting.

Design – After pretty much knowing what I wanted to create I opened UDK and went into Cascade to start messing around with the nodes I had written down. I went on and set up the particle system and then tweaked numbers and properties until it felt right and everything looked fine.

Production – By now I realized that we had no usable assets (textures, materials) for the particle effect I was creating, so I went into Photoshop and made a simple additive (gray tones where black is transparent and white is apparent) texture that would resemble something that could fall from the top of a mushroom and that resembled dust.

After creating the texture it’s imported into UDK and hooked up through a master material (saves me a lot of work in production) as an instanced material. I then swap out the default material with the newly created material before finally testing how everything interacts together within UDK and in the actual level where the effect is going to show.



After the given time decided for your project’s development cycle is over you can, hopefully, marvel at the final product in all its glory. Now it’s onto testing and optimizing everything properly so no unexpected flaws shows up, marketing and publishing your final work to the endless sea of distributors. *

1* This is, obviously, not done yet. We’re hard at work with our game, or.. hardly working?

On a closing note, here’s an update from our project, Bark! The base-mesh for the cave is done (high-five to the 3d guys in our team) and we’ve started production for meshes and landscape for new areas. I’ve completed most of the initial level-dressing (making a level look pretty) and lighting inside the start cave. The next step is obviously… making things interesting with events that you, the player, can interact with and puzzle your way through!