Cube Dev... It Is Definitely Different
Well, I finally got my hands on a cube. It took long enough.
It’s a fun little device to play with, and it’s also a fun little device to develop for… as long as you’re patient.
I want an infinite dungeon crawler. That’s all I want. And I’ll get it.
But there is so much optimization involved with this thing. I haven’t even really started the game yet. I haven’t touched audio. I haven’t added an animated sprite. And I still managed to get the thing down to 6 FPS just drawing the dungeon floor.
The cube is neat, but because of its nature, it’s a real challenge to develop for.
Saved games are a good example. You get 256 bytes max. I want to allow up to four character profiles, so that’s roughly 64 bytes per save.
Can it be done? Sure. But it’s definitely going to take some planning to do it right. Every byte suddenly matters when you’re trying to squeeze an RPG character, inventory, equipment, dungeon progress, stats and everything else into 64 of them.
Deploying to the actual cube, on the other hand, is surprisingly easy. Install the Cube SDK, select the cube in VS Code, hit F5, and done. It’s all sent over Bluetooth. No jumping through ADB hoops or dealing with bad USB connections dropping out halfway through deployment.
I’m still getting the hang of actually making everything work on the hardware.
I think I finally have movement figured out. It only took about six different attempts and different ways of calculating it, but I can now tilt the cube to move my adventurer — currently a lovely-looking yellow @ sign — around the map.
Now I just need to get my dungeon tiles drawing without losing 40 FPS.
Once I get that sorted out, I’ll move on to fog of war for the dungeon. Given the performance constraints, “fog” may end up being the highly advanced graphical technique of drawing a black square.
We’ll see.
While writing this, I did manage to get the dungeon rendering up to around 10–15 FPS. Not nearly good enough yet, but it’s progress.
I also figured out how I’m going to handle all of the development tools I’ll eventually need.
In Unity, we’d just build custom editor windows for updating weapons, monsters, balance values and all the other game data. Here, I don’t really have that luxury unless I want to go through the trouble of developing custom VS Code plugins.
Not ideal.
But after thinking about it, that limitation actually opens things up quite a bit.
The game’s data is just JSON.
Anything can create JSON.
So instead of being tied to an editor, I can build whatever tools make sense. A small desktop app, a web app, or something else entirely can manage all of the game’s data and simply output the JSON files the cube needs.
Considering I eventually have thousands of weapons and items to deal with, that’s probably going to be a much better solution anyway.
So there is a bright side to things.
Now, back to figuring out where the other 30 FPS went.
