We, a team of programmers from the Ukrainian software company, want to share the acquired experience with dear readers of Habr. Now in the mode of voluntary professional development we are developing toys for Windows 8 and in this task everything is new for us: OS, creating gaming applications, physics and graphics for games. To make our searches, knowledge and results as useful as possible, we decided to publish a series of articles on the development process for all to see. We sincerely hope for a dialogue with readers and that the information we describe will be useful and interesting.
Today we publish the opening introductory article on how we got the idea, what goals we set, and what we are going to.
How it all began…
We decided to conduct a Coding Dojo and chose a 3D toy, at first it was a 3D tank. Having spent 3-4 classes, we clearly began to lack organization and every time we became more and more interested in individual tasks. As a result, they came to self-study: everyone sat and wrote to himself.
')
But we made 2 important conclusions:
- Coding Dojo is cool, but there must be an organization and a leader (we will return to these sessions later)
- Making toys is very exciting and interesting; against the background of the development of corporate applications, it was a fresh stream, which was very interesting to us. Many things were new: vectors, matrices, quaternions, vertices, indices, textures, etc.
Now we should say a special thank you to the management of our company, which supported our idea of ​​creating a toy and gave the go-ahead to the start of this experiment.
What are we going to write ...
We had to write under Windows 8, since the practical development of development for this OS was one of the conditions of our self-study. After searching for ideas for the game, we interviewed many of our colleagues, sifted through the options and remembered about ... Kolobka. And so, we decided to create a children's toy with the working title “Kolobok Adventures”.
The plot is simple: by simple manipulations with a tablet PC, you need to carry out Kolobok through a fantastic maze, where various obstacles and obstacles will stand in his way.
Our tools:
- C # 5.0, .Net for Windows Store apps
- Bullet (slightly converted to C #), SharpDX, DirectX 11
- inspiration, experience, brains and hands of five people (two developers, team lead, designer and artist)
What we started with ...
The idea of ​​publishing the development process came to us, unfortunately, not immediately, so for the moment we have already completed a certain list of tasks:
- working out ideas for toys;
- architecture development;
- familiar with DirectX;
- familiarity with SharpX;
- familiarity with HLSL;
- search for a physical engine, a wrapper for C #, familiarity with the engine;
- project structure;
- work with the display of primitive objects;
- work with the physics of simple objects;
- work with shaders (effects, light and shadows)
Design
The application architecture is divided into two levels: abstract and implementation level. Layering promotes code reuse, expansion and maintenance. The level of abstraction includes four basic concepts: “Game”, “Physics”, “Logic” and “Visualization”. The basic principles of the interaction of these components are described at this level:
- The “Game” combines all the rest and here lies the basic principles of the game itself (start of the game, pause, lose, win, etc.);
- “Physics” is a software component that describes the interaction of game objects with each other from a physical point of view: handling collisions of objects, calculating gravity forces, speeds;
- "Logic" is a component that controls the game without paying attention to the physical interaction of objects. Here the rules of the top level for the game are described: the calculation of any bonuses, the decision to win, lose, the non-physical interaction of objects (for example, when a character collides with an object: the object disappears and there are bonuses);
- "Visualization" is one of the simplest components of the abstract level, which describes the concept of visualizers who can draw objects in the game world.
The level of implementation in our version creates specific components of the game, physics, logic and visualization. Here we take into account the specifics of our task: an application under Windows Store and game features.

Physics
Physics is implemented using Bullet Physics - an engine for processing the physical interaction of game objects. The physics engine, in principle, can be written independently from scratch, using existing algorithms and solutions, if some unique physical conditions are needed, as well as enough time and experience. In our game there are unique physical conditions: we simulate a model of the world in which the gravity vector remains unchanged and the ground changes its inclination with respect to the gravity vector (in parallel, we are considering the realization of the game world with a change in the gravity vector). There is such a real child's game in which the balls need to be driven into a certain place passing the maze. The maze is tilted in different directions, while the ball rolls and you need to get into the right passes. But since there was no experience in writing such applications and there was little time either, we decided to look for ready-made solutions and apply them for this task. After some sorting through the few options, we stopped at the popular bullet engine rewritten for the XNA platform in C # (
http://code.google.com/p/bullet-xna/ ). It should be noted that the engine is not completely rewritten, some of the functionality is missing, but it is quite sufficient to be implemented. We had to remove all the bindings in the code to the XNA platform and remove completely the debugging information.
Visualization
The choice of visualization tools was made on the basis of a review of possible options for creating a game in managed code:
- XNA is not supported in the Windows Store — even articles were found that said that XNA would cease to exist;
- Monogame is an open source XNA implementation, and Windows 8 support is currently under development (we will probably use Monogame with SharpDX in the future);
- SlimDX is older than SharpDx, and better documented than SharpDX, but now it does not support DirectX 11.1;
- SharpDx - supports DirectX 11.1, is updated much more often than SlimDX, and also judging by the tests (http://code4k.blogspot.com/2011/03/benchmarking-cnet-direct3d-11-apis-vs.html) faster than SlimDx.
Therefore, we decided to use pure SharpDx without any engines as a managed wrapper over DirectX and created a semblance of our own game engine.
Expenses :)
- 2-3 cups of coffee
- 4 liters of tea
- About 2 kg sausages
- Candy is not counted
- 1-2 hours of discussions per day
And, in fact, we will be familiar
