It's been a little while and a few life events have happened (for everybody), but progress continues on the game. If you haven't checked in for a little while, it looks very different now!

Here are the major changes:

New terrain generation

I swapped out the old terrain generation for a new algorithm that makes more interesting patches of terrain. The old system generated big curvy landscapes that were very predictable. The new system creates big patches of different biomes and I think it's a lot more interesting to walk around. Plus it will give me more control when it comes to creating interesting planets. If you're familiar with the game "Don't Starve", the new terrain generation reminds me of that a little bit.

New terrain tiling system

The old way of doing tiles just wasn't working for me - it was kind of a weird technical solution and that made it hard to experiment visually. The new system makes it a lot easier to experiment visually (and I've done just that with a bunch of free textures thanks to 3dtextures.me). I still don't like the way biome transitions happen (it's very abrupt), but I think this is a big step forward in terms of being able to make better aesthetic choices.

Different elevation levels

Planets now feature procedurally generated elevation levels. If you approach a different elevation level, you'll jump up or down. This started out as a quick experiment but I think it really adds some visual variety to the terrain.

New water shader

With the new tiles, the old water shader looked pretty out of place. So I wrote a new one from scratch, which was pretty fun - it's not super sophisticated but I learned some things about shaders and the way lighting works in relation to water. The more I learn about art and visuals, the more I end up thinking about light.

New scale

The overall scale of the game has changed a bit and the camera is closer in to the player as well. This is an experimental change somewhat inspired by Animal Crossing: New Horizons.

What's next?

I think next I want to focus on player starships for a little bit. There's a ton of work to be done everywhere, but starships are a big part of the game and they haven't gotten much attention yet. So I want to make it so your starship looks a bit more like a starship (instead of just a platform in space), and actually allows you to travel between planets. So look for that in the next update!

Full patch notes:

• New terrain generation algorithm allows for different biomes
• New tiling system and terrain shader allows for more versatile terrain visuals and multiple elevation levels
• Added a bunch of experimental biome visuals and a starship floor texture
• New water visuals look more tonally appropriate
• Terrain generation includes different elevation levels that you can jump between
• Terrain now has colliders so you can't walk into water
• Switched to using Cinemachine for the camera so there's a little smoothing as the camera follows you around
• The camera is now much closer to the player and at a less steep angle so you can see the player model better
• Zoom in on the player a bit when sitting in a Drop Pod
• Player model scaled up a bit, along with some other objects, in relation to the terrain tiles
• Player movement has been rewritten in a way that works with the new terrain colliders
• In-game news loads thumbnail images rather than the full sized ones so it should load a bit faster
• Loading messages throughout the game are now contextualized rather than just saying "Please wait"
• Tweaked the start menu visuals a bit and added a disclaimer to say that Starsteaders is in very early development

---

If you'd like to show support for my game, please join my Discord as that is very encouraging to me (even if you don't say anything). Or you could follow me on Twitter. And if you want to give Starsteaders a try, you can download it for Windows on this page. I'd love to hear what you think!

I recently made a new player character for my game Starsteaders, and since I'm a beginner at Blender I thought I'd share how that went as someone who is pretty new to 3D modelling.

Blender is a free and open source "3D creation suite", meaning it's a single program that can do pretty much everything you need to create 3D models and animations suitable for games. Over the years I've cobbled together a basic understanding of Blender from watching videos, but I've never felt very comfortable using it, so I decided to get a book as well. The book I got is "Learning Blender" by Oliver Villar. It's for an older version of Blender (pre-2.8), but whenever it said something wrong I just looked it up online. Getting this book was well worth it over just watching tutorial videos online (though doing that helped too). It looks like there's an updated edition of the book coming later this year, so be sure to check if you're reading this in the future. The main differences I saw are that Blender 2.8 overhauled some of the UI, and there's a newer rendering engine called Eevee that the book doesn't cover.

Getting started, the first thing was just to learn a bit about Blender's UI. Blender is some of the most complicated software I've ever used - basically nothing is intuitive, so you'll have to memorize lots of keyboard shortcuts and learn the proper terms for things. I definitely don't recommend just diving in and trying to figure things out. Instead, make a test file and spend a while just learning the interface and the basic modelling concepts. Understanding Blender's concept of an object and "object data" is enlightening (and too much to go into here).

Don't be discouraged, though - Blender is pretty well designed for what it does and it's honestly amazing that it's free and open source. Plus, you can press spacebar at any time to bring up a command search, which is incredibly useful when you don't even know the term for what you're looking for.

Pre-Production

As per the book, creating a 3D character actually starts outside Blender. The first step was to design and draw my idea in a 2D paint program. It's hard to overstate how helpful this step was, because when you're trying to learn some really complicated software the last thing you need is to also be making lots of decisions about what your model is supposed to look like. So don't slack on this step!

The first thing was to draw a bunch of silhouettes. The idea is that it's super fast to draw them, so you can iterate through a bunch of ideas quickly. Also, if your character is recognizable from just a silhouette, that can be a mark of good design. I'm not very comfortable drawing without a reference and I really wanted to stop after the 3rd one, but I forced myself to keep going anyway, and I'm glad I did because I think they improved over time.

I wanted something that left a lot to the player's imagination, and that would look good from a distance, so I picked M even though it's not necessarily my favorite design.

Next, I fleshed out the design in detail. You could draw various action poses and clothing alternatives to make sure everything looks good, but eventually you want to end up with something like the below images that can be imported into Blender and used as a reference while you model. It's important to get everything lined up correctly because you'll actually be modelling directly over these images.

Creating the 3D model

Next was to import the reference images into Blender and start modelling. I did this by creating a primitive like a cube or sphere, and then using Blender's various tools to add more and more vertices, nudging them around and extruding faces until it looked like a 3D version of my reference images. You only have to do one side of the body because Blender can automatically mirror your changes to the other side. For the most part, modelling wasn't too hard and was actually pretty fun, but I'm glad my character's face isn't visible because the helmet and hands were tough enough without having to do a nose, ears and eyes.

The trickiest part was getting the topology to be decent. Topology is the word for the specific layout of the vertices and polygon faces in the model. Basically, your model could look the same externally but have any number of different polygon arrangements. For instance, it could be made up of all triangles, or all quads (four-sided polygons), or it could have 5000 vertices or 100000 vertices. These topology choices can really affect how the model looks and animates, and I think understanding how to make good topology choices must come with experience because I had a lot of trouble with it. In particular, you're supposed to avoid triangles and only use quads, but sometimes you end up with a triangle and then it's really hard to get rid of it.

But eventually I had something I was fairly happy with!

Adding colors and texture

To add colors and details to your character, you first have to "unwrap" your model, which is the process of assigning every vertex to a position in a 2D image. Each vertex gets a 2D coordinate called a UV (which is just the X and Y coordinates in the image, except they're called U and V instead). It's basically the same thing as taking a globe of the earth and turning it into a 2D wall map. You have to "unwrap" the sphere so that every position on the 3D earth has a corresponding position on the 2D map. If you can imagine that in reverse, then whatever you draw on the 2D map will show up in the corresponding position in 3D - that's how you draw details on the model.

Blender did most of this for me - you just give it a few hints, and tell it to unwrap, and it does a pretty good job. Then you can make adjustments by dragging pieces around and resizing parts you want to have more or less resolution in the image. Here's the map of every piece of my model to its UV position in 2D.

So now if I draw directly on the above image and tell Blender (or my game engine) to use it as a texture for my model, my drawing will show up in 3D. However, I found this to be much easier said than done. Because the map is flat and the 3D model has curves, if you want a straight line on the model, you might have to draw it as a weird curve in 2D. Anything you draw in 2D gets distorted in unexpected ways when mapped in 3D. So that was really frustrating and I think I need to do more research on best practices before I try again.

But I was able to stumble through, so here's my final texture map (the polygon outlines aren't there in the real version, this is just for demonstration purposes).

And here it is applied to the model (note it's missing the logo on the chest because I just couldn't get it to look good).

You can use the UV map for other things, too - it's just a way of relating a 2D texture to the 3D model. I also had Blender bake out an ambient occlusion texture that tells my game engine which parts of the character should have extra dark shadows at runtime.

Rigging the model

In order to animate a 3D model, you have to "rig" it with something Blender calls an "armature". Basically, you create a skeleton for your character and tell Blender how each bone connects to the others and how they are allowed to move. This can get complicated, but the book I was reading led me through it pretty well and I mainly just re-created the rig from the book, minus the face parts.

You can see from my armature below how complex it got around the hands and feet, so having the book was very helpful here. Seeing the model I had created move was exciting! But it also revealed some problems - when the character moves in certain ways, you can see empty space between the torso and the legs! I hadn't thought to make sure every position would be fully covered in all poses. Also, my model probably needs more vertices in some areas to avoid weird jagged edges showing up when animating, but that's hard to go back and fix now. I think this is all the kind of thing you get better at with experience.

Putting it in the game

I got to cheat a little bit here because I already have animations I made for my old player model (which was just a stick figure). Because all humanoid characters have more or less the same configuration (a head, two arms, two legs, etc), my game engine (Unity) is able to retarget an animation built for my old character to my new one. So I didn't need to make any new animations this time (but you can use Blender to do that too).

Unity can import the Blender file directly, which is convenient. I just had to do a bit of configuration to tell it which bones are which, and it all just worked. Any special materials/shaders you set up in Blender won't import into Unity, so I had to create a material or two, but I already knew how to do that.

Here's what it looks like in my game! My model definitely doesn't stand up to close scrutiny, but fortunately it's pretty small in my game so a lot of the flaws aren't noticeable. Overall I'm really happy with what I've learned and it has made the whole concept of modelling in Blender seem a lot more approachable.

---

If you'd like to support me or my game, please create a Jellygon account and sign up for the newsletter as that is very encouraging to me. And if you want to give Starsteaders a try, you can download it for Windows on this page. I'd love to hear what you think! Daily updates and game dev chat in Discord, and even more updates on Twitter!

Starsteaders 0.1.5, the Astronaut update, is out! This update replaces the old stick figure player model with a new astronaut model I made in Blender. Even though eventually I want to have a customizable player model, I hope this adds a lot more visual appeal to the game for the time being!

I've been spending a lot of time lately working on my art and modeling skills. It has been really fun to me and even though it's a diversion from writing code and directly adding content to the game, I really believe that improving my art abilities will be a big help in the long run. At the least it makes certain things seem a lot more approachable rather than intimidating, which helps me to prioritize and not put things off just because they're scary/unknown.

If you'd like to show support for my game, please create a Jellygon account as that is very encouraging to me. And if you want to give Starsteaders a try, you can download it for Windows on this page. I'd love to hear what you think! Daily updates and game dev chat in Discord, and even more updates on Twitter!

Full patch notes:

• New astronaut player model
• Tweaked post-processing visuals and ambient colors
• Adjusted camera zoom

Starsteaders 0.1.4, the Drop Pod update, is out! This update took a while (a month and a half!), but contains a lot of fun new features and backend progress. The main new feature is your very own drop pod which will transport you from your starship to a planet's surface and back. This replaces the old method which was just clicking a button to teleport back and forth. Your drop pod serves as a safe zone with full life support, and for now you'll always spawn inside it. Only you can fly your drop pod - the doors won't open for other players, so no stealing allowed (for now, anyway)!

Here's a preview of some of 0.1.4's new visuals, drop pod features and run/planting animations:

To go along with drop pods, there has been somewhat of an animation overhaul. There's a new and improved walk/run cycle, animations for getting in/out of a drop pod, an animation for planting, and an animation for running out of oxygen and passing out (after which you'll be teleported back to your drop pod).

There's also a new indicator on the ground that tells you what grid position you'd be planting on, since it's not always obvious from your position.

Notice that in your starship there's now a starfield skybox, and when you interact with your drop pod a handy new UI shows up letting you know what your options are. When you remap your keys or switch from mouse/keyboard to a gamepad, the UI updates to reflect that. Lots of existing UI has also been redone, including new button styling and a new start menu.

Here's the old start menu:

And here's the new start menu. Hopefully it looks better to you!

And finally, less obvious but still very important, there have been a lot of infrastructure changes to make the above features possible. In particular, being able to get inside drop pods and travel with them to another location was a big internal change. Now that it's possible, however, it should open the door for things like ground vehicles with multiple passengers in the future. The multiplayer aspects of the game were also heavily modified (and still fairly untested) so I'm expecting that to continue to be a big deal for a while.

Next up, I'm thinking of writing a year-end wrapup news post highlighting everything I've done so far, and what's to come. In the new year I'm excited to start really fleshing out the game and hopefully add a ton of fun features and content!

If you'd like to show support for my game, please create a Jellygon account as that is very encouraging to me. And if you want to give Starsteaders a try, you can download it for Windows on this page. As always, I'd love to hear what you think! Daily updates and game dev chat in Discord, and even more updates on Twitter!

Full patch notes:

• Randomly spawn red crystals in the world (just cosmetic for now)
• Updated the character rig to be more sophisticated and allow for better posing options
• New and improved walk/run animations
• Improvements to multiplayer networking to allow seeing other players' actions as animations
• Improvements to animation handling to allow spawning placed objects in sync with an animation; e.g. planting a tree halfway through an animation
• Square "current tile" indicator on the ground that shows where you would be planting
• Overhauled the algorithm that decides which tile you want to plant on so you will no longer plant trees behind your character
• Made a new starfield skybox which is generated from a huge particle system at editor-time. The starfield is rendered out into images to be used as a skybox.
• Improved aesthetics for many UI buttons
• Visual improvements to the start menu
• Create a drop pod on each player's starship
• Drop pods can transport you from your starship to the planet's surface and back. A drop pod will look for a clear landing space on the planet near a shared initial location.
• New action bar UI that shows you how you can interact with drop pods. The UI shows your current options and their key bindings, as well as being clickable by mouse. It updates when you switch from mouse/keyboard to joystick, and when you rebind your keys in settings.
• Planting/interacting are now two different key bindings to avoid accidental planting
• Camera rotation keys have changed to Z/X
• Enhanced error handling on server messages to avoid client lockups
• There is now an animation that plays when you run out of oxygen

Bugfixes:

• Fixed a bug where remote player locations would get confused if you spun the camera around
• Fixed a bug where a newly planted tree would flash its fully grown object for a frame

Starsteaders 0.1.3 is out! This update comes with a big graphical update and our first real game mechanic, which is the need to refill your oxygen at naturally occurring gas vents you'll find around the planet. If you run out, you'll pass out and wake up back on your starship. Maybe the intergalactic patrol rescued you?

I'd love to hear what you think! Daily updates and game dev chat in Discord, and even more updates on Twitter!

Full patch notes:

• Tweaks to the procedural terrain generation on both planets
• New terrain tiles
• Tweaked many visual effects to add a bit of visual interest (antialiasing, shadows, fog, ambient occlusion, lighting...)
• Shoreline foam animation on water
• New oxygen mechanic with display copied from Subnautica (for now)
• Spawn oxygen vents around planets where you can refill your oxygen (just stand near a vent to get a refill)
• Send you back to your starship when you run out of oxygen
• The player now always starts on their starship (instead of the last planet they were on)
• Tweaks to movement prediction logic (nothing visible has changed here)
• Reset camera rotation when you go to a new place
• Camera zoom is now fixed
• Fixed a problem where lighting would get really flickery when you walked too far away from the origin
• Fixed a problem where objects were sunk into the ground a little bit

Starsteaders 0.1.2 is out! This update gives you a starship (just one room for now but in the future you'll be able to expand and build on it). You can also jump back and forth between two planets, Porl and Yarla. Both are pretty similar except Yarla is way bigger - it takes like 10 minutes to run around it.

Give it a try and send me feedback! BTW - daily progress updates and game dev chat in Discord!

Full patch notes:

• Lots of behind-the-scenes work to make starships possible (until now, only large wrap-around planets were possible in the backend)
• Generate a starship (with one square room) for you when you make an avatar.
• Made it possible to have multiple planets and added two (Porl and Yarla).
• Bumped shadow distance so you can always see shadows despite zoom level.
• Lighting no longer flickers after walking long distances.

Starsteaders 0.1.1.3 is out! This is a fairly small update, adding the ability for players to send feedback and bug reports directly from the game. Feel free to use it! Don't forget the game will automatically update so you don't need to re-download.

Also, I wrote a tutorial on how I did the feedback form. Check it out!

Full patch notes:

• "Send feedback" buttons added to start menu and game.
• Changed the planet generation seed so a new player will start off on land. There's also a lot more land. If you see any trees in the ocean, this is why - they were on land in the old seed!
• Added some social links to the start menu.
• Neatened up the start menu a (very) small amount, more cosmetics to come in the future.

When I decided I wanted to make a space-farming video game (sort of like Stardew Valley but traveling between planets), I had a bunch of fun gameplay ideas I wanted to work on. I wanted to be able to hop in my spaceship, fly to procedurally generated planets covered with hostile alien landscapes, and slowly make them livable by transporting soil, seeds and resources from one to another. I wanted to build a base that was a safe haven and invite my friends to come work on it. I wanted to dock at a local space station, trade with other players, and mod my ship with new craftable equipment.

But instead of working on that fun stuff, I spent months on boring things like making a website for the game and hooking it up to a payment platform. I spent time implementing user signup/login/password resets, wrestling with localization and joystick accessibility, dealing with code signing certificates, creating a deployment pipeline, making lots of accounts on lots of different websites, and tons of other work I'd usually put off until much later. 

And yesterday, I launched it! I "released" a playable build of the game, despite there being almost no gameplay (you can walk around and that's about it). There's a full company website with user accounts, an optional pay-what-you-want subscription, and some info about what I'm trying to do. On my end, I have deployment scripts that make it easy for me to test and deploy development and production builds. The game even auto-updates itself when there's a new build - I wanted to make it as easy as possible for people to stay in the loop.

This is the opposite of how I usually approach things. In the past, when I've had a game idea, the first thing I'd want to do is see if it's fun. I'd code the basic mechanics in a quick and dirty way, and then play around. I'd want to make sure I wasn't going to spend a bunch of time on an idea that wasn't going to work out - "fail fast", I guess.

So why didn't I do that this time? A few reasons.

1 | When should you quit, and when should you pivot?

There's something to be said for failing fast, but in the past I've given up a little too easily when I should have pivoted or compromised instead. Sometimes, when I look through old abandoned screenshots, I realize that what I was working on was actually pretty cool! All I needed was to lose my tunnel vision, scale down, and I could have kept going. Occasionally I've even seen others be successful with a similar idea to one I've had - not the exact same idea of course, but close enough that I could see how to get there from here, if I had stuck with it. In other cases I've released projects or demos to very little reception, and then watched them slowly build a bit of a fanbase - maybe if I had kept pushing new updates I could have built them into something bigger. My whole approach to marketing was wrong; I didn't realize it takes lots of exposure over time rather than one single push for attention.

All this has made me realize that sometimes it's not really about whether your idea is objectively good or bad, but how much you can adapt and compromise through obstacles without getting discouraged. The difference between a bad game and a good one might simply be trying some new game mechanics until it feels more fun to control, or adding more content until there's enough stuff to do. 

So with this new project, I decided I want to commit for a while, and do my best to compromise before throwing out the whole concept. And that means I can justify doing some up front work before diving into the core game.

2 | The last 20% is the least fun to do, so why not get it out of the way early?

Usually, the most fun part of a project is the first 20%. That's when you feel smart and cool for implementing the mechanics, you get to play around with your exciting new ideas, and it's easy to work on because you aren't mired in a bunch of bad code you wrote (yet).

The middle 60% is okay. It's not as fun as the first part, but there are still some satisfying bits and watching it all come together is pretty cool.

But the last 20% is stressful - that's when you have to do all the stuff you've been putting off because you didn't want to do it earlier. Stuff like accessibility, error handling, the marketing website (if you're like me you will not have done any marketing until the end), whatever arcane rules your publishing platform decides to impose, etc. Also it somehow takes five times longer than you think, and you're already pretty burned out on this whole thing anyway.

I'm exaggerating a bit and it's impossible to do absolutely everything up front, but I think I've done a fair amount of boring ground work that I would normally have put off. Now I'm excited to dive in to some fun game programming knowing I've already done some of the prep work.

3 | I wanted to have a revenue option as early as possible.

These days, it's hard to support yourself by making indie games. The market is hugely saturated, and you need to find some way to get noticed. I don't really have any ideas for that, so I'm trying to maximize my chances by creating a revenue stream early and having it available for the entire time I'm working on the game.

It may seem bad to ask for money before the game is playable, but it's basically the Patreon model - if people want to play my game and support me developing it, they can sign up on my site and pay a monthly amount of their choice. This seemed like a good fit to me because the game is online-only, and I'll need to cover server costs with a monthly subscription anyway. It's also important to me that it's not mistaken for early access - the idea here is to create a community of people who enjoy watching the game as it develops, not to sell a product that doesn't exist yet.

It took some work to make this option available up front, but I think it's important so that as soon as somebody thinks my work is worth supporting, they can chip in. Before that time, they can still sign up for the newsletter and check in occasionally.

What do you think?

What do you think of this approach? Am I being smart by doing prep work up front, or making a mistake by not focusing on making a good game first? Let me know!

The website is officially launched, along with a very early build of Starsteaders! This is a big milestone and even though the game is very basic right now, a ton of work has already gone into setting everything up, learning a bunch of new technologies, building a tech stack and deployment pipeline, forming a new company, etc, etc, etc.

Thanks for being here and checking it out! Feel free to get in touch, definitely sign up for the newsletter, and remember to check back occasionally to see the progress. More to come soon!