Facebook made a native version of their React framework:
I'm guessing it's very good. Three20 was very good at what it did, and this seems hugely better. Declarative programming... I wonder if that might be the future? React Native must rock the socks off golang with iOS bindings. The way we program right now must change anyway, it doesn't scale the way we still do it. Declarative programming. Mhm. Mmm.
Alphaville
The simulation part of Trabant is now in Alpha! It took longer than I expected (as usual), and the outcome was better than expected (not as usual). Right now I'm building for iOS, and when that it's built and tested I'll treat myself to some time off.
After that I'll build a small "IDE" of sorts for the iPad, and try to reuse as much as possible for the iPhone version. The IDE will more or less be a text editor with Python syntax highlighting and possibility to load/save/reset the examples and the user's own source. And a play button for running a Python VM (in a thread), communicating with the simulator using sockets. And then a lot of details. Some security for the dreaded Apple guidelines. Done! :)
Right now I'll test pull this shit through the compiler sewer and when it hits the iPad accelerator fan I should be done. I'll run it the way most hardcore developers will: using the Python VM on a computer and running the simulator only on the iPad. All that's needed is a config file in ~/ with addr=192.168.1.69 or wahevah. Oooo! I see the compiler's done it's deed. Unfortunately the cat just did it's deed in the litter box next to me. Cats don't seem to take note on my fobia of feces. Let's just hope the iPad does.
After that I'll build a small "IDE" of sorts for the iPad, and try to reuse as much as possible for the iPhone version. The IDE will more or less be a text editor with Python syntax highlighting and possibility to load/save/reset the examples and the user's own source. And a play button for running a Python VM (in a thread), communicating with the simulator using sockets. And then a lot of details. Some security for the dreaded Apple guidelines. Done! :)
Right now I'll test pull this shit through the compiler sewer and when it hits the iPad accelerator fan I should be done. I'll run it the way most hardcore developers will: using the Python VM on a computer and running the simulator only on the iPad. All that's needed is a config file in ~/ with addr=192.168.1.69 or wahevah. Oooo! I see the compiler's done it's deed. Unfortunately the cat just did it's deed in the litter box next to me. Cats don't seem to take note on my fobia of feces. Let's just hope the iPad does.
9 o' clock and all is well!
I'm making steady progress, the API for prototyping is going to be totally awesome. It's almost sickening how good it's going to be. I'll be back...
API and the Übernerdy
It won't result in any beautiful game, but the initial Trabant API comes down to 30 functions with a total of 32 mandatory parameters and as many optional parameters. That's very good by my coding standards. Here are some important functions:
Btw, Tetris and Terminal Velocity made it through the first round:
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:
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!
Tetris?
My Flappy Bird clone, Flappy UFO" took 33 LoC, and I've done the 10 examples I wanted. They are the core of: Asteroids, Breakout, a 3D car sim, Flappy UFO, a 3D heli sim, Pacman, a 3D physics sandbox, Snake, Space Invaders and squash 3D (hrm...) The median is 31 LoC with a stddev of 9.5. Not too foul.
I'm not content though, since half of the games are extremely basic 2D arcade games, and the other half is what I reused from my toolbox. There are two more games I'd like to add, a grand finale if you will. First I'll try and see if I can squeeze in a trivial Tetris in 50 lines. If I can't do it in 60 I'll scrap the idea. Secondly I would love to make a Terminal Velocity with a 3D height field and... no enemies.
If I can't make it in 60 lines, that too won't make it. After that it's just the implementation left. Hehe...
I once was an employee of a company in the outskirts of the gaming industry. Let's call them MindArk. When I started they had whole a shelf with binders full of ideas which they had spent years to complete. They said to me "now all we need to do is to implement it." Gosh. Hope I'm not as much off the mark as they were. At least they (proudly) made this hilarious clip:
The girl behind the costume and the amazing voice-acting (which she insisted she deliver herself) is the daughter of a friend of the boss/owner at the time. She and Dr. Alban was a couple at the time. As you surely realize by now I practically ruled the Eurodance scene at time.
I'm not content though, since half of the games are extremely basic 2D arcade games, and the other half is what I reused from my toolbox. There are two more games I'd like to add, a grand finale if you will. First I'll try and see if I can squeeze in a trivial Tetris in 50 lines. If I can't do it in 60 I'll scrap the idea. Secondly I would love to make a Terminal Velocity with a 3D height field and... no enemies.
If I can't make it in 60 lines, that too won't make it. After that it's just the implementation left. Hehe...
I once was an employee of a company in the outskirts of the gaming industry. Let's call them MindArk. When I started they had whole a shelf with binders full of ideas which they had spent years to complete. They said to me "now all we need to do is to implement it." Gosh. Hope I'm not as much off the mark as they were. At least they (proudly) made this hilarious clip:
The girl behind the costume and the amazing voice-acting (which she insisted she deliver herself) is the daughter of a friend of the boss/owner at the time. She and Dr. Alban was a couple at the time. As you surely realize by now I practically ruled the Eurodance scene at time.
Mocking well
I've started working on my 3D game mechanic prototyping app and it's going awesome! One of the main reasons is that I've only thought about the API. My starting point is writing some prototyping code and when I've done a few I'll have a minimal and stable API that supports various stuff you'll need in different games.
So far I've written six tiny games, 12-35 lines of code. Car and Heli simulator. Breakout is 20 lines of python code:
I'm not sure I can pull it off as I haven't written the receiving end yet, but my gut feeling is oooohhhyyeeaaahhh!
As you can see, the project name is 'Trabant,' which I think suits it. It's ugly, old-school, and slow. But you can assemble it in ten minutes.
So far I've written six tiny games, 12-35 lines of code. Car and Heli simulator. Breakout is 20 lines of python code:
I'm not sure I can pull it off as I haven't written the receiving end yet, but my gut feeling is oooohhhyyeeaaahhh!
As you can see, the project name is 'Trabant,' which I think suits it. It's ugly, old-school, and slow. But you can assemble it in ten minutes.
Impuzzable scrapped
I just decided to scrap the puzzle game too. Not only because it took a lot more man-hours than I had expected (not to mention calendar days), but even if I'd get the 3D "understanding" right (which I highly doubt), I now no longer think I'd have any energy left for polish.
But I'm not too upset with that, it's a feeling I've had since day three or so. That makes it my fourth game on indefinite hold so far. Three of the four had lousy controls in common, the fourth was supposed to be a co-op developed with another guy, but he never showed any interest.
The next game I'll tackle is going to be the prototype 3D game editor. The absolutely best part about it is dogfooding: I can fiddle with my own stuff until I'm satisfied. If run with it and let it evolve, I'm sure others will like it too. This will be my first great game, and it's not even a game. But it sure aligns with my obnoxious way of developing a homebrew game engine instead of games.
If it wasn't for the App Store Review Guideline 2.7 "Apps that download code in any way or form will be rejected," I could easily add end-user surveys (i.e. rating and possibly optional feedback) where you'd instantly know if the game idea is any good. Sort of like an instant App Store-within-the-App Store but with no money, no big dragons and no polish. I think that part would have been instantly gratifying, like codepen but for 3D games. Oh well, the tool will have to speak for itself.
This is what I'm thinking:
But I'm not too upset with that, it's a feeling I've had since day three or so. That makes it my fourth game on indefinite hold so far. Three of the four had lousy controls in common, the fourth was supposed to be a co-op developed with another guy, but he never showed any interest.
The next game I'll tackle is going to be the prototype 3D game editor. The absolutely best part about it is dogfooding: I can fiddle with my own stuff until I'm satisfied. If run with it and let it evolve, I'm sure others will like it too. This will be my first great game, and it's not even a game. But it sure aligns with my obnoxious way of developing a homebrew game engine instead of games.
If it wasn't for the App Store Review Guideline 2.7 "Apps that download code in any way or form will be rejected," I could easily add end-user surveys (i.e. rating and possibly optional feedback) where you'd instantly know if the game idea is any good. Sort of like an instant App Store-within-the-App Store but with no money, no big dragons and no polish. I think that part would have been instantly gratifying, like codepen but for 3D games. Oh well, the tool will have to speak for itself.
This is what I'm thinking:
- iterative builds on computer, when you're done you instantly shoot it over to the iPhone/iPad (this will have to be protected somehow or Review Guideline 2.7 will bite me again);
- I'll add a simple Python text editor and interpreter in the iOS version as well, so you can fiddle on the bus (a feature I'd use myself I if I ever went by bus);
- code can also be downloaded from the device to the computer while the app is in the foreground;
- 50 lines of code should be enough for the basic versions of games such as Breakout, Tron or Space Invaders;
- The initial installation will include ~10 examples of various kinds.
The hard part is the API. What I'll try to do is to make some very different games in it, and if I manage to make all of those both small and minimalistic, the API should be good. Less will always be more in this case, it is for game mechanic prototyping only.
Prenumerera på:
Inlägg (Atom)
