Over at
SourceForge, the August Project of the Month is the community-elected VASSAL Engine, described as “a game engine for building and playing online adaptations of board and card games.” Project manager Joel Uckelman sat down to talk about the project’s origins and future.
(Editor's Note: Here's the link to the project. Hello, Hacker News folks!) Tell me about the VASSAL Engine project. VASSAL provides a virtual tabletop for playing board games live over the net and by email. It’s cross-platform and open source, and has a huge library of games of all types—traditional board games, Euro games, war games, and card games—over 1,400 in our module library at present.
Click here to find game-developer jobs. What made you start this? Rodney Kinney created VASL (Virtual Advanced Squad Leader) in 1997 as a program for playing Advanced Squad Leader (a tactical WWII combat game). After a while it became clear that most of the code in VASL would be applicable to other board games as well; in 2001 Rodney split the project into the generic game engine VASSAL, while the ASL-specific parts kept the VASL name but became a VASSAL game module. I joined the project in 2006. The draw for me was and is that VASSAL lets me play games with my old opponents who now live in far-flung places, lets me set up large games for which I lack the table space, and lets me keep logs of what happened in those games. VASSAL is a tool I want to use myself, as well as a way I can contribute to both the board gaming and open source communities.
Has the original vision been achieved? Yes. We’re well beyond what anyone envisioned at the outset and have been for years now.
Who can benefit the most from your project? People who want to play short board games in real time, people who want to play longer games in sessions or by email, people who lack the space for setting up large games, game designers building and testing prototypes, game publishers who want more visibility for their board games—all of these can benefit from VASSAL.
What is the need for this particular game engine? There are custom programs for some board games. However, writing a custom program for each board game that someone might want to play is a huge duplication of effort, beyond the abilities of most people, and maybe not even be feasible given the incredible number of games published. Just within the war-gaming section of the hobby, there are more than 150 games published in a typical year; there must be hundreds of Euro games. Fortunately, even the most disparate board games have common elements: There are players, pieces, boards or maps, maybe cards, and dice. The code one needs for handing these things in one game is largely applicable to others as well. With VASSAL, there’s no need for anyone to recreate these things for each game. Using our module editor, anyone can build a game module—it’s not necessary to be a programmer to do so. Without VASSAL or a program like it, there would be no way to play the vast majority of board games over a computer.
What’s the best way to get the most out of using VASSAL Engine? Read the Users’ Guide. Read the instructions for the game module you want to use (if the module designer provided any). This is the best way to get started. It helps if you’re familiar with the game you want to play already, as then you’re not learning VASSAL, the module, and the game at the same time. If you have a problem, ask about it in our forum or in the #vassal IRC channel on freenode (but please
wait for a reply if you drop in to #vassal—sometimes we’re a bit slow to answer).
What has your project team done to help build and nurture your community? For some years now we’ve had a
forum (bridged to a mailing list) for our user community. It’s quite active—there are more than 44000 posts there as I write this. Our development team also frequents the VASSAL topic on
ConsimWorld.
Have you all found that more frequent releases helps build up your community of users? We’re fairly aggressive about fixing the bugs users report, so one of our motivations for releases is to get those fixes out to users—it makes users happy to see bugs they reported fixed, it makes it easier for us to troubleshoot with fewer changes between releases, and killing bugs in the wild helps us spend less time on bug reports and more time on development.
What was the first big thing that happened for your project? What happened was a collection of many small things rather than one big thing. Many war games have VASSAL modules before they’re even published in hard copy these days, which is something I never expected. It dawned on me that we were having an impact on the hobby when I started to see VASSAL module designers being thanked in the credits for printed games.
What helped make that happen? Game designers deciding to use VASSAL for play testing.
What was the net result for that event? It’s gotten VASSAL much more exposure in the board gaming community, but it’s also helped grow the hobby. We hear constantly from people who bought a game because they saw the VASSAL module or because they realized they could now play the monster game for which they lack table space. That’s good for us, good for game players, and good for game designers and publishers—good for everyone in the hobby.
What is the next big thing for VASSAL Engine? The next major version is VASSAL 4.
How long do you think that will take? I’m asked this often and I always try to dodge it. The most accurate thing I can say is that our current release, 3.2, is getting attention for bug fixes only now and I’m focusing the bulk of my own development efforts on VASSAL 4. In short, I don’t know when you’ll see V4 but I do know it will be next.
Do you have the resources you need to make that happen? Partially. I’m aiming for us to have
Android,
iOS, and Web clients for V4, in addition to Mac, Linux, and Windows clients that we have now. As a team, we don’t have all that much expertise with tablets or Web apps right now. More developers, especially ones familiar with those areas, would expedite things a bit.
If you had it to do over again, what would you do differently for VASSAL Engine? From 2009 to 2012—the period when 3.2 was in development—we were adding new features, but we were also getting a torrent of bug reports from the bug reporting tool we added to 3.1. Both experiences made us reflect on the overall design of VASSAL. It became clear that some design choices that were appropriate in 1997 weren’t in the 2010’s. But the main thing I learned was that we need a clearly defined specification (for the module designer API) so we can tell whether a behavior is actually a bug. VASSAL is in an odd position in that some of our users are game module designers and some are game players. It means that VASSAL is a client for some people and a library for others. Because VASSAL is extensible, module designers are constantly finding creative ways to do things, and we’ve increasingly found ambiguous situations where fixing an apparent bug for one module designer breaks another designer’s module. Providing a proper spec should help with that.
Any reason you can’t do that now? We’re planning to do all of that in VASSAL 4.
Related Articles
Image: VASSAL
Upload Your ResumeEmployers want candidates like you. Upload your resume. Show them you're awesome.
