The Start of a Journey
The origin of every game lies in the birth of an idea.
Our idea was simple. Bring the thrill of classroom drawing games back to life – but in a digital way. The idea was formed and molded almost exactly one year ago, on a lazy afternoon in the fourth story of a little office building right next to the Elbe river in Hamburg.
Subject of this blog will be a developers view on how this idea resulted in our very first indie game release, what obstacles we met on the way and future problems that will problably rob our sleep.
In this very first edition we'd like to talk a bit more broadly on how we went about implementing the drawing system that is now a core part of the Scribble It! experience.
More details about what we did and the way drawing in UE4 can work will be laid out in future editions of this blog. Those will be published on a regular basis from now on.
GPU vs. CPU
No matter what type of application, the first decision when implementing the functionality to let users draw is almost always the same: When to use GPU and when CPU?
Rendering user input to the screen via CPU often brings a lot of flexibility.
Implementing algorithms like floodfill can be done without a lot of computational and programmatic effort. This allowed for an easy implementation of the Fill Tool that you know from Photoshop or other graphics editing tools in Scribble It!. All the information about adjacent pixels is already there so you know which pixels to fill and which not.
When trying to do these things on the GPU you face the problem that shaders are executed on a per pixel basis. So you would have to go through multiple render passes to get the same information as on the CPU.
On the other hand GPU based rendering can result in a better performance. Especially when it comes to rendering a lot of textures.
Flexibility vs. Performance
In Scribble It! we placed a lot of value on good performance. The drawing process had to be a fluent motion. Any delay between the mouse stroke of the user and the rendering of the respective pixels on the screen would simply make the gameplay feel bad.
This is the reason that the rendering of brush strokes is handled on the GPU.
Every tick where the user is drawing we compute a starting point and in the next tick an end point based on the cursor position at first and second tick. In the next step this information is converted to a line that is then being painted according to current brush size and color.
On one hand this results in maximum performance but it also has a drawback: With our current way of handling things it is not possible to implement different types of brushes.
Enabling this feature would require us to use the classical approach that is used in many modern graphics editing tools: when drawing, along the drawn path a brush texture is rendered many times with a specific distance to the last texture. This technique is depicted in the picture below.
A disadvantage of this classic approach is that the performance varies depending on the brush size and the distance between two brush textures, resulting in inconsistent performance and can cause stuttering. Bigger brushes and a smaller distance would implicate worse performance but it is necessary to have a small distance between brush textures to create perfect straight lines.
With our technique we have a constant performance because the shader is always applied to the whole canvas and therefore always takes the same amount of execution time. This way we can ensure that if a player's computer is able to draw a single small point on the canvas, it'll also be able to draw a line with the biggest brush size, which means we don't have to deal with any edge cases. As a result we have a smooth drawing experience.
Opacity
As we wanted to support drawing with different opacities we also had to make a little adaption to our technique. Drawing with opacities < 1 would result in different colors at start & end points because the end point at every tick is the start point in the next tick. So the resulting color at that point would be too dark.
We tackled this issue by creating a mask of the pixels that were to be filled and only then multiplied the current brush color with the mask. This way we got perfect opacity with a maximum of peformance. While the opacity feature did not make it into the current version of the game, it might make a comeback in the future.
This technique prevents implementing something that is commonly called Flow. Flow means not filling the selected pixels immediately with respect to the opacity but fulling them depending on how long or how often they are being touched by the brush.
We decided against using Flow in Scribble It! to prevent the UI from being too cluttered with tools.
Anyway, this was a first broad overview of the underlying mechanisms that make drawing in Scribble It! possible. We hope you enjoyed the read and come back for the next edition in about two weeks.
Marcel & Sören
Be sure to follow us on Twitter!
