About Birke (twitter: @AlexanderBirke)

Game designer and programmer located in Bristol. Currently working on the first episode of "The Adventures of Bertram Fiddle" http://www.bertramfiddle.com/

Entries

 
Ludum Dare 37
 
Ludum Dare 33
 
Ludum Dare 32
 
Ludum Dare 30
 
Ludum Dare 18

Birke's Trophies

Visual Perfect Award
Awarded by SaintHeiser
on September 14, 2014

Birke's Archive

Making an entire game in Tilt Brush

Posted by (twitter: @AlexanderBirke)
Wednesday, December 14th, 2016 6:40 am

Since the start of the current VR revolution I have been more interested in how the technology could be used for creating games rather than just playing them. It should come as no surprise then, that one of my favorite VR apps are Tilt Brush, the 3D painting program that allows for a completely new way of drawing that gives depth to your doodles.

I finally got my own Vive a couple of weeks ago. Since Ludum Dare was around the corner, I decided to make a game where all the art was drawn in Tilt Brush. I thought it would give the game a unique look, and also be a fast way to create 3D content, an important aspect when doing a game jam. You can find the game called The Trans-Interdimensional Laboursaving Transportation Service entry here, as well as on Game Jolt and Itch.io. I couldn’t find anyone else who had tried to use Tilt Brush this way, so I decided to write this post on how I did it and my takeaways from the process.

Terrain, some flowers, and sleepy blobs painted in Tilt Brush and rendered in Unity

Terrain, some flowers, and sleepy blobs painted in Tilt Brush and rendered in Unity

The setup

Turns out the pipeline to get Tilt Brush sketches into Unity, which is the engine I use, was very straight forward. From inside Tilt Brush you can export an FBX of your sketch. I thought I would have to write my own shaders, but it turned out the Tilt Brush devs already provide a set of basic shaders as well! You still have to manually assign this shader to the imported models in Unity so I ended up writing a small AssetPostProcessor script that would automatically handle this when the FBX file was copied into the project folder which made it easier to adjust the look of the game since all brush strokes of the same type would share the same material. This would sometimes still break when Unity had to split up the imported mesh because of it’s 65k vertex limit per mesh but it still saved some time. Here is the source if you want to check it out yourself.

What worked well

The game ended up with the unique look I was after. You can clearly see it’s been drawn by a person which I think gives it it’s own charm. So aesthetically I’m very pleased with the result. Since you can’t really animate a Tilt Brush sketch other than its rotation, scale and location I choose to make a game, where you see a lot of different static environments which worked well.

Earth, so boring

Earth, so boring

Pocket Dimension #321754-B, so weird!

Pocket Dimension #321754-B, so weird!

 

 

 

 

 

If you want people to play your jam game it’s a very good idea to make a build that can be played on the web. I was really surprised how compact the WebGL build was. I haven’t gotten any complaints about the game relying on beefy GPUs to run either which was a nice surprise as well.

Lastly my assumption that it would be a quick method for making art turned out to be mostly correct. Drawing the art inside Tilt Brush was quick, but there was a lot of hurdles getting it into Unity as explained in the next section.

What didn’t work so well

The shaders provided by the Tilt Brush devs only cover the most basic brushes. All the more VFXish of them such as fire, lighting and disco are not supported.  You don’t get normal maps either, so some brushes such as Ink and Oil look flat when imported into Unity. There’s also no shader to to get the non lit strokes of the Marker brush to show up correctly. I know It’s a simple shader to write, but at the end of the jam I was too sleep deprived to sort it out ,so I ended up just using the premade shaders and calling it a day.

Pattern in Tilt Brush

Pattern in Tilt Brush

Same Pattern in Unity

Same Pattern in Unity

 

 

 

 

 

 

As you can see the shape of tapered strokes also didn’t match how they look inside Tilt Brush. It’s controlled in the shaders with alpha cutoff, but there wasn’t a value that made them have exactly the same shape as inside Tilt Brush.

There’s some positive news in the horizon though! The team behind Tilt Brush are going to release a set of resources that should make it a lot easier to import your sketches into Unity in the near future so really looking forward to give that a go.

The other main hurdle is that Tilt Brush is really more geared for sketching than for actual content creation. It’s designed to be approachable and playful to interact with. As a result it doesn’t have many of the features you would expect from a program appealing more to professional users. For example you can’t group your sketch into layers making it tricky to delete strokes. The biggest issue though was not being able to set a custom pivot point for exported drawings as shown on the picture below.

Tell me of the pivots of your homeworld Usul

Tell me of the pivots of your homeworld Usul

I compensated for this the standard way with using a GameObject parent as the pivot in Unity, but it was something that I had to spend more time on than I would have liked. Other

features I could also have used, was to just export a part of a sketch and overwrite existing sketches from inside Tilt Brush. Tilt Brush has never crashed on me but I didn’t want to take any chances so I saved fairly often which filled up the gallery really quickly.

Where Tilt Brush also excels is really in creating organic shapes with free hand brush strokes. My concept relied on creating a bunch of objects with harder edges which proved to be fairly time consuming. There is an option to use a straight edge tool, but it took a lot of trial and error to get the stroke orientation correct.

I spent way too much time on drawing the hard edges of the box the player is placed inside while playing the game.

I spent way too much time on drawing the hard edges of the box the player is placed inside while playing the game.

Conclusion

I really enjoyed making the art for my game with Tilt Brush. Even though getting the sketches into Unity isn’t a perfect process yet it was already a very powerful and quick way to create 3D content. With the new tool chain promised by the Tilt Brush devs on the horizon it will only get better. Next time I’m doing a 3D entry for a game jam I’ll likely use this approach again.

PS!
I’m planning to organize an online game jam for making games with Tilt Brush around February next year after the new tool chain has shipped. If you think that would be awesome to participate in follow me on Twitter or Facebook to stay tuned!

I’ll be making a game with Tilt Brush + Unity

Posted by (twitter: @AlexanderBirke)
Friday, December 9th, 2016 11:08 am

So I got a Vive a couple of weeks ago and the app I was looking most forward to use was Tilt Brush. I think VR has a massive potential not just to play games in but also to use it to make games. So that’s why I have decided that I’ll make all the art for my LD entry in Tilt Brush and import it into Unity. I have already run a pipeline test and it’s fairly easy to get an FBX from Tilt Brush you can import into the engine.

A Tilt Brush sketch imported into Unity

A Tilt Brush sketch imported into Unity

Google has even provided shader code you can use in Unity, of course since Tilt Brush is made in Unity why they don’t just release the textures, materials and shaders are beyond me. As it is many of the brushes such as the more effect based ones don’t render correctly so I might have to code some more shaders during the jam.

So what kind of game do I want to make? No clue! I’m looking forward to hear the theme :)

What Have My Jam Game Become? Turncoat Protocol!

Posted by (twitter: @AlexanderBirke)
Monday, October 5th, 2015 11:48 am

Duty Awaits - Even In Death

After LD 33 I have been busy adding even more glitches and content to my entry What Have I Become, a horror puzzle game that is a blend between The Matrix and Wargames. In the process the name also changed to Turncoat Protocol since I think this is a more exciting title that reflects the cyperpunkish feel and look of the game.

182884   182886

Turncoat Protocol is of course more polished than the jam version but more importantly the narrative should be easier to comprehend now. You can give the WebGL build a go or download a standalone version over at Gamejolt.

Let me know what you think! There’s a lot I’d still like to add to the game but I had to move on to my new secret project. Looking forward to share what that is sometime soon!

Gameplay and start sequence

Posted by (twitter: @AlexanderBirke)
Saturday, August 22nd, 2015 7:41 pm

So far my game is called Even in Death We Serve a Purpose. You are a dying space marine who has been hooked up to a brain reading device and have to provide your superiors with the last intel you acquired – or at least that is what they tell you. So far I have the intro pretty much done and gameplay sorted.

more-progress

Intro Sequence (click for gif)

 

obey-and-annihilate

Gameplay (click for gif)

Next up is to add some more levels and the end sequence. Been quite fun to do a game with a narrative so far.

Playing Unity WebGL builds on OSX

Posted by (twitter: @AlexanderBirke)
Monday, April 20th, 2015 7:58 am

Screenshoot0

I got some feedback on my entry Disco Icecave Laser Death Tag that suggests Unity WebGL builds only work in Safari on OSX.  Other than that it has really worked as a charm for me. I decided to do a game that would lend itself well to the limitations of  Unity’s current implementation of WebGL and learned some more about the 2D physics and UGUI systems in the process. Damn UGUI is good. Was especially happy to see the GL class is fully supported on WebGL since I love pure vector graphics.

Screenshoot2

 

Disco Ice Cave Laser Death Tag – First Playable

Posted by (twitter: @AlexanderBirke)
Sunday, April 19th, 2015 6:04 am

Its a game about robots shooting ricocheting lasers inside an ice cave. You can try out the first playable build here.

Disco Icecave Laser Death Tag first playable 1Disco Icecave Laser Death Tag first playable 2

I have a weird scaling bug when the game is fullscreened (more WebGL oddities!) so I’ll probably disable that option in later builds. The rest of today is just going to be spent on better controls, level generation and polish. I was not aware it was okay to use samples when creating music so that should make my job a lot easier! The game is also very difficult at the moment so I’ll have to work on a better progression curve for it now as well. I think I’ll change it so the exit is where you spawn but you first have to shoot some buttons before it will open scattered around the level to force the player to stop and shoot. Right now it is more favourable to just race through the levels.

First impressions of Unity WebGL deployment

Posted by (twitter: @AlexanderBirke)
Friday, April 17th, 2015 11:11 am

After having read Mike Kasprzak’s pre jam post that the Unity webplayer has been discontinued in Chrome, I decided to look into the new beta WebGL deployment option. I thought I would share my experience so the rest of you jammers out there can make an informed decision beforehand if this is the right option for your game or not. You can check out a test build I did here (controls are A, D, S, W, Q, E and mouse). My test build was done on Unity 5.0.1 and tested with Chrome 42.0.2311.90 m and Firefox 37.0.1 on Windows 8.1.

Build times are really really slow

First of it takes a long time compared to other platforms to make builds for WebGL. You can adjust how much optimisation Unity should do on the build so you trade runtime performance for faster build time, but even with the lowest level of optimisation you still have to wait quite a while. For my very simple project it took about 4 minutes to do a non optimized build and 6 for the most optimized build. Not much you can really do about it except taking more coffee breaks or maybe switching to either webplayer or standalone builds while you are working on the game and only use WebGL to perform final builds.

Get used to looking at this

Get used to looking at this

Performance is not super great

There’s already a good blog post from Unity on how performant WebGL builds are compared to native builds. In short you can roughly expect half the performance of what you get with a webplayer build but it depends a lot on what features you are using. In my fairly simple example there’s a fair bit of framerate stuttering on my laptop for example. If you are in doubt if your game idea will work in WebGL I’d recommend taking a look at the above link.

Cursor Juggling

WebGL builds supports full free mouse look but the player will have to click a popup that allows the content to take control of the cursor.  However if the game gets unfocused it will result in the cursor being stuck at the edges of your screen which makes games with free mouse look unplayable from that point on. This is problematic if the player wants to fullscreen your game since in the default Unity web template this is handled with a button. The solution to this is either automatically fullscreen the game when it loads in as in my demo or start your game with a button that also fullscreens it as they have done with the Dead Trigger WebGL demo. The later is definitely the more elegant option.

Other oddities

When you upload your build to your server be sure to exclude the .htaccess file Unity generates along with the rest of the build files. At least for my web server it meant the page would not load.

Remember to delete this when you upload your game

Remember to delete this when you upload your game

The Vimium plugin in Chrome also steals the input from the D key so it might be worth putting in a note on your webpage that it is adviced to disable that plugin first before playing your game if you use standard FPS controls.

Final Thoughts

WebGL is still very much a beta feature but I think it is definitely ready to be used for jamming. If you want to know even more about WebGL deployment, the documentation on it is definitely also worth a look. I am looking forward to see what the rest of you daring jammers will create with it!

The procedural level generation in Connected Caves

Posted by (twitter: @AlexanderBirke)
Saturday, August 30th, 2014 10:54 am

For Ludum Dare 30 my friend Sam Chester and I decided we wanted to focus on creating something with procedural generation. From the theme we got the idea of having the player explore an infinite complex of connected caves, which also ended being the name of the game.  I thought it would be fun to share the method I came up with for creating the levels. The Unity project is also available on github for the brave and bold.

Mmmm fog, lots of fog

Step 1: Generating the base cave geometry

I designed the generation to take place in separate stages so it would be easier to make sure each part worked on it’s own, and so we would have something done at the end of the jam. For generating the numbers used to create the cave we used unity’s build in Random class. Before the level generation takes place, we seeds it with either a value put in by the player or the seed assigned to the portal the player just used to exit the last cave they visited. The first step is to generate the overall shape of the cave. This is done with a series of randomized Bezier curves that forms segments of the wall:

Red lines are Bezier curves. Green lines connect the primary control points

Red lines are Bezier curves. Green lines connect the primary control points

The dimensions of the cave is the most important feature, since it determines later on which objects it can be populated with. The mesh for the cave is created by sampling the Beziers. This was not that straightforward since each segment is defined by one horizontal Bezier and four vertical ones, 2 for the top half and 2 for the bottom part:

The mesh for one segment

The mesh for one segment

You can think of the mesh as being a cylinder being pressed into the shape of the Beziers. I started to write an explanation for how this is done but it got a bit long winded so if you want to know how that is done ask me in the comments 😉

Step 2 Generate locations for props and place them

With the shape of the cave done the next part is to find out where to place props inside it. This is handled by this component:

Capture

This component generates the positions for props to be placed

Random positions on the surface of the cave is found by generating a random index for a vertex of the cave and use its position. The next big issue is to make sure that things is not created on top of each other. Each type of prop is associated with a category, that determines how many props should be generated based on the size of the cave, how random that number turns out to be and the minimum distance to other props of its own type and other prop types. When all the points has been generated, instances of the ObjectPlacer component is notified, and is responsible for spawning the prop its associated with. In this case it is the crystals:

The component that populate the cave with crystals

The component that populate the cave with crystals

This component both supports that a randomized object is spawned, and can also vary the size and rotation of the object created. This is all to give a more varied visual look.

Step 4 Color randomization and more pretty Beziers!

To change the look of each cave even more, the colors of the cave itself, crystals, and the fog along with the strength of the fog is also changed based on the seed of the cave:

The initial seed is used to select a color scheme that's applied to the whole cave

The initial seed is used to select a color scheme that’s applied to the whole cave

Since I had written the code for generating the mesh for the cave as a component that took an arbitrary set of Beziers as input, I also quickly added a type of prop based on that:

Flowers? Mushrooms? Spikes? a bit of everything I suppose

Flowers? Mushrooms? Spikes? a bit of everything I suppose

Conclusion: What went right/wrong

I think that overall the solution is able to generate some quite interesting spaces, but I would have liked each cave to be even more unique. A system to create more varied typologies for the cave would be great, since it would have the biggest impact. The type of prop that was based on Beziers also showed great potential to give more variation. As you can see from the screenshots of the components above I also ended up using a lot of AnimationCurves to define various probability distributions. This worked out great so I can recommend that. In the end I really enjoyed working on this type of programming since you both get to have the joy of getting it to work but also not knowing exactly what it will result in. This is definitely not the last time I make something procedural.

[cache: storing page]