Talk:Wordsmith(scrabble): Difference between revisions
(New page: I would love to hear any feedback and comments. Do put them up here.) |
m (→Ofcourse...) |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
I would love to hear any feedback and comments. Do put them up here. |
I would love to hear any feedback and comments. Do put them up here. |
||
== extensibility... == |
|||
Just one more game (even a cool one) is not as good as helping to build something that can be added-on-to to make further games. In this case, there are plenty of other word games which might benefit from a fast word-search algorithm, and you should do any necessary improvements to networking, etc. "upstream" in pygame. |
|||
Just a thought. |
|||
[[User:Homunq|Homunq]] 19:12, 28 March 2008 (EDT) |
|||
===Ofcourse...=== |
|||
I totally agree with you. Contributing upstream is essential for an Open Source project to suceed.<br> |
|||
On the same note, my game would really stress pygame wrapper and other modules, specially the networking layer. So, i had thought that while developing the game, if i found something amiss, or not functioning properly, i would dive deeper and produce a solution. I think this is the best way for upstream contributions.<br> |
|||
:[[User:AdityaV|AdityaV]] 12:35, 31 March 2008 (EDT) |
|||
=== Comments === |
|||
This looks like a good proposal. I'm a bit concerned that there may be too many features to be able to produce a solid game over the course of the project. |
|||
More attention should probably be paid to other XO activities and the HIG, for example there is no need for a multiplayer UI since that is already provided, and the journal is generally used to store activity instances, not high score lists etc. so I'm not sure how that would be made to fit. |
|||
Also, I think you should consider using PyGTK and Cairo instead of PyGame, and focusing on a clean look instead of flashy animations. I think you will end up with a better, more consistent looking application. See the Connect activity for an example of what I mean. |
|||
[[User:Wade|wade]] 09:45, 1 April 2008 (EDT) |
|||
==== reply ==== |
|||
I totally understand the scope of the project and understand the fact that lots of the features and trying to implement them all at the same time would destroy the project. <br> |
|||
So, i was aiming to have a solid multiplayer mode with mesh implementation, as well as a kind of ai for single player.After these are tested and debugged, i would start with Thesaurus, Hinting, Watching, (in that order) and then if there is time , the speech tools.<br> |
|||
Clean looks are certainly the priority here.I totally understand that too much flash can destroy the game. However here, i referred to flashy animation as simple cool animations that kept the child's attention. They would basically compose of simple rotations, blinking , enlarging effects with cool sounds.<br> |
|||
[[User:AdityaV|AdityaV]] 14:29, 3 April 2008 (EDT) |
Latest revision as of 19:00, 7 April 2008
I would love to hear any feedback and comments. Do put them up here.
extensibility...
Just one more game (even a cool one) is not as good as helping to build something that can be added-on-to to make further games. In this case, there are plenty of other word games which might benefit from a fast word-search algorithm, and you should do any necessary improvements to networking, etc. "upstream" in pygame.
Just a thought.
Homunq 19:12, 28 March 2008 (EDT)
Ofcourse...
I totally agree with you. Contributing upstream is essential for an Open Source project to suceed.
On the same note, my game would really stress pygame wrapper and other modules, specially the networking layer. So, i had thought that while developing the game, if i found something amiss, or not functioning properly, i would dive deeper and produce a solution. I think this is the best way for upstream contributions.
- AdityaV 12:35, 31 March 2008 (EDT)
Comments
This looks like a good proposal. I'm a bit concerned that there may be too many features to be able to produce a solid game over the course of the project.
More attention should probably be paid to other XO activities and the HIG, for example there is no need for a multiplayer UI since that is already provided, and the journal is generally used to store activity instances, not high score lists etc. so I'm not sure how that would be made to fit.
Also, I think you should consider using PyGTK and Cairo instead of PyGame, and focusing on a clean look instead of flashy animations. I think you will end up with a better, more consistent looking application. See the Connect activity for an example of what I mean.
wade 09:45, 1 April 2008 (EDT)
reply
I totally understand the scope of the project and understand the fact that lots of the features and trying to implement them all at the same time would destroy the project.
So, i was aiming to have a solid multiplayer mode with mesh implementation, as well as a kind of ai for single player.After these are tested and debugged, i would start with Thesaurus, Hinting, Watching, (in that order) and then if there is time , the speech tools.
Clean looks are certainly the priority here.I totally understand that too much flash can destroy the game. However here, i referred to flashy animation as simple cool animations that kept the child's attention. They would basically compose of simple rotations, blinking , enlarging effects with cool sounds.
AdityaV 14:29, 3 April 2008 (EDT)