YT YouTube2Text

YouTube2Text → Transcripts → I Spent 5 Years Building a Voxel Survival Game Where the World Is a Planet

I Spent 5 Years Building a Voxel Survival Game Where the World Is a Planet — Transcript

by Incandescent Games · 6,317 words · 1,167 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Five years ago, I started building
0:02Planet Smith.
0:03At its core, it's a sandbox survival RPG
0:07where you explore
0:09fully spherical voxel planets, build
0:12anything you can imagine, and eventually
0:15launch into space to explore the entire
0:17solar system.
0:19But, the idea for Planet Smith didn't
0:22start with space.
0:24It actually started with something I
0:26found unsatisfying with Minecraft.
0:29I've always loved the feeling of
0:31exploring a new Minecraft world, but
0:34something about it always frustrated me.
0:38Minecraft worlds are effectively
0:40infinite,
0:41which sounds great until you realize
0:44that exploring in one direction
0:47is basically no different than starting
0:49a brand new world.
0:51There is no logic to exploration,
0:54and it feels somewhat futile.
0:56Because of this, I often found myself
0:59building a base and staying in roughly
1:01the same area, exploring only on
1:03occasion to find a biome I needed.
1:07There's no real sense of completing a
1:10world.
1:12You can't circumnavigate the planet.
1:15You can't discover the tallest mountain
1:18on the entire world.
1:20You can't map your world as there's
1:22always another horizon that remains
1:25unexplored.
1:28So, I was wondering, what if a sandbox
1:30survival game took place on a real
1:33planet?
1:35A world you could actually walk all the
1:37way around.
1:39A world where you could map each river
1:42and find the longest.
1:44Where mountains compete to be the
1:46tallest on the planet.
1:48And where finishing your map actually
1:51means something.
1:53That idea naturally led to another one.
1:57If you're starting on a planet,
2:00why can't you leave it?
2:02And that's where the inspiration from No
2:05Man's Sky started to creep in.
2:08What if you could build rockets, launch
2:10into space, and explore the moons and
2:12other planets in your solar system?
2:15Each one bringing new resources, new
2:17dangers, new opportunities.
2:21And what if all of it, like No Man's
2:24Sky, was completely seamless?
2:27No loading screens, just a living solar
2:29system you can explore freely.
2:34Visually, I wanted it to feel like a
2:36tiny handcrafted solar system.
2:39Something closer to the charm and scale
2:42of Outer Wilds.
2:44But combined with the creativity and
2:46building freedom of a voxel sandbox
2:49game.
2:50So, over the past 5 years, I've been
2:53working on turning that idea into a real
2:56game.
2:58Along the way, I've built a custom voxel
3:01system,
3:02planetary climate models,
3:04procedural planet generation,
3:07a custom physics engine, and a whole lot
3:10more.
3:11In this video, I'm going to take you
3:13through the journey so far.
3:15This is the 5-year story of building
3:18Planet Smith.
3:34Quick announcement.
3:36We've just launched a demo for Planet
3:38Smith, and our Kickstarter is now live.
3:41There are some great ways to get
3:42involved. Stick around to the end for
3:45more details.
3:48Planet Smith
3:49actually started as an experimental side
3:52project.
3:53And this is the first world I ever
3:56created.
3:57Well, world might be a bit generous.
4:00It was really just a cube made out of
4:02voxels with gravity.
4:04Because my main inspiration was
4:06Minecraft, starting with cubes felt like
4:08an obvious choice.
4:11My first idea was simple. Build a world
4:14out of cubes, and then warp that cube
4:17into a sphere. And technically, it
4:20worked.
4:22Near the center of each face of the
4:24cube, it actually looks relatively good.
4:28But as you move towards the edges of the
4:30cube, the stretching starts to get
4:32worse.
4:34And by the time you reach the corners,
4:36the distortion becomes extremely
4:38obvious.
4:40Now, you might be thinking,
4:42"Why not just make the planet bigger, so
4:44the stretching becomes less noticeable?"
4:48Unfortunately,
4:49that doesn't actually fix the problem.
4:52Scaling the planet up just gets you the
4:55same distortion pattern with the same
4:58percentage of blocks being stretched.
5:01The planet is bigger, but the underlying
5:03problem is exactly the same.
5:07So, I needed a different shape.
5:11One option, which some games actually
5:13use, is to keep the world as a flat
5:16plane and fake the curvature using
5:19shaders.
5:21For example, the game Eco does something
5:24similar to this.
5:26Visually, this can work quite well when
5:29you're standing on the surface.
5:32But mathematically, what you've really
5:34done is take a flat world and stitch the
5:37edges together.
5:39Topologically speaking, you haven't made
5:42a sphere.
5:43You've made a donut.
5:46For some games, that's a perfectly
5:49reasonable compromise.
5:52But Planet Smith was always meant to
5:54have planets floating in space.
5:57And once you zoom out to that scale, the
5:59illusion completely falls apart.
6:03So, that meant I needed a true spherical
6:07world.
6:08That's when I started looking at
6:10hexagons.
6:11Now, if you know a bit of math, you
6:13might already see the problem. Hexagons
6:16tile a flat plane perfectly, which means
6:19if you try to warp them into a planet,
6:22you'd end up with the exact same issue
6:25we had with squares. You'd still get a
6:27donut world.
6:29But, there's a trick.
6:31If you start with an icosahedron,
6:34you might know it as a D20,
6:37and subdivide it many times, you end up
6:40with a sphere made entirely of
6:43triangles.
6:45And if you then take the 12 original
6:48vertices of the icosahedron and convert
6:52them into pentagons while turning all
6:55the other vertices into hexagons, you
6:58get something really interesting.
7:01A sphere made mostly of hexagons with
7:05just 12 pentagons required to make the
7:09curvature work.
7:11And the best part is the distortion
7:14becomes extremely small.
7:17No matter where you stand on the planet,
7:19the blocks look almost identical
7:22with the only exceptions being those 12
7:26special pentagons that make the entire
7:29shape possible.
7:31With my planet geometry chosen,
7:34I made my first proper world. This time,
7:38a bit bigger.
7:40I also introduced chunks, which breaks
7:43the planet into lots of smaller pieces
7:45so they can be generated and rendered
7:47more efficiently.
7:49At this stage, the world itself was
7:51still extremely simple.
7:53The repeating pattern was mainly there
7:55just so I could verify that my meshing
7:58system was actually working correctly.
8:02At this point, the world was still
8:04completely static. So, the next step was
8:07to make it editable.
8:09This meant adding what I call hexels,
8:11essentially the hexagonal equivalent of
8:13voxels, so terrain could be placed and
8:16removed dynamically.
8:19Once that worked, I added a very small
8:21amount of terrain generation, just
8:24enough to start shaping the surface. And
8:26after that, it was time to introduce
8:29different block types.
8:31I just like to take a moment for you to
8:33appreciate the beautiful test textures I
8:36created here.
8:38Yeah. They're truly works of art.
8:42But jokes aside, the important thing
8:44here wasn't the textures.
8:46It was proving that the engine could
8:48render different block types [music] and
8:51different rendering styles. For example,
8:54things like transparent water or cutout
8:57materials like leaves.
8:59Now, in a normal game,
9:01this might sound pretty trivial.
9:05But, in a voxel system like this, every
9:08block inside a chunk shares the same
9:10mesh. That means combining multiple
9:13materials and render types into a single
9:16efficient mesh,
9:18making it a lot more complicated than it
9:20might first appear.
9:23I'll go into more detail on that later.
9:26This world became really useful for
9:29debugging another problem.
9:31Because of the way the planet is
9:33constructed, Planet Smith actually
9:35divides the surface into 62 different
9:38regions.
9:39These exist mainly to handle the seams
9:41where different parts of the planet
9:42meet.
9:44And those seam introduce a lot of
9:46potential edge cases.
9:49So, this little test world ended up
9:51being the perfect place to make sure I
9:53handled all the quite literal edge
9:56cases.
9:58I also made this cool physical
10:00papercraft object,
10:02which was and still is a great tool for
10:05visualizing the data structure of a
10:07planet.
10:09The polystyrene balls represent the
10:11pentagons and are numbered 0 to 11.
10:15The popsicle sticks are the edges and
10:18are numbered 12 to 41.
10:20These are the edge seam chunks.
10:23And the 20 triangular faces are numbered
10:2642 to 61 to give us our 62 regions.
10:32Half of the faces are blue and half are
10:34red because some are left-handed and
10:37some are right-handed.
10:39This is required for indexing so we can
10:41always swap between a real-world
10:43position and an index with some simple
10:46maths without requiring any complex
10:49rules.
10:52I ended up creating quite a few
10:54different test worlds during this time.
10:56Each one had a specific purpose. Some of
10:59you were used to test performance while
11:01others existed purely to make sure my
11:03hexel meshing system was working
11:05correctly and handling all the strange
11:08edge-cases around the planet seams.
11:12This process of building, testing, and
11:14improving the engine actually took a
11:16couple of years.
11:17But during most of that time, Planet
11:19Smith
11:20was still just a side project that I
11:23worked on in the evenings and on
11:25weekends.
11:27Eventually though, I felt like I had a
11:29solid proof of concept. So about 3 years
11:32ago, I made [music]
11:34the decision to start working on Planet
11:36Smith full-time.
11:37And that's when I started properly
11:39planning the features that would turn it
11:42from a technical experiment into an
11:45actual game.
11:47I wanted to start adding features that
11:49would make the world feel more like an
11:51actual planet. So I added a volumetric
11:54atmosphere.
11:56This was heavily inspired by a fantastic
11:58video from Sebastian League about
12:00simulating planetary atmospheres. His
12:03in-depth breakdown was very helpful.
12:07It was a really fun feature to
12:08experiment with because the goal is to
12:11simulate the same light scattering
12:13process that gives Earth its blue sky.
12:16But there was a small problem.
12:19In reality, Earth's atmosphere is
12:22extremely thin compared to the radius of
12:25the planet.
12:26My planets on the other hand are
12:28relatively tiny, which means the
12:31atmosphere ends up being much thicker in
12:34comparison to the radius,
12:36which breaks how the scattering of a
12:38sunset works.
12:40Getting the scattering to look good both
12:43from the ground and from space turned
12:46out to be surprisingly tricky.
12:49One really nice side effect of the
12:51system though is that by tweaking the
12:53scattering constants, you can completely
12:55change the color of the atmosphere,
12:58which I'm sure will come in very handy
13:00later when it comes time to create alien
13:04worlds.
13:06As proud as I was of my beautiful block
13:08textures, I decided it might be a good
13:11idea to get a real artist involved.
13:14But this quickly exposed a technical
13:16challenge.
13:17Because of the way the engine works,
13:19every block in a chunk shares the same
13:22mesh.
13:23That means all block textures need to
13:26live inside a single texture atlas
13:30with the shader shifting the UV
13:32coordinates so each block points to the
13:35correct part of that atlas.
13:38This technically works, but in practice,
13:41it would mean asking the artist
13:43>> [music]
13:43>> to work inside a single 16,000 by 16,000
13:48texture file, constantly rearranging
13:51textures whenever a new block gets
13:53added,
13:54which is not exactly a great workflow
13:58and prone to mistakes.
14:00And the problem only gets worse as the
14:03number of blocks grows.
14:06So instead, I built a custom editor
14:09tool.
14:11This lets the artists work the normal
14:14way
14:15with one texture per image.
14:17And then the tool automatically packs
14:20everything into a single atlas and
14:23updates the ordering so the correct
14:25textures appear in game.
14:27The result ended up working really well.
14:30The tool gives real-time updates
14:33whenever textures change,
14:36lets the artist preview tiling directly
14:38on terrain, and even exposes optional
14:41PBR maps and tinting controls.
14:45This means we can reuse textures with
14:47different color variations, saving both
14:49development time and memory.
14:54To go along with the block tools, I also
14:56built this structure editor.
14:58Structures are collections of blocks
15:00that can be placed into the world as a
15:02single object during generation.
15:05That makes it easy to create things like
15:07trees and buildings,
15:09which would be too difficult and
15:10expensive to procedurally generate from
15:13individual blocks.
15:15Together, these two tools really opened
15:17up the possibilities for Planet Smith.
15:19And suddenly, the planet started looking
15:22a bit more interesting.
15:24But
15:25if we fly up for a moment, you might
15:27notice something.
15:29The biomes are pretty random and
15:32uninspired.
15:34That was actually one of my main
15:35criticisms of Minecraft.
15:37Biomes can feel like they're just
15:39scattered randomly across the map.
15:42So my next goal was to improve the
15:44procedural world generation. And this
15:46time, use the shape of the planet itself
15:49to our advantage.
15:52The first step was generating continents
15:54and islands.
15:57For the first planet, I wanted something
15:59fairly Earth-like with large oceans and
16:02connected land masses.
16:04To do that, I built a recursive
16:06algorithm inspired a little by Conway's
16:09Game of Life,
16:11but with randomness added.
16:14Instead of cells being alive or dead,
16:16they represent land or ocean.
16:19Each step of the algorithm increases the
16:22resolution and decides whether new tiles
16:24should become land or water.
16:27Areas with more surrounding land are
16:29more likely to stay land, which causes
16:31continents to grow and stay connected
16:34while still forming interesting shapes.
16:38Once the land masses were created, I
16:40moved on to biomes.
16:42But again,
16:44I didn't want them to be completely
16:45random. So instead, I built a simple
16:49climate model that predicts temperature
16:51and humidity across the planet. It takes
16:54into account things like distance from
16:56the equator,
16:57proximity to oceans, and adds a little
17:00bit of procedural randomness.
17:03The nice thing about this system is that
17:06it's deterministic.
17:07If you generate a planet with the same
17:09seed number, you'll always get the exact
17:11same world. But change the seed and
17:14you'll get a completely different
17:16planet.
17:17Finally,
17:18I assigned the biomes based on the
17:20climate conditions,
17:22which means the world actually makes
17:25sense when you explore it. If you travel
17:28towards the equator, you'll find hotter
17:30biomes, and if you move away from
17:33oceans, the environment becomes much
17:35drier.
17:37The model is still a little primitive
17:40and doesn't take things like mountains
17:42and rain shadows into account.
17:44I plan to make it much more complex
17:46later, but even at this basic level, it
17:49does a great job.
17:52Now that I had these great planet
17:53generation models, the next challenge
17:56was getting the actual world generation
17:58system to use them.
18:00The first step was terrain, making sure
18:03the islands generated in the correct
18:05places and shaping the terrain so it was
18:08actually interesting to explore.
18:12Like most procedural systems,
18:13>> [music]
18:13>> this took a bit of trial and error, but
18:16after some experimentation, I eventually
18:19landed on terrain generation that I was
18:21pretty happy with,
18:23at least for the time being.
18:25Next came the biomes.
18:28I hooked the biome system into the
18:30climate simulation and made sure they
18:33generated in the correct regions.
18:36I also added a small blending feature
18:39that uses dithering between chunks,
18:41which helps hide the chunk borders
18:44and makes biome transitions look a lot
18:46smoother.
18:48With the world generation coming
18:50together, I decided it was time to
18:52expand the block variety.
18:55I added a new type of block I call mesh
18:58blocks.
18:59These allow a block to load a custom 3D
19:02model instead of using the standard
19:04hexel shape, which means we can create
19:07blocks with much more complex geometry.
19:11But performance was really important
19:13here.
19:15If every mesh block was rendered
19:17separately, it would create a huge
19:19number of draw calls, which would slow
19:21the game down significantly.
19:23So instead, these meshes are merged
19:26directly into the chunk mesh just like
19:29normal blocks.
19:31That keeps rendering extremely
19:34efficient,
19:35efficient enough that I can literally
19:37build an entire world made out of
19:39barrels even inside the editor.
19:43After that, I added more specialized
19:45block types
19:47like stairs and fences.
19:49Fences were particularly interesting
19:52because they needed to change shape
19:54depending on their neighbors,
19:57connecting automatically to the nearest
19:59fence blocks.
20:01It took a bit of work to implement, but
20:03it's incredibly satisfying once it all
20:05snaps together correctly.
20:09I also experimented with some smart
20:11blocks that dynamically changed shape
20:14based on connectivity.
20:16In theory, this sounds like a great
20:18idea, but in practice, it was to build
20:21with and honestly just looked terrible.
20:25So, that idea didn't last very long.
20:28Also, I added torches as a new light
20:31source.
20:32Originally, my plan was to make every
20:34torch a fully real-time light source
20:37with all lighting in game being dynamic,
20:40but that quickly became problematic,
20:43mainly because of the performance cost
20:45of dynamic shadows.
20:47Instead, I plan to use a hybrid block
20:50light solution,
20:51still having real-time light and shadows
20:54from the sun as that just looks too
20:57awesome to get rid of.
21:00Up until this point, block interactions
21:02were handled with a pretty hacky
21:04solution.
21:06For ease,
21:06>> [music]
21:07>> I use standard mesh ray casting just
21:09like you would in a normal game to
21:11detect what block the player was looking
21:13at,
21:14but there was a problem.
21:16As I mentioned earlier, all the blocks
21:19in Planet Smith are merged together into
21:21chunks for performance.
21:23So, when the ray cast hit something, it
21:26wasn't actually hitting a block, it was
21:28hitting the entire chunk mesh.
21:31To figure out which block was actually
21:33hit,
21:35each chunk had a lookup table that
21:37mapped every triangle in the mesh back
21:39to a block index,
21:41which is absolutely disgusting.
21:45It works, but it's really inefficient
21:48and prone to bugs. And it also meant you
21:51couldn't interact with anything that
21:53didn't have a physics mesh like grass or
21:56water.
21:57So, it was finally time to fix the
21:59problem properly.
22:01From the beginning, the plan had always
22:03been to build a custom voxel physics
22:06[music] system
22:07and remove physics meshes entirely
22:10using the voxel data directly, greatly
22:13increasing performance and reducing
22:16memory demands.
22:18Starting with ray casting seemed like
22:20the perfect first step.
22:23The first thing I implemented was a
22:25function that takes a ray and
22:27calculates, purely with math, which
22:30voxel indices the ray passes through
22:33and putting them in order.
22:36Then, I simply check the blocks at those
22:38indices and determine whether the ray
22:41actually hit something.
22:42If it did, I return the block index.
22:47The great thing about this approach is
22:50that it requires no meshes at all.
22:52And it's incredibly fast, fast enough
22:55that I can perform billions of ray casts
22:58per second.
23:00And because we're working directly with
23:02voxel data, we can also add custom
23:05interaction rules. For example, if
23:08you're placing a block and there's grass
23:10in the way, the ray cast can ignore the
23:13grass and place the block on the terrain
23:15below.
23:16But if you're breaking blocks, it will
23:18correctly target the grass first.
23:22>> [music]
23:22>> There was still one issue, though.
23:24This system assumes every block is a
23:27full block, but many blocks like slabs
23:30or fences are actually smaller or more
23:33complex shapes.
23:35So, when the ray cast hits a partial
23:37block, I fall back to testing the actual
23:40triangles inside that block just like a
23:43traditional ray cast would.
23:45This means we can correctly interact
23:48with things like slabs, fences, and
23:50other detailed blocks.
23:53It does add a little bit of extra work
23:55for the ray cast, but since it only
23:57happens when absolutely necessary, the
24:00performance is still excellent.
24:03With ray casting working properly, it
24:06was time to do something a bit more fun
24:08to test its performance. So, naturally,
24:11I built a planet destroying laser.
24:13This thing could carve huge holes
24:16through the terrain,
24:17and I spent a surprising amount of time
24:20just flying around slicing pieces out of
24:23planets.
24:24It turned out to be a great stress test
24:27because every time a block changes
24:29inside a chunk, the entire chunk mesh
24:32has to be rebuilt instantly.
24:35It needs to happen fast enough that the
24:38player never notices.
24:41Since destroying planets was apparently
24:44so entertaining, I decided to push
24:47things even further and add explosions.
24:50For that, I created another voxel
24:52physics function called an overlap
24:54sphere, which, like the ray casts, works
24:58directly on the voxel data rather than
25:01physics meshes.
25:03I started with small explosions and
25:06gradually increased the size,
25:08and I was actually really impressed by
25:10how large I could make them
25:12while the game still ran smoothly.
25:15With a bit of randomness and some visual
25:18effects,
25:19the result looked pretty convincing.
25:22Although since then, I've actually
25:24changed how explosions work. Instead of
25:26using spheres, they're now generated
25:29using a collection of ray casts, which
25:32produces better shaped craters and
25:34allows for gameplay mechanics
25:36like blocks that can shield other blocks
25:39from explosions.
25:41And of course, since this is a space
25:43game,
25:44I had to add meteors.
25:47They're also fun to play around with,
25:49and I think they could become an
25:50interesting gameplay feature in the
25:53future.
25:54I might save them for some of the more
25:57dangerous planets
25:58because I'm not sure players would
26:00appreciate spending hours building a
26:02house only for it to be completely
26:05annihilated by a meteor.
26:07At this point, Planet Smith required a
26:09pretty powerful computer to run well, so
26:12I thought now was a good time to
26:13optimize the engine as I was planning a
26:16public play test.
26:18After finding a lot of low-lying fruit,
26:21the performance improved dramatically.
26:24In fact, I managed to optimize the game
26:26so much that I could actually get it
26:28running on my phone.
26:30I'd find out later that I still had an
26:32issue with older graphics cards,
26:35but this was very promising for the
26:37future as I knew there were plenty more
26:40things to optimize.
26:43At this point, I felt the game was ready
26:46for its first public play test, and
26:48thankfully, a lot of you joined in.
26:50At the time, we only had creative mode,
26:53but we ran a small building competition,
26:55and it was amazing to finally see what
26:58other people could create in the game.
27:01There were some really impressive
27:02builds, especially considering the game
27:05still had a fairly limited set of
27:06blocks.
27:08After the play test,
27:10my attention turned to the next big
27:12milestone,
27:13survival mode.
27:17The first step towards that was creating
27:19a player character and saying goodbye to
27:22the blue capsule, which had been a
27:24placeholder for years now.
27:27Because of Planet Smith's visual style,
27:30a high poly realistic character
27:33doesn't really fit,
27:34but I also didn't want the low poly
27:37look, either.
27:39I wanted something stylized that felt
27:41like it belonged in this hexagonal
27:43universe.
27:45The first attempt was not popular,
27:48but that actually started a really great
27:50discussion in our Discord.
27:53And a community member named Jerry
27:56submitted a concept for a stylized
27:58character that fit perfectly with the
28:00world.
28:02With some tweaks and iteration, that
28:04design eventually became North, the
28:06player character.
28:09He's still a little divisive, but
28:10personally, I think the style fits
28:12really nicely with the universe
28:15Planet Smith is trying to create.
28:17With the player character sorted, the
28:19next step for survival mode was block
28:21breaking.
28:22Up until this point, blocks were removed
28:25instantly when you interacted with them,
28:27which works fine in creative mode, but
28:29survival requires blocks to take time to
28:32break with the speed depending on the
28:34tools you're using.
28:36This was another one of those features
28:38that seemed simple in my head, but
28:40turned out to be much more complicated
28:42in practice.
28:44Because Planet Smith uses a
28:46multi-threaded architecture,
28:48most block interactions happen inside
28:51worker threads.
28:52That's great for performance, but meant
28:54I needed a proper callback system to
28:57track breaking progress and avoid
28:59strange situations like accidentally
29:02breaking the same block twice,
29:05which could become a serious issue in
29:07multiplayer.
29:09The breaking animation itself turned out
29:11pretty cool, though.
29:13It uses a 3D texture containing
29:16different break stages.
29:18This creates a smooth transition rather
29:21than the usual fixed cracking stages you
29:23see in Minecraft.
29:26Survival mode also meant introducing a
29:28proper inventory system. Instead of just
29:31having blocks, they now need to be
29:33stacked, stored, and consumed correctly.
29:37Just like block breaking, block placing
29:40turned out to be more complicated than
29:42expected because of the multi-threading.
29:46When you place a block, the request is
29:48queued to an asynchronous thread. This
29:50creates a tiny delay, which you could
29:53exploit by switching items at exactly
29:55the right moment, and essentially
29:57duplicating blocks.
30:00I eventually solved that using a token
30:02system that tracks pending placements
30:04and ensures the inventory stays
30:07consistent.
30:08Another important survival feature was
30:10the ability for items and blocks to be
30:13dropped on the ground and picked up.
30:15This turned out to be a great
30:17opportunity to continue developing
30:20>> [music]
30:20>> the custom voxel physics system.
30:23One of the big problems with traditional
30:25mesh collision [music] is that if an
30:27object ever clips into terrain,
30:30for example, if a player places a block
30:33on top of a dropped item, the object can
30:36fall straight through the world because
30:38the physics engine has no idea that it's
30:41inside a voxel.
30:43So,
30:44just like with hexel ray casts, I built
30:47a system that works directly with the
30:49voxel data instead of meshes.
30:52My first version had a slightly amusing
30:55problem where items would bounce around
30:58everywhere,
31:00which I quickly fixed by zeroing their
31:02velocity when they hit something.
31:05Now, if a block gets placed on top of a
31:08dropped item, the item will actually
31:10bubble up to the surface instead of
31:12being lost underground forever.
31:15Next, I added ambient occlusion.
31:18Ambient occlusion is a technique that
31:20simulates [music] how exposed different
31:22parts of a scene are to ambient light,
31:25darkening corners and crevices to add
31:28depth and realism.
31:30Most games implement this as a
31:32post-processing effect using depth and
31:35normal textures after the scene is
31:37rendered.
31:38I tried that, but the effect was a
31:40little underwhelming.
31:43Because Planet Smith has full voxel
31:45data, I was able to calculate ambient
31:47occlusion during the meshing process
31:50instead.
31:51When generating the mesh, I store extra
31:54data for each vertex that determines how
31:57much it should be darkened.
32:00The shader then uses that value when
32:02rendering the terrain.
32:04Because this effect works per vertex, I
32:08occasionally
32:09>> [music]
32:09>> had to add extra vertices to certain
32:11faces so the shading could interpolate
32:14correctly.
32:16The visual improvement was huge. To
32:18demonstrate the difference, here's a
32:20comparison.
32:21The left side with ambient occlusion
32:24enabled, and the right side with it
32:26disabled.
32:28It's amazing how much depth such a
32:31subtle effect can add [music] to the
32:33whole world.
32:36At this point, the game was almost ready
32:39for a survival mode play test, but one
32:41major ingredient was still missing,
32:44mobs.
32:45We need passive creatures for the player
32:47to hunt and gather resources from,
32:49and hostile mobs to create some danger.
32:52And to have mobs, we need AI.
32:55Not the modern large language model kind
32:58of AI, but the classic game development
33:00kind, a programmed set of behaviors that
33:03determine how characters act.
33:06The first challenge is navigation.
33:09Most games solve this using something
33:10called a navigation mesh, or nav mesh,
33:13a pre-built network that tells AI where
33:17it can walk.
33:18But because Planet Smith
33:20uses fully editable voxels, the world
33:22can change at any moment. That makes a
33:25traditional nav mesh impossible.
33:27Luckily, we already have something very
33:29similar, the voxel data itself.
33:33The system first identifies
33:35>> [music]
33:35>> which hexels the start point and the
33:38target location are,
33:40then uses an A* pathfinding algorithm to
33:44calculate the shortest path between
33:46those two points across the surface of
33:49the blocks.
33:51Once we can navigate the world, the next
33:53step is behaviors.
33:55Each mob has a set of behaviors that
33:57define what it should do and when it
33:59should switch between them.
34:00Take the bear, for example.
34:02Most of the time, it simply wanders
34:04around its territory, occasionally
34:06stopping to look around.
34:08During this state, it checks for threats
34:11using the voxel ray casting system.
34:14If it spots the player nearby,
34:16or the player attacks it, the bear
34:18switches into attack [music] mode.
34:20In this state, it tries to pathfind
34:22towards the target as quickly as
34:24possible, and once it gets close enough,
34:26it attempts to attack.
34:29If it loses sight of the player for long
34:30enough, it eventually returns to its
34:33normal wandering behavior.
34:35With AI working, the game was almost
34:37ready for the next [music] play test.
34:38Before opening it up, I quickly added a
34:41few survival features that were
34:43functional enough for testing. Things
34:45like a temporary crafting system, beds,
34:48chests, and a bunch of placeholder ores
34:50to mine.
34:53This play test [music] highlighted
34:55another major issue, performance.
34:58Quite a few players were experiencing
35:00heavy stuttering and could only run the
35:02game on the lowest settings.
35:04That was surprising to me because my
35:06machine could run at over 200 FPS on
35:09maximum settings.
35:11But after digging into the problem, the
35:13reason became clear.
35:15I'd accidentally created a cascade
35:17scenario.
35:18If a computer was just below a
35:20performance threshold, certain tasks
35:23would begin to lag behind.
35:25The delay would then block other
35:27important systems, which caused even
35:29more delays,
35:31and the problem quickly spirals into
35:33massive lag spikes.
35:35There was also another issue I already
35:38knew about.
35:39Planet Smith was extremely RAM hungry.
35:42If you let it, the game could easily
35:44consume 40 GB of memory.
35:47So, it was finally time to address
35:50something I'd been putting off for a
35:51while,
35:52a major overhaul of the game's core data
35:55structures.
35:57Up until now, every block in the world
35:59was stored as two bytes.
36:0212 bits stored the block ID,
36:05and the remaining four bits stored block
36:07state,
36:08things like rotation or color.
36:12This limited the game to 4,096
36:16different blocks, which sounds like a
36:18lot,
36:19but thinking long-term, especially with
36:21modding in mind, that probably won't be
36:23enough.
36:25But, the biggest issue is memory usage.
36:29Each chunk contains 16 by 16 by 512
36:33blocks, which is over 130,000
36:37blocks per chunk,
36:39and it's very easy for the game to have
36:4140,000 chunks loaded at once.
36:44That adds up to more than 5 billion
36:48blocks in memory.
36:49At two bytes per block, that's over 10
36:52GB of RAM,
36:54and that's where the memory problem came
36:56from.
36:58What I needed to do was increase the
37:01data per block, adding things like block
37:04lighting, while at the same time
37:06>> [music]
37:06>> reducing memory usage.
37:09The only realistic way to do that is
37:11through compression.
37:13So, instead of each chunk storing one
37:15massive array of block IDs, it now
37:18stores two arrays.
37:20First, a palette, which lists all block
37:22types used inside that chunk, and
37:24second, a block index array, [music]
37:27which references blocks inside the
37:29palette.
37:30Previously, each block needed two bytes,
37:33but with this system, if a chunk only
37:36contains 16 or less unique block types,
37:40each block only needs half a byte to
37:43reference the palette.
37:44That's a 75% reduction in memory usage.
37:48If the chunk contains up to 256 block
37:51types,
37:52we use one byte per block, which is
37:55still a 50% reduction.
37:57And in the worst case,
37:59with
38:00over 256 block types, we still only need
38:04three nibbles, giving a 25% reduction.
38:08In practice, though, most chunks use
38:11fewer than 16 block types, especially
38:14right after world generation.
38:16But, it gets even better. About 65%
38:20of chunks are completely empty.
38:23For those chunks, we simply store no
38:25block data at all, reducing their memory
38:28usage to essentially zero.
38:31Altogether, this system reduced the
38:33average memory usage by about 91%.
38:37And because blocks are now stored only
38:40in the palette, it also opens the door
38:43for more data per block.
38:45Planet Smith can now support over 65,000
38:49unique block types,
38:51each
38:52with a full byte for block state and two
38:55bytes of lighting data.
38:58With this complete, Planet Smith was
39:00using an order of magnitude less memory,
39:03now requiring about two gigs, which is
39:06much more reasonable.
39:09Changing the game's core data structure
39:11obviously broke everything.
39:14Suddenly, almost every system in the
39:16engine needed to be updated to work with
39:19the new format.
39:21But rather than just converting
39:23everything directly, I decided to take
39:26the opportunity to overhaul several core
39:29systems at the same time.
39:31Some of them were already showing their
39:34age. In fact, the old meshing system was
39:37one of the biggest causes of lag spikes
39:40because it had a tendency to block the
39:42worker threads while rebuilding chunks.
39:46Once those systems were redesigned, it
39:49was time to re-add world generation.
39:53Technically, I could have just ported
39:55the old system over, but it had its own
39:57problems.
39:59The biggest one was that every biome was
40:02hardcoded, which made it difficult to
40:04tweak and impossible to scale for the
40:07future.
40:08Instead, I wanted a data-driven system
40:10that could eventually support a proper
40:12world editor
40:13and make it much easier to create new
40:16biomes.
40:18The first step was terrain generation.
40:21The original system relied on simple
40:24height maps,
40:25which worked fine for hills and
40:27mountains,
40:28>> [music]
40:28>> but it makes things like overhangs and
40:30caves impossible.
40:32To fix that, I needed to add another
40:34dimension to the terrain calculations,
40:37but switching from a 2D system to full
40:403D noise would make the generation 512
40:43times slower, which would completely
40:45destroy all the performance improvements
40:48I'd just made.
40:50Instead, I used a hybrid approach.
40:53The base terrain is still generated
40:55using a 2D height map, but then 3D noise
40:59is applied around the surface,
41:01adding variation and allowing for
41:04cliffs, overhangs, and much more
41:06interesting terrain shapes.
41:08By adjusting the strength and depth of
41:10this noise, the system can generate
41:12anything from gentle rolling hills to
41:15extreme alien landscapes.
41:18For caves, I added a separate generation
41:21pass using another optimization trick.
41:25Instead of calculating caves entirely in
41:273D, the system first determines where
41:31caves should exist in 2D,
41:33and then sinks those cave systems down
41:36to their generation depth.
41:38Running this process several times
41:40produces cave networks that look
41:42surprisingly natural, while still being
41:45very cheap to generate.
41:48Next came the biome system.
41:51As we talked about earlier, I had built
41:52these great climate models based on
41:54temperature and humidity, but the biome
41:57systems itself was still completely
42:00hardcoded.
42:01That meant that making changes was slow,
42:03difficult, and impossible for modders.
42:07So, I built a new biome editor tool.
42:10On the left side, there's an interactive
42:12graph, where one axis represents
42:14temperature and the other represents
42:16humidity.
42:18Each biome appears as a point on this
42:20graph, and moving it changes the
42:23environmental conditions where the biome
42:25will appear.
42:26What makes this really powerful is that
42:29on the right side, the planet updates in
42:31real time.
42:33You can even change the world seed to
42:35instantly see how the biome generates
42:37across completely different planets.
42:41Each biome is now just a collection of
42:43data.
42:44You define the terrain properties,
42:46the blocks it uses, and the structures
42:49that can spawn with it.
42:51With this system, it becomes incredibly
42:54quick to create new biomes,
42:56and eventually, even an entire alien
42:59worlds.
43:01There was still one challenge left,
43:02though, blending between biomes.
43:05Previously, the terrain system was
43:07constant everywhere, but now the terrain
43:09properties needed to
43:10>> [music]
43:10>> transition smoothly between biomes.
43:13Since everything is data-driven, I could
43:15blend terrain parameters based on the
43:19weights of nearby biomes.
43:22I had weird patterns, missing chunks,
43:25and at one point, I was getting these
43:27bizarre wave patterns across the
43:29terrain.
43:30This turned out to be a quirk of
43:32blending frequencies.
43:35After fixing those issues, the results
43:37turned out really well.
43:39Here you can see several biomes blending
43:41together smoothly, each one gradually
43:44transitioning into the next.
43:48There are still a few features I'd like
43:50to add to this system in the future, but
43:52this is a much stronger foundation for
43:55PlanetSmith [music] going forward, and
43:57hopefully, one day, it will also become
44:00a really powerful modding tool.
44:03And with that,
44:04you're pretty much caught up to where
44:06PlanetSmith is today.
44:08Right now, I'm back working on the
44:10custom hexel physics.
44:12This time, focusing on full player
44:15collision and movement using only voxel
44:18data.
44:19It's proving to be one of the more
44:20challenging systems so far,
44:23but I'm confident it'll be finished
44:24soon.
44:26After that, there's still a few big
44:28technical features left, things like
44:30LODs, but the main focus is starting to
44:33shift from technology to gameplay.
44:37Over the next 12 months, my goal is to
44:39build a fully fleshed-out survival
44:41experience, something with real depth,
44:44progression, and unique mechanics that
44:47give players a strong reason to explore
44:49everything PlanetSmith has to offer.
44:52If that sounds exciting to you,
44:54if you've made it this far in the video,
44:55it probably does,
44:57consider subscribing,
44:59and head over to our Steam page to check
45:02out the PlanetSmith demo,
45:04and don't forget to wishlist PlanetSmith
45:06while you're there.
45:08I have just launched the PlanetSmith
45:11Kickstarter.
45:12As you've seen, the game has already
45:14come a long way over the past 5 years,
45:17but now I'm asking for your help to take
45:20it to the next level.
45:21The goal is to accelerate development
45:24over the next 12 months, and give
45:26PlanetSmith the strongest launch it
45:28possibly can.
45:30This means more survival content,
45:33features added earlier, like
45:35interplanetary travel and multiplayer,
45:38and a much higher level of polish
45:41leading into the planned 2027 release.
45:44If you believe in the PlanetSmith
45:46vision,
45:47this is your chance to help make it
45:49happen.
45:51And there are some great rewards, too,
45:53including instant alpha access,
45:56exclusive skins,
45:58the chance to leave your own mark on the
46:00game,
46:01and the best PlanetSmith discount you
46:04will find.
46:07So, if that sounds like something you
46:08want to be part of,
46:10head over to the Kickstarter page and
46:12check it out.
46:14If you're still hungry for more
46:15PlanetSmith content, you're in luck.
46:18There is a full back catalog of devlogs
46:21that go into much deeper detail on
46:23everything you've seen here,
46:25as well as a Discord community where you
46:27can follow development and get involved.
46:30And finally, a huge thank you to all the
46:34YouTube members and supporters, past and
46:37present.
46:39You've played a big part in getting
46:40PlanetSmith to where it is today.
46:44Thanks for watching.

About this transcript

This page contains the full transcript of I Spent 5 Years Building a Voxel Survival Game Where the World Is a Planet by Incandescent Games, generated from the public captions YouTube serves with the video. The transcript has 6,317 words across 1,167 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.