Hi Ben,<br><br>I'm the one who wrote the Idea entry, so I'll try and elaborate on what I was thinking.<br><br>True, there are a number of PyGame board and card games out there that can probably be run on the XO today. However, these games would fall into the category of what I call "obvious ports". The XO has a very specialized user interface, and a number of killer features that make it a unique and great platform for this kind of gameplay.<br>
<br>I don't think that there is much challenge in implementing the individual games, either. Given one solid two player game implementation with multiplayer and AI (say Othello), you can likely turn out Chess, Checkers, Mancala, Deducto, Tic-Tac-Toe, Connect 4 and a dozen others in about a week each. The same goes simple N player (or solitaire) card games.<br>
<br>So, what I wanted to do was to develop one very good game implementation and then base the rest on it. In reality, we would probably develop a few simultaneously to learn the requirements while improving and refining them together and extracting out shareable components as we go. <br>
<br>I'm not interested in developing a framework and restricting the games to implementing some few interfaces. But there is a need for several common (and complex) pieces of code that can be shared between games and used by future developers.<br>
<br>- A generic minimax AI implementation (one is on my User:Wade page already)<br>- A game state recording & playback component.<br>- A system to manage multiplayer games with 2 active players and N observers, rotating in new players to replace the losers while keeping the winner<br>
- A tutorial component (a list of game states with instruction text and moves that the player must make to continue).<br><br>These components could consist of generic "model" code as well as custom PyGTK widgets that would make up the "interface" code.<br>
<br>Since most games can be devolved into the concept of a "state" that can be modified by "moves", this could be the interface through which many of the components are communicated to. But the core idea is that they are "components", not a "framework".<br>
<br>Also, I agree with you about this being a great way to learn to program. It's how I learned as well, modifying games written in BASIC for the TRS-80. So these games are absolutely intended to serve the purpose of providing concrete examples in a "learn to program" environment, and that is accomplished through the "View Source" key on the keyboard, the Pippy (and eventually maybe Develop) activities, and the very clean, well organized and documented Python game code which we intend to write :)<br>
<br>Best regards,<br><br>Wade<br><br><div class="gmail_quote">On Mon, Mar 24, 2008 at 3:04 PM, bzlman <<a href="mailto:bzlman@gmail.com">bzlman@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
I am interested in working on the board/card game development project,<br>
but I wanted to get a little clarification about what is being asked<br>
for before applying.<br>
<br>