April 22, 2020
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:
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.
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.
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.
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.
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.
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:
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!
January 29, 2020
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.
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.
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!
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.
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.
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!
January 27, 2020
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:
December 28, 2019
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:
November 01, 2019
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?
Full patch notes:
October 17, 2019
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:
October 07, 2019
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:
October 01, 2019
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.
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.
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.
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 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!
September 27, 2019
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.