CyberStock
A programming game where you inherit a run down warehouse and automate it by writing real code. Pseudo-code, Python, Java, or C++, all four actually run.
// Challenges
Getting four different languages to drive the same robots through one API, and keeping the simulation fair when player code can be fast or slow. Also making it readable for someone who has never coded without making it boring for someone who has.
// Skills Used
// Current Status
Early build. The grid, the editor, and the hardware API are the current focus.
Brief
I like programming games. Screeps, Shenzhen I/O, that whole genre where the puzzle is the code you write instead of the buttons you press. CyberStock is my version of that.
You inherit a beat up cyberpunk warehouse from your uncle. It does not run itself. You make it run by writing actual code that drives robots around a grid, picks things up, feeds machines, and sells the output into a market that keeps moving whether you are watching or not.
The part I think is interesting
Four languages, one API. You can write in pseudo-code with blocks if you have never programmed, or in Python, Java, or C++ if you have. All four genuinely execute. They are not four skins over one fake language. A robot has the same commands no matter which one you pick, so robot.move() means the same thing everywhere.
There is also a one click conversion from the block version to real Python, Java, or C++ syntax. The idea is that someone starts with blocks, gets something working, converts it, and suddenly they are reading real code that they already understand because they wrote it.
Your code keeps running when you close the tab. The simulation lives on the server, so the warehouse does not pause because you went to class.
It pops out. The game can detach into a small always on top window, like a music miniplayer, so it can idle in the corner of your screen while you do something else.
The market moves on its own. Prices shift, contracts show up with deadlines, and slow world events roll through in phases. A drought or a power grid failure builds up over time instead of appearing all at once. Your scripts can read the market and change what the warehouse produces without you touching anything.
Where I am
Early. The warehouse grid renders with Pixi.js, the code editor is Monaco, which is the same editor VS Code uses, and I am building out the hardware API and the tick system that meters how much code each robot can run per turn.
What I am learning
Designing an API other people have to use. Every command a robot understands is a decision that is hard to take back later, because someone’s script depends on it.
Fairness in a simulation. If a player writes slow code, the game has to slow their robot down instead of slowing everyone down. Working out how to count that fairly is the hardest problem in the project so far.
Rendering performance. A grid full of moving units has to stay smooth, which means not redrawing everything every frame.