A couple of months ago, I wrote that I wanted to learn to program. The first couple of steps of programming are lots of fun to learn. You learn commands like Console.WriteLine, which allow you to let your computer "speak". Vice versa, Console.ReadLine lets your PC read your input. It's exactly the kind of stuff I expected to learn.

But as I progressed, new lessons started to subvert my expectations. Instead of teaching me new commands that allowed me to try new and exciting things, all the tutorials started to focus on abstract methods used to "organize" your code. That's not at all what I was interested in! I gave up and focused on other tasks.

Subconsciously, I approached programming like it was magic from Harry Potter. I thought experienced programmers, like Zun (the programmer on our team who has written the code behind Colony Survival), just knew a whole lot of "spells". I expected programming lessons to be like magic lessons at Hogwarts, learning a couple of new spells every day.



And at the start, that's pretty much what it will be like. Here's a piece of real, functional code:



When you run this piece of code, a console window will open and ask "In what year were you born?" Type "1993", press enter, and your PC will set "birthyear" to "1993". In the next line of code, it will set "age" to (2018 - birthyear) = (2018 - 1993 ) = 25. The final "Console.WriteLine" will print that age to the screen.

That's pretty awesome, right? It's relatively simple and does something useful. But... it only asks one question, gives one answer, and then it stops. Let's make it more interactive! We can start by asking what the user wants to do. If he responds with "calculate age", we can continue by asking him about his year of birth. If we create a loop with while {} and put the code between the brackets, the first question will be repeated when the end of the code is reached.

New problem: the code is too long to Photoshop onto one scroll. Now we've got to do the dreaded thing that frustrated me so much. We've got to work with "methods". I'll admit that it's pretty useless in this example. But it's crucial in larger projects, so please bear with me!

A "method" is a block of code that can be executed by using its title. So the code from the previous example can be copied to a different location and titled "calculator". When I type "calculator()" in my main code, it'll execute the full block of code saved under that title.


Fullscreen

It's becoming more complex now, but I hope the explanation above makes the basics of the concept pretty clear. There's one last concept I'd like to explain before I come to my conclusion, and that's structs. They're a way to save more complex information in an organized fashion. The basics of a struct look like this:



On the left, a general format for saving "game information" is defined. On the right, an example of specific information that can be saved in that format is shown. The struct isn't limited to one set of data, it can hold many more. The code on the right scroll can be followed by for example:

game Skyrim;
Skyrim.Developer = "Bethesda";
Skyrim.Releaseyear = 2011;
Skyrim.EarlyAccess = false;

A variable like "TimeSinceSkyrim" could be used like this:

TimeSinceSkyrim = ColonySurvival.Releaseyear - Skyrim.Releaseyear;
Console.WriteLine($"Colony Survival was released {TimeSinceSkyrim} years after Skyrim.");

All of these concepts are interactive. Structs can be used in methods, and methods can be used to fill structs. Using these concepts, you could write a more complex program that can sort games by age, or another one that provides users with a list of all games by a selected developer.



Structs can be used inside of structs, and methods can be used inside of methods. A complex program can quickly become an intricate web where everything is connected to everything.

That seems to be the difficulty of learning programming. It's not like learning magic or a foreign language. It's not about learning spells or acquiring a large vocabulary. It's about organizing complexity and understanding abstract connections.

If you're writing your own code, you're the one who has to decide how data is saved and used. You've got to determine which blocks of code will be split into methods, and which won't. Creating a good but complex program requires a lot of thought before the first line of code can be written.

Pretty often, your first plan won't be perfect and you'll learn that you've got to reorganize parts of your code. This is called refactoring. Sometimes code is refactored to prepare the game for new features, sometimes it's done to optimize performance, and sometimes refactoring can help mod developers.

The oldest code for Colony Survival was written in 2014. Since then, Zun has learned a lot. His programming skills have improved, and we've gotten a lot of feedback from mod developers and users with different kinds of hardware. This means that there is a lot of potential for improvement when working with older code. Instead of quickly hacking a new feature into the game by adding it on top of flawed code, Zun has the habit to rewrite older code to make it more useful, more stable and more optimized. It does take more time, but we believe it's worth it!



Progress

In the last video of the new world generation, there was no logic behind the location of biomes. That has changed dramatically! There's a cold north and a hot south, with a gradual transition between them. A dry steppe separates the spawn region from the far east. There's an ocean between the main continent and a new continent in the west. Every world is still unique though.

The code behind the terrain generation has been refactored. It's quicker now, and it's possible to change certain settings. Among others, the amount of hills, the "depth" of the world, the water level, the size of the world, and the amount of rivers can be changed.

To-do list:

• A nice in-game menu to change those settings
  
• Some new trees
  
• Some simple rock formations
  
• A simple map (mostly for us, not in-game) to help us fine-tune the continents
  
• Grass shouldn't grow on cliffs