Level editor for the Bionic Blue game.
Warning
Rather than a tool for general use, this is a crude tool meant for in-house usage. As such, it lacks many features and is susceptible to crashing/malfunctioning and sudden requirement changes; usually, though, it works effectively and efficiently/smoothly for the purposes for which it was created, and since it is so bare-bones/basic, it is very low-maintenance.
This tool was created by me, Kennedy Richard S. Guerra(website | GitHub), 34, as part of the Indie Smiths project (website | GitHub).
Please, help support my work on this and many other child projects of the Indie Smiths project (the Bionic Blue game, the Nodezator node editor and more) by becoming our patron, sponsoring us on GitHub Sponsors or via other available methods.
Since this is a crude tool meant for in-house usage, why release it then?
First, for the sake of transparency. That is, since I'm an open-source maintainer, by publishing to GitHub people can inspect my work on this project via the commits.
Second, naturally, for tracking and backing up my work using the git/GitHub combo.
Third, for instructional purposes, as I intend to write text pieces/tutorials referencing/using tools like this one. That is, despite its crude state, it is rather effective and allows for quick iteration and distraction-free progress in making the game. Or rather, it is precisely because I can focus only in the bare features needed to create a level that I can invest most of my time in working on the game rather than maintaining the level editor.
Finally, like all tools/games from the Indie Smiths project, I also wanted to release it to the public domain, so people can learn with it and use it as they see fit, usually changing it according to their needs.
To launch it, download the repo, then from inside the repository folder, with a Python instance where pygame-ce is installed, run this command:
python3 -m bblueleveleditor
Depending on your system, you might need to replace python3 with python.
The wasd keys move the canvas.
The g key toggles the grid:
The q and e switch between available assets:
If the asset is of seamless type, that is, it can expand over a larger area, like the city block asset for instance, you can click and drag on the screen to "paint" it over that area.
If the asset selected is not of seamless type (the robot is the only one for now), you can place one by simply clicking:
Press the x key to toggle the "erase" mode. In erase mode you can delete assets by clicking on them.
The r key toggles the outlines of assets (which are easier to see when the grid is toggled off).
Press v to save the level file (.lvl), press p to export the level as a .png image (hold Shift while doing that to also outline the different divisions of the level, as explained in the level chunk management section further ahead) and press the Escape key to quit the program.
The saved .lvl or exported .png file appears in the bblueleveleditor/levels folder created automatically within the repo (the folder is ignored by git/not tracked).
To create and edit a new level file, empty the folder (for instance, by moving an existing .lvl file to another location in your disk) and launch the editor again. When you save, a new .lvl file will be created there again. This is convoluted and may be improved in the future, but it is not actually a problem at all: as I said before this tool is supposed to be very basic and simple, so I can quickly create the levels I need and move on to the next development task of the game.
Likewise, the exported .png file will be overwritten everytime you export the level as .png. However, you don't need to move the .png out of the folder for a new one to be saved there. Renaming it will suffice.
This level editor has a feature called level chunk management. It consists in the automatic division and management of a level in chunks for the purpose of being able to handle many more objects at once.
Before this, whenever the level moved (i. e., scrolled), all objects in the level were moved and then checked for collision with the screen to determine which should be drawn.
Now the level is divided in chunks. Only the chunks are moved and then they are checked for collision with the screen (actually, we use an area that expands beyond the screen). Only such chunks have their objects checked for collision with the screen, making everything much more efficient than checking all objects in the level.
Implementing chunk creation and management didn't require us to change the data model either, because the chunks are created only when the level is loaded, grouping the objects is handled automatically by our algorithm. In other words, this feature doesn't require data to added to the .lvl files.
This technology was also implemented on the game itself and will likely be used in other sibling projects (child projects of the Indie Smiths project) as opportune.
For now, I actually indicate whether an asset is seamless or not and other properties of the asset in its name.
For instance, consider the name of the grunt robot asset: grunt_bot.actors.False.midbottom.png.
The .actors part indicates it is to be placed in the actors layer. The False part indicates it is not a seamless asset. Finally the midbottom part indicates which corner of the asset the position should be assigned to. That is, in this case it means the position data stored for the robot should be assigned to the robot's midbottom corner. You can use any of the 9 points defined in a pygame.Rect, that is, topleft, topright, center, etc.