Geekly Articles each Day
📜 ⬆️ ⬇️

Neither the game “Roads of Rome” (“Roads of Rome”)

In this article I want to briefly describe the development of the casual game Roads of Rome (Roads of Rome).
Perhaps it will be interesting to those who are just going to start developing games. Actually about programming will be little, more about what was used in the development process.


Briefly about the game

Roads of Rome is a casual click-manager / strategy game. The main goal - the construction of the road. Along the way, it is necessary to dismantle debris, repair / build / improve buildings.
In the development of the game was used PopCap Framework.


Briefly about yourself

Immediately clarify that I'm not a novice developer. I previously worked for a game development company. It was there that I saw and felt the process of creating games. And this experience was very useful to me. Many things seem unimportant until you come across them yourself. Therefore, before starting the development, I recommend to thoughtfully reflect on a variety of problems and solutions to these problems, on the choice of tools you are going to work with, on what requirements the publisher has for your game, etc.
')
About the role in the project

In this project, I participated as a programmer in the Whiterra team. Art, music, level design, etc. performed by other people. The development was carried out remotely and took approximately six months of calendar time.

Development

Communication in the project was carried out mainly through Skype, sometimes Jabber.
The task list was maintained in Google Docs. A shared document in which a numbered list and task priorities are determined by the background color of the line.

Despite my primary skepticism, this method of work was not so bad. Even in something convenient (here it would be necessary to exhibit the qualities of one click). Yes, no history of bugs and features, but it works quite quickly and simply and does not need to keep your server. For a project of this level with one programmer, this is quite enough.
I keep the code and art in the free SVN storage (there is a 500Mb quota, I’m happy with it).

The project is multilingual, there are Russian and English versions. The text is set in external XML (standard for PopCap Framework), therefore, for the Russian version, the text and some art with the name of the game are simply replaced. But since the icons in the resources and the text displayed in the file properties are different, that is, two types of assembly for this purpose: Release (English) and ReleaseRus (Russian).

The final build of the project is done using MSBuild. It comes with the .NET Framework, I use the version from .NET 4 (the version from the 2nd .NET did not want to work with '.sln' from Visual C ++ 2008 Express). This is done like this:

msbuild Game.sln /t:rebuild /p:Configuration=Release
msbuild Game.sln /t:rebuild /p:Configuration=ReleaseRus

It was possible, of course, to figure out the MSBuild settings in the external file, but this solution is enough for me. After execution, if there are no errors, we get two executables.

There is still a need to send the source. To simplify this task, the script was written in Python (which I just started to study and already recommend for familiarization as a very useful, simple and convenient tool), which packs files from a specified directory into a ZIP archive, preliminarily separating the chaff from the filter files and folders.

Programming

The development of the game was conducted under Windows on the well-known and well-proven PopCap Framework.
Visual Studio 2008 Express (C # and C ++ versions) was chosen as IDE. C ++ developed the game itself, a C # toolset for it (a level editor, a comic editor and small utilities).
The editor was done in a hurry, so it could be better, but, what we have, we reap.
Levels are stored on their own in XML, conveniently, given that levels are created in C #, and read in C ++.
Why C #? Because development on it is faster, compilation is faster (in comparison with C ++), the visual editor is convenient, there are own old practices. Well, stricter language, does not give himself a shot in the foot accidentally.


The game actively uses STL containers (mainly vector, map and hash_map from STLPort). Boost did not want to use it in principle, maybe in vain.


Regarding the game entities themselves, it’s interesting, probably, the road - it is drawn along a spline curve. The curve is built on the reference points, then relative to it (along the normals at each point) a “tape of triangles” is built. And then this tape is textured. Thus, it turns out that the texture for the road is small and suitable for several levels. During the development process, it turned out that this option does not look very good, because the light in the game on all objects always falls from one point, but the rotated texture does not fit into this picture. To solve the problem, we had to make a software pre-calculation of the lighting on the road height map (the usual old school bump mapping) and with the second pass draw the correct lighting on the road. And no shaders (and where do they come from in DirectX 7).

Water is made quite simple. First we draw the “bottom”, then we draw the texture of the water, then we draw the land on the mask.

Weather phenomena (rain / snow / sandstorm) are created by ordinary self-written 2D particles.

An earthquake is also quite simple - part of the level is drawn into a separate buffer (unfortunately programmatically) and then superimposed with translucency on the screen, shifting the coordinates of the drawing along the sine in a certain range. Together with the corresponding sound, a pretty good surface tremor is obtained.

The playing field itself is divided into cells of 16x16 pixels, along which the search for the path, the movement of units, the location of the game elements takes place. By the way about finding the way. To search for the unit path, use A * (the library is listed below). To determine the availability of game elements, a wave algorithm is used (the simplest diamond-shaped wave). Simple and convenient.

For convenient work with controls in dialogs, I had to write a wrapper that controls, their position and parameters loads from XML. Because of this, I had to shake up the PopCap Framework control system (get rid of int identifiers and switch to string identifiers). But it turned out to be convenient, it was a pity to write the editor, but it is more convenient than changing the position of the buttons in the code, and then recompiling each time.

For convenient tuning, twinning effects (smooth movements with slowing down / acceleration) made their settings also in external XML.

From my own experience I will say - try to make a maximum of settings in external files, so that changing something small does not have to start a project compilation (it eats from 30 seconds to 10 minutes of time depending on the project and the nature of the changes). And it is very desirable that in the game it was possible to reload the external settings without restarting the game (saving from 20 seconds to a minute depending on the number of images in the game). This seems trivial, but when you have to edit a parameter 5-10 times (well, if one), then significant time flows very quickly, and constant pauses in the work do not contribute to a good mood.
I did not manage to fasten the scripts, although at the beginning of the project it was not clear what exactly you need to be scripted, but at the end of the project there was no time for that.

Third Party Libraries

The editor used Grid-control SourceGrid . A little later, the OpenTK library was involved (by the way, version 1.0 was recently released).

In the game used:

I think it will be interesting to write a little about each library separately, for there is something.

PopCap Framework

This old-timer was chosen for several reasons. Firstly, the customer wanted it, because he already had experience with this framework. Secondly, I myself had sufficient experience with it and knew what kind of animal it was and what it was eaten with.
Do not listen to shkolotu, which says that such a framework is written for a month of work. This framework provides you with many conveniences: resource manager, loading of resources in a separate thread, system of widgets and controls, tracking of memory leaks, rendering system of bitmap fonts, packing of many resources into one PAK file, embedded XML parser, built-in profiler, stack- trace, simple and convenient API, the framework code takes into account many “special” situations and a lot of other things.
Of course, not everything in it is perfect. To work with Russian characters - you will have to “patch and zapdeytit” a bit (© “Shop Bo”). The built-in parser has errors, they will also have to be fixed. And the worst thing is that PopCap has stopped updating this framework. However, there is an unofficial version of the 1.34 framework - it fixes some shortcomings (at least a parser and Russian characters). But the main drawback remains: the framework is written for DirectX 7, and Windows Vista / 7 has some peculiarities when working with such antiques. In addition, ATI / AMD and NVidia in their drivers support DX7 on a residual basis, and because of this, many users have problems. At one time it was impossible to play on ATI cards at all (a black screen was displayed), then, however, a normal driver came out. On NVidia, with some version of drivers (in Vista / 7), 3D support was no longer determined, so the game went to Software-mode and, accordingly, it slowed down a lot. Therefore, at the moment I have to state that it is no longer possible to develop on the PopCap Framework - the range of problems that the developer cannot solve is too wide.
For those interested, I note that there is an unofficial forum on the PopCap Framework.
There is also a version of the framework, which is a wrapper over the Kanji engine, called SexyKanji and has a 98% similar API. It resolves obsolescence problems (as it works on DirectX 8/9 or OpenGL). In addition, the cross-platform framework, which can not but rejoice. The SexyKanji add-on itself is still OpenSource, but the Kanji engine is paid (something around $ 300). SexyKanji is good, but when you switch to it, some things will have to be “finished”. It also appeared that the engine was sold to another company and now, the version being equal in functionality, will cost $ 1000 (besides, this is only for one workplace).
There is another version of PopCap Framework, to work on platforms other than Windows - this is the TuxCap Framework , but so far there has not been time to see it, if anyone has used it - write your experience in the comments.

Possible free alternatives for game development:


STLPort

Replacing MS STL. What for? Then, which runs faster, memory consumes less. Stable and does not cause any complaints. Recommend.
I got used to it so much that I almost forgot to write about STLPort .

Micropather

At the very beginning of work on the project on the forum dedicated to the PopCap Framework, a library was found to find the path: AStar Library .
Maybe my hands are crooked, but I couldn’t work it out normally. She found a way, but very much he was not optimal. It was decided to look for another “driver”. That was the Micropather . At first there were problems due to path caching, but maybe it was me who forgot to reset the cache somewhere. But after turning off the cache, everything worked as expected. The library is simple, you only need to include the header file. Recommend.

PugiXML

I use this parser to read all my XML (except those that are standard for the PopCap Framework). I do not use the built-in, because it is not very convenient and I am not sure that there are any errors in it yet. And besides, PugiXML is one of the fastest parsers, and speed is good :)

Cpptweener

I no longer found analogs for twinning parameters in C ++, so I used this twiner . I had to debug deeply several times to correct some errors, now it seems to be working fine, but sometimes I want to rewrite its code in the right-way way.

Yasper

Just a good and very smart pointer . The main thing is not to do cross-references, otherwise it will not work, it is checked :) But PopCap will write about this in mem_leaks.txt (in Debug mode).

Bass.dll

At the very beginning of the project’s life, Audiere.dll was used. Free, keeps the necessary functionality, later even found AudiereMusicInterface for full integration with the PopCap Framework. All is good, but it drops on some tricky configurations. Simply and suddenly falls. My Athlon 64 X2 and Windows XP sometimes crashed. It was decided to switch to paid Bass.dll . It seems to work well (there is one non-fatal bag, but it can be tolerated). I use version 2.3.0.3 - the previous ones have serious bugs, and for newer ones, you need to rewrite the library support in the PopCap Framework.
This library is free for non-commercial use.

Pyro effects

First, for the effects it was decided to screw the effects of another OpenSource framework - from HGE. The main motive is the existence of a third-party port effects engine on PopCap ( SexyHGEparticles ) and the free effects editor from HGE. Almost immediately it became clear that it is impossible to use IT normally. The editor is unstable, and it is impossible to do anything complex in it. And the effects engine port does not work as it did in the editor, with the result that the effects behaved in a strange way, as if their gravity in the game is weaker, but it did not work out right away.
So lasted for a while. At some point, without normal effects, it was impossible to continue working, so I started studying other libraries and effects editors for them. What we needed: simple integration into the PopCap Framework and the ability to create complex effects.
First, the Magic Particles was reviewed. Like a powerful editor, a large base of samples with fairly complex effects. I started to fasten it. I do not remember why I climbed to watch how it loads the images. But when I saw that when creating an effect, he first saves the image to the disk, and only then loads it into memory (this is true for the PopCap Framework, everything can be different with other engines) ... I immediately refused this decision, well, I don’t trust me “Hakam”, and I had no strength, no desire to write normal support. Although the editor looked interesting.
The next test subject is Pyro . It was quite easy to fasten the effects system, especially since there was a small wrapper for the PopCap Framework. The editor is also quite his own. But as a result of the use it turned out the following: not all effects in the game look the same as in the editor (visually - something is wrong with the color addition options), not all effects work in the game, despite the fact that they work in the editor (maybe I did something wrong, but the inclusion of some options in the effect leads to the non-display of the effect in the game). Because There was no more time to mess around, and Pyro approached us more than it did not, we decided to stay on it.

SPARK . There is also such an engine for particle effects. There is even an OpenSource editor on the net. But I found him much later (and he came out later than I needed). It was not possible to use it yet, the editor did not compile at once (some dll were not enough). If anyone used - tell me how it is to you.

For the effects of rain / snow / sandstorm used its own particles, so it turned out to be simpler and more versatile.

Instead of conclusion

I hope someone will be helped by my experience of choosing between these or other libraries. After all, it’s just a few sentences in words, and in the process of development it’s a few capacious phrases and a few days of work that you don’t want to spend at all on picking in someone else’s code and realizing that this code doesn’t suit you.
Questions and clarifications in the comments.

Well, the link to the game itself.

Source: https://habr.com/ru/post/105011/

More articles:


All Articles