Sand-Box2D is Coming Back
Hello! Today, I've started working on Sand-Box2D again.
You don't know what is it? Hold on, I'll explain everything.
Contents
So What is Sand-Box2D?
It's a game I made in C++ using the Box2D library for physics. I just wanted to learn these technologies as well as the SDL2 library to create windows and draw some graphical stuff in it. OpenGL seemed too hard for me at the time so I decided to stay with SDL2's renderer.
After looking for how to do that, I've found a little project online by Simon Ranftl which does exactly that. It's a little C++ app for Mac (support for Windows and Linux is additional) which uses Box2D to create an environment where a box falls down on a platform.
After updating my project based on this one, I decided to give it a name and turn it into a game, a game which you can play on your PC and PS Vita (later, maybe, also mobile devices) named Sand-Box2D.
Here I leave a GIF of the gameplay so that you could see what the game looks like (you could actually see this one at the main page parallax):
PS Vita?
What really interested me is how I could compile that little project for my PS Vita. After a bunch of hours trying to setup VitaSDK correctly and linking up the dependencies (VitaSDK has Box2D preinstalled!) I've finally compiled the main.cpp
file that could init the renderer and actually show me the result. Here I leave the video from that same moment, August 24, 2022 (it was recorded shortly after arriving to my current city of residence for the first time!):
Since then, I've been working on this project in "Vita-first" mode, that is, when I work on PC and add a new function, I should first launch the game in a 960x544 window (PS Vita screen resolution), then compile and launch on the Vita itself, and only then work in other resolutions.
Why It Exists?
As I said before, I just wanted to learn some C++ libraries. But when I looked inside the
main.cpp
file provided by Simon in order to learn how he used the two libraries together (SDL2 and Box2D), I couldn't really understand everything. Code had some bloated parts, it was spawning more objects than I see on the screen (that's why I've been bumping to some invisible walls sometimes) and in general the structure seemed too heavy for me to comprehend.
This was the moment when I decided to create my new project based on this one, refactoring as I could, explaining every part of the code I could explain and removing all the useless stuff I could remove.
And as I said earlier, after adding a lot of functions to it I decided to turn it into an actual game.
Who Plays It?
No one. Literally! I've never released it and so it's normal that people don't know about it. As I write this article, the GitHub repository of the game counts exactly 10 stars.
Blog system: "And if I make the request to GitHub API right now, the project has... 10 stars. The new repo has no stars though. Cool huh?"
Who's going to Play It?
As I've been developing this game I've seen that I need to make everything modular: levels layout, button presses handling in-game... Because otherwise it all would be wildly hardcoded.
When I've been moving hardcoded parts of the code into a separate file, starting to think about its format in JSON and what also could I put in there, I've thought: "Wait! What I'm actually doing right now is creating a level!" - and yes, I've actually been creating a level. A whole custom level loading system to be precise.
Thus, I understood that my game should have a level editor and I should encourage people to use it and publish their levels.
But what also happened is that I found out that it's very simple to import Python scripting inside a project like this. It meant that at some particular moment I could execute a Python file importing a module that my C++ app exports, in order to give it the possibilty to call the C++ functions.
I've actually done that! Both on PC and PS Vita (don't forget project is still Vita-first). If you were to compile the game with right flags enabled, while clicking LEVEL EDITOR
button you would actually start the Python script that calls the "play random sound" C++ function in a loop and thus makes a loud noise. I can't tell you how I was excited when I've seen it working for the first time.
That's only one particular test. I want to implement this in level editing itself to make an actual cool use of it. You can see the concept idea here.
So, answering the question who's going to play it: that will be the people seeking for a method to express themselves while being en route with their PS Vita on the hands, by creating levels but not only that (you actually can create levels in a lot of Vita games), but also the possibility to script them with Python, on the go.
Isn't that cool as a possibility? When I was little, that could be my favorite thing alongside other stuff I could do on the go, like the Nokia Symbian era. Don't you know there were button phones (dumbphones) that actually had Python interpreter and a lot of software was based on it? I knew that, I knew I had to learn it and so I did. A lot of projects using AppUiFw: "Asteroids" game remake using sin/cos formulas in order to rotate the rocket when I was like 14 yo and no one forced me to actually learn all that math stuff that early; a little game where you have to capture the fruits from the top; an app which lets me use internal text-to-speech feature easily; all that being coded on the phone directly not using any PC and more and more... Man! I'm so dumb I didn't never save nor share this stuff with anyone! All that is stored on my Nokia C5 which calmly waits for me in my house in Mariupol, and I won't be able to get to see it all again in years because of the war.
Oh, sorry, I spoke a little too much. Just had to say all that somewhere.
Anyways you have your response. This game is made for those who want to create amazing stuff on the PS Vita directly. And not only Vita, if someone ports the game to Switch (i dont have one) that would be nice. And Steam Deck if we succeed to release the game on Steam.
So What?
So, now, I should just do something about this game.
I'll begin by refactoring the codebase completely (init the project from scratch. Again). This will ensure that I use all of my experience in architecture I gained this year and game won't have some stale problems (e.g. anchoring all the time-based events on frames. It means that the game runs in 60FPS only!).
I'll ensure it works flawlessly on all the platforms I have access to (Windows, Linux, macOS, PS Vita, later probably some mobile platforms), make sure that I don't depend on SDL2 & SDL2_Renderer specifically (to be able to render the game with GLFW & OpenGL or Metal for example) and be able to create its level editor based on the code of the game itself. That would help a lot.
Now, I think it finely explains what I am going to do. See you next time!