I’m too tired to write a clever opening for this post. There. Now that that’s out of the way, let me introduce Xeiso.
Xeiso is:
- A game console.
- An operating system.
- A bootable LiveCD.
- An intuitive interface.
- Open source.
Time to elaborate: it will be an Ubuntu-based system with a custom interface with the goal of making a fast-booting, open game console. I’ve been researching solutions for a few months now, and have been testing out various languages and methods, from C++/SDL, to Python/Pygame, and back to C++/OpenGL. But now I think I’ve finally found a compatible, fast development and fast running framework for the user interface: Python and Pyglet. Hey, if it can run an OpenGL ortho projection on a 1680×1050 screen at 60fps with minimal CPU usage, it’s good enough for anything.
I’ll stop blabbing for a few minutes while you watch this video:
That’s the basic interface. Keep in mind that that demo is relatively old; the current revision is varied quite a bit. But that’s the gist of how it runs: everything, from games to controller options, is configured and controlled via this “slider” interface. It’s intuitively simple: if an arrow appears on the screen, you can press that arrow on the keyboard to go there. Allows for blind and quick motions. Like it? Cool. Hate it? Great. Suggest an improvement on Launchpad or in the comments.
A lot of the meat is under the screen - there is a rather extensible packaging system that allows for anything to be run from Xeiso. In the latest revision (17) there is a basic Neverball package, though currently Neverball must first be installed. “Hey - if this is to be an APT-based distro/system, why not use dpkg?” Good question. Because in the future I’m hoping to support downloadable content - and remember we’re looking for a fast-booting system - “xpackages” are being used. It’s basically a tarball and module system, meaning that packages can be dynamically loaded into memory at boot from an external device without much delay.
Some planned features:
- LiveCD:
- Fast booting: “Boot to X in 10 seconds or less.” Likely? Not for a while.
- Ability to use the host HDD or an external device as a “memory card” to store game save data, additional XPackages, boot configuration, etc.
- Automated CD build system (near completion)
- Install to system w/ GRUB
- Partial install: Copy most of the files to the host device, and chainload it from the CD to speed up boot
- XPackage:
- Ability for banners, small animations that load on a preview screen (almost done)
- Content distribution system for downloading games (still researching)
- Patched games to support a freeze menu to reset, configure controllers, etc. (designing)
- Controllers:
- Mouse/Keyboard, Wii remote, Joystick
- Key customization
- Multiple players
Working code is available on Launchpad. It’s still under heavy development, so if you make a feature branch expect it to be 99% incompatible within a day. I’m not currently looking for any main developers - as I said it is being worked on at a fast pace and things can’t easily be coordinated. (I’m having trouble keeping up with my own documentation!)
In the future, though, I’ll be looking for:
- Packagers - work with XPackages and patch games.
- Graphic artist - I’m not too creative.
- Someone good with audio. Can’t have a game console without sound! Mostly creating/finding tracks/sound effects for the UI.
Again - don’t contact me about getting involved with development yet - you will be able to soon.
Neat, but I’m still not sure about the packaging format — why was it nessecary to invent a new package just for downloadable or plug and run games? Apt-get supports directories as repositories, and we both know it’s designed for networking. If sources.list is a problem, try sources.list.d. Meanwhile, the new features xpackage offers seem like something I’d want in the apt/dkpg system!
This all said, I’m glad someone’s put together a centralized effort to integrate games on Linux. Having toyed around with games and input methods on Ubuntu, its definitely a pain to deal with configuring controllers on a per game basis. Having a universal configuration and policy sounds like a good way to give game makers in the future a good reference on the subject!
jldugger:
The problem with dpkg is that it is rather slow for what is needed. Every time a package is installed or removed it has to update its database and keep track of system files and changes. Since we’re simply dealing with loading packages into either a single folder or into RAM, there is no need to keep any sort of database other than a simple file listing, and thus there is no need for the overhead of dpkg or apt.
Hi Jacob,
As someone who’s worked in the games industry (mainly as an artist), I’d actually had a very similar idea myself. There was one major difference though. I thought about why console games did so well and were quicker and easier to create, and it mainly came down to that they have a standard hardware set.
One target hardware set means programmers know that they *only* need to program for a specific model of gpu, cpu, gamepad etc. If you have a standard set of specs, then games can be developed and tested much more quickly. They may still work on other systems, but that’s where all the dev’s streamlined efforts go.
With a standard box, hardware vendors (Dell, New Egg, System 76, HP, Asus etc) can then sell boxes that are guaranteed to run all the approved games, 100% hassle free. Instantly you get rid of all the geek tinkering to get your specific hardware working properly that scares the mainstream away from Linux. You get a consumer ready, “almost never hangs,crashes,has X misconfigured” device. Because these boxes all use the exact same hardware they could be bought in bulk by anyone and sold cheaper too, exactly as game consoles do right now.
Linux games that already run fine under Xeiso could be given permission to use a “Xeiso Ready” logo. Later on this logo could even be licensed to non-open source games and hardware vendors as revenue for the project. Work with Ton Rosendaal (of the Apricot open game at apricot.blender.org), get John McCormack (Id games) and Mark Shuttleworth to endorse it as a Linux Gaming Standard and you could get some large scale momentum behind it. That could be snowballed by re-investing a good portion of licensing revenues into seed funding promising open source games which could then be pre-sold Peach/Apricot style with extra’s to raise further funds.
Anyway, as someone who is a better artist / businessperson than coder, I’d be curious to know your thoughts.
All the best for the project!
How much time are we talking here, and is there any way to mitigate it?
Bugsbane:
I have been thinking about that as well, though not into too much detail. A standard hardware spec would be nice, but it’s not really on the plate just yet. Definitely something to look into, and maybe find a hardware vendor to work with, but right now it’s just developing a fast software framework.
jldugger:
Do you mean the time of project development, or the APT loading time? If it’s the former, I’d say that there could be a somewhat mature UI by the end of the summer. The LiveCD portion will be somewhat delayed - I’m going to be doing that as part of my student project, but everything else should be ready real soon to work on and package for. As for APT/dpkg speed, there isn’t much to speed up. I suppose packages could be directly extracted instead of installed, but even then there is an unnecessary overhead of extra files.
A small note I’ve missed myself: XPackages is a bad name, because that’s already used for a specification for XML. So maybe something shorter will be used in general context; maybe XGPAK or simply XPK will be used.