Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
30. November 2015

 

 

 

This entry in the Closer Look series is a bit different than normal.  First, Blade Engine is very much a work in progress, so expect bugs and flaws and minimal documentation.  Second, it’s actually built over top of an existing game engine, LibGDX.  Finally, it’s a game engine focused on one very specific genre – adventure games.  Given the popularity of hidden object games on mobile these days, there are no doubt a number of people looking for an appropriate engine.  So without further adieu, I present the Bladecoder Adventure Engine, an open source cross platform LibGDX based game engine and editor for creating adventure games.

image

As always there is an HD video version available here.

 

Meet Bladecoder Adventure Engine

 

Blade engine consists of two parts, the underlying game engine and the editor that is layered on top of it.  It is designed in such a way that you can work entirely in the editor and never once right a line of source code.  You assemble your game from a collection of Chapters, Scenes and Actors and added events and actions in the form of verbs.  If you want to modify the fundamental structure of the game itself, you are going to have to jump into the underlying source code.  Fortunately that is an option, as Bladecode Engine is hosted on Github and the source is available under the incredibly liberal Apache 2 license.

 

Blade Engine Features at a Glance:

  • Multi platform support: Android, IOS, Desktop (Windows, OSX, Linux) and HTML
  • Several animation techniques: sprite/atlas animation, Spine (cutout) animation and 3d model animation
  • 3d character support
  • Multiresolution to deal with different densities and screen sizes
  • Multilanguage support
  • Open source and free (as in beer and freedom)
  • Code free game creation possible

 

The heart of Bladecoder is ultimately the editor, so let’s focus there after we cover getting started.

 

Getting Started

 

To get started with Bladecoder you need to have Java and git installed and properly configured.  Bladecoder uses the JavaFX ui library so you will have to use JDK 8 or newer or be prepared to have to configure JavaFX manually in the build process.  You will also require an internet connection for the build process to succeed the first time. To start, from a terminal or command line, change to the folder you want to install Bladecoder and enter:

git clone https://github.com/bladecoder/bladecoder-adventure-engine.git

cd bladecoder-adventure-engine

gradlew build

gradlew run

 

There is an example repository, including the work in progress game The Goddess Robbery available in the repository https://github.com/bladecoder/bladecoder-adventure-tests.  You should probably clone this repository too, as this is perhaps the single biggest documentation source available right now.

 

The Editor

 

Assuming the compilation process went without issue above, you should now see the Adventure Editor, where the bulk of your work will occur.

image

 

Your game is composed of a collection of Chapters, which in turn contain Scenes.  Scenes in turn are a collection of Actors and organized in layers:

image

 

Game Props enables you to set global properties of your game:

image

 

Resolution enables you to quickly create scaling modes for supporting multiple device resolutions ( think Retina ):

image

 

While Assets enables you to import multiple defined assets include audio and music files, texture atlases, 3D models, images and more.

image

 

You organize your scene using the editor available in the center of the window:

image

You can place actors on different layers, define walk paths, etc.  Click the Test button to preview that scene in action.

 

The actual logic of your game is defined on the right hand side of the editor. 

Here you can set properties of your actors:

image

 

Create and edit dialogs:

image

 

Define sounds and animations:

image

 

Clicking the edit icon will bring up the appropriate editor:

image

 

While selecting an animation will preview it in the scene:

GIF

 

Finally Verbs are the heart of your application:

image

 

You can think of verbs an analogous to event handlers, and they can be applied at the world, scene or actor level.  There are also default verbs that will be fired if unhandled.  Think the generic “I don’t know how to use that” messages from adventure games from the past.

 

Let’s look at an example from the Scene, handling the Init verb which is fired when the scene is ready.

image

 

This verb causes the sequence of actions shown at the bottom part of the above image to be fired when the scene init verb is called.  This causes the player to move, a dialog sequence, the player is scripted to drop an item, a state value is changed, etc.  You can create new elements by clicking the + icon:

image

 

And filling out the resulting form.  Each element has a different form associated with it.  Here for example is the result of the Say element:

image

 

Once complete simply click the play or package button:

image

 

Play launches the standard loader:

image

 

This screen can obviously be customized to each individual game.  While package brings up a form enabling you to build your game for a variety of platforms:

image

 

And that essentially is it.

 

Help and Community

This is certainly a weak point of the Bladecoder engine, it’s the result of a single coder, there is minimal help available and if you don’t know how to debug Java code, you will probably end up in trouble, at least at this point in it’s lifecycle.  There is currently no community or forum available for this engine but perhaps that will change in the future.  I spoke with the developer a few times however and he was very responsive and quick with fixes and answers.  He is also on twitter at @bladerafa if you want status updates on the project.

For now documentation consists of a minimal wiki although for the most part the best source of documentation is going to be from following the examples.

 

Summary

Make no mistakes, this is very much an under development engine so expect things to blow up spectacularly at any time.  When it does, you are probably going to be on your own figuring out why as there is no community to fall back on.  All that said this is a surprisingly robust tool that makes the process of creating an adventure game exceedingly simple.  Once the engine matures a little bit it will be an excellent tool for even a non-programmer interested in making adventure games.  For now though if you are competent in Java and interested in making an adventure game, this engine takes care of a hell of a lot of work for you and provides full source code for when it doesn’t.  Plus at the end of the day, the price is certainly good too!

 

The Video

Design Art Programming


25. November 2015

 

With the upcoming LibGDX jam, it dawned on me I hadn’t done anything with LibGDX in a while.  I decided to look into doing a mini game series in advance of the Jam and decided it was a good opportunity for me to look into the Kotlin programming language.  Ironically a day later, RoboVM and IntelliJ announce a Kotlin code competition… stars aligning I suppose.

 

So I decided to start with Kotlin-afying a LibGDX project and see how the process went.  This tutorial is the result of that experience, although to be honest calling it a tutorial is a bit of a joke as the process was amazingly simple.

 

Before we begin there are a couple of things you are going to need:

 

Open the project in IntelliJ just like normal with a Java application.

In your project, in core create a new Kotlin file beside your main class like so:

image

 

That’s one of the cool things about Kotlin, it can exist along side existing java sources.  Once you create the Kotlin file, this popup will be shown:

image

 

Click the link and let it configure as a Kotlin module. Defaults are good, click OK.

image

 

Now this part is impressive and I discovered it by accident.  Open your existing .java file and copy the contents, then paste them into your newly created kt file.  When prompted, let it convert the Java to Kotlin code:

image

 

Now the default project will be converted to Kotlin, but there will be a pair of errors:

image

 

Kotlin does not appear to like unallocated variables.  There are a few options here.  You can move the initialization of batch and img to the KotlinDemo constructor, you can default initialize them to null (this will however cause LibGDX to explode, so not recommended ;) ) or you can add the lateinit modifer, which is the route I went.  Here is the resulting code:

package com.gamefromscratch

import com.badlogic.gdx.ApplicationAdapter
import com.badlogic.gdx.Gdx
import com.badlogic.gdx.graphics.GL20
import com.badlogic.gdx.graphics.Texture
import com.badlogic.gdx.graphics.g2d.SpriteBatch

class KotlinDemo : ApplicationAdapter() {
    internal lateinit var batch: SpriteBatch
    internal lateinit var img: Texture

    override fun create() {
        batch = SpriteBatch()
        img = Texture("badlogic.jpg")
    }

    override fun render() {
        Gdx.gl.glClearColor(1f, 0f, 0f, 1f)
        Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT)
        batch.begin()
        batch.draw(img, 0f, 0f)
        batch.end()
    }
}

Congratulations, you’ve just created your first Kotlin application!  The mix and match nature enables you to slowly port your code over to Kotlin making the transition exceedingly easy.

Now there is one last very important step, we need to delete the original .java class. 

image

 

When you delete it, you want to make sure you don’t do a smart delete, as we want the existing references to this class to remain (as our Kotlin class is replacing it):

image

 

I’m going to continue to play around with Kotlin, so expect more coverage over the next few days/weeks.  Let me know what you think of Kotlin… any interest?

Programming


22. November 2015

 

As per this blog post the first ever LibGDX game jam is happening in mid December and topic voting has begun.  From the announcement:

image

The 10 Rules of Jamming

  1. You must use libGDX to create a game that fits the theme
  2. You may work alone or in a team. Only one submission per person/team is allowed
  3. You may use pre-existing code, e.g. libraries like Ashley, or your own code libraries
  4. You may use pre-existing art, e.g. assets from OpenGameArt, or your own art
  5. You may use external tools like Tiled or Overlap2D
  6. You must not re-skin an already existing game or prototype!
  7. You must submit your game before the end of the 18th of January via the jam’s site on itch.io (to be made public :))
  8. You must publish the source of your game, e.g. to GitHub
  9. You must submit your game to the itch.io libGDX Jam page before the end of day January 18th, UTC-12!
  10. If you want to win one of the sponsored prizes, you must tweet about your game and document its development, using the hashtag “#libGDXJam” and the handles “@robovm” and “@robotality

Prizes & Judging

We are happy to have RoboVM and Robotality as sponsors for the following prizes:

  1. Grand Prize: Mac Mini, sponsored by RoboVM
  2. Silver: iPad, sponsored by RoboVM
  3. Bronze: iPod Touch, sponsored by RoboVM
  4. For 20 random submissions: Steam keys for Halfway, sponsored by Robotality
  5. For another 5 random submissions: libGDX Jam t-shirt, by yours truely

To qualify for any of the prizes, you’ll need to follow rule 10 as outlined above. Judging works as follows:

  • The community can vote on itch.io from the 19th of January to the 2nd of February
  • The Grand Prize will be awarded to the entry with the highest community votes on itch.io. This way the highest quality entry will win!
  • The Silver and Bronze prizes will be awarded to the entries with the best mixture of dev logs and tweets and community votes. Our sponsors and the libGDX core team will pick these entries. This should motivate people to make some noise on the web and document their progress for the greater good of the community!
  • The random awards guarantee that everyone has a chance to win a prize!
  • The winners will be announced on the 3rd of February!

To view suggested comments and to cast your vote, head on over here.

GameDev News


23. October 2015

 

If you are a LibGDX developer or even a Java developer hoping to target iOS some pretty big news just happened.  In a nutshell Xamarin acquired RoboVM (more details here).  If both of those names are meaningless to you, here’s a quick rundown.

 

Xamarin are ultimately the company formed around Mono, which is the open source cross platform version of Microsoft’s .NET framework.  That’s actually simplifying their history a fair bit.  Many years ago they were a company called Ximian, and their big push was trying to make Linux on the desktop happen and part of that process was the Mono project.  In between they were purchased by Novell, Novell blew up in spectacular fashion and from the ashes Xamarin was born.  Of perhaps most interest to game developers, Xamarin developed the technology that Unity is built on top of.  In fact, if you are working in a C# based game engine ( MonoGame, WaveEngine, Paradox, etc ) chances are it requires a Xamarin license to target iOS or Android.

 

RoboVM on the other hand are a much smaller developer that provide a very similar product, just targeting Java instead of .NET.  Basically RoboVM provide an iOS runtime for Java applications, enabling you to run Java apps pretty much unchanged on iOS.

 

So, why do we care?

 

Well first off, RoboVM is the technology that LibGDX depends on for iOS deployment, ironically chosen while moving away from Xamarin years ago.  In many ways, RoboVM owes it’s success and existence to the libGDX community.  In fact, the LibGDX founder Mario Zechner started working for RoboVM about a year ago.  Note, working for…  it isn’t his company, something far too many people seem to miss these days.

 

Fast forward to recent history…

  • RoboVM is now owned by Xamarin
  • the core of RoboVM, the Ahead of Time (AoT) VM is no longer open source
  • the pricing is much less indie friendly

 

So basically a core component that LibGDX depends on to support iOS just became closed, more expensive and owned by a company that doesn’t really seem to get game developers.  This all in a world where people don’t expect to ever pay for anything… although that’s certainly a conversation for a different day.

 

To Mario/RoboVM’s credit, they have offered a free license option for LibGDX developers.  You need to apply for the license, have a development team limit of 3 developers and need to activate the license on your build machines with a machine count limit attached to the license.  Of course it also adds the pain of dealing with a license were there previously was none.  The one silver lining in all of this is you get debugging support including in this license, something that was previously a paid feature.

 

At the end of the day, what exactly does this mean for LibGDX developers?  Well you are now basically in the same boat as C# developers.  To support certain targets you now have a pay wall in front of you.  Of course the current license offer will mitigate that for many existing LibGDX developers but how that actually turns out is yet to be seen.  With that license offer in place, LibGDX devs are still in a better place than most MonoGame/Paradox/et al developers out there, to say nothing of the fact there is no added cost to support Android.  They are however certainly in a worse place then they were before.

 

I’m not going to lie and say this development is great news, it certainly isn’t.  It however isn’t the end of the world scenario many are making it out to be.  If enough community demand exists, they can pick up the code for RoboVM and run with it.  Or port to another Java on iOS solution such as Codename One or Avian.  Or explore a different approach entirely like Unity are moving toward.  Of course they could also take the path of least resistance and keep working with RoboVM.

 

There are however two meta-points I want to mention here.

 

First off, no matter how much this affects you personally, some of the reactions I have seen to this have been downright off putting.  The amount of heat Mario has taken over something that is basically beyond his control is just sickening.  It really makes one wonder why people would even contribute to an open source project in the first place.   Now caustic end users in an open source is nothing new, but it’s always disgusting to witness.  Now Mario is a big boy and is handling fine so far as I can tell, but really ask yourself… if you had to put up with this crap, would you bother donating your time anymore?

 

Second, Xamarin, if anyone from that company happens to be reading this, I hope the entire experience is an eye opener.  When the entire indie game development industry looks at you at best as a necessary evil, at worst as the devil, it’s time for some introspection.  Part of that relates to the above paragraph… people are horrifically over entitled these days and the thought of having to pay for anything is galling.  Ignore this crowd, there isn’t much you can or should do.

 

On the other hand, with a more reasonable licensing, you would have a much larger community of advocates and I have to assume greater profits.  Your legacy as a tool vendor to corporations really shows in your pricing model.   Heck, look at LibGDX for example… they were using RoboVM in the first place to avoid you!  If you followed the Unity or Unreal model of geared to income licensing then suddenly your products would become much more appealing to a much larger segment of the population.  Your license fees are a bitter pill to swallow for a hobbyist looking to release a free title, while someone who was commercially successful would probably be willing to pay a greater amount.

 

At the end of the day this isn’t a story that is going to play out in a single day.  There is an active discussion and more information on the LibGDX forums that I think is the ideal place to discuss things.  Just keep the personal insults out of it.

 

EDIT: One major concern people had with the license granted for LibGDX developers was how long it would be valid.  I just had the following conversation with Nat Friedman (CEO of Xamarin) on Twitter:

temp

 

Other very interesting things related to Xamarin licensing were discussed, which I will be putting in a separate post.  This announcement is very relevant to LibGDX developers however.

News


23. September 2015

 

LibGDX, the cross platform, Java based, open-source game development library just released version 1.7.  I have to admit, not the most exciting release notes ever mind you…

 

image

 

[1.7.0]

- Gdx.input.setCursorImage removed, replaced with Gdx.graphics.setCursor and Gdx.graphics.newCursor see https://github.com/libgdx/libgdx/pull/2841/
- Fixed an issue with UTF8 decoding in GWT emulation of InputStreamReader
- Updated to RoboVM 1.8 for iOS 9 and Xcode 7 support 

If you have a game on the iOS App Store, make sure it works on iOS 9. If not, recompile with RoboVM 1.8 and Xcode 7 and resubmit it to the App Store!

Update your project as usual. Also update your RoboVM Eclipse or IntelliJ IDEA plugin to 1.8.0!. If you are on a Mac, consider using RoboVM Studio. It will take away all the setup pain for you

Happy coding!

 

If you are interested in learning more about LibGDX, GameFromScratch.com has two comprehensive tutorial series for you, one in text, the other in video format.

 

RoboVM Studio is something I very  much have to check out.  It’s basically a fork of IntelliJ 15 with the RoboVM stuff preinstalled and preconfigured.  As IntelliJ is my Java weapon of choice, next time I am working with iOS i’ll have to give this a go.

News


AppGameKit Studio

See More Tutorials on DevGa.me!

Month List