Devlog #38 (25c796f):

the beans aren’t going to know what hit them (regarding my 145 hours waiting to be shipped)

I made a couple of changes, such as improving the readme and disabling the exit button, greying it out and making so that it can’t be pressed. For context, the game can only run on the web, and the exit button just doesn’t do anything useful on the web.

I also customized the itch.io page (which hasn’t been released yet but you can access it here via secret url). It looks kinda decent (i just copied the game’s color scheme)

Devlog #37 (8b55316):

I made a web build for the game! I took a break from Stardance to make something for Out to C, and when I was making a C game with Raylib I discovered that it is extremely hard to make a downloadable executable run well on Windows or MacOS, because on Windows you have to include DLL files, and on MacOS it’s just harder to install Raylib. In the end, I ended up making a web build, and since I wasn’t so bad, I decided to make a web build for this.

I used Emscripten, and using the em++ tool with the asyncify option, manage to get most of the game logic working, with only one small frame generation bug, which I fixed by changing this_thread::sleep for to something that is easier for the browser to render.

I also made some other QoL changes so that the bot feels less stagnant, hopefully.

Devlog #36 (fcc4f2f):

I made the first gameplay change in a while, and also changed the theming a bit more.

The gameplay changes

I noticed that the game was getting a bit… repetitive, so I changed the bot to have an element of randomness when there are multiple spots that provide similar advantage. This took me a long time, because my code is spaghetti, and also because random in JavaScript is so much better than in C++

The visual changes

I changed the theming of the game because I didn’t think the discord-esque style looked very good. Now, it’s changed to match the “Arch” theme on Monkeytype. I also changed the font to Roboto Mono since that’s what my configuration of Monkeytype uses.

Stuff to do

• Compile this for Windows and Mac, put this on Itch.io.
• Ship the project

Devlog #35 (b48efd0):

I fixed most of the font scaling issues, and also updated the README at bit (as always).

I did this by loading the same font 3 times, once at 20 font size, once at 40, and once at 80. I changed the code to use a either the 20, 40, or 80 version of the font according to the font size to make the text look smoother.

Devlog #34 (4eec49b):

I changed the font! And also updated the README.

Fonts in raylib are REALLY hard. Since I’m using multiple different font sizes, the scaling is really screwed up and blurry sometimes. When I was trying to add the custom font, I may or may not have… lagged out my computer and had to restart.

as for the readme upgrade, i added instructions to play

i also removed some semicolons. took me like half and hour

Devlog #33 (d16d3b8):

This time was used for trying to make the project work for webassembly, which i have decided to abandon. Therefore, this time should probably be deflated to account for the lack of progress.

I probably picked the worst language for compiling for the web, and next time I want to make a web version of anything, I’m going to use a game engine. This just did not work out, and was too much effort to save maybe ~2 seconds of time. I’m sorry that this will cause any reviewers to have to download the game to play it, and to compensate I will be attaching a link to a YouTube video demoing the game either on the readme, on the itch.io page, or both.

I feel like a failure for this, but maybe it’s the right choice for my mental health and academic… idk is health also the right word for this situation?

Devlog #32 (ca5f14e):

I changed the theming yet again. I’m not really good at making programs look good, and even when I do,
my designs are usually really basic.

Yes, it’s inspired by discord.

Please tell me how this looks in the comments, I really need feedback.

I also finally added a little change in color to some of the buttons when selected, which was the entire reason I decided to rework buttons in the first place.

I’ll also attach a beta design that’s more of a retro/terminal aesthetic, but contrasted too much with the cube and letters IMO

Devlog #31 (6639676):

I fixed the code!

Essentially, the code was breaking because the hover info for the code was undefined. I fixed it by setting the hover info to the regular button info if the hover info was not defined.

Then I ran into another issue, which was that the buttons, upon hover, were being drawn from the center instead of the corner. It was a simple enough fix, I just changed like 2 values to use the calibrated values instead of the center coordinates.

And yeah, the only real issue right now is that the text on the board is slightly offcentre, but that’s not really a big issue.

Devlog #30 (b5f8085):

The code is now compiling again, thanks to, as much as I hate to admit it, Visual Studio Code.

I’m on Linux so I can’t use Visual Studio, CLion is kinda weird and the error messages are broken, and KDevelop doesn’t have a Wakatime/Hackatime plugin yet (maybe it does, but it isn’t in the Hackatime docs)

I opened VSCode and was met with like a hundred errors. With a combination of VSCode’s functional error messages, DeepSeek telling me what those messages mean, and my pretty average brain, I managed to remove all the errors. But since I didn’t know how to use makefiles and stuff (still don’t ) I had to compile the program manually again.

Apart from the fact that it crashes upon any user mouse input, it’s functional!

Devlog #29 (57bac36):

Guess what I did:

• a: Made my code work again
• b: Add new features
• c: Complete the button rice
• d: Look up the GitHub Repo for DeepSeek because I got bored and discover how to add badges to my README.

I had way to much fun doing this (it was d)

Devlog #28 (ac77900):

I added an entire separate .cpp file for handling buttons because I wasn’t satisfied with how they were working (I love ricing).

Yes, it did take 9 hours. I have a skill issue. There are 3 main things I improved on:

• The buttons are now more customizable, as they now accept JSON files as setup input instead of like only 4 parameters.
• A function was added to change the button upon hover
• It’s more organized since the files are separate.

(I haven’t actually tested the code out yet, I feel pressured to get the devlog out ASAP)

Devlog #27 (a1b005f):

I highkey have trouble keeping track of what I did between devlogs sometimes, so I’m adding the SHA of the Git commit to devlogs.

So I tried to create a dedicated c++ file for handling buttons, since I wanted to have even more control over them, but ran into the issue of not having a way to share variables across different files. I know global variables are kinda bad, but I mean in this scenario they’re like config stuff that isn’t really going to be that harmful…

Most of the time was spent creating the button.cpp and button.h files, and they’re not even in GitHub yet lol

Devlog #26:

Pretty short devlog. I added some simple QoL changes: the main menu title is now centered, and the popup and some captions now have a margin around them so they aren’t stuck right on the edge.

Also this was technically done a couple of devlogs ago, but I added shell scripts to compile and run the program so I don’t have to type g++ -std=c++17 -Wall -Wextra -Werror -pedantic -o build/tic-tac-cube src/main.cpp src/board.cpp src/bot.cpp src/logs.cpp -lraylib every single time I want to compile the program.

Devlog #25:

I tried to make the UI look good. It isn’t necessarily good, but it’s better than it used to be IMO.

I just changed the color scheme, and now the text is round and the boxes are rounded.

I also reworked the board position display system. Since the squares are just buttons, and the button class can display text, I just made the board display text by itself.

For context I wrote the button class to draw and handle buttons. There might be a class for this or something but idc i just wrote it myself like 17 days ago.

(How is it) Devlog #24 (Already):

Lowkey, when I started this project I was expecting to take 1 week max, and it was supposed to be like practice for making a more advanced project. I’ve since decided to not make the more advanced project (for now). Now, it’s been more than 2 weeks since I’ve started it, and it’s still in rough shape and probably not ready for release.

The UI still sucks, but I added like a popup system for displaying messages, such as telling the user why they won/lost without the win being visible due to the nature of the board being a cube. I was going to make a class to handle all the popups, but I settled for global variables and functions. Probably not the best practice, but it works, and if it ain’t broke don’t fix it.

I also added a entire new menu, the help menu. It could probably use some improvements, so if you have anything you’re curious about or confused about, drop a comment. There’s like 8 people that have seen this project, so I’m really expecting anything, but it would be appreciated greatly.

I lowkey forgot to add one break statement, so I spent like 30 minutes trying to figure out why it wasn’t working

Still, how the hell did this take 7 hours? I swear I’m not inflating my time by any means.

Devlog #23:

“Minor” improvements that take like hours to do is literally my entire C++ learning experience so far. This time, I improved the “wild card” function that rotates the cube randomly. Before, it just actually rotated randomly, and now, I changed it to check and make sure that moves it makes does not cause the opponent to win on the very next move.

fyi i DO write these devlogs myself without ai, I just literally need Vim keybinds to function as a person and therefore type all the devlogs inside of NeoVim before pasting them into the devlog. felt like writing this after i discovered that the “please write this yourself, humans read it” text at the bottom actually flashes red when you paste text.

Devlog #22:

I made the buttons look nicer by centering the text inside of them. It was much harder than it looked and I had to work with “Vector2” in Raylib. I may or may not have spent like half and hour trying to find documentation on it, only for me to discover that it’s a struct inside of Raylib. Still not entirely sure what a struct is. So I may or may not have spent another half and hour trying to declare the struct inside of the main.cpp file, before I finally gave up and asked DeepSeek. Turns out, it’s just Vector2 something{(float)x, (float)y}. It’s not exactly simple if you don’t have much experience with C++, but I started coding in C++ 16 days ago and I understand it just fine.

Halfway through, while testing, I accidentally overrode the main file and had to restore it and re-add all the changes I make. I don’t like committing before the program doesn’t have that many bugs, so a lot of progress was lost. This is like the second time I’ve done this, and if you’re curious what I did, well… The command used to compile my program for testing is g++ -std=c++17 -o build/program src/main.cpp src/board.cpp src/bot.cpp src/logs.cpp -lrayib. This compiles the code for all the C++ files and the Raylib library, and creates and executable inside the build/ directory. Except I forgot to type build/program, and so GCC just overrode main.cpp. Honestly though, it didn’t do that much harm, thanks to the test.cpp file having a similar version of code as the code that was overridden, and also git.

hackatime isn’t working so i can’t even post this devlog

nvm it just worked

nvm it broke again

honestly this is one of the first times anything has broken in my experience as someone who joined hack club like 3 months ago. im sure everyone involved in fixing this is trying their absolute best.

Devlog #21:

I am very very very very bad at debugging code. Somehow I managed to fix the major rendering bug and also make the fork handling better within 2 hours. I don’t believe I’ve mentioned anything about it before, but there was a rendering glitch upon the bot winning the game right after the user has made a cube turn that allowed the bot to win the game. I’m still not sure wy that happened, but I fixed it by re-rendering the entire board before drawing the board position again. If that didn’t make sense to you, it doesn’t make much sense to me either. If it did, well good for you ig.

I feel like the fork handling deserves and entire paragraph, so here:

I changed the win blocking function to also log the direction that potential win is in, by logging “position 1” of that specific potential win. The possible neutralizing moves of the directional indicator value is then compared against the potential win location neutralizing move to try to find a match. If a match is found, that means that the move is guaranteed to neutralize the given threat.

That paragraph did not make much sense, even to me. If you read my code, it’ll probably make more sense, as long as you do not get permanent brain damage from reading the it (I need to learn how to write better code)

Devlog #20:

I abandoned searching for potential forks and stopping them from ever forming in favour of handling forks that have already been formed. After more than one win for the opponent is detected, the bot registers that it is a fork. It then calculates which moves are best to neutralize the threat. There are four ways for each single win to be neutralized, so I need to make one of these four moves, for each of the two cases. In some cases, one or more of the moves overlap, in which case the overlapped move will be immediately returned, but most of the time, the bot just picks from one of the 8 possible neutralization moves randomly.

This is definitely less efficient than just figuring out how to prevent forks from ever forming, but I mean it’s a good implementation for the cube part of this game.

(Sometimes it messes up and I just win instantly)

Devlog #19:

In an effort to procrastinate fixing the bot fork bug while still doing something useful, I 1) took a 2 day break from this project to work (and ship) something else, and 2) fixed a very annoying bug where the user would be X every single time. I solved the issue by switching from older, more C-like rand() from cstdlib to the more modern #include <random>. I highkey copied the code from Stack Overflow, but at least it’s better than relying on AI.

That solved like half of the problem, but then I discovered that I wasn’t actually resetting the board properly when manually exiting a game, since I was looking through the logs. I made the logs are procrastination, but they’re actually really nice.

In case you were wondering btw, most of the time logged in this devlog was spent on trying to fix the fork bug, but I’ll make a dedicated devlog only when I’ve actually fixed the bug.