I still have not found any time to continue work on my reversi app. I'm not planning on changing the development language of the game logic due to lack of time, but for the interface it might be a good exercise to try jquery mobile and html5. @Rockncoder has some slides on beginning HTML5 mobile game programming. I would like to make a sprite map to animate disc turnovers during a reversi turn.
As described in the slides, a sprite is a two dimensional image that gets placed into a scene. The map part means that there is a single file composed of several individual sprites. From what I've read, having a single file makes the transfer from server to browser more efficient. Perhaps this is because there are fewer transfers to setup.
On the other hand, I was originally planning on using an animated gif to animate the disc turnovers. A timer would start at the start of the animation and then swap out the animated gif with a regular image at the end of the turnover sequence. This method has a chance of getting the animation out of sync with the image swapping, so the sprite method seems better.
A Github repository has the demonstration code associated with the slides. I also need to look for images to make the sprite map for reversi. To animate the turning, I plan on scaling the images of the black and white disc and saving out the different scaled images with sumo paint online. A different github repository by Christian Cantrell has some images I can try to do this with. They have a transparent background so hopefully all I will need to do is scale the png files.
I don't have much experience with the sumo paint web site, but I assume scaling the images shouldn't be that hard. There should be a way to upload the images and then apply an image resize tool to them. Hopefully it will remember the background is transparent. Also, the newly sized image will need to be recentered and the image background size preserved to keep the sprite sizes the same. Also, since the goal is a collection of images in a sprite map, some of the images may need to be separated out and then put back together. That way, the original images will not get scaled along with the images of the discs turning. Recentering is important so that the disc does not shift during the turnover animation. One way would be to calculate the difference between the new image size and the original image size, divide by 2, and then shift by that amount.
So my next steps for the reversi project are to scale some disc images, collect them into a sprite map, reuse parts of the sprite engine from @rockncoder, and make a test html5 and javascript page that animates disc turning.
Saturday, October 27, 2012
Sunday, October 14, 2012
Reversi Blog Posts
I still haven't worked on my Reversi program since the last post. Instead, I did some web browsing and found a blog post by some one who wrote an Othello program in C#. He has several posts on the topic that look like they could be educational. I only had time to look over a couple of them. The Othello program part 2 post had an interesting trick on how to encode a position on the board. Instead of a coordinate pair such as 0,0 or 7,7, he transformed the location into a single offset 0-63 and then started the offset that from a letter to turn the description into an alphanumeric. Since it is text it could now be transmitted as part of a hyperlink.
My current system is not as simple. To turn the coordinate into text I used base64 encoding of a byte array. Each byte I separated into a low and high 4 bit number to get a board coordinate. Base64 uses 6 bits instead of all 8 bits. However it still needs to end on a byte boundary and is an extra call. The minimal amount of bits to describe a coordinate is 6 bits, so it could map to Base64 encoding. However, it seems like it would get complicated aligning a series of 6 bits numbers to byte boundaries so I didn't go to the trouble of doing so.
A calculation can describe a rough estimate of the savings. For a maximum of 60 moves that could be played the single offset method would simply describe it with 60 bytes. If encoding with 6 bits instead of 8 bits, that would result in 360 bits or 45 bytes. So a potential savings of 15 bytes at the end. It seems like a lot of complication for 15 bytes so I haven't done it yet, but there is a difference that could add up if this operation is done a lot. However, if one decides to just send back one move at a time the base64 encoding would actually take up more bytes than the single character encoding method.
This seems like a change of detail that I might have enough time to do over a weekend. However, I would still need tools to quantify the benefit of making a change to 6 bits, while the change from a pair of numbers to a single character is clearly simpler to work with and may be the way to go. Hopefully, reading his other Othello blog posts will encourage me to work on my project again.
My current system is not as simple. To turn the coordinate into text I used base64 encoding of a byte array. Each byte I separated into a low and high 4 bit number to get a board coordinate. Base64 uses 6 bits instead of all 8 bits. However it still needs to end on a byte boundary and is an extra call. The minimal amount of bits to describe a coordinate is 6 bits, so it could map to Base64 encoding. However, it seems like it would get complicated aligning a series of 6 bits numbers to byte boundaries so I didn't go to the trouble of doing so.
A calculation can describe a rough estimate of the savings. For a maximum of 60 moves that could be played the single offset method would simply describe it with 60 bytes. If encoding with 6 bits instead of 8 bits, that would result in 360 bits or 45 bytes. So a potential savings of 15 bytes at the end. It seems like a lot of complication for 15 bytes so I haven't done it yet, but there is a difference that could add up if this operation is done a lot. However, if one decides to just send back one move at a time the base64 encoding would actually take up more bytes than the single character encoding method.
This seems like a change of detail that I might have enough time to do over a weekend. However, I would still need tools to quantify the benefit of making a change to 6 bits, while the change from a pair of numbers to a single character is clearly simpler to work with and may be the way to go. Hopefully, reading his other Othello blog posts will encourage me to work on my project again.
Saturday, October 06, 2012
Ruby Reversi
My progress on a reversi program has stalled. To help revive my interest in the project, I looked around for Ruby implementations. There are a couple from Japan on github. The one called Ruby Reversi looked like it would be easier to understand since it looks like a console application rather than an entire Rails app.
So far I've tried to get a grasp of the overall organization. It looks pretty logical. There are divisions based on the user interface, AI, game rules, board data, and some kind of dynamic controller. Of these divisions, two differences from my project that stand out. One is the separation of the game logic from the board's 2-d array data structure. I'm guessing that separating the 2-d array data structure from the game logic enables the 2-d array to be more reusable while isolating the specific problem domain code in the rule files. Perhaps this also helps readability because once one reads the file name "array2d" the behavior of that file is understood, and one can pretty much skip reading that code.
The other major difference is the method of program flow control. I'm not that familiar with Ruby, but it looks like his or her design is event based. When the user interacts with the program their actions raise events and are not causing a method to be called directly. Instead, it looks like an action method routes the event to the appropriate behavior. Benefits of this design may be those of using the command pattern: undo and macro operations. However I don't see those in the design. I'm not sure whether I like this way of organizing the behavior as it seems to complicate the initial reading, but it could have benefits in terms of centralizing and organizing how a program behaves.
Overall it was interesting to look over some one else's design and see some differences, such as in the language and the organization. It was not entirely obvious what the benefits and drawbacks are to the various differences, but by working on this post, I hope some of them were revealed. I also hope this post encourages me to finish the project.
So far I've tried to get a grasp of the overall organization. It looks pretty logical. There are divisions based on the user interface, AI, game rules, board data, and some kind of dynamic controller. Of these divisions, two differences from my project that stand out. One is the separation of the game logic from the board's 2-d array data structure. I'm guessing that separating the 2-d array data structure from the game logic enables the 2-d array to be more reusable while isolating the specific problem domain code in the rule files. Perhaps this also helps readability because once one reads the file name "array2d" the behavior of that file is understood, and one can pretty much skip reading that code.
The other major difference is the method of program flow control. I'm not that familiar with Ruby, but it looks like his or her design is event based. When the user interacts with the program their actions raise events and are not causing a method to be called directly. Instead, it looks like an action method routes the event to the appropriate behavior. Benefits of this design may be those of using the command pattern: undo and macro operations. However I don't see those in the design. I'm not sure whether I like this way of organizing the behavior as it seems to complicate the initial reading, but it could have benefits in terms of centralizing and organizing how a program behaves.
Overall it was interesting to look over some one else's design and see some differences, such as in the language and the organization. It was not entirely obvious what the benefits and drawbacks are to the various differences, but by working on this post, I hope some of them were revealed. I also hope this post encourages me to finish the project.
Subscribe to:
Posts (Atom)