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.
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.
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.
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.
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.
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.
-->
diff --git a/feeds/all.atom.xml b/feeds/all.atom.xml
index 7f3786a..4da36a1 100644
--- a/feeds/all.atom.xml
+++ b/feeds/all.atom.xml
@@ -1,5 +1,45 @@
-Opensource Game Studiohttps://ogstudio.github.io/2017-08-16T00:00:00+07:00Scripting research2017-08-16T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-08-16:scripting-research.html<p><img alt="Scripting research" src="https://ogstudio.github.io/2017-08-scripting-research.png" /></p>
+Opensource Game Studiohttps://ogstudio.github.io/2017-09-10T00:00:00+07:00The birth of MJIN world2017-09-10T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-09-10:mjin-world-birth.html<p><img alt="The birth of MJIN world" src="https://ogstudio.github.io/2017-09-mjin-world-birth.png" /></p>
+<p>This article describes the birth of MJIN world in August 2017.</p>
+<p><strong>mjin-player</strong></p>
+<p>As you know, <a href="https://ogstudio.github.io/scripting-research.html">we spent July to research scripting</a>. We found a solution that satisfies the following criteria. Scripts should:</p>
+<ol>
+<li>run unchanged on all supported platforms</li>
+<li>allow extending C++ code</li>
+</ol>
+<p>We have verified the second criterion by writing a sample application. The first criterion was taken for granted because it SHOULD be true.</p>
+<p>At the time, we saw two ways to verify the first criterion:</p>
+<ol>
+<li>create one sample application for each platform to verify scripting only</li>
+<li>create a single cross-platform application, which can run any code</li>
+</ol>
+<p>We chose the second approach because it is more beneficial in the long run. As you might have guessed, <a href="https://bitbucket.org/ogstudio/mjin-player">mjin-player</a> is that application.</p>
+<p>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.</p>
+<p><strong>mjin-application</strong></p>
+<p>This set of rules for MJIN projects is packaged into <a href="https://bitbucket.org/ogstudio/mjin-application">mjin-application</a>. 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.</p>
+<p><strong>MJIN world</strong></p>
+<p>So what is <a href="https://bitbucket.org/ogstudio/mjin">MJIN world</a>? 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.</p>
+<p>That's it for describing the birth of MJIN world in August 2017.</p>Рождение вселенной MJIN2017-09-10T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-09-10:mjin-world-birth-ru.html<p><img alt="Рождение вселенной MJIN" src="https://ogstudio.github.io/2017-09-mjin-world-birth.png" /></p>
+<p>Эта статья описывает рождение вселенной MJIN в августе 2017.</p>
+<p><strong>mjin-player</strong></p>
+<p>Как вы знаете, <a href="https://ogstudio.github.io/scripting-research-ru.html">в июле мы изучали скриптование</a>. Мы нашли решение, которое удовлетворяет следующим критериям. Скрипты должны:</p>
+<ol>
+<li>исполняться в исходном виде без изменений на всех поддерживаемых платформах</li>
+<li>позволять расширять код C++</li>
+</ol>
+<p>Мы проверили второй критерий в рамках тестового приложения. В первый критерий мы просто поверили, т.к. он ДОЛЖЕН быть верен.</p>
+<p>В тот момент мы видели два варианта проверки первого критерия:</p>
+<ol>
+<li>создать по одному тестовому приложению под каждую платформу для проверки лишь этого критерия</li>
+<li>создать одно кросс-платформенное приложение, которому можно скормить практически любой код</li>
+</ol>
+<p>Мы выбрали второй подход, т.к. он выгоднее в долгосрочной перспективе. Как вы уже догадались, <a href="https://bitbucket.org/ogstudio/mjin-player">mjin-player</a> является тем самым кросс-платформенным приложением.</p>
+<p>mjin-player служит базой для остальных проектов MJIN, которая позволяет этим проектам работать на всех поддерживаемых платформах. Тем не менее, в mjin-player нет никакой магии, проекты никак не скрыты от деталей платформ, да и не было такой задачи. Вместо скрытия деталей платформы mjin-player предоставляет набор правил, которым должны удовлетворять проекты MJIN для работы на всех поддерживаемых платформах.</p>
+<p><strong>mjin-application</strong></p>
+<p>Этот набор правил представлен в виде <a href="https://bitbucket.org/ogstudio/mjin-application">mjin-application</a>. mjin-application является библиотекой с базовым функционалом, необходимым для каждого проекта MJIN, но не более. Например, mjin-application не содержит и никогда не будет содержать скриптования или подобного специфического функционала.</p>
+<p><strong>Вселенная MJIN</strong></p>
+<p>Так что же такое <a href="https://bitbucket.org/ogstudio/mjin">вселенная MJIN</a>? Это множество проектов, которые являются нашими средствами для разработки игр. mjin-player и mjin-application - первые кирпичики недавно появившейся вселенной MJIN. А будет их намного больше. Оставайтесь на связи, нас ждёт светлое будущее с MJIN.</p>
+<p>На этом мы заканчиваем описание рождения вселенной MJIN в августе 2017.</p>Scripting research2017-08-16T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-08-16:scripting-research.html<p><img alt="Scripting research" src="https://ogstudio.github.io/2017-08-scripting-research.png" /></p>
<p>This article describes scripting research in July 2017.</p>
<p><strong>Our first goal of using a scripting language was to have a platform-independent code that runs unchanged on every supported platform.</strong></p>
<p>OGS Editor 0.10 supports Python for such a code thanks to <a href="http://swig.org/">SWIG</a>. 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.</p>
@@ -171,10 +211,4 @@ We spent 120 hours in five months to produce ten tutorials of the guide.</p&g
<li>main.h - содержит остальной код приложения</li>
</ol>
<p>Их содержимое несколько отличается для каждой из платформ, но наличие всего двух файлов позволяет увидеть общую картину.</p>
-<p>На этом мы заканчиваем описание проблем, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.</p>Pelican review2017-06-03T22:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-06-03:pelican-review.html<p>So far so nice. Pelican is really cool, and provides a quick starting guided
-to get up and running real fast.</p>
-<p>Much more smooth than Jekyll.</p>
-<p>I <3 Python and its ecosystem. Something is just EASIER in Python.</p>Обзор Pelican2017-06-03T22:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-06-03:pelican-review-ru.html<p>Пока что полёт нормальный. Pelican действительно крут, позволяет
-быстро всё настроить и запуститься.</p>
-<p>Намного легче, чем Jekyll.</p>
-<p><3 Python и его экосистему. Что-то просто ЛЕГЧЕ в Python.</p>My first review2017-06-01T10:20:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-06-01:keyboard-review.html<p>Here is a full review, guys.</p>Моё первое ревью2017-06-01T10:20:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-06-01:keyboard-review-ru.html<p>Вот и моё первое ревью, чуввви.</p>
\ No newline at end of file
+<p>На этом мы заканчиваем описание проблем, с которыми мы столкнулись во время создания самоучителя для iOS в мае 2017.</p>Stub2017-06-03T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-06-03:stub.html<p>TODO Import previous Opensource Game Studio articles from Wordpress.</p>Заглушка2017-06-03T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-06-03:stub-ru.html<p>TODO Импортировать предыдущие статьи Opensource Game Studio с Wordpress.</p>
\ No newline at end of file
diff --git a/feeds/news.atom.xml b/feeds/news.atom.xml
index c7f8648..8206aff 100644
--- a/feeds/news.atom.xml
+++ b/feeds/news.atom.xml
@@ -1,5 +1,25 @@
-Opensource Game Studiohttps://ogstudio.github.io/2017-08-16T00:00:00+07:00Scripting research2017-08-16T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-08-16:scripting-research.html<p><img alt="Scripting research" src="https://ogstudio.github.io/2017-08-scripting-research.png" /></p>
+Opensource Game Studiohttps://ogstudio.github.io/2017-09-10T00:00:00+07:00The birth of MJIN world2017-09-10T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-09-10:mjin-world-birth.html<p><img alt="The birth of MJIN world" src="https://ogstudio.github.io/2017-09-mjin-world-birth.png" /></p>
+<p>This article describes the birth of MJIN world in August 2017.</p>
+<p><strong>mjin-player</strong></p>
+<p>As you know, <a href="https://ogstudio.github.io/scripting-research.html">we spent July to research scripting</a>. We found a solution that satisfies the following criteria. Scripts should:</p>
+<ol>
+<li>run unchanged on all supported platforms</li>
+<li>allow extending C++ code</li>
+</ol>
+<p>We have verified the second criterion by writing a sample application. The first criterion was taken for granted because it SHOULD be true.</p>
+<p>At the time, we saw two ways to verify the first criterion:</p>
+<ol>
+<li>create one sample application for each platform to verify scripting only</li>
+<li>create a single cross-platform application, which can run any code</li>
+</ol>
+<p>We chose the second approach because it is more beneficial in the long run. As you might have guessed, <a href="https://bitbucket.org/ogstudio/mjin-player">mjin-player</a> is that application.</p>
+<p>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.</p>
+<p><strong>mjin-application</strong></p>
+<p>This set of rules for MJIN projects is packaged into <a href="https://bitbucket.org/ogstudio/mjin-application">mjin-application</a>. 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.</p>
+<p><strong>MJIN world</strong></p>
+<p>So what is <a href="https://bitbucket.org/ogstudio/mjin">MJIN world</a>? 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.</p>
+<p>That's it for describing the birth of MJIN world in August 2017.</p>Scripting research2017-08-16T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-08-16:scripting-research.html<p><img alt="Scripting research" src="https://ogstudio.github.io/2017-08-scripting-research.png" /></p>
<p>This article describes scripting research in July 2017.</p>
<p><strong>Our first goal of using a scripting language was to have a platform-independent code that runs unchanged on every supported platform.</strong></p>
<p>OGS Editor 0.10 supports Python for such a code thanks to <a href="http://swig.org/">SWIG</a>. 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.</p>
diff --git a/feeds/stub.atom.xml b/feeds/stub.atom.xml
new file mode 100644
index 0000000..c447cbd
--- /dev/null
+++ b/feeds/stub.atom.xml
@@ -0,0 +1,2 @@
+
+Opensource Game Studiohttps://ogstudio.github.io/2017-06-03T00:00:00+07:00Stub2017-06-03T00:00:00+07:00Opensource Game Studiotag:ogstudio.github.io,2017-06-03:stub.html<p>TODO Import previous Opensource Game Studio articles from Wordpress.</p>
\ No newline at end of file
diff --git a/index.html b/index.html
index 4674474..f60bbe9 100644
--- a/index.html
+++ b/index.html
@@ -47,6 +47,45 @@
+
+
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.
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.
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.
Эта статья описывает рождение вселенной MJIN в августе 2017.
+
mjin-player
+
Как вы знаете, в июле мы изучали скриптование. Мы нашли решение, которое удовлетворяет следующим критериям. Скрипты должны:
+
+
исполняться в исходном виде без изменений на всех поддерживаемых платформах
+
позволять расширять код C++
+
+
Мы проверили второй критерий в рамках тестового приложения. В первый критерий мы просто поверили, т.к. он ДОЛЖЕН быть верен.
+
В тот момент мы видели два варианта проверки первого критерия:
+
+
создать по одному тестовому приложению под каждую платформу для проверки лишь этого критерия
+
создать одно кросс-платформенное приложение, которому можно скормить практически любой код
+
+
Мы выбрали второй подход, т.к. он выгоднее в долгосрочной перспективе. Как вы уже догадались, mjin-player является тем самым кросс-платформенным приложением.
+
mjin-player служит базой для остальных проектов MJIN, которая позволяет этим проектам работать на всех поддерживаемых платформах. Тем не менее, в mjin-player нет никакой магии, проекты никак не скрыты от деталей платформ, да и не было такой задачи. Вместо скрытия деталей платформы mjin-player предоставляет набор правил, которым должны удовлетворять проекты MJIN для работы на всех поддерживаемых платформах.
+
mjin-application
+
Этот набор правил представлен в виде mjin-application. mjin-application является библиотекой с базовым функционалом, необходимым для каждого проекта MJIN, но не более. Например, mjin-application не содержит и никогда не будет содержать скриптования или подобного специфического функционала.
+
Вселенная MJIN
+
Так что же такое вселенная MJIN? Это множество проектов, которые являются нашими средствами для разработки игр. mjin-player и mjin-application - первые кирпичики недавно появившейся вселенной MJIN. А будет их намного больше. Оставайтесь на связи, нас ждёт светлое будущее с MJIN.
+
На этом мы заканчиваем описание рождения вселенной MJIN в августе 2017.
+
+
+
+
\ No newline at end of file
diff --git a/pelican-review-ru.html b/mjin-world-birth.html
similarity index 53%
rename from pelican-review-ru.html
rename to mjin-world-birth.html
index 5613612..d11327e 100644
--- a/pelican-review-ru.html
+++ b/mjin-world-birth.html
@@ -4,7 +4,7 @@
- Обзор Pelican
+ The birth of MJIN world
@@ -46,18 +46,35 @@
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.
-->
diff --git a/openscenegraph-cross-platform-guide.html b/openscenegraph-cross-platform-guide.html
index 918a8e6..ce15333 100644
--- a/openscenegraph-cross-platform-guide.html
+++ b/openscenegraph-cross-platform-guide.html
@@ -99,7 +99,7 @@ We spent 120 hours in five months to produce ten tutorials of the guide.
-->
diff --git a/scripting-research.html b/scripting-research.html
index d7ef525..77bcab5 100644
--- a/scripting-research.html
+++ b/scripting-research.html
@@ -109,7 +109,7 @@ Next, we tried to inherit a class in Lua and override the class methods. We fail
