Open Source Game Development - Preparation

In my previous topic, I published a link to a small sketch of the game’s ideas under the working title Hexagon (the document at that time featured the name Celestial island). Quite a lot of people showed interest in him, and not only as proofreaders: punctuation and frantically correcting spelling errors in it, for which of course I thank them, but it was still a “sketch” - notes in the margins. But also some asked questions and expressed a desire to take part in the project.

After a little reflection and weighing all the pros and cons and saying to yourself: - Ah, why not.
I decided to conduct an experiment: from the project “for the soul”, which is being developed in my free time, I would open the project and conduct the development publicly under an open license and see what came of it.

First stage
The first stage of any work is preparation for it. It is not unimportant to solve on the shore the main organizational issues that may become stumbling blocks and stall work in the future. First of all, I decided to decide on the working environment, which should make the work on the project comfortable and transparent. Not only for me, but also for other developers and “viewers”.

Working environment


Game engine
Initially, the choice was from several engines that are “on everyone’s ears”:

All of them in one form or another have “sparing” licenses for non-commercial projects with the ability to switch to the paid version on different conditions. They all offer a whole infrastructure, a developed community, and an excellent portfolio of AAA titles. UDK and Unity3d, in turn, “out of the box” provide the ability to port projects to mobile platforms.

Unity3d was removed from the list almost immediately - misunderstandings with licensing for non-commercial projects: it is not explicitly available on the site; according to rumors on the Internet, someone was able to do this - to solve it individually or on special licensing terms and all that sort of thing ... Too many questions and few answers - decided it was easier not to get involved.

A little later, two other candidates were sent after him.
All three engines with their “infrastructure” impose their own philosophy of what you can create on them and how to do it from beginning to end - it was this feeling, possibly erroneous, that I developed when I met you. You start the demo and the editor, and literally before your eyes you see how to do it: first-person or third-person shooter, racing or a "level" platformer ... But the image of the strategy with an open endless world didn’t appear.

In addition, an important criterion for the choice was cross-platformness of both the final product and development tools - this was a common problem.
As a result, the choice fell on blender. Until now, many perceive it solely as a tool for 3d modeling (rendering, compositing, animation, etc.), but not as an engine. Although this module of it literally with every update gets new features. You can also connect to it an external graphics engine, for example: Ogre or Crystal Space , as well as another physical engine, if necessary.

The engine and runtime are initially cross-platform and include source codes in the delivery. At the same time, everyone has their own infrastructure, but to a certain extent there is no "philosophy" and the imposition of "the only right path."
After several feature tests have been conducted:
  • Creation of "full" shaders (GLSL)
  • Ability to connect external script files (by default, scripts are written in the project's .blend file itself, in the built-in editor)
  • Checking the performance of physics and logic by the collision between objects, as well as the event model as a whole.

It was decided, at least at the prototype stage of the main version of the game, to dwell on it.

Here it’s probably worth clarifying that the game implies the ability to play using various devices and “protocols”. For example, sending sms with a short team to change the tactics of the battle of game units, and going into the game from a mobile in the opened requested mode, make strategic decisions or participate in the auction. A fully functional client is currently planned only for a computer - this also allows solving the important problem that many ports face from one platform to another: when it is inconvenient to play the touchscreen in the same shooters, while using the joystick or mouse with the keyboard "Hurray."

Programming Language and IDE
The choice of engine was made, he defined the language - python. Prior to that, I had experience writing on it both for web projects, and once upon a time scripts directly under blender itself. Problems with developers, documentation and the community should not be.

The choice of the IDE was to make in favor of pycharm it is not surprising that the developers who expressed a desire to join also worked in it, since at the moment, by their own conviction, this is the best tool on the market that is worth its money, and of course support is beyond praise.

3d editor
It might seem that the choice was obvious given the presence of it in blender, but - it is not. Unfortunately, far from all modelers, the specificity of its interface has a positive effect on performance. At the same time, it is open and free and there was a desire to find an alternative on the same conditions.

It became Softimage Mod Tool , a much-cut version of the Softimage XSI editor for creating game mods and non-commercial projects. The problem was only on different scales between the game scene and the Mod Tool, but it is quickly solved by the export-import pipeline.

Localization
In order for the project to be truly “open”, it is necessary to get rid of the language barrier as much as possible. It was decided to keep all texts including documentation in parallel in English and Russian. For this, the notabenoid project was chosen, as it turned out, according to their administration, with the help of him and his audience, a number of game projects and project documentation have been translated for a long time.

Web platform
A public project must be adequately and conveniently presented on the network:
  • Collective Remote Work and Planning
  • Writing documentation
  • Ability to work with the community
  • Source Publishing

The collective tool was first googel apps later teamlab . It was extremely inconvenient to describe the project and create tasks (especially nested ones) in teamlab, and the differentiation of user rights was extremely unclear as a result, I had to continue the search, including creating the corresponding question in q & a . The most relevant to all of my voiced requirements there turned out to be not very famous birdviewprojects . Combining tools: planning, teamwork and small “bookkeeping”.

For documentation, the choice is obvious - you need a wiki engine. Google docs are good for everyone, but you can’t do without convenient links and support for monolingualism either, especially with large amounts of text. The choice turned out to be rather limited by the framework of the cloud platform which became appfog . For all its advantages (tariffs, attachment of your domain names, a wide selection of languages, good documentation, etc.) compared to OpenShift, for example, glitches and slowness which begin literally after registration (access to the service for an unknown reason was obtained only a week after it) she has childhood illnesses and a number of restrictions on downloadable applications.

Only MediaWiki booted and started. Moreover, it was she who was in first place among the applicants in terms of the totality of available opportunities. So the combination of circumstances has become a determining factor.

Working with the community and source storage in a modern open source software product often go side by side. This is our case - github , in my personal opinion, has no competitors at the moment, unless private projects are needed that are not relevant for this project.

License

An important aspect of open source development is the license for published materials and source codes. It was important for me, first of all, to keep authorship of all project participants no matter how much they made a small contribution to the project, and also not to exclude the possibility of creating paid “editions” of the project.

For these and a number of other reasons, after a long study of various options, New BSD was chosen for the code , and for all other content, from models to documentation (for all materials where the license is not explicitly specified) CC BY-NC 3.0 makes it possible to use everything in non-profit projects, and if desired, request from the copyright holder an individual extension of its scope.

Afterword

On this, I think it’s worth completing my story about the stage of “preparation” for the development of a game project. If the visitors of the Habr will have an interest in the project, which was literally a couple of lines in this article, then ask - I will answer. If you want to participate - contact, we will discuss.
Also, in the near future, the publication of source codes and documentation will begin, about everything - this is except for articles on the hub

UPD: Project website opened: hexagon scrw

Also popular now: