next »

[ElkiwyDev]

Hello Everyone!

Stefano and the 21th Project_BuildTutto update here!
This week has been a bit slow week. No timelapse since I was away from my working station all week long and I also haven't done big changes or features to announce.
I still managed to do something kinda cool with shaders at least, but first changelog and stats:

Shaders
I know, I know... I'm already hearing every developer screaming "Just work on the mechanics first! Graphics comes later!" and you are all right. But I simply cannot ignore the graphics of the game while I develop it so it has to look at least decent while I test it. So here we are fiddling with shaders once again.
I worked with shaders before with GameMaker:Studio and I remember that it was pretty much a nightmare. Luckily now I had better time with Allegro and I managed to set up and understand the base mechanism of shaders in "just" one day of work and few extra hours of the next day.

The main reasons why I wanted to add shader was that I had an idea to improve the look of the GUI's windows.



Gui style rework
So with the shaders all set up I looked online how to make a decently efficient blur shader because I wanted to give the GUI’s windows a transparent look, but with some extra blur in order to make it both clean and cool to look at.

I managed to get the look I wanted to do, but it still feels a bit too heavy on the performance for my taste... I'll work more on that to improve them.

(The gif recording destroyed all the color fading and blending, just image a normal simple smooth blur)

The overall feel of this iteration of the GUI's style is less flat and boring than the previous one so I'm happy with the result so far.

Lastly: of course a "WIP" screenshot of a glitchy shader can't miss to the collection when we are talking of noobs working with shaders

Lights on doors (again)
Taking a break from the shaders I returned back to the light passing through doors effect.
The light system right now it's very efficient (taking resources only when a light is added or removed) but being efficient doesn't means that is easy to maintain and change.
I have an idea on how to make it work but at the time being I didn't managed to concretize that idea into a snippet of code that works in the system, so more work ahead on this point.



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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharing

[ElkiwyDev]

Hello Everyone!

Stefano here with yet another weekly update of Project_BuildTutto! I'm very happy with this week since I worked a lot in the direction of an actual playable state, slowly leaving the "it's all debug" sort of thing. So a pretty work week has passed and a lot of new stuff has been coded into the game, so let me throw at you the usual timelapses, changelog, and stats so we can dive into the changes!

Items Management Menu
So, this week is pretty much all about menus. The first one that I made is an "Items Management" menu, where it lets the player see all the items currently present in the current level (NB: Only resource type items, this means that all the installed and working items are excluded).

Other than see all the items, the player is able to choose what to do with these items, and right now it can choose if some items need to be scheduled to be transported to another area by choosing through a dropdown menu. After he choose it, a transporting order will be inserted in the orders list and will be executed as soon as possible by ordering to a guy to call a transport truck, grab the item, place it in the truck, and let it leave the map. As soon as the truck exits the current map it will appear in the destination map and there a guy will need to unload it from the truck.

Guys Management Menu
Since you can now transport items between level, I needed to add a Guys Management Menu too, which is pretty much the same thing as the items menu, but for guys.

Right now, the process of moving a guy between maps is pretty rough since it basically teleport instantly a guy here and there, but later on I think I'll add some sort of car that will transport guys and I'll let them having a better animation for it.



Guys Hire Menu
An alternative to teleporting guys around, is to hire them right in place. This is really a big one since it finally leaves the “spawning guys by debug shortcuts” thing behind and moves the whole project ahead in the direction of a playable build. So, how this hiring actually works?

The hiring process in Project_BuildTutto is a bit different from other games. Guys now have stats that affect their behavior (currently it only affects speeds, but later on those will changes a lot of stuff), and these stats will make a guy better or worse than another one. Other than that, each guy has a monthly income based on how good it is. As everything in real life, good things are paid more.
So, through this hire menu, the player can take three actions:
   -Hire the currently displayed guy
   -Generate another guy by hitting "next" and effectively rerolling its stats
   -Change the "budget" input value. This will tell the system how much the player is willing to spend each month for the generated guy. Changing the budget and rerolling will create an overall better or worst guy depending if the budget has been increased or decreased.

This budget system works by giving to the generator more "points" to give to the guy, more or less like a "choose what stats to level up" kind of thing.

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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharing

[SamLouix]

I have no idea about all of that programming jargon but I'm convinced you do.

Good luck!

Got a mailing list?

[ElkiwyDev]

Hello Everyone!

Stefano here with the 23th update of this Project! I'm very happy with this week work since I kept working through the "Actual game" state with objectives and things to do, and not only a sandbox thing with mechanics to play around.
So here you have this week's timelapses and changelog:

Level's Objectives
Until now the game didn't have any goals or progress counting, making it very "useless" as a game. Now each level has its own objectives to complete. The main progress system that I want inside the game is that the player has its own main base where he can do anything he want, where he should build everything needed to construct the other levels, and then there will be various levels with specifics objectives that need to be completed to unlock the next levels.
These objectives will be something like:
   -Be profitable = stay X months earning more than Y in profit
   -Produce = produce X things of type Y
   -Create employment = hire more than X guys and stay profitable for Y months
   -Luxury = Have a total worth of more than X and return all the investment
Sometimes with some sub-goals like:
   -Spending less than X1
   -Having less than X1 of Y1
And something like that.

The goals will be very generic at the start of the game, to let the player has freedom on his creativity in the designing process, and later on will be more complex to really give the player some hard task and really think well the design of the building.

To make this easy to maintain and to work with I created a struct capable of holding all the different variables that could be needed to create the objectives:
   

Then, I can simply create structs, assign the right variables and the right type code, and later iterate the list of objectives checking their code first and then checking the right variables based on their code.

Profits counter with Buy and Sell Records
Since many objectives will be based on being profitable, I needed to create some sort of profit counter in each level. To do that I had to create records to store the detailed information of each object bought and each object sold, so the player can review all the income and the outcome he made in that specific building.

All these things can be checked inside the newly added "Stats Menu" (probably will be renamed) where it will be displayed both the selling and the buying records, but also the profit counter taking into account the guys income and later in the development I'll add electrics bills and minor stuff like that.

Since the profit counter is based on the single building, I had to fix the problem where the object could be transported inside levels. The player could easily buy resources in the main base, construct the final product in the main base, transport it to the level, and sell it from there and make pure profit with all the expenses in the main base.
To fix this problem I made all the transported items unsellable and uncraftable, so transported items will be useful only to build the building in the creation phase, like it should be.

Unsellable items will be marked with a red dot near them.



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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharing

[ElkiwyDev]

Hello Everyone!

Stefano here with the 24th Project_BuildTutto's Update!
Quite a slow and steady week this one, I took two days off since I'm away from my usual working place and I had some stuff to do that kept me busy for those days. No timelapses neither since I was able to work non continuously and the stuff I did wouldn't have made great content for a video.
So here you have this week's changelog:

(NB: The word and line count has gone down since I heavily cleaned a lot of code inside the WindowObject_ScrollableList and I removed many old lines)



Shader Improvements
Blurred Menus are now back online! After I created it few weeks ago I had to disable it since I discovered that the things I did lead to undefined behavior, and in C++ this usually means that bad things will happen if you ignore it. So I managed to rework it and improve the performance a lot by process a downsampled image of the frame instead of the full res one, giving roughly 75% reduction of execution time!

Smoother windows' animations
Windows has been tweaked and improved too giving them a nicer scaleIn and scaleOut animation smoother by the same constraint used by the guys' in their movements.

Also Library windows has been modified removing the right panel.



Object selection menu improvements
This menu is still ugly as hell, but now has a bit more functionality that will let the player select a resource in the level and let him choose to install that object somewhere in the map or to sell that object to make profit.

Other minor stuff
-The right gui panel now updates correctly when a resource item is added or removed from the current level
-The Object selection menu on machines now displays what is stored inside and what are producing
-Machines now display the sprite of the item that are producing over them when those are working
-A lot of minor fixes and tweaking

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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharing

[ElkiwyDev]

Hello Everyone!

Stefano here and this is the 25th Project_BuildTutto's Update!
I finally got back at my usual working place on Wednesday, so I regain the productivity of this place, and the timelapses videos too!
Nothing hugely visible has been done, but a lot of "under the hood" changes to improve both performance and my quality of life maintaining and upgrading the code base.

A lot of fixes and optimizations
Last week I worked away from home on my mac machine where I have a sublime+gcc setup for coding (and a windows partition with visual studio for emergency) and with that setup I really enjoy coding a bunch of stuff without testing much and debugging the problems. So, when I work away from home I usually add new features and when I get back at my windows workstation I spend whole weeks debugging and fixing all the problems caused by rushed code on mac.
This week, sadly, was no exception to this rule. I spent a good part of Wednesday fixing small problems on the resources installation menu and improving the process of building new items without crafting them and picking the final product from the storage. While fixing that, I noticed a lot of other stuff going wrong and those lead me into a rabbit hole that ended with me analyzing code performance of the whole game and picking optimizations spot trying to improve them. Luckily, I was able to improve the performance a lot just by tweaking and changing small portion of the code, and the boost is quite noticeable.



What I *think* I learned about memory and caches
When I was optimizing stuff, I noticed a lot of the bottlenecks when the game was mass updating big portions of 2d vectors. For example, this portion of code was present into the pathfinding algorithm used by guys to move around the map:

That portion of code cycled all the vector<vector<int>> in order to reset it back to his default value each time a guy had to find the path to some place. At first, I couldn't imagine that this could be the slowest point of all the pathfinding system since it was the simplest operation to do. But it indeed was, and by a lot.
From a sampling analysis, that portion of the code was more than the 80% of the time spent inside that function.
To give you an idea of the context this is the whole function body:

Something had to change in that snippet of code, and after a bit of thinking I remembered something about memory and caches. That's a pretty complex topic to tackle here, I think I should go straight to the point:
a vector of vector isn't a contiguous memory block. This means that one of the nested vector could be anywhere inside the memory, and the next vector could be also anywhere in the memory. This creates a lot of slow down and cache misses when trying to do operations on the whole 2d vector, since the system is always busy moving each vector from ram to cache.
A contiguous data structure on the other hand has the advantage of being all compact in a big block on the main memory, this lead to huge boosts in performance since when the first part of the vector is moved to cache, a lot of other parts are moved as well, removing the needs of other movement later on.

To solve this problem, I then implemented a custom vector2d class which is simply a big 1d vector (which is contiguous) with custom operators to access to memory location simulating a 2d grid.

Replacing the old code with this new code was quick and easy and leads to an impressive boost in performance, since the old 80% of the time spent there decreased to a whopping less than 1%! (Note that I also discovered the std::fill function that is also a nice improvement instead of the manual assignment of default values like I did before)

New recipe and library manager
Phew, that was a lot of talking on the previous point. This could be another long one, but since is not really finished yet I'll talk just of the ideas here, and explain the implementation deeper next week
Long story short: I had to redo the way new objects are created and discovered through the blueprint menu. The old way was just a bunch of hardcoded stuff which was a nightmare to maintain and improve. So, I redid all the system by creating a parser from external files, which I can modify to add, remove, or edit anything of the item properties like the materials needed to craft it, the pattern, the properties inheritance, value, and a lot of other stuff.
I'm also very happy with this change, but as I said before, I'll talk about it better next week.



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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharingr]

[ElkiwyDev]

Hello Everyone!

Stefano here with yet another Project_BuildTutto Update! Not the most feature rich week, but still a lot of improvements during these days since I did many tests and debugging sessions to smooth out all the various edges of the game right now, aiming at the famous "Stable and somehow playable" state of the game.
So, lets dive into the changelog, stats, and videos!

New recipe and library management
As I anticipated you in the previous update, I reworked the way new objects are coded inside the game. In particular I had to think a way to specify for each object all these different properties:
   -The object resources used to craft it
   -Their pattern inside the blueprint grid
   -How all the different object's properties are inherited by its component
   -The final value of the object
   -Its category and materials
   -Its class
   -How big the object is
   -How much time it takes to be crafted
   -Other things that I eventually add into the game
As you can see those are a lot of information and I absolutely needed a parser to understand all that crap and convert it into the game when needed.

The final system that come out of this is a series of functions and an external file. In this external .txt I write all the different objects stuff in this way:

Then, on the game startup, this file is loaded and parsed by few functions, and for each recipe a Recipe object is created. When the player will enter the blueprint menu, each time he will add or subtract an item from the grid, the game will run through all the recipes and will look for a matching pattern for that object, saving all the possible valid patterns inside a "validRecipes" vector. Then, the game will create the new object, feed all its stats and properties, and make it available to be saved in the player's library.
I'm happy with this system since it gives me much more freedom and ease of access on all the various details of each object without changing anything inside the actual code, allowing much easier balancing and tweaking.



Improved orders handling by guys
Another quite substantial improvement is found inside the guy's code base. To recap shortly, the main order system is structured like this:
   -Each Level has a list of orders to do to satisfy the current level's needs.
   -Each guy when it is looking for a job to do asks the level object and it gives a set of orders to do.
   -The guy executes all the orders and check back at the level object to tell it he did all these orders and he can erase them from the list.

Now that each guy has its own strength and can lift different quantity of objects, I had to improve the code allowing guys to change internally the orders to fit their stats and capabilities. This wasn't a very easy process since I had to improvement the communication between this two classes, but at the end it worked and I'm very happy with the results.

Small minor changes and fixes
Other smaller improvements consists in quality of life tweaks like the library that closes itself when an object is selected, the blueprints menu that doesn't take all the screen but leaves the bottom and top gui still available to be used, reintroduced the serialization save system only for library so I can test the game without having to blueprint all the objects each time I run the game, added information like progress bars and the sprite of the items being produced inside the fuelmachines.
Optimizations improvements like a faster code inside the ghosts checking for materials to be built and better GUI objects code.



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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharingr]

[ElkiwyDev]

Hello Everyone!

Stefano here, and this is the 27th Project_BuildTutto Weekly Update! Another pretty boring week feature-wise, but a lot of improvements has been done and next week there will be (finally) some cool new feature! So, let's dive into the timelapses, changelog, and stats!

NB: I didn't record Monday because I worked on a side project, and on Thursday I didn't record correctly the video so I didn't upload anything that day.

Blueprints Menu improvements
The firsts things you can notice in this update are the improvements on the blueprint menu. The old version was buggy and very little descriptive about what you were making giving little or no information other than the sprite of the new object. Now, thanks to the new recipe system added last week, I can display a lot more information giving you everything you need to compare objects of different materials and how they interact with each other.
Other than that, you can now also remove an existing blueprint by selecting it from the left list and drag it over the "Remove blueprint" button in the bottom right corner.

   

   


Scrollable list's bar
Another little handy thing is that now you can use the scrollable list’s bar typical of these GUI objects! The whole object got some other improvement like limiting your scroll more than the total height of the list, and other boring stuff like that.

   


Early game testing
The quest for testing the whole early game continues this week too. I'm still working pretty hard fixing all the bugs and crashes that I come through, trying to polish it as much as I can. Other than bugs I'm also trying to keep eyes open on everything that could feel bad or not correct in a game like this (And there are A LOT of things to think about) so the experience of the new players can be as smooth as possible.

In this list I'm trying to work out all the small little minigoals for the earlygame to help new players and guide them into the basic mechanics of the game. Thanks to this list I discovered that I have no early game light sources, and this is kinda bad because right now indoor rooms and night times are almost pitch black.



Added gas objects
To try adding some basic light sources I come out with the idea of fluorescent lamps like the typical neon ones. But after designing the recipe of it I quickly realized that it wasn't really early game-ish since it involved a lot of machines to do it.
But anyway, this gave me the opportunity for introducing gases.
Right now, gases are basically a variant of liquids, but I'll make adhoc pipes for them.
Next week I'll work on a new machine capable of doing work with both classical objects and also liquids/ gases.



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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharingr

[ElkiwyDev]

Hello Everyone!

Stefano here and this is the 28th Project_BuildTutto Update! Even if this week changes could seem small, a lot of "under the hood" stuff changed and improved to make this work, and since this new feature push the game forward on the development progress I'm really happy about it!
This week I tried a little different format for the video, I grouped up two days inside one video to make the content denser of stuff and maybe less painful to watch... Let me know if you have any feedback about it!

The Assembler machine (Again)
In the past weeks I talked briefly about this machine, but I think that I didn't really went deep explaining what the plan for it was. Anyway, the initial idea for this machine was to simply have a machine that will craft anything you can craft with your hands but way faster to speed up production without hiring more guys. This is still one of its feature that will be added in the future weeks, but instead I wanted to work first on another important feature of this machine: the ability to links to pipes and work with them to craft objects that requires liquids or gases.

This is an important thing to note since it's one of the first machine that the player will encounter during the early game, which will allow him to craft important objects like early game fluorescent lamps to pass the (maybe too dark) darkness of the night.
This object is also an important one since it will make the player design the liquid/gas pipe system carefully to make sure that it will work correctly with the current flow of his guys.



Objects made with liquids/gases
The assembler could seem like an easy small feature, but to make it work I had to recode many parts of the codebase to be able to manage all the recipes that involved liquids and gases since those are objects required in the recipe, but that will NOT be transported by your guys like all the solid objects are. Instead, the player will have to work to make sure that the liquid/gas is already present in the machine when it is required to allow guys to operate the assembler and craft the thing he want.

Early game progress
This feature, as I said before, it's a big step forward in the direction of having a "complete" early game experience. There is still a lot of things to do before reaching a playable state. Next week I'm planning on reworking part of the light renderer to allow different types of lights, and after that I want to finally start working on the fundaments system to improve greatly the feel and design process of creating the actual structure of the building that the player will create.
There are also many other points on the todo list, but slowly and surely I will address and complete them all!

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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharingr]

[ElkiwyDev]

Hello Everyone!

Stefano here, and welcome to this 29th Project_BuildTutto! This week was an unconventional one since I had to stay away from my working place for the first part of the week, effectively being able to work properly only from Wednesday afternoon. So, not the most changes rich week code-wise, but still important changes have been done to the code base.

Light Renderer rework
Since I added new kind of lights inside the game in the past weeks, I quickly realized some limitation of my previous light renderer: It could only generate one kind of light. So, I had to revisit part of that code to add support to many different kinds of light, being able to change their size, intensity, and also their color.

So after some of this:

And some of this:

I finally got a decent light again:

Other than that, since I was already changing that code, I improved the way that the lightmap updates itself.
To briefly recap how my light system works, there are mainly two types of objects to keep in mind: light sources and solid objects that stops light.
-When a light is placed, the system needs to create its mask by subtracting the shadows created by solid blocks around it to the original light sprite.
-When a solid block is placed, the system needs to update all the lights to change eventually their mask since a new block is now present on the map.

When I added light to the level there is no big problem since it already checks only the blocks in its range, but when I was adding block I was updating ALL the lights inside the level, even the ones so far away that it would make any difference.
Now I added a 2d vector to hold a map of all the effect areas of lights, so now when a new block is added, I only have to check and update the lights present in that tile, leading to huge improvement on performance.

This method was kind of obvious and looking back at it it's pretty stupid, but somehow I didn't think about it back then.



Save and load serialization changes
Now that I'm doing a lot of testing on particular setups I really had to improve the loading performance of the game because it was REALLY slow (something like more than 1 minute to load a save file with few objects in it).
The first thing that I discovered to slow down the loading was the loading of all the 2d vectors holding various information about the state of the map.
Those vectors were 100x100 cells, and zooming back I quickly realized how insanely huge was a 100x100 map. An easy and quick fix was to tune down the map size to a still modest 48x48 grid, cutting the serialization time of each 2d vector from +800ms to more or less 200ms.

(This is a 48x48 tiles map)(PS:Don't look at that glitchy fog, I'll fix that later)

Another thing to do was to get rid to the hold NVP (name-value pairs) method of serialization in favor of a quicker and simpler binary file method.
This means that first, the serialization was creating an XML-like file holding all the information, but this was extremely inefficient on the performance, and was useful only for debug purpose when I didn't have the knowledge to build a decent serialize function for the objects. Now that the system was working fine, I finally changed back to binary files and the performance improvement was really huge, cutting the vectors loading time by 90% from 200ms to 20ms!
Now the games loads itself in a blink of an eye and I finally can test thing much quicker and in a less painful way.



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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharingr]

[ElkiwyDev]

Hello Everyone!

Stefano here and welcome to this brand new Project_BuildTutto Update!
Pretty happy with this week's results, there were a lot of structural improvements and new objects, all spiced up with the usual performance improvements which are always nice.

StructuresManager Class
This is a really nice improvement. Before the introduction of this class all the static objects (the ones that doesn't really need an Update event each step because don't do anything fancy after their installation) were instantiated and managed just like all the other objects like furnaces and machines. This was a bit unnecessary and ugly to work with since the Level class needed to pass through every floor tile and wall tile individually once to update them doing nothing and once to draw them one by one.
This class changed a lot. Now when a wall or floor (or anything static) is installed in the map, the important information of it is moved inside this structuresManager class, stored in a 2d vector grid and the original object is destroyed, saving a lot of space and compacting all the data into a more easily accessible structure.
This class has also a single big bitmap which updates each time an object is added or removed, so the player doesn't notice any changes and the game keep showing these objects like they are still individual pieces.
Other than performance improvements, this class also give me a much more comfortable place to work on more complex mechanics like the structural strength of the building the player will create or the roof/wall/foundation system which I'll talk more in-depth later.

Foundations

NB: Both Foundations and Roofs sprites are WIP, in two weeks I'll take a whole week to try improving the general graphics of each tile.

Foundations are always a really important part of any building, and in the game this fact is still true. Now the player can't simply place stuff like walls and floors anywhere he wants, but he has to build foundations first to handle the weight of the thing he wants to build in that tile. He'll also need to create strong enough foundation because obviously he can't place too much weight on a foundation made of simple wood (or glass if he is really a madman), because eventually those will collapse leading to very ugly situations.

Roofs
Roofs are another really important piece of this huge puzzle. The player will have to think a good way to build roofs to cover his building, but that's not it. Eventually I'll add the possibility to build more than one floor in a building, so roofs will need to be perfectly planned to be able to sustain the weight of the floors above it.

Different materials will lead to different roofs with different properties. For example, an iron roof is more rigid than a wood one, so it can extend further away from the wall supporting it without having an intermediate wall to support its distance, BUT an iron roof weights much more than a wood one, so the supporting wall needs to be able to support all that weight, otherwise it will collapse leading to other ugly situations.

The “calculation of the distance of each wall to their support” algorithm took a big bite into my mental sanity since it had to support a whole bunch of different situations like:
-Adding a new roof
-Adding a new wall below an existent roof and update all the distances correctly
-Adding a new roof that connects to another roof leading to a different balancing of their weights
-Removing a wall below a roof and updating the new distances
-Removing a roof disconnecting two chunks of roofs previously linked
-Being able to always know on which wall each roof is supported
-Being able to know the total weight each wall is supporting
-And other very situational conditions...

Foundations/Roof View Mode
Since both foundations and roofs are normally invisible or hided away from the player view, I added two more "special" view in the view mode to be able to see and easily manage roofs and foundations.

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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharingr]

[ElkiwyDev]

Hello Everyone!

Stefano here with a brand new Project_BuildTutto Update!
This week I moved to my parent’s house for the summer so I wasn't be able to produce videos, but for the next weeks I'll try do that and MAYBE even stream something on Twitch if my connection allows that!

Walls and Roofs collapsing
Last week I introduced to you the new StructuresManager class with its new classes and objects.
Objects like roofs were particular complex since the player will have to be able to manage them properly to build the right structure and supports for the building in order to not fail in it.
Poorly designed roofs will indeed collapse and fall down, and they could also destroy objects below them!
So, this week I added all the conditions and checking where roofs and walls should collapse and the following condition are now present in the game:
-A group of roofs will collapse if the player decide to remove a wall that was previously supporting those roofs, leaving them without nearby walls to offload their weight.
-A wall, and the roofs supported by that, will collapse if the sum of the weights of all the roofs supported by it is greater than the maximum weights that that wall can support.

Improved Indoor recognition
Before the indoor recognition system was pretty easy since it checked only walls and doors to delimit all the rooms of the level and that was it.
Now, a room without a roof is obviously not an indoor space, so I had to improve the previous algorithm to be able to check for roofs too to be able to recognize a correctly indoor space as a room.
To be able to achieve that result I kept the old system, but after one run of it I check that all the rooms have a roof in each tile of them, if one tile is missing a roof I set that tile to be outdoor and propagate it on all the rest of the room.



New Indoor Light system
With the new indoor recognition system I wanted to also improve the old indoor light occlusion.
Previously the rooms were lit until the last wall was installed. Once they became an indoor room I started to render all the indoor tile as dark tiles. The problem with that was a very unrealistic feel of sudden darkness in all the room which was totally not what I wanted.

Now instead of just one type of dark tile I have two (maybe more in the future): a soft darkness and an hard darkness.
The new rules that the light renderer follows to assign darkness to a tile are simple:
-A soft darkness tile is rendered when it has a roof over it and has at least one tile adjacent to it with the normal ambient light (no darkness)(solid walls counts as full darkness)
-A hard darkness tile is rendered when it has a roof over it and all the 4 adiacent tile are hard darkness OR soft darkness OR a solid wall
This system create a very basic way to fade lights. A simple but quite effective way to improve the previous system.

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: https://discord.gg/mSCn4BU

YouTube channel for Timelapses: https://www.youtube.com/channel/UC2l3kcw6wUn4Z1-cr5UMLMw

Twitter: https://twitter.com/ElkiwyDev

Changelog: https://docs.google.com/spreadsheets/d/1kVIHUpf0jC8NFg5rxJF_hiWDkw-0VWnMI-Au4op0MiQ/edit?usp=sharingr]

[ElkiwyDev]

Hello Everyone!

Stefano here with not a really update this time sadly.

There was a lack of weekly updates lately and I'm really sorry about that, but few things changed in my life in the past month and those things forced me to change my route slightly, especially about the work side of things.

So, to be short, I had to find a stable and secure job because I wasn't able to sustain the development of Project_BuildTutto anymore. I had to pause temporary the coding, build up a CV, send that to some companies nearby, and bla bla bla...

At the end I found a job position as an iOS app developer in a company near my parent's home so I accepted that and now I should begin to work somewhere around the 16th of July.

BUT, I'm not quitting with this project. I want to keep work on it, but I'll not be able to keep up with the big and constant updates that I was pushing previously.

Currently I'm spending most of my time to prepare for the job, but when the things will settle down a bit I'll grab this project again and I'll keep working on it.

I hope you guys understand, and see you in the next update!