Blocks are kept track of internally through two ways. There is a Field array which stores block information sequentially, keeping track of its id; x, y, and z coordinates; color; and functionality. This information is actually displayed to the user as blocks are moved within the Event Log. The second way they're kept track of is the Voxel object, which holds x, y, z information, indexed by block id. This is second object type is only important to the client, as it helps determine block positions relationally; it's useful for easily and quickly telling if the block is North, East, West, South, or Up or Down. The Field array is what's actually stored serverside (using JSON); it's more concise and it'd be harder to draw the blocks using the Voxel data, which is more for in-game logic. I figure that anything that needs to be done through Voxels would be best done clientside. This not only decreases server load, it's also more responsive; they don't get a wheel, they get a progress bar, and if their computer is slow enough, or there are too many blocks, they're even treated to a show. :)
I'm also making some real Google App Engine code, too. One problem with my current Google App Engine code is that... well, there isn't any. What's there is an app.yaml script that serves up static files. However, that's going to change with Sputnik-6. The current code serves up the program on the main page (rather than at index.svg), and also has a really neat RPC function. In this RPC function, I already implemented a way to save Field objects to the App Engine datastore. It works really well, and didn't take long to set up from the examples given by Google. So, not too much of the code there is 'mine' right now. I'm still debating how I should handle the GPL header there. The data is sent using POST, because if it were sent with GET, it would be ridiculous to have that much data sent through the URI, escaped so I get that much extra overhead.
I'm also going to split the main Drop() function into Create, Stack, and Move functions. The functionality is all within the code already, it's just a matter of extricating it from this monster function. This will help in three ways. It will allow me script block placement, so I can add behavior such as stacking blocks on top of a block you placed lower down on a stack (currently if you do so, the block will occupy the same space. This bug was found by my friend, who goes by darth_vader on the AmbrosiaSW forums). It will also be integral to the PopulateField function, which will take the specified block data from the server and add it to the grid. Finally, it will make my code easier to understand. As another friend, Giulio, said... 'one simple function to do one simple thing.'
Once I move onto Voskhod development-- Voskhod will be the name of the alpha release, which will be more game-like, once the Sputnik prototypes are finished-- I plan to give everything more generic names.
SVG, surprisingly enough, does not help by giving me a textArea element; that's in 1.2. So, unfortunately, I will have to make my own text box function. I'm going to implement in the file, text.js, a function along the lines of the ones here:
- http://www.kevlindev.com/gui/widgets/textbox/index.htm
- http://srufaculty.sru.edu/david.dailey/svg/keys4.svg
Also, I will need to make a python script that can be run on my code before uploading it to the Google App Engine. It will minify the code, as well as consolidating it into one giant file. This will make things faster by reducing overhead as well as probably cutting bandwidth in half.
Finally, a note on browser performance. Firefox is really nice and all, and on my computer (with Firebug enabled) initializes the program in about 120ms. However, with WebKit's new SquirrelFish JavaScript interpreter, my program is initialized in only 50ms! Plus, Safari supports SVG animations natively, and its new Web Inspector is really sweet; very similar to Firebug now. (I will probably have ot implement a JS animation feature before Firefox comes up with some decent SVG animation capabilities, much as the scripts here: http://srufaculty.sru.edu/david.dailey/svg/)
However, Opera is a different story. Although the latest Opera 9.5.2 (development release) initializes in 70ms, for some reason it translates the blocks very slowly and choppy. I think this has to do with the speed it draws SVG. Hopefully this will be fixed soon; I talked to JonCruz in #svg on FreeNode, and he knows and Opera developer who might be able to address this.
At any rate, that's all for now, folks.
- Alex
No comments:
Post a Comment