We are surrounded by a three-dimension world and that’s why it’s obvious that we got used to interact with three-dimension objects. That is why, in the majority of cases three-dimensioning representation of some process, for example a game, is preferable for an end user, than something other. Due to that fact, three-dimension applications, at other equal conditions, will be better perceived by users, than two-dimension ones. But 3D applications have 2 serious disadvantages:
- 3D applications are much more difficult to implement;
- 3D applications demands much more calculating resources and if there are not enough of such resources, then the application won’t be able to function on a proper level, in particular, a necessary performance won’t be provided.
In order to avoid these shortages and at the same time get some 3D traits a technology on the implementation of pseudo-3D on the base of using isometric projection was offered. A simple principle lies in the ground of this technology - user view point should be at some angle to the plane on which the objects are placed. A rectangular isometric projection is more frequently used. In such a projection, axonometric axes form themselves 120° angles and Z’ axis is vertically directed.
Rectangular Isometric Projection
We decided to use this technology for creating pseudo-3D game for Android. The game matter is to drive a block, consisting of two cubes, moving it on some plane, into a hole and not fall behind the boundaries of this plane.
Isometric projection on the example of a game
This article is devoted to the methodic of creating pseudo-3D graphics on the example of a Android game being developed by AndroidDevStudio.
There are two main methods to build such projections:
- Projecting of an ordinary rectangular sprite (bitmap) into a rhomb directly in a moment of its drawing by turn operation and shrinking on a diagonal operation;
- Pre-rendering - that is the use of sprites, projected on a plane by isometric projection in advance.
Method 1 demands some volume of calculations and that is why it is slower than method 2. Method 2 is quicker and doesn’t demand more memory for the case of fixed axes than method 1 that is why it is more widely used. It is considerable, that method 2 can have several principally different implementations using different types of sprites for getting rhomb projections:
- Using rectangular sprite with “transparent” areas (into which projection rhomb is written);
- Using a special “rhombic” sprite with a matrix of lines of variable length;
- Combined method with a rectangular matrix but without transparent areas - the output is done on a rhomb, which is calculated directly at the moment of output.
On practice, all these implementations are used, 1 is more frequently used - but just because the majority of universal graphical libraries (the library used in Android as well) don’t have means to output a specialized “rhombic” sprite.
Due to that, we will use method 1.
See the next part “Programming Game Field” very soon in this blog! Sign up for RSS feed or follow us on twitter to be posted about updates!
