annabunches.net/content/posts/archived/pygo-go-game-client.md

23 lines
6.9 KiB
Markdown
Raw Normal View History

2016-04-11 22:01:00 +00:00
---
2020-05-15 21:15:51 +00:00
deprecated: true
2016-05-04 18:41:25 +00:00
excerpt_separator: <br/>
category: technology
2016-04-11 22:01:00 +00:00
layout: post
title: pygo - a go game client
date: '2012-04-19T02:30:00.000-04:00'
author: Anna Wiggins
tags:
- Programming
- go
- pygame
- SDL
- pygo
- python
- GTK
- "碁"
modified_time: '2013-10-22T11:19:51.955-04:00'
blogger_id: tag:blogger.com,1999:blog-4209116010564764361.post-1830924094339482390
blogger_orig_url: http://www.stringofbits.net/2012/04/pygo-go-game-client.html
---
If I have anything like 'regular readers' (I'm not certain from the traffic patterns on the blog whether or not that's true), you're probably wondering where I've been. The answer is, basically, the same as it ever is: writing code.<br/><br/>I've also been playing a lot of <a href="http://en.wikipedia.org/wiki/Go_%28game%29">Go</a>, and doing some tabletop roleplaying. My latest programming projects are related to those hobbies. Today I want to talk about pygo, my new Go game client.<br/><br/>There are already a tremendous number of game clients out there. So, why would I want to create Yet Another One? There's always the excuse of 'it is a learning experience', but I also try to make things that I hope will be useful to me personally. And the problem with all of the existing Go clients is that they come in one of two styles:<br/><br/><ol><br/><li>Desktop clients that are timed, and expect you to play an entire game in one brief sitting. Of these, <a href="http://www.gokgs.com/download.jsp">cgoban3</a> is by far my favorite client (although it can only connect to its own <a href="http://www.gokgs.com/">kgs server</a>).</li><br/><li>Web-based clients that expect your games to take a long time - usually you make a move, and come back later to see what your opponent has done.</li><br/></ol><br/><br/>I wanted a client for <strong>medium-length</strong> games: a game that unfolds over the course of an afternoon, or maybe a couple days, while the players are simultaneously doing other things. So it needs these features:<br/><br/><ul><br/><li>Untimed - infinite thinking time allowed</li><br/><li>It is possible to put it down (close the program) and pick it back up later</li><br/><li>Desktop-based. Being on a website makes me feel like I should play just one move and check back much later, and I want to avoid that mentality</li><br/><li>Ability to play multiple simultaneous games</li><br/></ul><br/><br/>I couldn't find a client that met all of these requirements, so I decided to build this one.<br/><br/><h3>First steps - pygame</h3><br/><br/>My first implementation of the game used pygame. Pygame is a pythonic layer on top of SDL (which I've talked about <a href="http://stringofbits.net/tag/sdl/">before</a>, with some convenience libraries added for games. Unfortunately, this really means 'games' in a much more 'modern video game' sense, and this library felt less and less like a good fit the longer I worked with it. When I started implementing network play, it really fell apart; getting pygame to work with either threads or existing networking libraries (like Twisted) is painful. Adding widgets like buttons or menus requires adding third-party libraries, and theming them is an additional layer of work.<br/><br/>Here is what the pygames version looked like before I scrapped it. This represents a long weekend's worth of very casual hacking (maybe 6-8 total hours of distraction- and interruption-filled programming):<br/><br/>[caption id="attachment_728" align="alignnone" width="480" caption="This looks okay, but those buttons are an eyesore, and just feel like bad UI"]<a href="http://stringofbits.files.wordpress.com/2012/04/pygo-pygame.png"><img src="http://stringofbits.files.wordpress.com/2012/04/pygo-pygame.png" alt="Original pygame implementation" title="pygo-pygame" width="480" height="399" class="size-full wp-image-728" /></a>[/caption]<br/><br/>Note the fairly ugly buttons along the side; several of those buttons (Quit, Join Game, Listen) would be better off in a menu. But menus (especially via a menu bar) are non-trivial with pygame.<br/><br/><br/><h3>Now with more GTK</h3><br/><br/>With pygame scrapped, I decided to use a widgeting toolkit that wasn't aimed for games, because I don't really need anything graphically sophisticated. GTK is an obvious choice, because I've used it extensively before. It was the first widgeting toolkit that I used, and it is still, in my mind, how such toolkits "should work" (I realize there are toolkits out there that may be better, but this one feels like the natural way because it is what I