Stefano here, and welcome to the 13th Project_BuildTutto's Update! I'm excited from this one because this week the project hit the 100 development days mark! Looking back to the beginning of this adventure I'm now super happy to see how the things turn out, the development is going much smoother than what I could expect! Enough talking now, let's dive in to the changed with the usual Timelapses, changelog, and weekly stats update:
Automated orders menu
A new menu made its appearance this week in the game: The automated orders menu. To quickly refresh your minds, previously if you needed a raw resource item you had to open the "BuyResources" menu, select which resource to buy, input the ammount you needed, and buy it. Now you can still do that if you want, but you can also set thresholds to automatically buy resources when the amount available in the level is below the threshold of that resource.
This menu is designed to be complementary to the BuyResource one because during the play through the player will need both of these: the BuyResource one will be useful when he will design new objects to try out different material properties and stuff like that; while the AutomatedOrders one will be useful to him in a slight more advanced state of the factory to constantly keep a stock of the most useful materials in order to avoid production chain slowdowns.
Trucks (aka "Camion" in the changelog) improvements
Each resource bought with one of the previously mentioned menus will arrive with Trucks, and they have been slightly improved this week to polish them up a bit. The functionality is still the same but now they are able to wait in line their turn without overlapping.
That aside, they received a code improvement too with a brand new Camion base class and two derived class from that: Camion_Solid and Camion_Liquid. The base class now manages all the moving, stopping, waiting in a line, and departing since it’s a behavior in common between both the trucks that carry solid stuff and the trucks that carry liquids. While the two derived class will manage what to do when they are ready to unload their stuff into the level, which is obviously different between solid and liquid.
Day/Night cycle and Time flow
Time now flows! The game has a clock with second, minutes, hours, days, months, and even years! This is a simple feature that will influence a lot the behavior of the working guys since they will be affected by the light and the temperature of where they are.
Now the previously created light system shine (pun not intended) much more because it will play a major role during the night time in the game.
With the time stuff done I was able to introduce the temperature feature too! I needed to code time first because the ambient temperature will be derived by the current time of the day (daytime is warmer, nights are colder) and the current month of the year.
Currently the temperature in the game will influence only a graphical effect that will turn the screen to cold colors when below certain temperature or to warm colors when above another threshold. Later on this will affect a lot of different stuff: from guys behavior to objects deterioration.
One of the goals of next weeks will be to add objects like heaters and coolers to control the temperature inside rooms, but also adding small heat outputs to objects like lamps, furnaces, and things like that.
Bonus (not so) fun debugging story
Last Friday, after writing and posting the weekly update, I worked on a bug. It has been terrible. I spent 4 full hours inside visual studio to hunt down that monstrosity.
The test case was: I load up a level with some pipes, I click on one pipe to create the little object's detail window, I click the destroy button inside the window to destroy the selected object, and everything was fine...But when I tried to click another pipe to select it, the game would crash.
The VisualStudio screen after the crash was pointing out that the newly created object's detail window had a corrupted bitmap scheduled to be drew on screen.
Long story short here it's what was going on:
I wasn't removing the pointer of the delete pipe object from a vector of Pipe's pointers, but I was deleting that object. So, the memory was freed and marked as available memory to store new objects. When I create the new window, the program could place the window and his button inside that just freed memory and the old pointer stored inside the vector remain valid, but pointing to an object different from what the vector thoughts. Then I call a simple variable assignment function to all the pipe's pointers effectively corrupting the memory where the window's button was stored, but still without crashing the game. Then when the window tried to draw his button it would try to draw a corrupted bitmap and crash the game.
Lesson learned 1: always make sure to remove pointers to deleted objects.
Lesson learned 2: start to use that f***ing smart pointers.
Keep in touch
If you are curious to see how things will go feel free click any of these links to join our community:
Discord Server: Discord.gg
YouTube channel for Timelapses: Youtube.com