Tuesday, November 6, 2012

Procedural Terrain Generation

Procedural Worlds

I wanted to be able to generate worlds procedurally in the game so I could encourage exploring - and why explore unless there is tons of content to find?  I want to have many different variables interacting to keep it interesting, but still not have to create too many assets manually. Well, that's a huge task, so I just started with making a generated heightmap from some multifractal noise functions.  I'm not yet worried about the water or textures - just the shape of the terrain. I want to have a few huge mountains, but also want some flat areas, rocky areas, etc. It's surprisingly difficult to get things at varying levels of detail, and looking natural.

Parameter tweaking

The hard part is that all you're tweaking are parameters like lunicarity, or persistence. What effect does it have on the terrain if you set lunicarity to 1.7? The easiest way is to just experiment with different values until you see something that looks good.  This means you're going to be spending a lot of time tweaking random numbers and then looking at the result, and you will want as fast of a turnaround time as possible.

At first, I started with just hardcoding some numbers in my C# script. In Unity, all you have to do is expose some public variables on your script and it automatically gets shown in the editor as a panel of numbers. What's more, you can even tweak those numbers at runtime and update the values right there. I actually used this technique at first, and just regenerated the terrain every frame. It worked just fine for a 256x256 mesh, but obviously started getting much slower at higher detail levels, and I realized I couldn't just calculate the terrain every frame.

I tried doing the generation on another thread and updating on the fly, but it got pretty messy since Unity enforces a lot of things (like setting heightmap values) to be on the main thread, which kept me from improving performance much.

Programming the Unity Editor

I realized that I could actually just write some code to interact with the Unity editor itself, basically updating the terrain whenever I click a button (even when the game isn't running).  This way, I could update the terrain without building and running the game - I'm simply changing the height values on the heightmap. This turned out to be a great idea, because waiting for the game to start up every time I changed a parameter was getting annoying. I also wanted to have several interacting noise functions which were getting confusing to keep track of in public variables, so I split them into classes and gave them their own parameters, which they each expose on the control panel.

This way, I can define a class once, like "Ridges", and then have two instances that act at different scales.  I can also combine other classes in interesting ways without getting confused now.

Custom Terrain Editor, with the generated terrain above

Saving state

Unfortunately, all of these values are still variables within the code, which means they aren't saved anywhere. I wanted to keep track of each variable that I was setting so I could load them up when generating new terrain.  A simple key-value store in the filesystem was all I needed, so I quickly wrote a system for serializing the variables on each noise class into a file using System.Reflection.  Now, I can even make a few different kinds of terrain for different worlds without worrying about having one massive random function that handles them all.

I have a feeling all this will get more complicated as I start implementing more world values like gravity, temperature, etc. Really, this will be about generating the right plants, animals, and resources to be convincing - but that's for another post.

Weekend progress

Here is a video showing me driving around in a test vehicle to get a feel for the scale:



The textures, water, and vehicle are just placeholders for now - I am just trying to get a feel for the size of the terrain I'm generating. I am not that happy with the size right now. It might be fine if I'm just walking around, but I would like more room to explore on a planet.  This is basically what you'd get if you were in space and wanted to land on the planet at a given latitude/longitude. I would be able to generate a consistent chunk at a different coordinate value if requested, but I don't want to have to worry about generating it all at once or streaming yet.

I will think about it some more, but my goal for the game isn't to have the best terrain out there (the procworld blog clearly blows me out of the water on this one), I just want some terrain to aid with exploring. I think I'll spend a little more time on terrain, then move on to the programming aspect.

Thanks for reading!


Friday, November 2, 2012

Ship Computer Programming Test

As I mentioned in my intro post, I'm working on having a full scripting interface within the game, so players can automate their world. This can either be used for practical purposes like efficient resource gathering, or just cool decoration.

Here's a video of the basic scripting engine in action. I have given the Javascript interpreter access to the ship's thrusters and a basic 21x4 character console for output (computer 3D model took 5 minutes to make - I plan to make it much nicer eventually).



Eventually, I want to have a GUI for writing, organizing, and debugging your code - but for now it's just a hard-coded string in C#. It definitely works though - the video you see shows the Javascript code fully controlling the thruster power and console status text based on the current time (basically toggling every 2 seconds).

Here's a screenshot of the code that's running right now. The "Update()" function is called by the system every frame.


Note that you can have persistent variables over time - so you can even keep track of the world's state how you see fit - say, by organizing all the planets you've scanned for minerals in a sortable database.

That's it for now! Right now I'm working on

Wednesday, October 31, 2012

First Monster + Video!

Here's my first YouTube upload, as promised!  Read the description for details on this particular demo, but I'll be explaining all of it in more detail later.


Intro and FAQ

What's the purpose of this blog?

Glad you asked. This is the dev blog of an indie game in development, tentatively named Project Space Engineer.  It's just me for now; designing and developing using Blender, Photoshop, and Unity with C#.

I will be keeping track of my progress here, updating as soon as I have something worth sharing (I already have one YouTube video I'll link shortly.)  Partially it's to help solidify the ideas I have in my head - a place for notes and thoughts. Also, I hope anyone interested in the game can comment here and make suggestions. I already have too many ideas, and will definitely appreciate feedback to determine which ones to build first!  Lastly, I know how much I like following dev blogs - it's just interesting to learn new tricks and understand the thought process of other developers. I'll be describing the challenges I'm facing as well as little tricks I learn along the way - so new and aspiring game developers might learn something!

Of course, I will post any Alpha/Beta releases here as well, and get some early feedback from fans.

What's the game about?

Project Space Engineer is primarily a futuristic, 3D space exploration/sandbox game. Here are a few ideas I am working through as I go:

Planet and Space exploration

Primary focus is exploring planets, mining for resources, and leveling up your character. I want players to be genuinely curious as to what awaits them at any given planet.  Each will have a different environment, with different optimal ways of traversing and mining it.

Open World

Each planet (and the rest of space) is an open world you can freely travel through. However, just like in real life, it costs money and resources to travel, so you can't instantly teleport anywhere you want in space. You need a powerful enough warp drive and enough energy to get where you're going, or enough money to pay for a worm hole trip.  Of course, you can acquire any or all of these things by spending time in the game.

Programming

The main character will be a "Space Engineer",  so I already have a fully working Javascript interpreter within the game, and plan to have the players actually automate their world. Things like resource gathering, traveling, or protection. I want the player to be able to control the spaceship (engines, life support, etc), and even worker drones on the surface of a planet. However, the programming should be optional, and only an enhancement of the experience. The more time you want to spend writing your programs, the more sophisticated should be your benefits (like complex resource gathering algorithms).

Multiplayer

I'm tentatively planning to make this a multiplayer experience, but really want to focus on making the single player experience good first. Space is a big place, and anyone exploring a random planet shouldn't be very likely to run into someone else on the server. Of course, there would also need to be hubs where players meet, but I'm still trying to figure out how it fits into the rest of the game. The main thing I can think of for now is the ability for players to showcase the things they've acquired in the game - or work together on mining expeditions.


What's the motivation?

Minecraft has shown that the whole open world creative game can work really well when done right, so I hope to have my game elicit similar emotions.  I've wanted to make a futuristic space exploration game for a long time, but until recently, really haven't had the skills to pull it off.  Since then I've learned a lot about 3D modeling, texturing, rigging, and animating - so I'm ready to take a stab at it. My background is in software engineering, so the coding is the easy part. The hard part will be not trying to put a million things in the game, and above all, making it actually fun to play.

Like I hinted at above, I already have some working code for the game! It's nothing close to playable yet, but I certainly have at least one video to upload and share here. Stay tuned!