Post news RSS Project_BuildTutto Development Update 17

In this series of updates I'll document the development process of the game in detail, post timelapse videos of the work, and talk about some features...

Posted by on

Hello everyone!

Stefano here with the 17th update of Project_BuildTutto!
I'm finally back at my usually working place, but still no timelapses because I wanted to get back at some boring work here and there on my windows machine and I didn't record that because I think is quite boring to watch a timelapses of someone who do nothing for 4 hours trying to solve bugs. Luckily the week wasn't just a solving bug week, but I did coded something interesting the last days so lets dive into the update!



(nb: line, word, and char count is a bit messed up because
I din't worked on the pc that counts line until today)

Storage areas

This was a thing that I promised last week since I coded the general areas but not their specific behavior inside the game. The storage area is conceptually quite simple: the player designates an area where guys can store there items. Even if the concept was simple, I still had to think about it a bit to try find a way to code that in such a way that will work seamless with the storing code already in the game, and at the end I came up with the idea of creating fake item chests in each area’s tile. In this way the game sees the area like many simple basic chests and the code works just fine.


Later on the development I want to add a contextual menu to storage areas where players can choose which items can be stored inside the area and which cannot, to give them a way to better organize their working places and optimize the storing system to their needs.

Improved storage items and guy's storing behavior

Since I needed to make StorageAreaTiles basically a simpler chest item I finally changed and layered the chest class splitting it in GO_GENERIC_Storage (derived from Gameobject class) and GO_Chest(derived from GO_GENERIC_Storage class). This let me code all the generic behavior and function of a storage unit (like addItem, getItem, getFreeSpace, etc.) inside the generic storage, leaving the properties of each chest in the specific derived classes like GO_Chest(which can hold infinite different object types and has a maximum capacity of 1000 items) and GO_StorageAreaTile(which can hold only one object type at the time and has 100 max capacity).

With this layered system, coding a new storage unit is very quick and simple since I basically have to code a basic object and only change his properties.


Other than that, I also improved how the logic of storing things works making guys a little bit smarter. Now a guy will always try to see if there is already a not completed stack of the same item that has to store to optimize space and store items in a nicer and compact way.


Crafting areas and auto craft orders

Before talking about crafting areas, I need to introduce you the concept of autoCraftOrders: those are a type of order that the player can give to the game telling what items he wants to be automatically produced to be sold and obtain money. Those can be a continuous (infinite) order or can be limited to a specific amount, but to be completed the player will have to create a crafting area to tell the game where to craft and store those objects before loading them inside a truck and sell them.


So, crafting areas are similar to storage areas with the difference that those will not be an accessible storage unit but will be a unit that will store only items crafted there instead.


Right now, the background structure of it is already done but I'm still working on the autoCraftOrders menu to give an accessible interface to create orders.

Huge performance boost on Windows and bitmaps reloading

Monday and Tuesday were very bad days since I didn’t code that much and I spent a lot of time working on bugs and such, but at the end it all came up with an happy ending: a huge performance boost at no compromise at all!
Trying the game with visual studio CPU profiling I discovered something strange, my workload distribution of the main gameloop was something like this:

al_backup_dirty_bitmap() --- 80%
Draw() --------------------- 7%
Update() ------------------- 4%
Other ---------------------- ...

So, after some researching and googling I discovered that allegro backs up all the bitmaps to video memory EACH FRAME to avoid a problem that happens when the window get resized or toggles fullscreen where it loses all the bitmaps.
To work around that problem allegro suggested to implement a custom bitmap reloading system, and it was what I did. This system will reload all the bitmaps from disk when something happens to the window (resize or fullscreen) and will do nothing at all in normal playing conditions. Few hours of coding later I was finally able to disable that allegro feature and all the framerate issues in Windows just disappeared!

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:
YouTube channel for Timelapses:

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.