Well it didn't take long before the daily updates stopped. I'm busy packing up my house, throwing away my crap rather than working.
After wrestling with the iPhone http connection code I got it downloading files with stability. The cocoa framework code was threaded too, and I had only quickly put the code together for synchronous connections. I've expanded the system so after creating a connection you start a Download() or Upload() with an url (which obviously we can adapt for other protocols) which creates a task with a TBinaryTree which contains data being sent, URI information, error codes, and then on success will have the returned HTTP data -which will be exclusivly XML-. We poll the connection with our task ref to get the current status (False,Wait,True) and the data on the task and wait for the thread to finish.
Now that that was working on both formats (same fish test as before of course) I added uploading data via multi-part form posts. This wasn't too much trouble using Curl... I never realised how poorly thrown together some of the HTTP protocols are! The use of an arbrtitry string to seperate fields seems a little daft to me, and doesn't really impose any error checking for half-submitted forms IMO. But anyway, it's a 20 year old standard so I guess the world has coped.
Anyway, data gets uploaded as hex strings - a little ineffecient, but reliable, easily translatable back to binary, readable so good for debugging - as they're UTF8 compatbile and so good for XML and Form data. Each branch of the Upload data we supplied to Upload() gets put into a different form-part. The PHP code simply enumerates through the POST variables, and converts the form part name (Ref) and the form part data from Hex back into binary for whatever data we require; Ref, String, Data, integers etc. The whole system is essentially templated from setting up the upload data all the way through to the PHP code which now has the $_POST variable as an equivilent binary tree.
I'm now working on the database interaction code on the web side to store the match asset's data in the database and return some relevant data.
This can then all be re-used in the same way to get a list of matches applicable to one user name[ref] returned in an XML format which we can parse, or just to fetch the latest asset from the server of a particular match.
Monday, 7 September 2009
Wednesday, 2 September 2009
Embiggen day N
After wrestling mostly with NSConnection and an Objective-c learning curve, I've got the file-downloading code down to a wierd bad_access crash and stopped work on that to spend the rest of the afternoon on Embiggen features.
The next task was to do something with the words (and points) now that we've calculated them. To aid this I've setup player information; A list of players in the match, and arbritary data on the player. The data on the players contains a player ref (a global unique identifier) an avatar texture ref, a current score and a list of letters in the players rack.
I setup the gui to display the avatar, name and score. It also currently colours the active player red so we know who's playing. Upon pressing play, it calculates the words generated by the current player, verifies everything is okay (although I've not done spell checking yet), burns the players tiles into the board, adds the points to the players score.
It then saves the match asset which contains the board, (which contains tiles, letter pool), players and active player. Due to the way the engine works this is easily serialised into an asset. Now we have an asset we can/will send that asset up to the web, where some PHP will write it back to the database, do notifications etc and wait for the next player to make their move and submit the next board.
All simple data-orientated changes, but it does mean it turns into much more of a game now that we handle multiple players and save/load the board :)
Next task is back to sorting out the IPod web-connection, THEN I can do the PC and IPod web-sending code, then I'll sort out the server side PHP scripts and database to save our match and make it accessible world wide!
Target to finish by the end of the week may be reachable :) (Although I need to start packing for my move to Manchester next week)
The next task was to do something with the words (and points) now that we've calculated them. To aid this I've setup player information; A list of players in the match, and arbritary data on the player. The data on the players contains a player ref (a global unique identifier) an avatar texture ref, a current score and a list of letters in the players rack.
I setup the gui to display the avatar, name and score. It also currently colours the active player red so we know who's playing. Upon pressing play, it calculates the words generated by the current player, verifies everything is okay (although I've not done spell checking yet), burns the players tiles into the board, adds the points to the players score.
It then saves the match asset which contains the board, (which contains tiles, letter pool), players and active player. Due to the way the engine works this is easily serialised into an asset. Now we have an asset we can/will send that asset up to the web, where some PHP will write it back to the database, do notifications etc and wait for the next player to make their move and submit the next board.
All simple data-orientated changes, but it does mean it turns into much more of a game now that we handle multiple players and save/load the board :)
Next task is back to sorting out the IPod web-connection, THEN I can do the PC and IPod web-sending code, then I'll sort out the server side PHP scripts and database to save our match and make it accessible world wide!
Target to finish by the end of the week may be reachable :) (Although I need to start packing for my move to Manchester next week)
Embiggen day five
All day doing apple network code. 2am now. Quickly added word detection. Bed time.
Subscribe to:
Posts (Atom)
Posts
