Stefano here with yet another Project_BuildTutto update! This week was planned as a "Redo some stuff and test everything" so nothing very exciting at start, but it did turn out as a good and fun week with some cool stuff here and there. As always, here are the timelapses and the full changelog:
Unique object's IDs
The main goal of the week was to redo the light system with raycasting, but after thinking a bit during the weekend I had to face it: the old ID system was not good enough to handle the complexity level reached from the current state of the game. Since every object in the game is made out of something else starting always from raw resources, every blueprinted objects has to have an ID able to describe the object and tell to everything else in the game what is it and what material is made of. Before, IDs were like : *category of the object* + "_" + *material of the object*. So if a block was made of raw iron, its ID was "block_iron", and if you would use those blocks to build a wall, the wall ID would have been "wall_iron", since the blocks were made of iron. That system was "good enough" for the blocks and wall example, but not enough for objects like the continuous caster which was something like this:
That kinda worked because when I built the furnace, its properties were already inherited from its materials so there was no real need to knowing what was made of to get its behavior. When a contcaster was made, it would inherit everything from the furnace and still work just fine. The problem was: "raw_B" define how much heat the furnace can output in order to melt materials, so it's a key element to both furnace and contcaster, but it's not present in their IDs. So if the player would blueprint two different furnaces, one made of iron-wood and one made of iron-coal the resulting two furnaces would have the same ID. And that would create big problems in the crafting system since the algorithm could not distinguish which furnace is requested from the ID only. Getting rid entirely of the old is wasn’t ideal, since it's a handy little string that gives me easy access of what an object is and what sprite assign to it. But I clearly needed to add more information to objects. The solution was to keep the old id for non-crucial task, and add a "uniqueID" to the objects in a JSONarray-like structure like such: [*category of the object*, [*uniqueID of ingredient1*, *uniqueID of ingredient2(if any)*, *uniqueID of ingredient3(if any)*,...]] So, to make it clear here are some kind of uniqueIDs:
so with that, if I have two different furnaces and contcaster, I’d have two different uniqueIDs describing those, and the recursive nature of it is ideal to get the exacts IDs of the components deep as I want during the crafting system.
Improved light system with raycasting
Ok, after that big one done here is time to turn up the lights. As wrote in the previous update, the lights i made last week weren't good enough for me, so I re-made part of it and implemented raycasting. After getting through some of this:
...and some of this:
I got something like this:
What I didn't wanted was something that could take too much performance for such a non-crucial task, so I tried to design it as efficient as i could. What come out is an almost-dynamic-but-not-in-realtime light system which plays a lot with sprites and blending. It works something like this:
In this way I only need to make all the calculus when I spawn a light source, or when i place some solid objects like a wall nearby a light source. In all the other "normal" frame the light already has the right custom sprite in memory and the only thing it needs to do is draw it.
Improved objects rendering with camera movements and scaling
Another important thing to do was to work on the camera rendering, since it worked only when the camera was at the default position and it was at the default zoom level. An important performance thing to always keep in mind is: "drawing is hard, so don't take that much effort to draw something if the player won’t see it". In fact, if I tell to the game "draw this sprite offscreen" the computer will still have to work to draw that but the user will not see it, effectively taking resources for no reason at all. That thing is a crucial performance key when coding a tile based game with levels bigger than the normal camera view, since I always have to calculate what the player can see and what he can't, and adjust the rendering as such.
GUI console and improved scrollable list rendering
Lastly, yesterday I finished the goal for the week, and while I was testing out stuff in the game I thought "Right, a potential player can't see the debug console in the terminal to understand what is going on in the game... I have to do something about it". So I designed and coded a custom console log to let the game communicate to the player. I wanted something well made and scalable so I took particular care in making it. The final result looks like this:
From anywhere in the game I can tell the console to add a new message with a specific color and a specific lifespan before fading out. In any moment the player can scroll the log showing all the messages printed previously with a custom maximum backlog of 100 messages.
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