Xsokoban on NetBSD

Having been busy and stressed out lately I haven’t had much time for tinkering or gaming. This is where smaller games that you can play as a quick distraction can help, as they are easy to squeeze in between other jobs, and todays game is one such game.

Xsokoban is obviously a clone of the old classic game sokoban. The original was made for the PC-8801 way back in 1982 by Thinking Rabbit. It has since been implemented and ported to pretty much every system, Xsokoban is one such port for Unix systems running X windows.

There isn’t anything really remarkable about this particular port. The quality of the graphics is quite reasonable, and it works well on pretty much any system I’ve tried it on including my older machines such as the Sparcstation 20. I’ve even played it over SSH via my comparatively slow ADSL2 connection, and it worked really quite well.

Interestingly the game has been studied in the field of computer science, it turns out it’s quite a difficult problem computationally, being PSPACE-complete. Lots of different researchers have worked on different algorithms for solving and producing optimal solutions. The complexity certainly makes me feel better about getting temporarily stuck on level 6!

As far as enjoyment goes, it’s really enjoyable for the puzzle solver in me, even when I’m stuck. It doesn’t take a huge commitment to play for a short while, and is quite challenging! This particular port isn’t any better or worse than any other, so don’t go out of your way, but NetBSD and FreeBSD users will find it easy to get running.

This slideshow requires JavaScript.

OS Shootout: Trying to get the Sun Frame Buffer to work.

Frame buffer

Quite a while ago I bought a Sun frame buffer (Wildcat Expert3d-lite) on ebay in the hopes of turning either my Sun Fire machines into a workstation. I had FreeBSD on the 280R and Gentoo Linux on the V440. FreeBSD didn’t like the card as it doesn’t have support for it, the version I have installed has become out of date and was having trouble updating packages. The Gentoo install had suffered a similar fate, I went to update it and found that the package system had become broken and couldn’t download the latest update.

So this weekend I decided to try a number of different operating systems to see if I could get the frame buffer working and see if there was a newer OS that would work better. Here are some notes about the different systems I’ve tried.

I decided to use the V440 as the base machine for performing the tests. I had been using Gentoo linux on it and had some minor success using the frame buffer. I was able to get a basic text console working beautifully, and it even displayed Tux the Linux penguin during boot up. But unfortunately the fbdev driver for X didn’t work producing some horrific corruption on screen, but the mouse and keyboard appeared to work.

Sunfire V440

The first fresh OS I decided to try out was NetBSD as it works well on my older Sparc machine. The installation went relatively smoothly, but I had to use the serial console in order to do it. I looked for support for my particular frame buffer but didn’t find any, even for some of the other available hardware. At this point I went to the documentaion online and realised I need not have tried it as the UltaSparc machines I have are not in the supported list for NetBSD. Although most hardware works, it seems that older machine are supported much better.

Next I decided to try the latest FreeBSD, the first time around I was using 8.3 which was quickly superseeded, but it was the only one that worked on the Sunfire 280R. So I downloaded the latest at the time of writing this, 10.0. Reading the documentation seemed to indicate that I’d be unlikely to get anything on this frame buffer at all, but if I buy a different type in the future there is good support. The installer was much easier than last time, again it required the serial terminal but it had everything set up very quickly. Of course the downside is the amount of time needed to build packages from ports, but thats a minor inconvenience if you leave it to build over night. I built and installed X, and with no surprise this frame buffer didn’t work.

In searching the internet for systems that support this particular device I came across OpenBSD. I had not really tried it out before so I didn’t know what to expect, but my hardware was listed as supported including the frame buffer. So I downloaded the install CD and began the process of installing. Compared to the other systems the installer is very _very_ basic, but at least you could do it from the computers console. Unfortunately I couldn’t get this one to complete installing, as the system rebooted every time it tried to extract the base system. At first I thought it likely this would be a hardware fault (as I had some in preparation for this) but I ran the system through its diagnostics multiple times and it passed every time. I may transfer the frame buffer into the SunFire 280R and try this system out again, but I think there’s something wrong with the installer/disc. The real shame is I saw in the kernel messages that it does indeed support my card!

Lastly I returned to an old favourite, Debian Linux. It is similar to Gentoo in that it supports the basic hardware and some framebuffers. Since Gentoo had some basic functionality I hope Debian might work better. I booted up the installer and was surprised to get the normal console-based Debian installer on the machines frame buffer. The installer was nice and easy, no major problems. I reboot into the new installation to see what would happen. Just like Gentoo the text console worked beautifully on the frame buffer, but X didn’t work. You could see the login screen behind some kind of strange corruption, but it seemed the keyboard and mouse were working as I could log in! I suspect Debian would work very nicely if I had a different frame buffer, but perhaps the guys working on the kernel will eventually fix the wildcat support.

So to summarise I found that Debian and FreeBSD would be quite workable if I had another frame buffer (or didn’t want to use it) and that OpenBSD might work well with this one if I could just manage to work out why it is crashing during install. NetBSD just doesn’t support the newer UltraSparc hardware well enough to use with a frame buffer, but might work quite well as a server. Basically I’m going to have to get another frame buffer card, then I can install either FreeBSD or Debian and have quite a nice Sun workstation.

Artsoft games on NetBSD

R’n’D Menu Screen

Today I am looking at two games for Unix systems called Rocks’n’Diamonds (R’n’D for short) and Mirror Magic. Both were developed by Artsoft which seems to consist of one person, Holger Schemel. Both games are sort of clones of older games for much older platforms. Rock’n’Diamonds is a Boulder Dash like game that was first released in 1995 and last updated at the end of 2013. Mirror magic is very much like Deflektor, originally released in 1995 and updated until 2003. Whilst both games are based on older games they both add features to the old formula. Today I’ve built and played these under NetBSD on my SparcStation 20.

Text Box

Being made by the same person, both games share some similarities, particularly in the art style. The menus and sprites are very colourful, they almost look like they belong at a carnival. Everything is well drawn, animated and items look like they should. Items brought over from the older games have been updated graphically, they don’t look identical to the originals but are also easily identifiable for players of the old games.

Green Goo

They run of the same graphics engine originally developed for R’n’D which supports X11 and SDL mainly. The X11 versions work quite well, even on exceptionally old hardware like my old SparcStation 20 which is quite impressive. They work moderately well over longer distances via SSH, but the latency and bandwidth can be a problem on slower links whilst LAN speeds works flawlessly. There is a SDL version, but the version I installed (from Macports on my macbook) seems to be significantly slower than even X over SSH. This is hopefully just something peculiar to the Macports version on Mac OSX.

Playing Via SSH

Both also have the same sort of sound engine and from what I can experience on the Macports version they are good for what they are. I only got to test sound in R’n’D and unfortunately during game play you can get swamped with the same sounds playing repetitively. So you might enjoy your playing experience more with the sound off. Playing on NetBSD on the old Sparc machine this wasn’t an issue as sound doesn’t work there.

Mirror Magic Menu Screen

The game play for R’n’D is interesting in that it combines elements from games such as Boulder Dash and Sokoban, and includes most of the elements added by Supaplex and Emerald Mines to Boulder Dash. The game has three game engines that any level can use. Rocks’n’Diamonds, Supaplex and Emerald Mines. The later allowing levels from those games to be played and solved as they are in the original. I haven’t played enough of the levels to give a good impression of what they are like as a whole, but those that I have played have been fun. I did try levels from the older games and they seemed to work quite well.

Holy balls of steel!

Mirror Magic similarly has its roots in older games, specifically Deflektor and Mindbender. Basically there is a Laser, a bunch of mirrors, obstacles, and stuff to destroy in the levels. You need to direct the laser with the mirrors to destroy objects in the way and get the beam to the target. Usually this requires destroying all of the metal spheres in the level. You have a limited amount of fuel, and the laser can over heat if the beam hits the wrong type of object. It’s important to keep an eye on both the fuel and heat gauges as running out of fuel or over heating can sneak up on you. What I’ve played so far has been quite fun, although I was disappointed that only levels from the old games were included.

Balls busted

Both games have a level editor which is easy to use. The editor in R’n’Ds is quite flexible and allows users to create their own custom objects that behave differently to the stock ones. This allows people to make all sorts of different creations, one even claiming to have recreated Zelda! There are lots of different level packs available on the Artsoft website for R’n’Ds, but not really any for Mirror Magic. In either case, if you do happen to beat all the levels there is still lots of gameplay in the user created levels and building some of your own.

What Mc Duffin?

Despite being based on older games that are well known, I think both of these games bring something new to the table. R’n’Ds brings many more levels including user created ones and variety in game play that the original games didn’t have. Mirror Magic is a decent remake of the originals with the addition of a level editor. Both run on Windows, Mac OSX, Linux, and BSD. There is even a DOS port of both although the port of R’n’Ds is a little out of date. If you like any of the old games on which these are based you might wanna give them a try.

Some words on X windows

I’ve recently been reading about and watching a few videos about the replacement for X called Wayland. Now I know very little about Wayland itself, but I’ve been a user of X since about 1999 when I first went to university, so I can’t help it, I feel moved to write about my current and old experiences. X is actually really quite an old protocol and was designed with different goals in mind than those modern desktop environments have today. The history is written all over the internet so I won’t repeat it, but it is evident that X was originally meant for the X-terminal connected to a mainframe case that was so very common at the point of its inception.

One of the questions asked was “what does X do well?”

Lincity via SSH

The core of the X protocol is based around drawing primitives such as lines and circles but also includes pixmaps (bitmaps for those who don’t speak X). Here is an example screen shot of a program, lincity, that was one of the first games I wrote about here on my blog. In this case I’m running it through an SSH tunnel over an ADSL line with a maximum upload rate (to the X server) of about 75Kb/s. Because of the way X works lincity is not only able to draw to my remote display, but is able to animate the play area at a reasonable rate. This situation is something which VNC and RDP just can’t do over my connection. The remote machine running lincity is my old Sparcstation 20 with 2x 50Mhz supersparc processors, running a pkgsrc build at the same time.

Working remotely

Here is another screenshot of me monitoring my old Sparc, again doing a pkgsrc build (they take a long time with only 50Mhz you know). I’m able to get real time performance graphs and interactive terminals, all using about 5-7Kb/s data through a SSH tunnel, and much less when the remote windows are not visible on the screen. This kind of use if very common for me, not just to old machines, but also modern ones that are around my workplace, X and SSH makes it easy to start a program from any machine. This is very handy for testing and I can run software from home or work as I need.

XDMCP Chooser

My machines at home are running NetBSD, FreeBSD and Gentoo currently and whilst some of them are capable, none currently have a head attached. So I frequently use XDMCP and a X server on my windows machine to access them, and it works basically flawlessly. I realise this is a less common situation now, but with thin clients becoming all the rage in different forms, it seems this feature of X could be exploited more.

FVWM on my Sparc

I love that there is so much variety in window managers and that there are light ones that make even my oldest machine quite usable with recent operating systems. Pictured here is my nostalgic favourite FVWM, which incidentally is still being maintained and developed. Windowmaker, openbox, fluxbox, etc, all deserve to exist and have a dedicated user base. They are interesting and useful, but mostly truly light-weight, making using older hardware viable. People like myself who collect and use old hardware find this useful to keep life in their old pride-and-joys.

No matter how it is implemented under the hood, for users the network feature of X is seamless and very easy to use, in no small part due to the hard work of the X11 developers, many of whom are working on Wayland. So what motivated the big change?

One of the major factors is X is becoming too large and difficult a project to develop and manage. A contributing factor to this is the explosion in extensions to it that made it kind of bloated. It seems they were sort of added willy-nilly (mostly during the Xfree86 days) to meet the demands of people developing the more eye-candy based style desktop environments we see now. Fortunately the X developers have been cutting much of the debris out of the extensions and have made the X server modular. Now if only the X server was actually installed/packaged in separate modules for each extension and the core it might make having a slimmer server easier, but as far as I know that’s not possible.

Personally I’ve not had much trouble with X. I mostly had problems with getting proprietary drivers to work for my GPU back in the Xfree86 days, but I’ve not had that problem in ages. I have only really seen the flickering that has been talked about over high latency network connections, never over any LAN I’ve ever used. I understand that it probably does have huge design flaws, and that a newer system and design is needed to meet the needs of new desktop environments. I just feel somehow, that when it’s gone I’ll miss X.

The Battle for Wesnoth

Main Menu

The Battle for Wesnoth is an open source game project that had its first release back in 2003. It is a strategy game based in a fantasy world with many RPG like elements. Today I’m playing it on my Macbook running Mac OS X (Lion), but the game also works on many other platforms including Linux, Windows, and most BSD systems. I have been able to get it running on my sun UltraSPARC sunfire v440 which I have Gentoo Linux on currently.

Campaign Selection

Upon starting up the game and being greeted with the menu system, I was struck with how professional the game looks. The menus, backgrounds and graphics all appear of professional quality as soon as you see them. The menu system is easy to use, and gives you help when faced with something more complex. The music is equally epic as soon as you first hear it, bringing to mind epic battles before you’ve had a chance to fight any.

Starting area

The game offers a tutorial mode which I highly recommend, not so much because playing is difficult, but it is a much more gentle way to get used to the way the game works. The tutorial teaches you all the basics of movement, combat, and recruiting new soldiers. I found within no time I had managed to get the hang of it, and had managed victory in the tutorial and the earlier part of a introductory campaign.

Combat

The game has many campaigns of different difficulty and length, meaning there is always a campaign to suite your skill level and amount of time available. Many members of the community have created extra content including campaigns, new resources and units all for you to enjoy in single player or multi-player. Of course if you have played through all the created content there is also the option of playing random maps, or creating new ones of your own.

Recruiting

In addition to the single player, hot seat, network and internet multiplayer games are all supported. Connecting and playing any of these modes is simple and easy to do. Although you need to be well prepared to play online.

Playing the game I’ve found the controls fairly easy to use and have had no trouble getting my armies to do what I want. There is however an incredible amount of depth in the stories for the campaigns and the number of stats the units can have along with their effect in battle.

Killing Mordak

Combat in particular is interesting. There are two main types, Melee and Ranged combat. Different types of units can perform one or both of these different types of combat. Interestingly if you attack someone with a ranged attack and they have no ranged capability then their unit cannot retaliate and you unit will emerge unharmed whilst theirs does not. This can also happen with Melee combat if the other unit has no melee capability.

Whilst all the attacks units have are either ranged or melee, they also can have other properties such as being magical attacks. These modifiers can change the effect of the damage, the chance to hit, and inflict poison or drain health from an opponent.

Victory!

Units are much like characters in a role playing game, they have attack capabilities in various forms, traits that affect their stats, and they have health points and experience points. Units can level up and get upgraded down one of a few paths in an upgrade tree. There are only a few levels to upgrade to depending on the unit, I think most get to level 3 or 4. Upgrades can significantly improve a unit so this is understandable. Players need to try and hold onto their strong and experienced units longer as they are much more effective than the base units you can recruit. If you are in the middle of a campaign you can recall units from the last scenario you played to benefit from them having more experience and perhaps being higher level.

Your main avatar can recruit new units when in the main castle. This requires gold that you acquire by occupying villages. Villages will support one unit for free and earn you some gold, which can be spent on support for more units, or on recruiting more units. Villages will also provide a defense bonus and heal units stationed there. This makes villages an important asset in the game, as you need them for income and to heal your experienced and important soldiers.

Campaign story

The Battle for Wesnoth is very polished, it is pretty much the same or better than commercial games quality wise. I’ve not run into any bugs in the limited time I’ve been playing. Installing add-ons and getting online for internet play is seamlessly handled in the game UI itself, removing any need for manually extracting files or arranging servers. It works on a wide variety of platforms so getting a version for your system should be no problem. If you like strategy games I highly recommend it.

WindowMaker on FreeBSD

WindowMaker on FreeBSD

This weekend I decided it was time to upgrade the software on the two functional Sun Sparc systems I have. I have FreeBSD on the newer of the two machines, and had been trying various window managers to use. The older Sparc has FVWM (recently upgraded to the latest version) on it so whilst it is really my favourite for reasons of nostalgia, I felt I’d like something different. I had tried XFce, but many features of it were broken on the FreeBSD/Sparc64 platform. So I installed a few other window managers to see what they were like.

I had never installed WindowMaker before but had certainly heard of it. I remember looking through many package lists to see many of the dock apps, and wondering about the window manager itself. WindowMaker has a similar style to the old NeXT workstations operating system called NeXTStep the system that would eventually become mac OSX.

The first thing I noticed when I fired it up was how minimalist it appeared to be. I found the root menu relatively quickly and managed to work out most of how it works within a few hours. I was quite impressed with how fast the interface responded when I clicked on items, although FVWM is a slight bit faster but not by much. There is a very nifty configuration program built-in that controls pretty much everything you could want to change. This makes it very newb friendly, I was able to set up my desktop the way I wanted it very quickly.

It isn’t the most pretty of window managers however, and there is no pager built-in. Workspaces are managed by the clip icon, usually at the top left of the screen. When using it via X on the local network it was quite fast, but over a VPN or SSH connection it became quite sluggish when FVWM maintains reasonable speed. I’ve heard that it can get slow if you have a large number of dock apps running.

Overall I quite like WindowMaker, whilst it isn’t a replacement for FVWM for me, it will be a nifty interface for my newer sparc machine. I like that I can configure most things with the user interface, and the large number of dock apps available for it. It isn’t so useful when I’m connecting into my machine externally however as the speed drops of significantly. It’s available on all the different distributions and the various BSD systems.

Freeciv on FreeBSD

Main Menu

Quite some time ago I worked at a radio telescope for 3 months as part of my work experience for my engineering degree. During that time I had an incredibly old machine as my work station, it was an original Pentium running at 77 Mhz. Because it was so old and because of the job I was doing I installed Linux on it. I used my favourite old school window manager (FVWM) and had it set up pretty sweet.

One of my duties for a short period of time was looking after the telescope after hours. This was called being the duty astronomer and was something everyone did at sometime during the year. Basically you were on call for if something happened to the equipment that the remote astronomer couldn’t handle. Most of the people using the telescope were often some distance away and did observations remotely thanks to the power of the net.

The main view

So I was spending many hours at my workstation after work hours, not working, and watching the telescope and waiting for something to happen. This is when I installed freeciv and started playing. Surprisingly even on that hideously old machine the game played quite well and was quite enjoyable.

The city screen

Recently I compiled and installed it on my sun fire R280 machine which is running FreeBSD. The machine is headless so I was accessing the machine via XDMCP in order to play. There are too many graphics to play the game via a VPN connection, but it works very well over a LAN connection, mine is 100Mbps so it would be significantly better on gigabit.

City production

I was playing on the standard GTK based client, but there are other clients with support for the Xaw, Xaw3d and SDL toolkits so you can get it to work on systems without GTK installed. Most of the clients look pretty much the same with the exception of the SDL client which imitates the interface of the newer civilization games.

Research tree

The graphics for units and the terrain are consistent across all the clients so you won’t be confused trying to identify units or terrain. There are several tile-sets to choose from as well so you can customise the way the game looks. Unfortunately the newer versions of freeciv don’t have as many tile-sets available as the older ones. Some times I have found some of the text is difficult to read because it is so small.

Other civilisations

If your platform supports sound there are some sound effects for events such as combat. On the sun machine I didn’t have sound, however I do have it working on my macbook running the SDL client for freeciv. The sound is reasonably good, but not essential to game play. There isn’t any music in the game, but this leaves you room to play some of your own.

The SDL client

The game play is of course very much like civilization. The default rules most resemble the rules of civilization II with some differences. There are different rule sets that you can use, for instance there is a rule set for the first civilization game. There are unfortunately many subtle differences in game play that may annoy some players. The main draw card here is that multiplayer games are supported. This is reflected in the way diplomacy works differently to the commercial games.

Personally I actually prefer the original civ II game play, graphics and sound, but freeciv has some merit of its own. There are some features that are nice such as extremely large maps, and many more players in one game. The rules are subtly different which can change some of the strategies for play, but for the most part the same strategies will work. It still is fun to play for me, but it really will be a matter of personal preference as to whether you enjoy it or not.

This slideshow requires JavaScript.

XBlast on NetBSD

XBlast was created by Oliver Vogel and Garth Denley between 1993 and 2006. It is a multi-player game that is based on the Bomberman games which were popular on many old home consoles as early as 1983. I had never previously played a Bomberman game before so I have very little frame of reference for comparison to the older original games,  many of which I’ve read about have a similar multi-player facility. I built XBlast on my old Sparc hardware as I have done for many of the old X based Unix game. It built with out any problems and seems to run quite well even via XDMCP over the network. I haven’t tried building it on other platforms but I suspect that it would work on most Unix like systems.

The graphics for the game are colourful, and look fairly nice. Like I said they seem to work over the network with very little to no performance issues at all. The user interface has many options and I found it a little confusing to use, in particular when trying to use the network play options on what they call central. The game has an option for sound, but that did not work for me on the Sun platform so I can’t really comment on the quality of it.

There is no single player option really for this game, you can play multi-player games over a LAN, the internet, or on the local machine by sharing a keyboard or using multiple controllers. I wasn’t really able to get multi-player working, either because there is no-one on-line or because I couldn’t work out how to get the internet play working properly. I was able to play against an AI on the local machine and found the game was a little confusing to play at first. The controls for movement seemed to worked fine, but when I tried dropping bombs I’d find that it was a bit slow to do so, or wouldn’t do it at all for some unexplained reason. The game basically involves running around trying to get power-ups whilst avoiding bombs and laying your own to get your opponent. There was little of any kind of puzzle element and after a period of time the level space would start shrinking until some one gets killed or caught in the new wall sections appearing. There are many different levels/arenas for you to play in each with it’s own rules for game play. Some are quite large whilst others are relatively small. They change your strategy in where you try to place your bombs, and how you go about avoiding bombs placed by other players.

I think the software itself and the graphics are crafted quite well, but the game does get old fairly quickly. I think that it would definitely benefit from having a single player campaign with puzzle elements much like the original Bomberman games. I found myself getting bored fairly quickly, and I didn’t really enjoy the experience. This may be different for you if you liked the multi-player elements of the Bomberman games, or if you were a fan of them. Otherwise I’d suggest you’d probably be better off finding another way to entertain yourself.

Victory

The Title Screen

The Main Menu

Gameplay

Before a Level

Xboing on NetBSD

Xboing is a breakout style game for the X windows systems, it was written by Justin C. Kibell in the years 1993 – 1997. It is written using the basic X toolkit libraries so will run on pretty much any Unix system with a half decent compiler set. The game models itself after an arcade machine, and even goes as far as having an attract mode (or demo) to show the basics of the game.

The graphics are very colourful and pleasing, and I’m happy to report it works very well even on very old hardware, or via an XDMCP session over the local network. I found it worked quite well on my old sparcstation. The animations and movement of the paddle and ball are fast and this helps the controls be responsive.

Sound didn’t work very well for me, it froze the game on the sparc, which could be caused by any number of issues. The game doesn’t suffer for not having sound, so if you have similar issues, I’d just turn the sound off.

Gameplay is very similar to all the other break out classics around with some differences. For instance, the power ups do not drop out of bricks when they are broken. Instead they themselves are bricks that when you break them give you the power up contained therein. You get a limited supply of bullets in the game to help you clear areas faster. This is very handy when there are only a handful of bricks left that are quite hard to hit with the ball. That being said, because you have a limited supply, you aren’t tempted to go shooting down every brick in a level as it will affect how much ammunition you carry over to the next level. Interestingly you can accidentally shoot your ball and end your game if you aren’t careful. I’ve also noticed you can squeeze the bullets up between columns of blocks to hit something at the top of the screen. This was useful when the “eyeball dude” went past, I had a chance to shoot him for points.

The default setting for the game is quite fast, so you will probably want to slow it down. Don’t slow it down too much however as this impacts your ability to score and get bonus score for completing a level quickly. Control is via the mouse, and is very responsive and quick. The only problem I had was when I accidentally moved my mouse out of focus and the paddle stopped moving. This may not be a problem for you depending on your window manager, I could always configure mine to improve the situation!

I found that the game was quite fun, and offered something different to the other breakout games out there that mostly follow after the classic Arkanoid. The challenge is high enough depending on the speed you set, and you shouldn’t find yourself bogged down trying to get that last one or two bricks for very long. So if you are a fan of breakout games, have a Unix system, and want to play a good breakout game, I’d recommend giving Xboing a try.

The blocks

Play area

Game Controls

Basic Instructions

Xpilot on Mac OS

Xpilot is a game very much like Thrust on the C64, but with many more complicated features and game-play. The game is one of the pioneering games in internet gaming, it was one of the first to include in game chat and different game modes such as capture the flag. It was written for unix workstations, and the first public release was made back in 1992 by Bjørn Stabell and Ken Schouten. Xpilot runs on most unix systems including Linux, FreeBSD, NetBSD, Mac OS, ans Sun OS that I know of, in theory if the X libraries are installed Xpilot should run on it. You can build it under cygwin for windows, but I believe that there is a proper windows port you can use.

I built the game on my macbook which runs Mac OSX Lion. It was fairly straight forward to build, but I needed to install the imake utility from macports to make my life easier. I also had to modify some source code very slightly for it to work on my computer, so I would suggest using the version of it in Fink. I have previously built and ran the game on NetBSD, Linux and FreeBSD without any issues.

The games system requirements for getting it to work are fairly low, but it’s a good idea to not run it on very old hardware. Anything younger than about 10 years old should be fine. It can demand a lot of the X server, and can require a lot of your network if your X server isn’t local to where the game is running. I tried running the game on my old sparcstation to see how well it would work, it seemed fine, but the server used all of one CPU and the client a good part of the other. I was running the X server on my desktop machine which was taking some of the load off, so it would be unlikely that the old machine could have coped very well with the full load of the game unless I upgrade it.

Because of the systems the game was meant to run on originally, there is no audio as many X terminals never had sound and there wasn’t a uniform way to access audio hardware when it was first written.

The game play seems very complicated at first, there are tons of controls, options and bonus pickups to learn about. The initial keyboard controls are a bit unintuitive, so it is a very good idea for you to change them before hand. This can be a little difficult because you need to modify your configuration file to do it. Once you have changed to controls to something that suites you better, it is a much easier and better game to play. I found I was woefully outgunned against a bunch of robots, and I am still pretty much a newbie at piloting. My scores often go negative. Very negative. I have occasionally done better but that was weirdly enough when testing on the sparcstation.

If you’re looking for more information about how to play or configure the game there are numerous newbie guides of which I found this one to be quite good. The game is very addictive and quite fun (more so against humans than robots!) and many people still play it today. There are also a couple of newer ports that are partly compatible with the original called xpilot-ng and xpilot5. I’ve also noted there is a java client available on source forge and an app for the iPhone available. I tried xpilot-ng quite a while ago and think it’s pretty alright, but I haven’t tried the others for comparison.

The play area

The about screen

Keyboard Reference

Items, bonus, and weapons

Internet servers