Things are far from calm on our front these days. Every day, we dive into new adventures, and in the process, we’ve realized we have serious issues. Today, we’ll be discussing the following topics:

• TIC-80 games are vulnerable
• The damage open-source code inflicts on engineering
• What will we do now?

Without dragging this out, let’s start by explaining our grievance with the first topic.

TIC-80 Games Are Vulnerable

We know it’s a system whose concept we absolutely love, but which falls apart no matter how you hold it. Still, relying on it to make games was clearly not a wise investment, as we witnessed firsthand just yesterday. Today, let us explain everything we observed.

The first problem we noticed is that there is no real .tic file format. If you look at the image above, you’ll see that the initial Hex values do not contain TIC. This means that Windows and other operating systems cannot inherently identify what kind of file this is. Such metadata is essential for verifying the integrity and honesty of these files.

The second issue we discovered is even more shocking. In software like Unity, you can still view data through reverse engineering, but here you don’t even need to go that far. When you open the data with any basic text editor, all the code is visible in plain text, and the graphics are unencrypted (if you’re lucky enough to interpret them).

Would you call these problems disgraceful or irresponsible? Honestly, it doesn’t matter what label you put on them. We have proven that this constitutes a serious issue for us. So, what will we do about it? We’ll address that later, but first, let’s discuss an even more critical topic rarely covered in the Turkish market: The damage open-source code inflicts on engineering.

The Damage Open-Source Code Inflicts on Engineering

We won’t indulge in speculation here. Let’s face the harsh realities. They have trampled upon the honor of engineers. By constantly preaching "open source," they have driven away true engineers. Because every piece of readable code essentially says, "Come, let’s feed our egos here." The damage caused by this mindset doesn’t stop there. As an example, when the wonderful developer behind Celeste saw this vulnerability, they immediately left.

Currently, the PICO-8 world consists solely of demakes and demos. Even worse, if you claim to support open source, why do you charge $15? Let’s set that aside for a moment—why do you interfere with game sales? TIC-80 is in an even worse state. Only demos and prototypes remain. Why is there no flagship game among them? There is a rule in engineering: Any software, language, or tool used must offer predictability and security. Otherwise, developers will stop writing code for it instantly. Ironically, Linux’s desktop market share is directly proportional to its usage numbers, reflecting this very issue.

What Will We Do Now?

As part of this transition, we have decided to reshape our development workflow. During weekdays, we will focus exclusively on Construct 2, using it to develop our long-term projects for the Windows platform. Since stability, development speed, and project management are our top priorities for larger-scale games, Construct 2 will become our primary development tool.

Alongside that, we will use GDevelop for the short-term games we release every Sunday. Saturdays and Sundays will be dedicated entirely to creating these smaller projects with GDevelop, while weekdays will remain focused on our main projects. This approach allows us to continue our tradition of releasing a new game every week without compromising our long-term goals. By using each tool where it performs best, we aim to build a more sustainable and efficient development workflow. Of course, this new schedule will only take effect after we have completed all of the games currently planned for TIC-80.

In Conclusion

Once this system is complete, the Wiki and site will be redesigned according to the new system. We will consider the Wiki content at a later date.

Respectfully,
Hexabee Network.