Recent Comments

Archives

Categories

Meta

Tag: libGDX

Since we are heavily relying on the amazing game development framework libGDX, we will post a short review about the “Libgdx Cross-platform Game Development Cookbook” by David Saltares Márquez and Alberto Cejas Sánchez which has lately been released.

General

Being a “cookbook” it is structured in small chapters (socalled recipes), that may be read or looked up individually. This is particularly handy, if you are no beginner, but have a good understanding of most topics and just want to read through some certain chapters.

Unlike a lot of other sources about libGDX, this book is up to date! For example, it covers the gradle build system to build your libGDX projects, as well as Viewports to handle different resolutions and aspect ratios. Both features were introduced in early 2014.

A negative aspect: When reading it, the book looks a bit cluttered. The many different ways of formatting on a single page make it a bit difficult to read. However, that might be because of the high degree of “compactness” of this book. It jumps directly into action, delivering a constant stream of how tos, hints, warnings and facts in the form of code listings, notes, lists (and many others…).

Content

It delivers hands on practical tips about common problems that might happen, even when it’s just about the tools, like the IDE, you are using. The experience of the authors working with libGDX is really noticable.

Furthermore it covers some topics, like git and gradle, that are not directly related to libGDX, but will tremendously help using it and working with it, especially if you are planning to contribute to libGDX yourself.

The book also describes commonly used tools like the 2D Particle Editor, Texture Packer (GUI), Hiero, Gradle Setup UI etc. that come with libGDX. Those will help with a basic game development workflow.

Another slightly negative aspect: It covers some basic information that other sources like the wiki also cover. One example is the File API or the Box2D API. That makes the book more suitable for beginners as a single source of information to get started with LibGDX. However it results in some advanced topics being missing, like the 3D API which certainly would have been worth a chapter or even two.

The chapter “Third party Libraries and Extras” partly makes up for that though. It introduces some tools, extensions or related frameworks and libraries that go well with libGDX and are not part of the framework core.

Conclusion

In total, it is worth buying it, especially if you are a beginner. But even for advanced libGDX developers this book will still be useful and reveal some unknown secrets, tips and tricks about game development with libGDX. You can buy it here.

Since not everyone has easy access to the libGDX sources and is able to build or run the tools that one needs, we’ll keep a list of the most important libGDX tools here in form of a runnable / precompiled .jar file.

To run these, just double click the file (should work on most operating systems), or start it via the command line:

By default, libGDX does not perform any kind of culling when rendering models via the ModelBatch. This blog postby @xoppa shows how it can be implemented with game logic specific knowledge. That means it is not generic and can make use game specific information, because the models will be culled before they actually reach the ModelBatch.

However, we have tried a more generic approach by extending ModelBatch and implementing culling right here and there. The following CullingModelBatch is optimized for speed, but also has some limitations:

Easy to activate culling just by replacing your standard batch with this one

Lightning fast

Because of the sphereInFrustumWithoutNearFar test

Because of the caching mechanism

Because of the Mesh check instead of the MeshPart check

Cons:

Does not work with animations

Can produce false positives (not everything that could be culled, will be culled)

Because of the sphere check

Because we check the whole Mesh and not the rendered MeshPart

Small memory footprint

The memory overhead of this approach might very well be neglected. In total it is a trade-off between CPU processing time and GPU rendering time. To get more accurate results one might replace the sphere check with a bounding box check, or check the actual MeshPart of the renderable instead of the complete Mesh.

This apprach might not produce the optimal results, but it is a very quick solution which you can try just by replacing new ModelBatch() with new CullingModelBatch() in your game. In many games this might very well be sufficient because it does get rid of a lot of models very quickly and in our upcoming game Pocket Galaxy it was completely sufficient.

Yesterday the libGDX pull request 2005 has been merged into the core. It contained a whole new 3D particle engine made by @lordjone.

There is no wiki page yet, but that will change soon. For now you can see how to use it in the ParticleControllerTest. The result of that looks like this:

Beautiful! Feel free to grab the editor from below, try it yourself and share your effects!

The editor

It did not only contain the 3D particle engine itself though, but even an editor to create and preview different particle effects. A runnable JAR file of the editor called Flame can be downloaded here. It can either be run via a double-click on the file in most operating systems, or on the command-line via the following:

The SlotTooltip

The SlotTooltip is a Window itself. In contrast to the inventory, it does not have a button to close. Furthermore it displays the amount of items and the item name in the title bar. The content area could display anything, but to keep it simple, it will be just another dummy Label with some text. It’s also a SlotListener and will get notified when a slot changes. According to the new state of the slot, the tooltip will hide itself when the slot is empty.

Making the tooltip follow the cursor

The following listener will be attached to every SlotActor and will activate or disable the tooltip when the mouse hovers over a certain slot. It will also hide the tooltip when the mouse is not hovering anymore. Furthermore it adjusts the tooltip’s position based on the movement of the mouse cursor.

Compared to the other parts of this series, this one will contain less code, but will add a lot of functionality! We will make the inventory interactive by making the items draggable.

The DragAndDrop class

Drag and drop functionality is usually always avoided since it is very difficult to implement. LibGDX on the other hand provides a neat little class to handle it: DragAndDrop. Unfortunately there is not much documentation about it besides the JavaDoc and this test.

Basically a DragAndDrop handles all you need for the input processing like hovering, clicking and dragging. All one has to do, is define Targets and Sources. A Source can define a Payload, which can be any Object. In our case this will be a Slot.

The SlotSource

With the above description, understanding the following code should be a piece of cake!

Putting it all together

For now we have just defined some classes, but we haven’t actually used them yet. In the previous parts of this series, there have already been some places where those classes were used, but it wasn’t clear yet what they did.

The following was found in the constructor of the InventoryActor and creates a SlotSource and a SlotTarget for every slot.

In this part II of our inventory tutorial series we are going to create the actual UI for our Inventory and Slots. LibGDX offers us some basic functionality for UIs, namely scene2d.ui. In case you are not familiar with it yet, you should probably read this article first.

The SlotActor

In part I of this series, we have seen how a Slot looks like. Now we have to render this slot somehow. To do so, we are going to create a SlotActor which is an ImageButton itself, and which displays the TextureRegion of the Item.

As always, read the code carefully and also check the comments within. It should be pretty self-explanatory.

The InventoryActor

To display the Inventory, we are going to create a new Window which can be dragged around by default. For each Slot of the Inventory, we are going to create a new SlotActor, which we’ve just seen in the previous paragraph.

public class InventoryActor extends Window {
public InventoryActor(Inventory inventory, DragAndDrop dragAndDrop, Skin skin) {
super("Inventory", skin);
// add an "X" button to the top right of the window, and make it hide the inventory
TextButton closeButton = new TextButton("X", skin);
closeButton.addListener(new HidingClickListener(this));
getButtonTable().add(closeButton).height(getPadTop());
// basic layout
setPosition(400, 100);
defaults().space(8);
row().fill().expandX();
// run through all slots and create SlotActors for each
int i = 0;
for (Slot slot : inventory.getSlots()) {
SlotActor slotActor = new SlotActor(skin, slot);
add(slotActor);
// this can be ignored for now and will be explained in part III
dragAndDrop.addSource(new SlotSource(slotActor));
dragAndDrop.addTarget(new SlotTarget(slotActor));
i++;
// every 5 cells, we are going to jump to a new row
if (i % 5 == 0) {
row();
}
}
pack();
// it is hidden by default
setVisible(false);
}
}

Closing the inventory

This is actually pretty easy. In the previous code you could already see that we added a HidingClickListener to the button to close the window. Its only purpose is to hide a given actor on click.

Next

In this part, we have created a basic UI for our inventory and slots. But we cannot do much with it yet. In the next part we will see how to make that inventory interactive by adding drag and drop functionality!

This part of the inventory tutorial series is about the base classes to handle the logic, store the inventory information and manage them.

The Items

First we need to define what an Item is. For us it is just an enum. Additionally the enum has a String value which is the name of the TextureRegion in our TextureAtlas with all icon textures. The atlas files can be checked out here.

The slots

To support stacked items, our inventory Slots won’t only have an Item type, but also the number of items. The class itself is pretty simple as it only manages those two variables with an add(...) and take(...) method. What the SlotListener does is described in the next paragraph.

Many games are in need of a UI for an inventory. So does our game Pocket Galaxy and that’s why we thought to share our solution with you.

Our inventory basically offers the following features:

Inventory is placed in an extra window

Grid-based layout

Random amount of slots

Icons are displayed for the items

Items can stack

Tooltips with additional information

Items can be moved around via Drag and Drop

It’s possible to define valid and invalid targets

Especially the point about drag and drop might scare many people, since that’s usually a lot of work, but with LibGDX and its scene2d framework (and the DragAndDrop class) it’s a piece of cake. The last point on the list means that you are even able to use this to drag and drop items (for example armor/weapons) on a character slot to activate those, or to an action bar with hotkeys, or into a crafting grid like in minecraft.

The end result might look like this, but can easily be changed with another Skin.

2D user interfaces in a 3D environment are something pretty cool. Probably the most well-known game for utilizing UIs in very immersive way is Dead Space.

Another possible application of this are ingame computer screens with minigames, or menus.

How can anything like this be achieved with LibGDX? That’s super easy!

UIs in LibGDX are usually made with the help of a Stage and Actors. The scene2d.ui package offers a bunch of useful widgets like Label, Button, ScrollPane and many more. But by default those will be drawn with an OrthogonalCamera into the X/Y plane.

Now how to get those in a 3D enironment? We just replace the camera! See this forum thread for NateS original post about that.

Another problem is that clipping (which is done via the ScissorStack) won’t be correct anymore, due to the new perspective. That might look like the next picture. Note that it doesn’t look like it, but it’s actually a rectangle which has been cut out because of the clipping.

By default clipping is used for all widgets that are based on Table. Some of them need clipping, for example the ScrollPane, but a Window usually doesn’t. As a quick workaround for that problem it is possible to disabled clipping on all widgets via setClip(false).

The end result could look like the following. The camera is controlled via a CameraInputController. Notice that the input is perfectly accurate.