11 Dec

DragonScales 6 game: Solution for Level 5-8

Some players of the latest DragonScales game, DragonScales 6: Love and Redemption, have reached out to us asking about a solution for Level 5-8. That level might seem a bit intimidating at first look, but once you figure out the little tricks for several parts of the board you’ll agree it’s kind of easy. Let’s take a look at the initial configuration of the board.

DragonScales 6 game initial configuration of Level 5-8
Initial configuration

A typical DragonScales board. We have two goals only: capture the red and the green cross-scales. There are some novelties, though, specific to DragonScales 6: keys and doors. Cells with a door icon won’t accept scales on them, so you’ll first have to remove the doors. That means you won’t be able to clear the top-left red cross-scale, or the green cross-scale or activate the arrow until you manage to remove the respective doors. To remove a door just click on it, but you’ll obviously need to capture at least one key beforehand. To capture a key, just form a combination containing the cell with the key.

Read More
08 Dec

Inversion of Control in Software Engineering

What is Inversion of Control in Software Engineering?

Inversion of Control in Software Engineering (IoC) is essentially a strategy for decoupling software components. Basically, the purpose of IoC is to remove unnecessary dependencies (couplings) which might reduce flexibility and elegance of a system’s design. The term Inversion of Control in Software Engineering might sometimes appear applied to different design contexts. It is a term that comes from the 70s, when bottom-up parsing was considered an inversion of top-down parsing. It has roughly continued to be applied in multiple contexts. Some people think Inversion of Control in Software Engineering is a design strategy. For others, it’s a design pattern. After some articles dealing with OpenGL, in this post we will briefly discuss this topic of Software Engineering.

Read More
04 Dec

Render a Triangle with OpenGL

This post will discuss how to render a triangle with OpenGL. In the following, renderization of a triangle assumes modern OpenGL, i.e., the old, fixed-function pipeline is of no concern for us in this post, as we’ll be using OpenGL buffer objects and shaders.

A Simple Triangle

By following the tutorials in the previous posts (Setting up Eclipse CDT for OpenGL and the GLFW Example) we were able to create a minimal program displaying an empty window. Now we want to draw something with OpenGL on that window, specifically, a triangle. Why a triangle? Well, the geometric shape more frequently used to approximate surfaces is the triangle. Approximation of 3D surfaces in real-time graphics by means of simpler shapes is known as tessellation. For our tutorial purposes, a single triangle will suffice.

GPU Power

Modern GPUs are quite fast and can also have a considerable amount of dedicated memory. When rendering, we’d like for as much rendering data as possible to be read by the GPU directly from its local memory. In order to render a triangle with OpenGL we’ll need, obviously, to transfer the 3 vertices of the triangle to the GPU’s memory. However, we do NOT want our rendering to go like this:

  • read a vertex from our computer RAM
  • copy it to the GPU memory
  • let the GPU process that single vertex
  • and then repeat this whole process for the next vertex of the triangle.

Ideally, what we want is to transfer a batch of data to the GPU’s memory, copying all the triangle vertices, and then letting the GPU operate with this data directly from its local memory. In OpenGL we have the concept of Vertex Buffer Object (VBO) to represent these data placed on GPU’s memory.

The data to render the triangle in OpenGL

Normally, we think of a vertex as a point, which in 3D space leads to a representation with 3 coordinates, commonly designated by x, y and z. However, in this case I’d like to think of a vertex as a more abstract concept: a minimal data structure required to define a shape. Given a vertex, we can “link” attributes to it to further define our shape. Thereby, one of such attributes of a vertex can be its position (the “x, y, z values”.) Other attribute might be the vertex’s color. And so on. In this tutorial we will “link” two attributes to our vertices: position and color. For position we will have three coordinates, each a floating point value. If a float takes 4 bytes, then our position attribute would require 3 x 4 = 12 bytes. For the color attribute, we’d have 3 extra components, following the RGB model. Each color component would then take 4 bytes, and the color attribute would also require 12 bytes. In total, each vertex would take 24 bytes, 12 for its position attribute, and 12 for its color attribute.

Now we have to specify how to process these vertices.

Read More
03 Dec

GLFW Example

Here I’ll briefly discuss a tiny GLFW example. Previously, I explained how to setup Eclipse CDT to work with OpenGL, using GLFW and GLAD. However, I instructed to copy-paste the example code on GLFW Documentation page, without providing any details. In the following I’ll present some code that you can add to the little project of our setup post, and will include GLAD initialization too.

Read More
27 Nov

Setting up Eclipse CDT for OpenGL with GLFW and GLAD

What’s OpenGL?

OpenGL is an API to render 2D and 3D graphics. Remember that an API (Application Programming Interface) is an interface for interaction between components of a system. Typically, an API defines a set of functions, protocols and/or tools. I’ll skip the details about the client-server model, but OpenGL allows a client program to communicate with GPUs (Graphic Processing Units, e.g., your videocard) to achieve faster, hardware-accelerated rendering. That’s why OpenGL is a common topic in the game development scene.

OpenGL is focused on just rendering. It’s an API to write and read data from a framebuffer, and that’s it. It won’t handle user input, or sound playback, or loading a PNG image. It does not even have functions to create or close a window. We’ll need auxiliar libraries for all of that.

A minimal OpenGL window

So we want to build a minimal OpenGL application on Windows. We’ll create an empty window with an OpenGL context, using the GLFW and GLAD libraries. In the following, I assume we’re using a 64 bits version of Windows. I’ll also be relying on mingw-w64. In summary, these are our assumptions:

  • Windows operating system (64 bits.) Things will be a tad different for macOS and Linux users.
  • Eclipse CDT.
  • mingw-w64 to build GLFW from sources. Besides, our Eclipse CDT project will be compiled with the gcc version of mingw-w64.
  • GLFW and GLAD libraries.

What’s GLFW?

As told, OpenGL does not provide any facility to create a window, retrieve user input, create the OpenGL context, etc. These functionalities depend on the operating system. GLFW is a C library which provides a neat abstraction layer to handle all of this on several platforms. Notice that GLFW is focused on management of windows, OpenGL contexts, user input and time. It will not play sounds, or load images, etc.

Read More
12 Nov

Compatibility of our games with macOS 10.15 Catalina

Recently Apple released an upgrade for macOS, Catalina 10.15, which finally dropped support for 32-bits-only apps. This essentially means that 32-bits-only games won’t run on macOS Catalina. Regarding IKIGames titles, this is the current status of our games on macOS:

  • DragonScales 1 to 5: if your purchased them on iTunes, they will run on Catalina. If you purchased them on other stores, they should also be playable, but we cannot guarantee it.
  • DragonScales 6 won’t be available on iTunes, but you can purchase it on Big Fish Games. That version runs on Catalina.
  • NagiQ 1 will not run on Catalina. NagiQ 2 might not run either. Currently we have no plans to make these games compatible with Catalina and later macOS versions.
  • The Rainbow Machine, if purchased on iTunes, will run. Again, if you purchased it on other stores, the game should also be playable, but we cannot guarantee it.

If you upgraded to Catalina, it should be possible to play 32-bits-only games by using a virtualization program. That way you could install macOS Mojave (or previous versions) and run your 32-bits-only games.

If you need further assistance, please contact us.

13 Feb

Updating older games

We’ve finished updating several of our older titles, specifically, The Rainbow Machine, DragonScales: Chambers of The Dragon Whisperer and DragonScales 2: Beneath a Bloodstained Moon. These games were originally built with versions of LibGDX <= 1.6, so we took the chance to update them to the latest LibGDX 1.9.9. As expected, updating LibGDX broke a lot of things: several functions had been altered or simply removed, support for LWJGL3 was added, and plenty of other details we had to address. Once we managed to fix all the projects, we were able to create new Windows and Mac versions.
Extra steps were taken on Mac, as we had to produce a bundled Java app, code-sign it and resubmit the games to iTunes and other stores. Little by little, we’ve been getting the games live on iTunes again:

Our next goal is updating DragonScales 3: Eternal Prophecy of Darkness too. But this time we’ll also try to integrate the game with Steamworks 🙂

07 Feb

Recent Progress

Things have been a bit hectic over here, for good, since the beginning of 2019 🙂 We’ve managed to get new publishing deals and a few of our games have been recently released. Specifically:

    • All of our games were released on Shockwave.

Currently, we’re focused on updated builds for DragonScales 1 to 3. Of course, we’re also making progress on DragonScales 6. And other (secret) projects 🙂
Oh, remember DragonScales 5 is on sale (Steam Lunar Sale) until next Monday.

07 Jan

2019: Projects

2019. We’re back to the grind!

The first project we’ll be working on, undoubtedly, is DragonScales 6. That installment of DragonScales should wrap up the Zarya arc. We’re still in a very preliminar design stage (for instance, we’ve not yet reached a consensus regarding the title of the game,) but design of the new levels is coming out smoothly. DragonScales 5 had 200 levels, so the new level count must also be, at least, 200. At the outset, DragonScales 6 is expected to be a desktop-only game (Windows and Mac,) with no plans for a mobile version.

We also have plans for additional games. For instance, we’d like to deliver a mobile version of DragonScales. A totally new, custom DragonScales, different to the desktop versions of the game. In the past, we generated Android ports of DragonScales 1 to 3, aimed at tablet devices. However, we’d like to produce a novel DragonScales game, specifically tailored to cellphones. This version might pose a significant challenge, as we’ll have to fully redesign the UI and create new levels with proper dimensions for tiny screens.

There are other projects we’d like to tackle. For instance, we’ve been designing a new casual game with a non-fantasy setting. However, we’ve not been pushing this new franchise as much as we’d like because the casual market in 2018 has not been overly attractive. We’ll keep monitoring this trend. Nevertheless, we hope DragonScales 5 is released though several casual partners in Q1 or Q2 of this year.

There are also older projects we’d like to revisit, but we’ll handle them as (if) time permits.

Looking back, 2018 has been a good year: we completed two games (DragonScales 4: Master Chambers and DragonScales 5: The Frozen Tomb,) and we (finally) completed the submission for the greenlighted DragonScales on Steam. Please buy our game here:

OK. Now it’s time to return to work. First the story of DragonScales 6. It’s the beginning of a long journey.