Opensource Game Studio

OpenSceneGraph cross-platform examples

2018-04-20T00:00:00+03:00

This article summarizes the work we did to produce the first two cross-platform OpenSceneGraph examples.

By the time the first technology demonstration of OGS Mahjong 2 has been released, we've already had issue request (to explain how to load images with OpenSceneGraph on Android) hanging for some time. We considered creating a new tutorial for OpenSceneGraph cross-platform guide at first. However, we realized that it's time-consuming and excessive for such a tiny topic (compared to what an average game has) as image loading. We decided to continue sharing our knowledge in the form of concrete examples. That's how OpenSceneGraph cross-platform examples were born.

Each example:

explains crucial code necessary to perform a specific task
accents platform-specific nuances
provides implementations to cover desktop, mobile, and web platforms
provides a web build to showcase results

The first two examples cover the following topics:

Embed resource into executable: this greatly simplifies resource handling across platforms
Use PNG images with PNG plugins: this explains the requirements necessary to build and use PNG plugins

We will be adding new examples as we proceed with OGS Mahjong 2 development.

That's it for summarizing the work we did to produce the first two cross-platform OpenSceneGraph examples.

First techdemo of OGS Mahjong 2: Gameplay

2018-02-16T00:00:00+03:00

We are glad to announce the release of the first technical demonstration of OGS Mahjong 2. The purpose of this release was to verify gameplay across supported platforms.

Get techdemo for your platform:

Notes:

iOS version is not released because it cannot be easily shared outside AppStore.
Launch run script under Linux and macOS.
Linux version is only available in 64-bit variant.
macOS version should run on macOS Sierra or newer.

That's it for now, have a nice testing!

Mahjong recreation start

2018-01-26T00:00:00+03:00

This article describes the start of Mahjong game recreation.

Plan

We started Mahjong recreation endeavour by composing a brief plan to get gameplay with minimal graphics:

Load single layout
Place tiles in layout positions
Distinguish tiles
Implement selection
Implement matching

Just like any other plan, this one looked fine at first sight. However, once you get down to work, new details start to come out. This plan was no exception. Below are a few problems that came out during development.

Problem №1: provide binary resources across supported platforms

Mahjong is going to be available on desktop, mobile, and web. Each of these platforms has its constraints on accessing external files:

Desktop can access almost any file
Android/iOS have limited access to file system
Web does not have any file system at all

To provide a unified way for accessing resources, we decided to include them into final executable. This decision led to the birth of mjin-resource and mahjong-data projects.

mjin-resource:

converts binary files to C header files with the help of xxd utility
generates MJIN project that contains generated headers to be compiled into static library
provides C++ interface for accessing generated resources

mahjong-data is an example of such generated MJIN project that is referenced by mahjong project.

Problem №2: load PNG images across supported platforms

To load PNG, we use corresponding OpenSceneGraph plugin. We built it for desktop with no issues. Building for web (Emscripten) turned out to be more difficult: Emscripten provides its own version of libpng, which OpenSceneGraph build script can't detect. We had to work around several OpenSceneGraph checks to successfully build the plugin for Emscripten. Building the plugin for Android and iOS is still waiting for us. Once we get PNG plugin working across supported platforms, we are going to publish a new tutorial for OpenSceneGraph cross-platform guide to cover PNG image loading. We already got a request to describe image loading.

Development

As you know, we published OpenSceneGraph cross-platform guide to make OpenSceneGraph community stronger. We value education, and we love to share our knowledge. That's why we decided to develop Mahjong in small reproducible chunks uniquely identified by internal versions. These versions are available in mahjong repository.

We also provide version history and web releases of each internal version for the following reasons:

education: show how development looks like internally
accessibility: provide older versions for comparison

Current Mahjong game status

As of the time of this writing, we have implemented tile selection. Try it in your browser!

Once we finish tile matching implementation, we are going to publish the intermediate result for all supported platforms.

That's it for describing the start of Mahjong game recreation.

The year of lessons

2017-12-31T22:00:00+03:00

So, the year 2017 is approaching its finale, the year's results have already been summed up. We're going to take a break from igniting the fireworks or preparation of the champagne so that we can designate our goal for the following year.

As it may be clear from other articles on the site, half of our plans in 2017 were destined to be completed at least approximately as we assumed. The other half was changed significantly.

During the year, people joined the team and left it. As a result, we meet the end of the year with exactly the same team as 365 days ago. It made us think. A lot. But We'll save the story for another time.

There will be exactly one goal for 2018. We will take all the results, and then we will make a new mahjong game. We're already know how to make a mahjong solitaire so we will begin with it. This time, it will be cross-platform. We will definitely try to cover Windows, Linux, macOs, Web, and Android. We can't promis anything about the iOS right now (although we'll see what we can do).

There is no point in writing more than We want to say. We learned a lot for this year, and we will try to apply all this knowledge to achieve more in the next one. We wish everyone a Happy New Year. Stay tuned.

The Opensource Game Studio Team.

2017 summary

2017-11-22T00:00:00+03:00

It's time to step back to see our accomplishments in 2017 and how they connect to the overall goal of Opensource Game Studio project.

Brief history

Opensource Game Studio project is 12 years old now.

2005. We started the project with a fanatic call to create the best game ever. Probably right after finishing Half-Life 2 or Morrowind. 99.99% of those who wanted to participate weathered during a couple of years leaving only the two of us: Michael (coding) and Ivan (the rest). The project was in a constant turmoil because we had no clear purpose and discipline. Thus, we only got a handful of demonstrations during that period.

2010. The first year for us to admit we failed big time. After accepting the failure, we have set Mahjong game as our initial target. We also realized that if we want the game out, we must work every day. We didn't get anywhere by working on weekends because they often collided with family time.

2012, 2013. We released Mahjong 1.0 and Mahjong 1.1 correspondingly. We created a complete, polished game in 3-4 years after failing to provide anything of value during previous 5 years. To this date, Mahjong is the best and only game we released so far. We're still proud of it because it still feels great.

2015. We showcased the first version of our game toolset. After releasing Mahjong, we decided to spend time on building toolset that would allow us to develop games faster.

2016. We recreated Mahjong gameplay with our game toolset. However, we quickly realized that desktop only game toolset is a dead end. It led us to research mobile platforms.

Last year

2016, October. We started mobile platforms' research by making simple straightforward OpenSceneGraph application run under Android.

2017, January. We got the Android version working and started iOS and Web research.

2017, February. We made the sample application work everywhere: desktop, mobile, web.

Researching mobile and web took us about five months. We spent that much time because there was no documentation on how to run OpenSceneGraph across platforms. We had to step in and create said documentation.

2017, July. We published OpenSceneGraph cross-platform guide, which describes how to create a simple OpenSceneGraph application and make it run on desktop, mobile, and web. To this date, this is our most popular GitHub repository.

2017, November. We published simple Memory: Colors game and the guide on how to create the game from scratch. The game is powered by MJIN, our new cross-platform game toolset that we started this summer.

Currently MJIN toolset is in its infancy. MJIN needs a real game to flourish. That's why we are already working on cross-platform Mahjong. We'll do our best to make Mahjong faster this time.

Back to the Static

2017-10-16T00:00:00+03:00

We have been using Wordpress as our website engine for more than seven years. And now it's time to move forward. Or backward. For some time we've been tracking the development of the new breed of website engines - static site generators. It seems that this is the technology capable of changing past into future.

A static website is more straightforward, quicker and more secure. And with the help of generators, it is also as easy to manage, as the dynamic website. So, we are starting our site anew with the help of the Pelican. Right now it doesn't have all the content from our old site, but we'll add most of it soon.

The birth of MJIN world

2017-09-10T00:00:00+03:00

This article describes the birth of MJIN world in August 2017.

mjin-player

As you know, we spent July to research scripting. We found a solution that satisfies the following criteria. Scripts should:

run unchanged on all supported platforms
allow extending C++ code

We have verified the second criterion by writing a sample application. The first criterion was taken for granted because it SHOULD be true.

At the time, we saw two ways to verify the first criterion:

create one sample application for each platform to verify scripting only
create a single cross-platform application, which can run any code

We chose the second approach because it is more beneficial in the long run. As you might have guessed, mjin-player is that application.

mjin-player serves as a base for the rest of MJIN projects to make them run on all supported platforms. However, there's no magic trick to hide the projects from the platform, and there was no such intention. Instead, mjin-player provides a consistent set of rules how other MJIN projects should be structured to be able to run on all supported platforms.

mjin-application

This set of rules for MJIN projects is packaged into mjin-application. mjin-application is a library that provides basic functionality every MJIN project would need and nothing more. For instance, mjin-application does not and will not contain scripting or any other specific functionality.

MJIN world

So what is MJIN world? It's a set of projects that constitute our game development tools. mjin-player and mjin-application are the first bricks of the newly born MJIN world. A lot more to come. Stay tuned for the brighter MJIN future.

That's it for describing the birth of MJIN world in August 2017.

Scripting research

2017-08-16T00:00:00+03:00

This article describes scripting research in July 2017.

Our first goal of using a scripting language was to have a platform-independent code that runs unchanged on every supported platform.

OGS Editor 0.10 supports Python for such a code thanks to SWIG. SWIG provides a way to wrap almost any C/C++ code and use it in dozens of languages like Python, Ruby, Lua, Java, C#, etc.. SWIG really helped us taste the beauty of platform-independent code. However, SWIG only works one way: from C/C++ to a target language. This means the main application must be in the target language, and C/C++ code can only be used as a library.

Having the main application in Python works fine for the desktop, but not so great for mobile and web, where C and C++ are the only natively supported cross-platform languages. There are projects like Kivy, which allow you to develop cross-platform applications in Python, but they are not supported natively. This means it's a lot of headaches when Android and iOS APIs change.

Having the main application in C/C++ and the need to support scripting means that a scripting language should be interpreted by the application. This is what SWIG, Kivy, and similar projects are not meant to fulfill.

Our secondary goal for using a scripting language was to allow to extend C++ code.

OGS Editor 0.10 has some modules written in C++, and some in Python. The modules are equal from the perspective of the main application; it doesn't care what language the module is written in.

To achieve such flexibility, we introduced a so-called Environment. Each module would register the keys it responds to, and Environment would deliver corresponding messages. Technically such behaviour is achieved by inheriting a base class and overriding its methods in both C++ and a scripting language.

First, we evaluated Python for the role of cross-platform scripting language.

Since we already used Python, we started to research the possibility to run Python code on every supported platform. The result was disappointing because CPython (the default Python implementation used on the desktop) does not mention mobile and web platforms. We only found some years old forks of CPython that were claimed to work either on Android or iOS. Such a disarray was not suitable for us. We also had a look at PyPy, another Python implementation. It also did not mention support for mobile and web platforms.

This was a clear indication that Python community doesn't care for mobile and web platforms. Or that nobody had time to provide the information about building Python on such platforms. Either way, it was not acceptable for us.

Second, we evaluated Wren for the role of cross-platform scripting language.

Wren was the first scripting language we stumbled upon in the long list of non-mainstream scripting languages.

Wren claimed to be small and easy to learn. Wren also claimed to be intended for embedding in applications. Ironically, the author had no time to document how to do the embedding in the first place. When we asked for the time estimates of publishing the critical part of the documentation, we just got a reference to another issue where the other guy was asking the same question half a year ago!

That's when we ended our relationship with Wren.

Third, we evaluated Chai for the role of cross-platform scripting language.

Chai was in the long list of non-mainstream scripting languages, too. Chai was promising because it claimed to be specifically tailored for embedding in a C++ application. We successfully managed to call a C++ function from inside Chai but failed to call a member function. We asked for help, but nobody replied.

We had to end our relationship with Chai.

Fourth, we evaluated Lua for the role of cross-platform scripting language.

Lua is the mainstream language for embedding. So we decided to try the obvious choice. Documentation looked promising, too. However, by the end of reading the C API chapter we had no clue how to inherit a class inside Lua.

This led us to search for libraries that wrap Lua C API syntax into something more meaningful for C++. That's how we found Sol2. Just as before, the first attempt to call a C++ member function from Lua failed. But unlike before, we asked for help and got the help! This was a refreshing surprise for us. Next, we tried to inherit a class in Lua and override the class methods. We failed, but the author helped us out again. In the end, we succeeded in inheriting a class and overriding its behaviour.

That's when we understood it's a start for a long and mutual relationship with Sol2/Lua.

This search for a scripting language taught us one important lesson: people matter, not technologies.

There are lots of scripting languages that look shiny on the outside but are dead. Why? Because some authors don't have time for users. In return, users don't have time for the authors' projects.

That's it for describing scripting research in July 2017.

OpenSceneGraph cross-platform guide

2017-07-17T00:00:00+03:00

This article summarizes the work we did to produce OpenSceneGraph cross-platform guide.

June marked the finish of OpenSceneGraph cross-platform guide with the publishing of the last (initially planned) tutorial. The tutorial describes how to build and run sample OpenSceneGraph application in Web using Emscripten. In case you missed it, here's a link to the final application. Open it in your web browser.

We started to compose the guide in February when we successfully managed to render a simple model on mobile and web. We spent 120 hours in five months to produce ten tutorials of the guide.

We have been doing OpenSceneGraph cross-platform guide for two main reasons:

Keep OpenSceneGraph cross-platform knowledge in easily accessible and reproducible form
Share the knowledge with OpenSceneGraph community to make it stronger

We believe we succeeded in both. Here's why:

The guide repository has more stars (aka "likes") than any other repository of ours
OpenSceneGraph project leader Robert Osfield said "Great work", which means a lot
The guide already has two issues

Reaching our goal of researching OpenSceneGraph cross-platform development and providing the knowledge back to the community just made us happier.

However, our journey does not stop here. Using the knowledge of the guide, we now continue to work on bringing our tools to support mobile and web, just as we promised in January.

That's it for summarizing the work we did to produce OpenSceneGraph cross-platform guide.

iOS tutorial

2017-06-08T10:00:00+03:00

This article describes problems we faced during the creation of iOS tutorial in May 2017.

This February we managed to get simple model rendered under iOS in just a few days. We expected to finish iOS tutorial in no time. However, the reality reminded us: it's easy to come up with a hackish demo that works for one person, but it's hard to create a concise example that works for everyone.

Native library

The first question we had to answer was: should the sample application be part of Xcode project or be a separately built library?

We had to consider the following facts:

Xcode project can use C++ directly (thanks to Objective-C++) without stuff like JNI
- There's no need for a separate library (+ application)
- Creating a separate library is an additional work (- library)
OpenSceneGraph builds libraries
- It's easier to use standard build process (+ library)
- It's harder to create custom build process just for a single platform (- application)
OpenSceneGraph uses CMake build system, which is not supported by Xcode
- Xcode project can't include CMake files (- application)
- It's easy to create custom CMake file that includes OpenSceneGraph CMake file to build a single library (+ library)
CMake can generate Xcode project
- It's possible to create a CMake file that builds both OpenSceneGraph and the sample application (+ application)
- Xcode is the de-facto tool to create Xcode projects; it's easier to use standard build process (+ library)

After evaluating the pros and cons of each approach, we decided to turn the sample application into a library and include it in Xcode project. The downside of this approach is that simulator and real device builds need separate library builds.

Refactoring

The second question we had to answer was: should there be a single source code base for all platforms or several ones, one for each platform?

While doing Android tutorial we used single source code base because it worked fine for desktop and Android. As we started to work through iOS tutorial, it became apparent that particular features may or may not work on some platforms. For example, one feature may work on desktop and iOS, but not Android. Another feature may work on iOS and Android, but not desktop. Since we didn't want to pollute the code with #ifdefs, we started to put each platform combination into a separate file. The number of files grew rapidly. The files were reusable, but it became extremely hard to see the whole picture.

At this point, we realized there's the second question. We reminded ourselves that the main purpose of the sample source code is to teach how to do basic OpenSceneGraph things, not create a reusable library with API that is stable across several years.

That's when our home grown feature tool came into play. With its help, we separated the code into several parts, which in the end produce just two files for each platform:

functions.h - contains reusable classless functions
main.h - contains the rest of the sample application code

Their contents differ slightly for each platform, but it's easy to see the whole picture now.

That's it for describing problems we faced during the creation of iOS tutorial in May 2017.

OpenSceneGraph sample

2017-05-12T00:00:00+03:00

This article describes creation of the tutorials for building sample OpenSceneGraph application under Linux, macOS, Windows, and Android in April 2017.

Previous tutorials described how to install OpenSceneGraph under Linux, macOS, Windows and render a model using the standard osgviewer tool. This time we worked on a sample OpenSceneGraph application that would run under Linux, macOS, Windows, and Android.

The application is very basic and has the following features:

Render window creation
Model loading
Model rendering with simple GLSL shaders
Model motion with a mouse under Linux, macOS, Windows and a finger under Android

Creating the tutorials for Linux, macOS, Windows was so easy and straightforward, that it only took us half a month. We spent the second half of the month creating Android tutorial.

Our first successful Android build last year included hacks and non-obvious steps to make OpenSceneGraph run under Android. This time we wanted a cleaner, faster, and cheaper approach.

The approach we ended up with requires just a few files and a few changes to the original Android Studio project (with C++ support) to make sample OpenSceneGraph application run under Android.

Here's a quick rundown of the files:

GLES2 surface
Render activity to render to the surface
Native library Java interface
Native library C++ implementation
CMake file to build native library
Render activity layout
Model to display

Here's a quick rundown of the project changes:

Update Android manifest to use GLES2 and render activity
Reference native library's CMake file in the project's CMake file

OpenSceneGraph documentation suggests building OpenSceneGraph outside Android Studio with CMake. However, this approach has the following limitations:

You have to build OpenSceneGraph for each target architecture
You have to manually copy/reference built OpenSceneGraph libraries into Android Studio project

Our approach includes building OpenSceneGraph for those target architectures that Android Studio project is built for. Also, OpenSceneGraph is already referenced, so no extra work is required: you just need to rebuild the project, and you're done.

That's it for describing the creation of the tutorials for building sample OpenSceneGraph application under Linux, macOS, Windows, and Android in April 2017.

It's all fine

2017-04-07T00:00:00+03:00

This article describes creation of the first four OpenSceneGraph tutorials in March 2017.

The first four OpenSceneGraph tutorials explain how to create a cube model with Blender and display the model under Linux, macOS, or Windows using OpenSceneGraph tool called osgviewer.

The whole process of creating a single tutorial turned out to be pretty daunting because it includes several tasks:

Record original video depicting one or more steps
Name the steps as clear as possible
Select the parts of the video that display the step
Remove the parts of the video that bare no value, e.g., waiting in the middle of compilation
Select a single frame to best represent current step, e.g., typing a specific command
Add a detailed description to article, why current step should have been taken
Proof-read the article
Correct typos and video timing
Review the whole video
Upload the video to YouTube with timestamps of steps for easier navigation

Some of those tasks had to be repeated multiple times until the combination of video, text, and article was clear and logical.

Overall, it took us 30 hours to create the tutorials. The whole process gave us a lot of experience, which will help us in shaping learning materials for our technologies in the future. We don't know how they will look like exactly, but they will definitely be better.

That's it for describing creation of the first four OpenSceneGraph tutorials in March 2017.

Let's go

2017-03-16T00:00:00+03:00

In this article we describe our progress in January and February of 2017: rendering under iOS/Web and a new tutorial tool.

Rendering under iOS/Web

To our surprise, we got a simple red cube rendered under iOS and Web pretty fast: in early February. However, this is only the beginning of this year's challenge to support Android, iOS, and Web platforms. There's a long and bumpy road ahead of us as we need a lot more on each platform before we can claim a success: visual effects, Python scripting, data archives.

Since it took us about four months to get to mobile and web platforms, we decided to share our knowledge and help OpenSceneGraph community with a guide that shows how to use OpenSceneGraph on desktop, mobile, and web. We believe the more widespread OpenSceneGraph is, the stronger our technology becomes. As Isaac Newton said, "If I have seen further, it is by standing on the shoulders of giants." OpenSceneGraph is our giant.

Tutorial tool

Having conducted four live sessions before, it was clear the guide needs videos depicting every nuance. However, bare video alone is only good for showing what to do and not for explaining why do it in a certain way. That's why we decided to combine video with text in the forms of video subtitles and separate articles.

To combine text and video, we first tried OpenShot. It worked well, but we quickly saw its limitations:

Too much time is spent on adjusting time frames and animations
Project file and original resources are hard to track with VCS

Since OpenSceneGraph cross-platform guide would consist of several tutorials, we decided to automate the process. Brief research revealed a great multimedia framework called MLT, which powers OpenShot itself. With MLT we got our tutorial tool in no time.

Currently, the tutorial tool allows anyone to combine text and video using a simple text file like this:

background bg.png
text 5 Let's install Blender
video 0:6 install_blender.mp4
text 5 Installing it with apt
video 6:26 install_blender.mp4
text 5 We're still installing it
video 26:56 install_blender.mp4
text 5 Congratulations! We just finished installing Blender

This is the actual script. See the final result here.

That's it for describing our progress in January and February of 2017: rendering under iOS/Web and the new tutorial tool.

The year of challenges

2017-01-25T00:00:00+03:00

This article describes our plans for 2017.

Our past plans suggested we would have Android platform support by this time. However, we have a long way to go, before we can declare Android support. See for yourself:

Some people would consider this a failure. We don't. We see a chance to start low and jump high!

Having only worked with liberal and forgiving desktop environments, Android was a complete surprise for us. Android punished us for everything: memory, resources, graphics. The usual Android response was either a crash, or an empty screen. At the same time, such a harsh environment highlighted weak spots in our technologies and helped us see where to go next.

This month we start working on iOS platform support, even though we have only scratched Android. Why? Because it's a lot easier to get those red cubes rendered on iOS without polishing Android first. We don't want to spend months polishing Android only to find out later we had to implement certain feature differently so that it works on all supported platforms.

And right after we get those cubes rendered on iOS, we start to work on bringing them to Web.

You got it right: we challenge ourselves with support for Android, iOS, and Web this year.

That's it for describing our plans for 2017.

Happy 2017

2016-12-31T00:00:00+03:00

Okay. It's been a hard year for everyone in the team. And it's almost over. Praise it ends! Praise the new one!

It may seem, that our progress stalled. Three years ago we announced the beginning of a new project (two to be precise), and now we still working on the engine and editor, haven't even started creating the actual game.

If you were monitoring our news during the year, you know that we held several live sessions, showing in the real time how to use our tools to create some simple games. Each session was a step in a long road to our goal. While preparing for these live sessions, we added necessary building blocks, that will be needed to create almost any game.

Future live sessions and technical previews will add even more, so at some point in future (i hope not very distant), we will have everything we need to sit down and build our planned game from these blocks.

So, the project isn't dead; the idea was not thrown away. But there is a lot of work to be done before we can start making the game, and there are only two of us, using our spare time. So. You want our game to become a reality? Join us. Together we will rule the galaxy. Or just wait and see. We didn't stop several years ago. We won't stop now. After all, there is only one way to create a fine tool (and it's our initial goal if you remember) - we need to use it ourselves. We will. Stay tuned.

Happy 2017. Let it be simple.

November 2016 recap

2016-12-15T00:00:00+03:00

This article describes the start of MJIN library separation into modules.

Once we built OpenSceneGraph for Android, it became obvious that some MJIN functionality is not suitable for Android. For example, UIQt provides a basis for OGS Editor UI. Since OGS Editor is a desktop application, we don't need UIQt for Android.

We decided to have a look at two approaches to separate MJIN into modules: build-time separation and run-time one. Build-time separation means MJIN becomes highly configurable and each platform gets specifically tailored MJIN build. Run-time separation means MJIN is divided into smaller libraries that are connected at run-time, which makes it easy to change functionality without rebuilding.

Run-time separation research.

Since run-time separation has more benefits, we started researching it first. The easiest way to achieve it was to use C API, because C ABI rules are much simpler than C++ one's.

We created a sample project consisting of the application, library, and plugin. The application has been linked to the library and used it to load the plugin. The library provided functions to register plugins and call their functions. The plugin provided functions for the library and called library functions.

The research was successful: the sample project worked correctly under Linux and Windows. However, since MJIN is currently a single large entity, we postponed C API application until we finish build-time separation.

Build-time separation start.

We extracted the following modules from MJIN:

Android: provides Java Native Interface (JNI) to MJIN
Sound: provides access to OpenAL
UIQt: provides access to Qt UI

Sound and UIQt modules are currently statically linked into MJIN library, while Android module is already a separate library due to JNI requirements.

In the coming year, we're going to significantly restructure MJIN so that it suits as many platforms as possible.

That's it for describing the start of MJIN library separation into modules.

October 2016 recap

2016-11-19T00:00:00+03:00

This article describes how we spent a month building OpenSceneGraph (OSG) for Android: the first attempt to build OSG, the search for OSG alternatives, and the success in building OSG.

First attempt to build OSG.

Having no prior knowledge of Android development, we grabbed the latest Android Studio and started doing beginner tutorials. We passed Java part pretty fast. Everything worked out of the box. Then came C++ part and related problems.

CMake. To work with C++, Android Studio uses custom CMake, which conflicts with the system one. This was a clear indication that we had to set up a separate development environment specifically for Android.

KVM. We got Ubuntu under VirtualBox installed. All went fine until we tried to use Android Emulator. Turned out, VirtualBox could not run Android Emulator, because a virtual machine cannot provide kernel virtualization inside already virtualized environment.

Chroot for Android. Since we had a successful experience with chroot to build OGS Editor before, we decided to place Android development environment into chroot. With minor tweaking, we could finally run Android Emulator and build C++ project.

OSG. Building OSG seemed like a piece of cake at the time. However, all we got was a crash. Thinking that we got it wrong the first time, we tried to rebuild OSG once again. And the same crash again. Searching for the problem did not reveal any hint. Nobody helped us at the OSG mailing list.

We were in despair.

The search for OSG alternatives.

Since OSG community did not help us, we decided to search for an alternative open source project to fit our Android needs (and may be more).

And we found it: BabylonHX. The home page looked awesome: it rendered WebGL in the background! We thought we finally found the gem we were looking for. However, the example on the home page simply did not work.

You can probably understand our feelings at the time.

The success in building OSG.

We realized nobody would make OSG work under Android for us. We had to do it ourselves.

Since OSG 3.4 document on building for Android was very short, we no longer trusted it and headed to original OSG 3.0 document. While following it, we faced a dead link to third party dependencies. The search for an alternative download link lead us to a 2013 tutorial on building OSG 3.0 for Android.

After following the tutorial, we finally got OSG to run under Android! But there was a nuance: both OSG and Android tools used in the tutorial were ancient. In a few days, we gradually updated both OSG and Android tools to their latest versions.

During the update process, we learned two things that prevented us from having OSG to work in the first place:

Android API headers changed in NDK r12
OSG only works as a static library under Android

That's it for describing how we spent the month building OSG for Android: the first attempt to build OSG, the search for OSG alternatives, and the success in building OSG.

Technology showcases

2016-10-31T00:00:00+03:00

In this article, we take another look at 2015-2016 live sessions' format and introduce a new showcase format for 2017.

2015 and 2016: live sessions.

As you know, we use live sessions to show the state of our technology and create a small functional game from scratch. We have conducted four live sessions in the past year, which gave birth to the following small games:

№	Created game	Live session date
1	Whac-a-mole	November 2015
2	Rolling ball	February 2016
3	Domino	May 2016
4	Mahjong Solitaire	September 2016

We spent four months to prepare for these live sessions. It has been an extremely useful experience for us. However, 2017 will have only 2 live sessions. Why? We want to spend more time on actual development!

2017: live sessions + technical previews.

Starting next year, we will be doing technical previews twice a year. A technical preview is another way to show the state of our technology, but without creating new games and conducting live sessions.

Here's an approximate schedule of technical previews and live sessions for 2017:

№	Month	Showcase type	Topic
1	January	Technical preview	Android platform support
2	April	Live session	Android game creation
3	July	Technical preview	To be announced
4	October	Live session	To be announced

That's it for taking another look at 2015-2016 live sessions' format and introducing the new showcase format for 2017.

September 2016 recap

2016-10-11T00:00:00+03:00

This article explains September 2016 live session stages: draft, rehearsal, live session itself, and publishing.

Even though live session takes only a few hours, we devote a whole month to prepare for it. Let's have a look at live session stages in detail.

Draft. Game creation for the first time.

Purposes:
- test our technologies and fix major bugs;
- discover usability issues to fix in the next development iteration;
- list exact steps to reproduce the game later;
- create draft version of the game assets (models, textures, sounds, scripts).
Upon stage completion, we announce live session date and show you the game preview.
Rehearsal. Game recreation.

Purposes:
- make sure we have no major bugs left;
- record the whole process of the game creation;
- create final game assets.
This is 99% the game we publish later.
Live session. Reassembling the game live in front of you.

Purposes:
- show how easy it is to create a game;
- walk you through nuances of game creation;
- get feedback from you;
- answer your questions.
We take game assets from the rehearsal and use them to quickly reassemble the game in just a few hours.
Publishing. The release of our technologies' last version, live session materials, and stand alone game.

That's it for explaining September 2016 live session stages: draft, rehearsal, live session itself, and publishing.

OGS Editor 0.10 and live session materials

2016-10-03T00:00:00+03:00

Note: we won't release 0.10 for macOS due to technical difficulties with the build system. macOS support will be back for 0.11.

OGS Editor 0.10 is available at SourceForge. Simply unpack the archive and launch the run script.
Mahjong Solitaire game is available at SourceForge, too. Simply unpack the archive and launch the run script.
Live session project is available at GitHub.
Live session recording is available at YouTube. The video depicts the whole process of creating Mahjong Solitaire from scratch using rehearsal project resources.

A few words about live session yesterday

2016-09-26T00:00:00+03:00

Mahjong Solitaire was successfully created, and it took less than 4 hours. We will publish live session materials later this week.

Thank you for joining us.

Live session is in 24 hours

2016-09-24T00:00:00+03:00

Get ready for live session, it's about to happen in 24 hours!

Live session: 25 September 2016

2016-09-17T00:00:00+03:00

We will hold live session on 25 September 2016 at 12:00 CEST It's time to create simple Mahjong solitaire game.

August 2016 recap

2016-09-03T00:00:00+03:00

This article explains the most important technical details about development in August: UIQt module, its refactoring, a new feature based development approach, and its benefits.

UIQt module is a collection of UI components backed by Qt. We only use it for Editor UI at the moment.

Here is a list of UIQt module components with their description and current code size:

№	Component	Description	Size (B)	Size (%)
1	UIQtAction	Actions (events) for menus	11224	9
2	UIQtAux	Initializes Qt and main window. Provides widget resolution by name to other components	15518	12
3	UIQtDock	Widget docks	5273	4
4	UIQtFileDialog	File selection dialogs	8960	7
5	UIQtMenu	Menus for main window and pop-ups (like node's add/copy/paste/delete menu)	4566	3
6	UIQtMenuBar	Menu bar for main window	4222	3
7	UIQtRunner	Allows to start QApplication	2450	2
8	UIQtThumbnailDialog	Dialog with thumbnail images	18615	14
9	UIQtToolBar	Tool bar for main window	4276	3
10	UIQtTree	Provides complex widgets like Scene tree and Property browser	51216	39
11	UIQtWidget	Common widget properties like focus and visibility	5465	4

UIQt module refactoring purpose was to replace old State API with new Environment API, which allows to achieve the same functionality with less code, i.e., makes development easier and faster.

Refactoring started in July and should have been done the same month. However, we only finished the work in August. Initial plan assumed 28 hours would be enough, but we spent 65 instead. We estimated planned time by relying on the number of public API calls of each component. That worked fine for small components, because the number of their public API calls was roughly equal to the number of their features, and features themselves were very small. However, it totally failed for UIQtTree, which contains 39% of UIQt module code, because there was no direct connection between public API and features.

Feature based development approach was born as a result of UIQtTree refactoring struggle. Since Qt uses MVC, UIQtTree component consists of several classes. By the time UIQtTree could display and manage a hierarchy of items, the component was already 27K in size. We noticed UIQtTree started to require abnormal amount of development time even for tiny features. This was an obvious quantitative complexity manifestation.

We decided to separate UIQtTree into base part and additional ones. Base would only contain minimal code required by all features. Addition would contain specific feature code and could be safely modified. In the case of UIQtTree, item hierarchy display and modification is the minimal functionality, while item renaming is an addition.

Here is a list of current UIQtTree features:

№	Feature	Description	Size (B)	Size (%)
1	Base	Allows to construct item hierarchy, modify it, and display it	26966	52
2	Item open state	Keeps track of collapsed/expanded item properties	3094	6
3	Item renaming	Allows to rename an item	3471	7
4	Item selection	Allows to get/set selected item	2338	5
5	Item value	Provides 2nd and the rest columns for items, used by Property browser	1307	3
6	Item value editing	Allows to edit item values with a default editor widget	1996	4
7	Item value editing with combobox	Provides combobox editor	5819	11
8	Item value editing with spinner	Provides spinbox editor	5290	10
9	Menu	Provides pop-up menu	1248	2

Here's an example of UIQtTree Menu feature file: TREE_MENU.

Benefits of the approach include:

Faster code reading/understanding due to small size
Easier and safer modification due to isolated code

There's a drawback, too: new approach requires learning.

That's it for the most important technical details about development in August: UIQt module, its refactoring, a new feature based development approach, and its benefits.

We’re back to social networks

2016-08-18T00:00:00+03:00

If you follow us on Facebook, Twitter, or VK you noticed we started to use them again. That's no coincidence: we're finally ready to communicate our progress verbally after 4 years of almost silent development.

Once Mahjong – always Mahjong

2016-08-10T00:00:00+03:00

We started Opensource Game Studio project a long time ago. We wanted to provide open source community with tools to create games. However, it was unclear what tools' purpose was. So we decided to start small: create a game first.

It took us 3 years to reach the first goal: we released OGS Mahjong 1.0 in 2012. Even for a hobby project (we spend about 40 hours a month) it's too long.

Upon the game release we got it: Tools are means to save development time.

We spent 4 more years to develop them. Now is the time to prove they are worth every single day spent. How? We will recreate Mahjong solitaire mode in just a few hours!

Join our next live session in September.

May 2016 live session materials

2016-05-29T00:00:00+03:00

This time we have shown how to create a simple Domino based game. Below you can find all materials related to the game creation.

Editor 0.9 for Linux (Debian based), OS X (10.9+), Windows is available at SourceForge. Simply unpack it and launch the run script.
Domino project created during live session is available at GitHub.
Domino rehearsal videos referenced during live session are available at YouTube
Domino rehearsal project referenced during live session is available at GitHub.

The next live session will be held in September 2016.

Live session: 28 May 2016

2016-05-17T00:00:00+03:00

We're glad to annouce that the LiveCoding session will take place on 28 May 2016 at 12:00 CEST. Join us!

May live session (Editor 0.9)

2016-04-24T00:00:00+03:00

As you know, the previously published roadmap assumed, that we would hold a live session in April and it would feature a ping-pong game created with Editor 0.9.

We have to admit, our abilities to plan are not yet good enough. That's why the next live session will take place by the end of May. The exact date will be announced later.

Here's a short preview of the coming game:

"Rolling ball" live session videos and downloads

2016-02-10T00:00:00+03:00

Since we held 2 live sessions to create "Rolling ball" game, here are 2 YouTube videos of the process:

"Rolling ball" game for Linux (Debian based), OS X (10.9+), Windows is available at SourceForge. Simply unpack it and launch the run script.

Editor 0.8 is available at SourceForge, too.

"Rolling ball" project for the Editor is available at GitHub.

To open it in the Editor:

replace slideDown.ogs with rollingBall.ogs you downloaded
rename rollingBall.ogs to slideDown.ogs

Since live session took us so long, we decided to concentrate on polishing. Editor already has a lot of features, but their use is inconvenient. We will fix major obstacles for the next Editor release.

Game creation live session (part 2): 7 February 2016

2016-02-02T00:00:00+03:00

Unfortunately, we have failed to finish creation of the simple "Rolling ball" game in 3 hours. That's why we will hold the second LiveCoding session on 7 February 2016 at 12:00 CET. Let's finish the game!

Game creation live session: 31 January 2016

2016-01-25T00:00:00+03:00

We're glad to annouce that the LiveCoding session will take place on 31 January 2016 at 12:00 CET. Join us!

SOON: Creating a simple game live (Editor 0.8)

2016-01-21T00:00:00+03:00

We are ready to present Editor 0.8 with Player. The live session will be held at LiveCoding SOON. We will show you how to create a simple game with sounds from scratch. And this time it will not need an Editor to run. The exact date and time is to be announced in the coming days. Stay tuned!

Roadmap for 2016

2015-12-26T00:00:00+03:00

As you know, according to the previously published roadmap, we now have sound system in place. However, we decided to go further and implement the first version of Player. We wanted to get it done by December, but, unfortunately, more work resulted in the change of dates.

Here's the revised roadmap for the first half of 2016:

Editor + Player 0.8.0 (January 2016): Sound system, Whac-a-mole game with sounds
Editor + Player 0.9.0 (April 2016): Networking system, simple ping pong game for 2 players over the net
Editor + Player 0.10.0 (July 2016): Polishing, "Shuan" prototype

Live session video and downloads

2015-11-15T00:00:00+03:00

If you missed the live session, you can watch it here: https://www.livecoding.tv/video/kornerr/playlists/whac-a-mole-from-scratch/

You can download the resulting project here: https://github.com/OGStudio/liveSessionWhacAMole/archive/master.zip

The latest editor can be found here: http://sourceforge.net/projects/osrpgcreation/files/Editor/jenkins/42_2015-11-13_08-16-46_0.7.4/

Download the editor archive, unpack, delete the wam.ogs folder, copy wam.ogs from the live session archive to the editor folder.

in Windows - run the run.bat file.
in Linux and OSX - run the run file.

Creating a simple game live: 15 November 2015

2015-11-09T00:00:00+03:00

We're glad to annouce that the LiveCoding session will take place on 15 November 2015 at 12:00 CET. Join us!

SOON: Creating a simple game live (Editor 0.7)

2015-11-02T00:00:00+03:00

As we have promised, we are ready to give you Editor 0.7 which is capable of creating the complete test chamber. However, after recreating the test chamber ourselves, it became clear that:

it takes more than 8 hours to recreate it (too long)
it's inappropriate to be presented in the form of an article (too boring)

Therefore we decided to hold a live session at LiveCoding SOON to show you how to create a simple whac-a-mole like game from scratch.

Currently we are busy making final preparations, so we'll tell you the exact time and date this week. Stay tuned!

Desura no more, hello Humble Bundle Widget

2015-07-23T00:00:00+03:00

After the recent bankruptcy of Desura's parent company, we decided, that we need a new place for our Deluxe version. Something better, more modern and more trustworthy. We have chosen the Humble Widget, with which you can buy the deluxe version of the game without leaving our site.

Here it is:

We haven't received a single penny from Desura (due to the minimal cache out limitations), but if you bought the deluxe version from them and experiencing any problems with downloading it (right now we see no problems with that), send us a letter, tell your name on Desura, we'll figure something out.