Will It Rain Tomorrow?

Several years ago I started learning Ruby, which is my first dynamic-typed programming language. As a rookie programmer I was very astonished by its elegance and flexibility. But as time goes by, I has stopped being a fan of dynamic languages.

I have to admit dynamic languages are generally easier to code and understand. In the meanwhile, however, you can’t find an efficient way to refactor/debug them. Unit Test only mitigate this problem partially. On the other hand static languages are tedious but easier to scale in features.

To get the best of two worlds I chose Scala, a functional language based on JVM. Scala is not the final answer of programming language(the syntax is too obscure), but for me, it’s the most viable solution by far.

One of the best features of Scala is the fact it’s based on JVM, so it can utilize existing libraries written in Java. What interests me most is libGDX, a cross-platform game development library.

Scala and sbt

First, of course, you need Scala. It’s a kind of popular language now, so you may be able to install it via your package manager:

sudo apt-get install scala // On Ubuntu
brew install scala // On OSX

If you want the bleeding edge version you can check the official site.

libGDX decided to use Gradle as dependency manager. It’s not a bad idea(compared to Ant and Maven), but in the world of Scala we use sbt. Similarly:

brew install sbt

On Ubuntu or other Linux systems you can download .deb file here.

libGDX and the game

It may not be a simple job to figure out all dependencies and build scripts, especially when you wish to develop game for multiple platforms, not just desktop. Luckily someone has done that and save his work as a template. To set it up you need giter8:

curl https://raw.github.com/n8han/conscript/master/setup.sh | sh
cs n8han/giter8
g8

Then set up the template. It will ask you to specify some configurations.

g8 ajhager/libgdx-sbt-project
...
package [my.game.pkg]: cc.raintomorrow.smile
name [My Game]: Smile
scala_version [2.10.3]:  
api_level [17]: 
main_class [MyGame]: Smile
libgdx_version [0.9.9]: 

It will generate a directory named smile. Now you have a fully functional game project! Oh wait, I’m lying. You haven’t installed its dependencies yet. Before you do this, you can check the project directory in the project. You can change the versions of dependent sbt plugins in project/plugins.sbt and sbt itself in project/build.properties if the template’s choices don’t please you. Be careful, not every up-to-date plugin is compatible with each other.

Then install everything you need:

sbt
> update

It will take a while. After it’s done, you can run your game now! Watching an empty window is sort of boring, however, so let’s add some code. (Of course you shouldn’t use ShaderRenderer in real-world project.)

Read More

Sadly we decided to stop the development of Dig Quest. It’s due to my personal reasons, and the presence of a similar game, Pocket Mine(by the way it’s a great game).

If anyone ever paid attention, thank for your concern.

libGDX is an incrediable library which allows we to develop iOS game in Java. The fly in the ointment is that its toolchain is a little bit complicated and expensive. You’ll still need Xamarin to build your iOS app.

As the wiki says, when you’re develop iOS game with LibGDX, you have to import every single asset into Xamarin, manually. The “Build Action” of some file extensions iOS doesn’t know, such as .json or .atlas, must be set as ‘Content’ one by one. For a rapidly developing project it can be tedious. So I wrote a tiny Ruby script to automatize this task.

#!/usr/bin/env ruby
require 'xmlsimple'

asset_dir = ARGV[0] || '../assets'

csproj = XmlSimple.xml_in('digquest.csproj')
asset_list = csproj['ItemGroup'].find { |ig| ig['LibGdxType'] == 'assets' }
unless asset_list
  asset_list = { 'LibGdxType' => 'assets' }
  csproj['ItemGroup'] << asset_list
end

asset_list.delete 'BundleResource'
asset_list.delete 'None'
asset_list.delete 'Content'

asset_paths = Dir["#{asset_dir}/**/*"]
assets = asset_paths.select { |p| File.file?(p) }
asset_list['Content'] = assets.map do |a|
  win_path = a.gsub('/', "\\")
  { :Include => win_path, :Link => [win_path.gsub("..\\", '')] }
end

XmlSimple.xml_out csproj,
                  :RootName => 'Project',
                  :XmlDeclaration => '<?xml version="1.0" encoding="utf-8"?>',
                  :OutputFile => 'digquest.csproj',
                  :NoEscape => true

To run it you need install XmlSimple gem first:

gem install xml_simple

Then the usage is very simple:

./import_assets.rb {path_of_your_asset_directory}

Without command argument, it will assume your assets are in ../assets(relative to the working directory where you run the script).

By the way, if you have imported some assets manually, you may need to remove them in Xamarin before making this script work.

makegames:


Note:
This tutorial was created in 2007 for my personal website. Some small tweaks have been made since then, but nothing too significant.

In this 10-step tutorial, I’ll teach you how to create a “sprite”, which is a stand-alone two-dimensional character or object. The term comes from video games, of course.

Creating pixel art is a skill I picked up because I needed graphics for my games. After a lot of practice, I became kinda handy with it, and started to see it more as actual art rather than just a tool. These days, pixel art is quite popular in game development and illustration.

This pixel tutorial was created many years ago to teach people the basic concepts behind pixel art, but I’ve streamlined it a lot since its first incarnation. There are other pixel tutorials around, but I find them to be overly-complicated and too wordy. Pixel art is not a science. You should never have to calculate a vector when doing pixel art.

Read More


(all images are just placeholders)

It has been more than a month since last post. What am I doing recently?

I got started on a new mobile game project, Dig Quest, with David Chang.

In the past month David and me mainly focused on core gameplay, and I believe we have developed a strong prototype. Trying to describe it in one sentence, in Dig Quest players have to dig down, beat monsters and dodge the falling rocks at the same time.

Since We’re both programmers lacking in aesthetics ability, we contacted the art studio Fludot.Co, and established some consensus with them.

It’s still under heavy development, and sorry for that I can’t put a download link here, because some of the assets we’re using in prototyping are extracted from other games. In any case there is a long way to go. I hope we can have something to show soon.

By the way it’s very likely to have desktop version, including PC, Mac and Linux. Thanks to the great libGDX.

Do you know how to do something periodically, like ticking the second hand of a clock, in Java? The old java.util package provides Timer class, and Swing provides a simliar(with different API) TImer as well. In JavaFx, they invented Timeline, which adopted the concept of ‘keyframe’ so you can make very complicated animation with it.

Though using such a powerful class to do a simply repeat job is like killing flies with a shotgun, it’s a viable way. Here is a example:

import javafx.animation.*;
import javafx.application.Application;
import javafx.event.ActionEvent;
import javafx.event.EventHandler;
import javafx.util.Duration;
import javafx.stage.Stage;

public class Ticker extends Application {
    private Timeline videoTick;

    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(final Stage primaryStage) {
        Duration duration = Duration.millis(1000 / 30.0);
        videoTick = new Timeline(new KeyFrame(duration, new EventHandler<ActionEvent>() {
            public void handle(ActionEvent actionEvent) {
                System.out.println("Tick");
            }
        }));
        videoTick.setCycleCount(Animation.INDEFINITE);
        videoTick.playFromStart();
    }
}

Compile and run above code with JavaFx in your classpath. Not surprisingly, you will see repeat Tick, Tick, Tick, one per line.

The next is the interesting part. You can ruin this program by modifying a single value. Guess which one it is?

Well the puzzle is somewhat easy because there are only a numeric value. Now change 30.0 to 30.1. Run and compile.

See? It doesn’t work anymore. If you don’t believe, please try it yourself with Java 1.7.0_21 or lower version.(According to this answer, it has been fixed in Java 1.8.)

It’s very bizarre to me, and I can’t figure out the reason yet. A very general-purposed class works with 30.0, 29.0 and 30.5, but runs like a cold corpse with 30.1 and 29.98? Could anyone explain this?

JavaFx, why are you so broken?

I just exported [my first libGDX game] as a Java Applet. Since I never made any Applet before, it took me several hours and I learnt several tricks from this process.

No, I’m not posting a step-by-step guide because someone has done it. This is just a memo recording the gotchas I encountered during porting my mini game to Java Applet.

  • Sign all jars your game uses. Not only your game itself(main jar), but also all the dependencies have to be signed. Typically it means lwjgl_util_applet.jar, gdx-backend-lwjgl.jar, gdx-backend-lwjgl-natives.jar. gdx-natives.jar and gdx.jar.
  • Keep your .keystore somewhere, and then you only need to resign main jar when you make a new version.
  • You don’t need a MENIFEST.MF in your main jar. Instead you set it in al_main attribute.
  • Put your (internal) assets in the jar. Not in a separate directory on your server. If you write Gdx.files.internal("assets/foo.png"), you should have exactly assets/foo.png in your main jar.
  • Use jar tf command to check what’s in your jar.
  • Set the second argument of LwjglApplet to true if you like to use OpenGL ES 2.0. Typically it’s been called by super from its derivative.
  • Host your Applet on a server, not in local file system to get around some permission issues. Of course you can also make your local machine a server with Apache or Nginx. Another way to work around this is to lower security level of your Java to medium, but it’s not recommended.
  • Take notice of your system status. Sometimes crashed Applets become undead processes and eat your CPU and memory.
  • Don’t add the dependencies into your main jar, especially when you’re using IDEA Intellij. If you choose Artifacts -> jar -> From modules with dependencies IDEA will add all stuffs in your main jar. It just slows down compilation and signing as you can specify depended jars in al_jars attribute.

Finally, you should realize the fact Java Applet’s an out of fashion platform. If possible, consider exporting your project to HTML5 via GWT.

[Play It]

Mini Arena is a game I made to get familiar with libGDX. Essentially it’s a old-school, retro-style strategy game. My initial target is to make a Fire Emblem parody.

Compared to the game engines I used, such as Unity and HaxePunk, it takes much more time to write a game with libGDX. After all it’s just a library, not an engine. The experience I gained, however, is very great and valuable. To some extent I made my own mini game engine(including event-driven and entity-component model).

Why did I choose libGDX, not MonoGame or Cocos2d-x? Well I hate C++ so Cocos2d is out. For MonoGame vs libGDX, you may take a look to my Reddit thread, where there are some opinions from people wiser than me.

According the Wikibooks, Scala has “the productivity associated with scripting languages”, and in my humble experience this is true. It brings the possibility to use Scala as you scripting language to automate daily chores.

Indeed, Scala main file(an object with a main method inside`) can be executed as a script. See this example:

#!/usr/bin/env scala
// In Clock.scala

object Clock {
  def main(args: Array[String]) = println(new java.util.Date)
}
$ chmod +x Clock.scala
$ ./Clock.scala
Sun May 19 10:34:13 CST 2013

Interesting, isn’t it? For one-shot script this property is very convenient. But if your script consists more than one file, and will be run many times on many different machine, you may want to package them into a jar. After all, Scala will never be as ubiquitous as Java Runtime.

Scala -> Jar

Thanks to sbt and its plugin sbt-assembly, this task can be done in a few minutes. First of all you need to install them.

Then, write a simplest build.sbt:

import AssemblyKeys._

assemblySettings

jarName in assembly := "Clock.jar"

name := "Clock"

version := "0.1"

scalaVersion := "2.9.1"

Test if sbt works well(the shaband line has to be removed before):

$ sbt run
Sun May 19 11:10:13 CST 2013
[success] Total time: 5 s, completed May 19, 2013 11:10:13 AM

Compile code and package your jar:

$ sbt assembly
[info] Packaging /Users/raincole/test/target/scala-2.9.1/Clock.jar ...
[info] Done packaging.
[success] Total time: 7 s, completed May 19, 2013 6:20:21 PM

Now it can run on machine with only Java but not Scala.

$ java -jar target/scala-2.9.1/Clock.jar
Sun May 19 18:27:20 CST 2013

Jar -> Exe

In most case a Jar file is good enough. But sometimes, for those Muggles who live in non-geek world, you had better provide an executable that guides them to download JRE if they don’t have one.

If you google “jar to exe” you will get many results, but most of them are outdated, hard to use or not even runnable. Fortunately I found one that works well and intuitively: Launch4j.

It provides a good GUI so you don’t have write configuration by hands. But if you prefer, the exhaustive doc is here.

To make an .exe, there are only three fields you must fill in GUI.

output file and jar pathJRE version

Then press gear icon on top. I can’t imagine how to make it simpler.

The biggest downside of using Scala as in a jar or exe is file size, because all Scala and Java standard libraries have to be packaged with your program. In fact, the simplest Clock program above occupies 9MB in your disk. So if all your target machines have Scala installed, it may be more efficient to run compiled .class files directly.

Folding is a puzzle game where you ‘fold’ a simple structure into a even simpler form. Precisely, a straight line or a loop. Though the concept is not complex, some puzzles may be trickier than you expected.

Try it and wake up your minimalist inside!

Post Mortem

Photo on 4-30-13 at 12.58 PM

What went right

  • Simple but concrete design.
  • Unique(as far as I know) mechanism.
  • Use computational geometry.
  • Did design on paper.

What went wrong

  • Use Haxe and Haxepunk. They are the kind of immature technique I will not want to use again.(at least in game dev)
  • Not enough instructions. Some players got confused at first.
  • Not enough visual feedback.
  • A little (minor) bugs.
  • Tried to go streaming but failed. FMLE slowed down my laptop too much so I had to close it.