Baseline Eclipse for Java Game Development?

The Eclipse IDE as it is offered for download at eclipse.org has become quite large. Size in bytes is probably not the biggest issue, but I think some of the functionality showing up in the UI is unnecessary clutter for many purposes that Eclipse could be used for. One such purpose I’m personally interested in is game development on the Java Platform (using Scala, Java, or another JVM language).

Some Java game development tools are already being built as Eclipse plug-ins and most likely more will be in the future. But right now they must provide them as a plug-in for an existing Eclipse installation that has all the clutter or build a completely custom Eclipse-based application, possibly an RCP app that doesn’t even include the Java Tools. I think this shouldn’t have to be the case: users of Java game dev tools should be able to download a version of Eclipse that is freed (as much as possible) from the cruft that they will not need, and be able to install specific tools and engine specific libraries into that baseline game development environment.

So I’m thinking of creating a lighter distribution of Eclipse JDT + XML tools that removes rarely used features from the Eclipse for Java Developers distribution and is specifically geared towards game development rather than enterprise Java or application development. Perhaps this should also extend to C/C++, but I am not familiar with the CDT so I’m not considering that aspect right now.

This distribution shouldn’t come from eclipse.org of course, but rather from the open source game engine and tools developers. I am willing to work on such a project, as long as it provides actual value to game developers and doesn’t eat up too much of my time. The first version of it could be fairly basic, just a lighter distro of Eclipse. Later versions can start incorporating game dev specific tools and UI concepts. Is there anyone interested in contributing to such a project? Or using such a build of Eclipse? Please let me know.

The first step of the project should be to create a reduced version of Eclipse JDT + XML tools that is still updateable, so that game development plug-ins and plug-ins such as Scala IDE, M2Eclipse, Subclipse, EGit can be installed. I have done some initial experiments and found an approximate list of features that can be easily removed from Eclipse JDT. If you would be interested in using such a distribution, please comment what you would like to be kept:

• APT or Annotation Processing Tool support — I think this is very rarely used and just clutters the UI in some screens.
• Ant support — I think a lot of people would be against this, so it should probably stay
• CVS support — CVS should not be used by anyone for other than legacy reasons, now that we have Git, Mercurial, SVN etc. And I expect that games development will not involve much poking around in legacy repositories. I think most open source game tools use SVN (correct me if I’m wrong).
• Help — this is debatable, but I would remove it from the first version and decide later what to do with it
• Welcome screen — same as help, can be added back later if it’s found to have some use
• JUnit3 support — JUnit4 should be enough, I think
• Various internal tools and plug-ins, backwards compatibility stuff

I’m estimating that the size of this distro would be somewhere between 50-70 MB. The P2 update manager included in Eclipse will increase the size on disk though, because it may create a lot of meta data and caches. But disk space is relatively cheap, and I don’t think there’s a better update manager available. My main concern is removing UI clutter so that game dev tools that plug into it will have more UI space and better visibility. Compared to the Eclipse IDE for Java Developers distribution, which lists the following “features” (feature in Eclipse terms is a collection of plug-ins):

• org.eclipse.cvs
• org.eclipse.epp.usagedata.feature
• org.eclipse.equinox.p2.user.ui
• org.eclipse.help
• org.eclipse.jdt
• org.eclipse.mylyn.bugzilla_feature
• org.eclipse.mylyn.context_feature
• org.eclipse.mylyn.ide_feature
• org.eclipse.mylyn.java_feature
• org.eclipse.mylyn.wikitext_feature
• org.eclipse.mylyn_feature
• org.eclipse.platform
• org.eclipse.rcp
• org.eclipse.wst.xml_ui.feature

Only these would remain (and even those not in complete form):

• org.eclipse.equinox.p2.user.ui (this is the update manager)
• org.eclipse.jdt (custom lite version with APT and maybe a couple of more small things removed)
• org.eclipse.platform (custom, with various plug-ins removed)
• org.eclipse.rcp
• org.eclipse.wst.xml_ui.feature (possibly custom with a couple of plug-ins removed)

Later versions could add optional updates that bundle engine-specific tools and libraries, Scala, SVN, Mercurial, Git or Maven support etc.

What do you think? Is there need for such an Eclipse distribution? I’m especially interested of the opinion of Eclipse based game tool developers, if any of you happen to read this post. Would you contribute if someone does the initial work? Has someone already done something like this (not engine specific)?

Call to JVM library developers: upload sources to Maven repos

I wish all developers that release libraries for the JVM platform (Java, Scala and other libraries) and put their libraries on Maven repos would also put the sources there. It makes it so much easier to get sources automatically attached in an IDE without going digging for them. Maven doesn’t do this by default, but building (and deploying) the sources Jar along with the binary Jar should be a matter of adding these settings to your library’s POM (or better yet, to a parent POM if you use a parent which defines commons settings).

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-source-plugin</artifactId>
  <executions>
    <execution>
      <id>attach-sources</id>
      <goals>
         <goal>jar</goal>
      </goals>
    </execution>
  </executions>
</plugin>

P2 Still Not Awesome

P2 has surely seen a lot of improvement in Eclipse 3.5, but some functionality that was actually somewhat acceptable in the old Update Manager is still lacking awesomeness. I’m trying to install VE into Galileo (Eclipse for Java + M2Eclipse + Subclipse + Scala IDE).

There are two usability issues with this. The first is that after selecting the “Visual Editor” feature from the site, I don’t have a “select dependencies” option. But from past usage of VE I remember that it requires Java EMF Model. So I select that too. A new user would not know to select this. I’ll have to navigate to the next page to find out if there are unresolved dependencies. And then we come to the second problem, which is this screen:

Am I really supposed to decipher this text and take action based on that? No thanks, I’ll just skip installing VE this time, I don’t have actual need for it right now.

ScalaBox2D is getting SVG support

ScalaBox2D is going to get an SVG scene importer soon. This will let you draw a scene in Inkscape and load it as a Box2D world in ScalaBox2D. I already pushed a very basic version of this to GitHub. It uses Slick’s SVG parser and has many limitations as of now, but you can already draw a Scene like this:

Inkscape SVG drawing

And bring it to life in a ScalaBox2D application:

ScalaBox2D scene

Currently every circle, box or polygon that has a red (#ff0000) fill will be turned into a dynamic body, the rest will be static bodies. There are also some limitations to the shapes, including: polygons must be convex, and have at most 8 vertices (or they’ll become static edges). Ellipses/arcs are not supported, only circles. You may get exceptions when loading some shapes.

The goal right now is to make this as robust as possible, so you can run the ScalaBox2D testbed and load (almost) any SVG file saved by Inkscape into it. After that, I’ll add support for loading scenes from game code and tying the physical bodies to game objects.

The code for the app looks like this:

import org.villane.box2d.svg._
import org.villane.box2d.draw.DrawFlags._
import org.villane.box2d.testbed.slick._

object SVGApp {
  val scale = 15

  def main(args: Array[String]) {
    val loader = new SlickSVGSceneLoader("C:/drawing-1.svg", scale)
    val world = loader.create
    val flags = Shapes
    SlickDisplayWorld.runWithSimulation(world, false, flags)
  }

}

ScalaBox2D performance problems solved

Turns out I had a small bug in the broad phase collision detection that caused all the performance problems. It is now fixed and the speed is now roughly equal to JBox2D.

URL Alphabet

When FireFox 3.0 (or was it 2.0 even?) added the new location bar, I was initially not so happy with it. But I got used to it pretty quickly and now it saves me a lot of typing when I want to visit my favourite sites. Typing one letter is usually enough. I thought I’d write down the whole English alphabet and what the location bar shows first for each letter. I think this sums up my current interests pretty nicely. Except some sites in this list are not really my favourite, they just happen to start with an uncommon letter.

Update: Oh man, I’m so behind the times. Seems that this was a meme in 2006.

A is for http://adventuregamers.com/

B is for http://www.box2d.org/forum/

C is for http://city24.ee/ (real estate portal)

D is for http://dzone.com/

E is for http://eurogamer.net/

F is for http://frictionalgames.com/forum/ (still checking every now and then to see if someone solved the mystery)

G is for http://google.com/ (surprise!)

H is for http://hansa.ee/ (although they are now SwedBank, I still use the old URL out of habit)

I is for http://www.idlethumbs.net/ (in it’s current incarnation an awesome video game podcast by Chris Remo, Jake Rodkin, Nick Breckon and occasionally Steve Gaynor)

J is for http://jazz.net/

K is for http://kv.ee/ (real estate portal)

L is for http://localhost:8080/ :)

L is also for http://listofdomainnamespointingtoidlethumbsdotnet.info/

M is for http://mail.google.com/

N is for http://news.google.com/

O is for http://www.offworld.com/

P is for http://planeteclipse.org/ (and some other planets follow)

Q is for http://www.infoq.com/

R is for http://rockpapershotgun.com/ (the best of PC-focused games journalism)

S is for http://scala-lang.org/

T is for http://twitter.com/

U is for … wow. Nothing interesting for U

V is for http://villane.wordpress.com/wp-admin/

W is for http://wired.com/

X is for http://xkcd.com/

Y is for http://youtube.com/ (another big surprise!)

Z is for http://www.escapistmagazine.com/videos/view/zero-punctuation (awesome video game reviews by Ben “Yahtzee” Croshaw)

What’s your URL alphabet?

ScalaBox2D Physics Engine source available

The source code for my Scala port of Box2D is now available at GitHub. There is not much support or documentation at the moment. For now, use only if you already know Box2D or really need a physics engine written in Scala :) More documentation and better user experience will be coming in the future.

I am working on the performance, but currently it is about two times slower than JBox2D (which you can also use from Scala).

Get the source code here. And a little information on how to build and run the testbed is available on the Wiki.

Eclipse finally defaults to UTF-8? In my dreams

Do my eyes deceive me? How the hell did this happen:

Eclipse defaults to UTF-8?

This happens in an Eclipse Galileo milestone (3.5M6), I can’t remember which exact package I downloaded, because I required some unusual combination of plug-ins.

If it was truly the case that UTF-8 is now the default, it would be awesome, because often programmers forget to change the default setting when creating a new workspace and end up committing something in an encoding specific to their machine. Which is guaranteed to cause pain at some point.

Unfortunately I think this is probably just a bug, because I downloaded another 3.5M6 package and it still defaulted to my region-and-operating-system-specific encoding. And even if I create a new workspace with this instance of Eclipse, it will also default to the other encoding. I wonder what exactly could have caused this instance to default to UTF-8 for a particular workspace…

The Improved Scala Eclipse Plugin

For the last few days I’ve been working on an Eclipse plug-in using a combination of mixed Java/Scala projects. That is, the same source folder contains both Java and Scala files. I think it’s awesome that this is finally working! At least I wasn’t aware if it was working before. There are still bugs in the Scala Plug-in for Eclipse, but the integration with JDT is now a lot better than before, thanks in part to Equinox Aspects as I understand. You can get the 2.8.x branch of the Scala plug-in, which contains the improvements, from the nightly builds update site.

Also, I noticed a curiosity: I wrote the most complex parts of the mixed projects in Scala, but I mostly created bugs in the comparatively trivial Java code. The Scala code ended up almost bug free from the start, even with hours and hours of coding without actually running the code. Is it really harder to create bugs in Scala? I’d like to think so.

My Head Asplode

For some reason I decided to count the programming projects I’m more or less working on in my spare time and counted more than I thought.

Some Eclipse related stuff:

• Bulletin Board API for the Eclipse Communication Framework. Recently did a major refactoring, needs some more updating to get all the features working again. (Java)
• Padclipse, a “lite” packaging of Eclipse which includes only the Text Editor and a bit more, plus some custom additions. I haven’t really worked on it for a year and a half, but I want to update it when 3.5 comes out. (Java)
• Eclipse plug-in to make 2D game development with Slick a bit easier. I was working on this for the past two weeks, just finishing up now and will release in a few days. (Java)
• A secret Eclipse plug-in. Just started, will see if something good comes of it. (Java, likely some Scala too)

Server and game related stuff:

• Ziggy, the forum bot that runs interactive fiction games, uses BB API. (Scala / Java)
• Web interface for managing Ziggy, barely started. (Scala, PHP)
• Scaler, a web framework, too little done to talk about. (Scala)
• STON, a strongly typed and extensible JSON-like data format. Not sure of the usefulness. (Scala)

2D Game related stuff:

• Scala port of the JBox2D physics engine. Almost done, but needs polishing. (Scala)
• Gamp, a game entity system based on Slick and my Box2D port. (Scala)
• Orbitum, a game making use of Gamp. (Scala)
• A secret 2D platformer game, but I have barely started with this so perhaps it doesn’t count. (Scala)
• Another game project, also secret. (Scala)

And this is not all. I occasionally work on quite a number of smaller things, some are just little experiments, others just for excercise. Some may become “projects”, some may not.

Looking at the list almost makes it seem unmanageable to me, but actually I don’t think I’m doing that bad, although there certainly have been release dates promised that haven’t been met. Now I know I should always multiply my time estimates by the number of projects I’m working on :) Only two of the projects are actually released/in production, and beta at that: Ziggy and Padclipse. At least two should have a release rather shortly: the Slick Eclipse plug-in and Scala port of Box2D. But even as I can move them out of the “yet unreleased projects” list, they are still going to need maintenance and updates.

Anyway, please comment, if you are also a programmer, or a geek with a different specialization, who has a lot of hobby projects, how do you manage not to get swamped with them or get the feeling that you are always working on cool stuff but never releasing? I was actually stressed by this a year or more ago, when I had somewhat less projects, but had not released any of them yet.

There are certainly good things about having so many projects: I don’t think I’m ever going to get bored. I have many ideas and wish there was enough time in the world to work on 30 more projects. And even if I wouldn’t think of any more new ideas, whenever I get bored with one of my current projects, I can switch to another one and so on.