cam(angle=None, distance=None, target=None) create_ascii_object(ascii, pos=None, vel=None, angular_velocity=None, col=None, static=False) closest_tap(pos) # Helper to return the tap closest to a 3D position. accelerometer() # Return current accelerometer setting. Obj.pos(self, pos=None, orientation=None)I don't think it's too specialized either, so I guess it's pretty good already. Just remains to be seen how ugly the prototypes will look on screen. The only resources that will be part of the kit are two textures (a b/w checkers squares used for all cubes and an explosion billboard), six sounds (two explosions, three engine sounds and a "ping"). I'll keep constants for those. It's flat shading ftw.
Btw, Tetris and Terminal Velocity made it through the first round:
| Game | Lines of code |
|---|---|
| asteroids.py | 34 |
| breakout.py | 20 |
| car.py | 23 |
| flappy_ufo.py | 28 |
| heli.py | 33 |
| pacman.py | 23 |
| physics.py | 12 |
| snake.py | 25 |
| space_invaders.py | 38 |
| squash.py | 8 |
| terminal_velocity.py | 53 |
| tetris.py | 48 |
I'm not sure how much reality will interact negatively with my vision, but I don't think it will be very much. No more than a line here and there. And unless the prototypes will be too ugly to endure (by my lowly standards) I'll keep the API this way for the first release. I have no idea what people would want to make with it, but at least some variation is supported in look and feel.
Next I'll implement the helpers and wrappers in the Python API, then it's the network interface used to communicate with the simulator (this is actually a simple socket wrapper of a command-line interface). Those two should be a breeze. But after that comes the IDE itself. Here's what I'm thinking right now:
- The IDE will only be implemented on iOS. (If you're testing on a computer you might as well use Notepad++, Sublime, Emacs, Vim or whatever.)
- The IDE is the root view (controller?) containing a simple Python 3 editor+runtime and a simplistic file list. This is where you load, save, run and return to after you've run some prototype.
- The IDE must contain a log view so you can tell what went wrong if your prototype crashes. I could show a split-screen between code and log, and simply dismiss the log if the user pass focus somewhere else.
- Since iOS code downloading is disallowed according to Apple's guidelines, the function to upload source code to the device might have to be disabled by default. I hope not, I'll start out by placing a message box of the type "computer xyz wants connect, permanently allow? yes/no," and if that doesn't pass review I'll try to circumvent one way or another.
- I'll make a "revert to original source" if you screw up and don't know how to repair.
- I'll release it free (at least initially) with in-app purchase, but then I should probably lock something down. Maybe the number of lines of code the IDE will run (100)? Or the number of files you can store (20)? Or both? Or something else entirely? I'm not sure.
I still think a leaderboard where you can post your games and try out other peoples ideas would be totally awesome. Hm. What if I built an upload mechanism, likes and all that, but if you wanted to try something out you'd have to cut'n'paste manually? That just might work! Gamification of game development itself. Whoa. Meta-meta. Übernerdy. Whoa. Groovy baby!
