PatateNouille's castle with the new lighting
With the new lighting done, focus has shifted to some small but necessary tweaks. The biggest changes happened to the chatbox - it finally has a scrollbar, among other improvements! Here’s a full changelog of this week’s progress:
----------------------------------------------------------------------
- Added "/debug texturecheck" - spawns all blocks that have no mesh but have a texturemapping set around you (requires cheats on)
- Added "/debug generateiconmapping {path/to/icons} {path/to/mapping.json}" - generates a types json file filled with overrides for types where the icon file name matches an icon file in the indicated folder (requires cheats on)
- Added "/debug generateiconmapping {path/to/albedo} {path/to/emissive} {path/to/normal} {path/to/height} {path/to/result_mapping.json}" - generates a texture mapping json file filled with mappings overriding existing ones where the texture files match files in the indicated folders (requires /cheats on)
- Added "/colony printhere" - prints a list of unique colonies overlapping your position
- Added "/colony setleader {player} [colony]" - sets the player as the leader of the colony (duh)
- Fix mods not being shown in the server browser if they did not have a dll associated with them
- Redid client chat box: -- Use the new render method for text (no more blurry text) -- Add the ability to scroll, and keep some history
- Added the ability to scroll to the server interface log, and keep some history there
- Added "/teleport player {name}" - teleports you to that player if found (even if offline)
- Added "/teleport spawn" - teleports you to .. spawn
- Added "/setspawn" - sets .. spawn
- Added rotation support for sending positions to the client
- Added rotation support to spawn position setting
- Saved player rotation on exit & load it back
- Fixed trading menu breaking when making a rule with a few added zeroes to the standard billion item limit
- Vary chatbox transparency based on how it's opened
----------------------------------------------------------------------
We're testing a private build with a small group of players now. We'll tweak things according to their feedback, and if we don’t run into major issues, we’re planning to launch 0.7.2 next Friday!
The new torch/lantern lighting is pretty awesome :D
As explained before, I’m working to improve my C# and Unity skills, so that eventually I can work at the core of features instead of only supplying parts like models, textures and icons. Last week, I’ve been following Brackeys RPG tutorial. It’s very helpful and I’ve been learning a lot. And it’s really helpful to make me understand what things are problematic in game development - and what things aren’t.
The tutorials explain some very fundamental parts of most games: moving around, interacting with objects, storing stuff in your inventory, equipping and unequipping it. Here’s a short GIF of those things in my little project. But if you’ve got to code these things from scratch, these fundamental things are not easy.
In game engines like Unity, there is not this one single long list of code that determines how stuff works. It might sound silly, but that is how I imagined it! In reality, you can make lots of scripts, and attach them to all kinds of different items. Your enemy probably has his own script, and when he equips a weapon, that weapon also has its own scripts with unique instructions and data. And when the enemy uses that weapon to fire a rocket in your direction, that rocket also has a script that determines how it moves and when it explodes. Last but not least, when the rocket hits an objects and explodes and generates a whole lot of smoke, that smoke is probably also a separate GameObject with its own unique script attached!
As you can imagine, all of these things are related, so all of these scripts have to communicate. The enemy needs to know what kind of weapon it’s wielding, and when the rocket spawns it needs to know the position of the weapon. Etcetera, etcetera. To give an example of a script like that, here’s part of the script “EquipmentManager” in Brackey’s RPG, the tutorial I just mentioned:
This part of the code is called a “method”. This means it’s a special part of code that can be invoked somewhere else, by for example pressing a key or a button on the screen, which then executes all of the code in the method.
The name of the method is “equip”, which makes sense, because the method is used to equip stuff. Between the round brackets is written “Equipment newItem”. This means that the method accepts anything labeled “Equipment” as input, and that input can be used in the method with the keyword “newItem”.
This means that somewhere else I need to have a script called “Equipment”, and that script is used for items like “Equipment Helmet” and “Equipment Sword”. These can now be equipped by calling the EquipmentManager, invoking the Equip method, and entering the name of the specific object, e.g.: “Equip(Helmet)”. When called like that, the method will use the referenced item and its properties wherever "newItem" is mentioned inside of the method.
In the second line of code (don’t worry, I’m not going to do the entire block line by line), it defines a new Int, a number. This new Int slotIndex is set to newItem.equipSlot. This means that the Equipment script contains data called “equipSlot”.
As you can see, all of this code is highly interlinked. On one hand, it’s building a lot of structures to store data. On the other hand, it’s a complex set of interrelationships that modify and transmit that data from one place to another. And in general, these interrelationships are pretty “dumb”. The Equip() method requires Equipment specified in exactly the right way, otherwise it won’t work. This means that changing one little thing in one place might mean having to fix a dozen or a hundred other little things in as many different places.
I hope you can imagine why that can be very difficult to set up and change. The example here is from a very simple tutorial prototype, but “real” games also have to deal with things like multiplayer, savegames, translations, key bindings and mods, making the structure even more complicated.
It’s a high price, but it does come with enormous benefits! Programming scales really, really well. Compare writing 1 Friday Blog vs writing 100 Friday Blogs, walking 1 Mile vs walking 100 Miles, preparing 1 Meal vs preparing 100 Meals. As you’re getting more experienced you might become a bit quicker, but not a lot. Multiply the things above by 100 and the time and cost involved will probably also increase with roughly that number.
That doesn’t have to be true with programming. Setting up the EquipmentManager in the example above takes a pretty long time, but once that task is finished it’s a relatively flexible thing that can handle a lot of content, as long as it’s formulated in the right way. Adding new swords, helmets, shields and other equipment items with varying stats should be easy. The difference between making sure 100 pieces of equipment can be stored, equipped and unequipped properly isn’t that much higher than the cost of doing the same for 1 piece of equipment.
The tutorial world in the editor, with multiple pieces of Equipment on the ground
So, how are all these technical details relevant to you? Well, as you had probably guessed, Colony Survival also contains a whole lot of programming and scripts and complex interconnected systems. Within certain limits, they’re very flexible, and all kinds of parameters can be adjusted or content added with little effort. New items and jobs similar to existing content require barely any effort on our side. On the other hand, some changes that might sound fairly simple would actually be very costly in terms of development time and/or performance.
This is not an excuse to safeguard us against all changes. But you’ve probably noticed that there are some relatively common feature suggestions that keep getting ignored. For most of them, the reason lies somewhere in the explanation above - changing the system to accommodate that feature would just be too costly.
There’s plenty more to write about the practical implications of this. The importance of refactoring, the difficulty with changing the NPCs, etcetera. If you would like to hear more about this, please let us know in the comments or on Discord!
Bedankt voor het lezen :D