Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon Join the GFS Discord Server!
12. November 2011


The new update should make the install process even easier. The process still works the same, just now with less annoying warnings and work around required.  Also, the Java (target) has been split out as an individual sub-project, a move which makes lots of sense.  I would describe why, but frankly the original author Michael Bayne did a good job already.

Howdy everyone,

I just released PlayN 1.0.1 to Maven Central (and the mirroring to the
public servers is complete).

This release corrects a bunch of pesky errors relating to building
PlayN that crept into the 1.0 release in the eleventh hour.

It should now be possible to import the PlayN sample projects and to
create a new PlayN project using the Maven Archetype without
encountering a single error or mysterious weirdness in Eclipse. I
would have liked to be able to say "warning or error," but annoyingly
my Eclipse complains that certain XML files lack a DTD specification,
which seems excessively anal to me, but that's how they like to roll
over there at Eclipse HQ.

One other important change was introduced in this release. The PlayN
archetype now generates a separate "java" submodule which contains the
Java backend entry point file (FooGameJava) and which has a dependency
on playn-java. The core submodule now only depends on playn-core.

Prior to this change, the core submodule depended on playn-java (and
by transitivity playn-core) and the Java entry point was in the core
submodule. This eventually causes problems, because all of the other
submodules (html, android) depend on the core submodule, and if one
added some Java-only dependency to their code submodule so that they
could use it when testing with the Java backend, it would show up in
the html and android submodules and cause problems. Now the core
submodule can remain "pure" with only PlayN-safe dependencies, and if
you need additional dependencies for your Java backend, you add them
to the java submodule where they won't cause problems with the other

Because the Java entry point is in a separate project, it is now
necessary to test the Java backend via Maven in a different way.
Instead of "mvn compile exec:java" in the core submodule directory,
one now invokes "mvn test -Ptest-java" in the top-level project
directory. This is more consistent with the way the HTML backend
works, so that's nice. It's also unfortunately a little slower, and
when you're rapidly edit/compile/debugging, every millisecond counts.
The "ant run-java" target still works great in this new setup, and
remains very fast, so I recommend that command line users use that to
iteratively build and test their project. Eclipse users will now "Run
As -> Java Application" on the mygame-java project instead of the
mygame-core project, but otherwise everything is the same.

Due to current-working-directory related issues exacerbated by the
creation of the java submodule, I rewrote the Java asset manager to
load assets from the classpath (robust) instead of loading them
directly from the file system (fragile). This means that you'll need
to make a change to your Java entry point. Where you probably had
something like:

    platform.assetManager().setPathPrefix("src/main/java/playn/showcase/resourc es");

you should now use:


As a fringe benefit, this was one of the main challenges preventing
the packaging of the Java backend up for use as a Java applet. Now
that this has been fixed, there are probably only a few niggling bits
that need fixing, and PlayN games can be deployed as Java applets by
anyone crazy enough to want to do so. :)

Also, for those of you using sound in your games, the Java backend
used to require that you maintain separate .wav versions of your sound
resources. The HTML backend used .mp3 versions of said resources. The
Java version has been updated so that it uses the .mp3 versions as
well, so you no longer need to maintain .wav versions of your sounds.
Sounds on the Android backend remain largely untested (meaning they're
probably broken), but when I get a chance, I'll make sure that they
also work properly with .mp3 files, so that things remain consistent
across platforms.

Between these and other small improvements to the archetype, it is
probably worth the small bit of trouble to regenerate your project
from the latest archetype, and move your sources and resources into
the new project, just to be sure that all the little fixes that have
made it into the archetype templates are applied to your project.
Alternatively, you could generate a new project using the latest
archetype with specifications equivalent to your project and then diff
the files that were generated against those in your project and
migrate any fixes you find into your project. Whether one or the other
is easier will depend on how much you've customized your poms.

The flash submodule has been completely disabled in the latest
archetype. If the Flash backend is made functional again, it will be


The other key things to note is the removal of the Flash target ( which was apparently quite a ways from ready for prime time, and was breaking the build ).  Anyways, good job to the PlayN team.


9. November 2011



Along with many others, I don’t really recommend C++ as someone’s first language for various reasons.  Sometimes concrete examples aren’t easy to come by off the tip of your tongue, so I figured the next time I encountered one of those things that make C++ so beginner unfriendly, I would post it.  Not the obvious stuff like memory leaks, dealing with the linker or exceptionally cryptic template errors, but the more benign stuff that add up to frustrate new and experienced users.  If you are a veteran C++ coder, you will probably spot the problem in a second or two, but this is the kind of thing that will trip up a beginner completely and is a complete nightmare to solve.



Consider the following C++ header file:


#pragma once #include "SFML/Audio.hpp" class SoundFileCache { public: SoundFileCache(void); ~SoundFileCache(void); const sf::Sound& GetSound(std::string) const; const sf::Music& GetSong(std::string); private: static std::map<std::string, sf::Sound> _sounds; static std::map<std::string, sf::Music> _music; }; class SoundNotFoundExeception : public std::runtime_error { public: SoundNotFoundExeception(std::string const& msg): std::runtime_error(msg) {} }



Pretty straight forward stuff right?  Two class declarations, nothing really funky going on.  Now consider the following implementation:


#include "StdAfx.h" #include "SoundFileCache.h" SoundFileCache::SoundFileCache(void) {} SoundFileCache::~SoundFileCache(void) {} const sf::Sound& SoundFileCache::GetSound(std::string soundName) const { std::map<std::string,sf::Sound>::iterator itr = _sounds.find(soundName); if(itr == _sounds.end()) { sf::SoundBuffer soundBuffer; if(!soundBuffer.LoadFromFile(soundName)) { throw new SoundNotFoundExeception( soundName + " was not found in call to SoundFileCache::GetSound"); } sf::Sound sound; sound.SetBuffer(soundBuffer); _sounds.insert(std::pair<std::string,sf::Sound>(soundName,soundBuffer)); } else { return itr->second; } } const sf::Music& SoundFileCache::GetSong(std::string soundName) { //stub }



Again, pretty standard code, ignore the fact GetSound and GetSong don’t return values, they aren’t the issue here.



Now consider the error:


error C2533: 'SFMLSoundProvider::{ctor}' : constructors not allowed a return type



If you are new to the expression ctor, it basically just shorthand for constructor. For the record, it’s Visual Studio Express 2010 and if you double click that error, it brings you to this line:


SoundFileCache::SoundFileCache(void) {}



So… what’s the problem?  By the error, it is quite obvious that the constructor doesn’t in fact return a value, so the message is clearly not the problem.



What then is the problem?  I’ll show you after this brief message from our sponsors… Smile







Welcome back… figured it out yet?  If not, I don’t blame you, the warning sure as hell didn’t help.  Here then is the offending code:


class SoundNotFoundExeception : public std::runtime_error { public: SoundNotFoundExeception(std::string const& msg): std::runtime_error(msg) {} } <-- Missing semicolon


So, forgetting a semi colon ( something you will do A LOT! ) results in a message that your constructor cannot return a value.  Now, once you’ve been coding C++ for a while this kind of stuff becomes pretty much second nature.  Getting nonsensical error messages?  Check your header for a missing include guard or semi colon become pretty much the norm.  But for a new developer, this is the beginning of a complete train wreck.




Think about if for a second, you just developed some of your first code, the error says you are returning something you aren’t, the compiler is pointing at your constructor and now you need to figure out just WTF is going on..  What do you do?  Many run off to a forum and post the error verbatim and hope for an answer ( which they will probably get, learning nothing in the process ). Hopefully you Google it using exact quotes, but even then you get forum answers like this where you have a bunch of other new developers fixating on the error message itself and leading the developer down a wild goose chase.  Fortunately a moderator stepped in and gave a proper explanation, but that doesn’t always happen.  Even worse, it is a legit error, you really can’t return from a ctor, so if you encounter it again in the future you may actually have a real problem but find yourself instead on a missing semi-colon hunt!




How would this work in Java, C#, Python or Ruby?  Well it wouldn’t, as no other modern language I can think of use header files any more.  For good reason too, they add a level of complexity for very little positive return.  It could be argued that separating interface from implementation is “a good thing”, but even that is munged up by the fact you can actually have you implementation in your header file.  Also don’t get me wrong, other languages have their faults too, just wait till you get forced to go on your first Java XML configured error hunt, you will be begging for C++ errors again!




This is just a classic example of the little things experienced developer forget the pain of experiencing in the first place!  As I said, once you’ve got a bit of experience this kind of stuff becomes second nature, but while you are learning this kind of error is absolutely horrific.  It’s little things like this that add up and make it so hard to recommend new developers start with C++.  When I say it isn’t pointers and memory management that make C++ difficult, I mean it.  It’s crap like this.


7. November 2011



Now that PlayN has been pushed into Maven Central, life and installation just got a heck of a lot easier.  Not that I appreciate their timing… couldn’t you have done this on Friday before I wrote an installer! Winking smile



I will cover two ways to create a PlayN project.



Using Eclipse to create a new PlayN project



Load Eclipse.  If you haven’t already, install the JDK and Maven m2e plugins, which are described in this thread.


Select File->New->Other…






Scroll down and select Maven Project in the Maven folder. Click Next.





Click Next again, if you don’t want to change the Workspace that is.





In the “Filter” type Playn, then select com.googlecode.playn.  Click next.






Now fill in your game details.  There is a small bug in Eclipse in that the Finish button will not be available until you click focus away after filling in the gameName value.  Once you fill that in, click somewhere else on the dialog and the finish button will be enabled.  Click it.






Your game will be created, but you might get an error like I did:  Notice the red x by the testGame-android?





If you look down in the problems section, you will see details off the error:





Fixing this is pretty straight forward.  Right click each one and select, appropriately enough… Quick Fix.  Do that for both errors.





In the following dialog, select “Permanently mark goal…” then Finish.  Another dialog will pop up, simply click OK.  You may ( I did once, and not the second time ), get another error along the lines of your project needs synchronization.  Simply Quick Fix it as well.


Now right click your game ( root class as in “YourGame” not “YourGame-core” ), choose Run As->Maven Install.





Sadly, I am currently getting this error still, with the Flash build being broken:





As a temp work around, open pom.xml from your root project, find Flash in the modules section and remove it.





After removing it, you get that error I mentioned earlier.  Simply right click and select Quick Fix.




When you do, this dialog will appear.  Select all then click Finish.




And you are done.  The process is actually quite a bit easier than it looks, and if it weren’t for the few incompatibilities, it would be flawless.  Regardless, it is a much nicer process than before!


You can now run your project, for example, right click yourproject-core and choose Run As->Java Application.  Scroll down and select your main:




And there is your game running in Java!






All told, the process takes about 3-5 minutes, a very reasonable amount of time.





Using Netbeans to create a new PlayN project


Now we enter the ( in my opinion ) much nicer land of using Netbeans instead of the hateful Eclipse.  As you will see in a second, this process is an absolute joy!


Load up Netbeans.  I am using the 7.1 beta, but other versions should be similar enough.


Select File… New Project:





Select Maven, then Project From Archetype, click Next.





In the New Project dialog, click Add:




Fill in as follows, then click OK




Back in the New Project Dialog, select your newly added archetype and click Next.




Fill the next screen in like follows.  Make sure you fill in a value for newGame and click somewhere in the dialog to make sure it takes.   Then click Finish.




NetBeans will churn away for a minute while it creates your project and voila!





Right click your project Core and choose Run.  In the dialog that pops up, choose your main class ( there is only one ), then Select Main Class.




And voila:





To fully build your project, you need to right click MyProject MetaProject and choose Build:




And a familiar problem arises:





Same solution too.  Under your metaproject locate pom.xml





And remove this line:





Once you edit that line and save, right click->  Build your meta project again.  This time everything should work fine.



Can you tell why I prefer NetBeans over Eclipse any day?


7. November 2011

In one of those all time "my timing sucks" moments, Google's Fred Sauer just announced PlayN 1.0 was just added to the Maven repository, which makes the install process a few orders of magnitude easier to get up and running.


When I get off a tablet and back to a computer, I will document the process... it will be a short document, the process is now a heck of a lot easier.  It's a mix of ahh crap, since I just finished my installer and great news as frankly the process needed to get easier.


6. November 2011



Hmm, kinda realized I missed this part in my recent PlayN installer post.  After you go ahead and create your game, it creates a new project hierarchy and… then what?  This post shows the various ways you can start your game.


Assuming you used my installer to install PlayN, you can run your game from the command line using the following steps.  I will assume your game’s name was “mygame” in these examples and that you installed to c:\playn.




Running the desktop Java app with Maven



cd playn\playn\mygame\core

..\..\..\maven\apache-maven3.0.3\bin\mvn install compile exec:java



Running the HTML target with Maven


cd playn\playn\mygame

..\..\maven\apache-maven3.0.3\bin\mvn package  ( wait, this takes a bit )

..\..\maven\apache-maven3.0.3\bin\mvn –Ptest-html


This will currently through a bunch of errors in your face since the Flash build seems to currently be broken, ignore them.  Once you run that second command, a web server Jetty will be downloaded and installed.


Now open a browser and go to http://localhost:8080 to see your game running in a browser.


When done, you can use CTRL+C in the dos window to get Jetty to stop.


Running the Flash target with Maven


You can’t, it’s currently broken, I’m looking into it and will update with details or a fix if possible.


Running the Android target with Maven


This process is a bit too involved and requires other steps ( like configuring the emulator or a physical device, which we didn’t do during the initial install.  I will cover this in detail in a later post.


There is a problem in that the fact Flash is broken, and before Android in the build order, your Android target will never be built!  This can easily be fixed by opening pom.xml in your game folder and remove the line <module>flash</module>.


Running the Java and HTML targets with Ant


If you have Apache ant installed, you can also use it to run Java and HTML targets. Currently you cannot run Flash or Android this way.


Running desktop:

cd playn\playn\mygame



Running HTML:

cd playn\playn\mygame

ant run-html


Just like with Maven ( but a whole lot quicker ) it runs Jetty and you can reach your website using a browser.  However, unlike the maven install, for some reason the ant install is in a subdirectory, so your URL is http://localhost:8080/mygame.



Of course, if you are using an IDE like Eclipse or NetBeans, they can automate many of these tasks.  If you add Maven’s bin folder to your PATH variable, it will save you a ton of typing.  Of course you could also make a simply script to run your game in a much more terse syntax.


See More Tutorials on!

Month List