Nepostmortem game "Roads of Rome" ("Roads of Rome")

In this article I want to briefly talk about the development of the casual game "Roads of Rome" ("Roads of Rome").
Perhaps this will be interesting to those who are just going to start developing games. Actually, there will be little about programming, 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 is to build a road. Along the way, you have to disassemble the rubble, repair / build / improve buildings.
In the development of the game, the PopCap Framework was used.

Briefly about myself

I’ll clarify right away that I’m not a novice developer. Previously, I worked for a game development company. It was there that I saw and felt on myself 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 development, I recommend thoughtfully reflecting on a variety of problems and solutions to these problems, on the choice of tools that you are going to work with, on what requirements are presented to your game by the publisher, etc.

About the role in the project

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

Development

Communication in the project was carried out mainly through Skype, sometimes Jabber.
A list of tasks was maintained at 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. It’s even convenient in some way (here it would be a matter of putting the pro -ities in one click). Yes, there is no history of bugs and features, but it works quite quickly and simply and you do not need to keep your server. For a project of this level with one programmer, this is enough.
I store the code and art in a free SVN storage (there is a quota of 500 MB, I have enough).

The project is multilingual, there are Russian and English versions. The text is set in external XML (standard for the 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 assemblies for these purposes: Release (English) and ReleaseRus (Russian).

The final assembly of the project is done using MSBuild. It comes with the .NET Framework, I am using the version from .NET 4 (the version from 2nd .NET did not want to work with '.sln' from Visual C ++ 2008 Express). This is done like this: Of course, it was possible to figure out the MSBuild settings in an external file, but I have enough of this solution. After execution, if there are no errors, we get two executables.

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



Still there is a need to send source codes. To simplify this task, a Python script was written (which I just started to study and already recommend to familiarize myself with as a very useful, simple and convenient tool), which packs files from the specified directory into a ZIP archive, after separating the grains from the chaff by the file filter and folders.

Programming

The development of the game was conducted under Windows on the well-known and well-established PopCap Framework.
Visual Studio 2008 Express (C # and C ++ versions) was selected as the IDE. The game itself was developed in C ++, in C # the toolkit for it (level editor, comic book editor and small utilities).
The editor was made in a hurry, so it could have been better, but what we have is what we reap.
Levels are stored by themselves in XML, conveniently, considering that levels are created in C # and are 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 developments. Well, the language is stricter, it does not accidentally shoot itself in the foot.


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


Regarding the game entities themselves, the road is probably interesting - it is drawn along the spline curve. The curve is constructed using reference points, then a “tape of triangles” is constructed relative to it (according to the normals at each point). 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 always falls on all objects from one point, but the rotated texture does not fit into this picture. To solve the problem, I had to make a software calculation of the lighting on the road heights map (normal old-school bump mapping) and draw the correct lighting on the road in the second pass. And no shaders (and where do they come from in DirectX 7).

Water is made very simple. First, draw the “bottom”, then draw a texture of water, then draw the land using the mask.

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

The earthquake was also made 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 render by sine in a certain range. Together with the corresponding sound, a pretty good surface jitter is obtained.

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

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

For convenient adjustment, twining effects (smooth movements with deceleration / acceleration) made their adjustment also in external XML.

From my own experience I’ll say that you try to transfer the maximum of settings to external files so that, changing something small, you don’t have to start compiling the project (it eats away from 30 seconds to 10 minutes depending on the project and the nature of the changes). And it is very desirable that the game can reload external settings without restarting the game (saving from 20 seconds to a minute depending on the number of images in the game). This seems like little things, but when you have to edit some parameter 5-10 times (well, if one), a significant amount of time flows very quickly, and constant pauses in 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 needed to be scripted, and at the end of the project there was no time for this.

3rd party libraries

The editor uses the SourceGrid Grid control . And a little later, the OpenTK library was involved (by the way, version 1.0 was recently released).

In the game itself were used:

• STLPort - Needs No Submission
• MicroPather - search for the way, really liked, works great. OpenSource (zlib / libpng License)
• PugiXML is a fast XML parser. Convenient and easy to use. OpenSource (MIT License)
• yasper - "A non-intrusive reference counted pointer". Saved me from finding most of the possible memory leaks. OpenSource (zlib-license)
• CppTweener is a convenient tweener, a similar functionality was liked back in ActionScript, and before there was a lack of an analogue in C ++. OpenSource (MIT License)
• PopCap framework - comments below. OpenSource (own license)
• Pyro effects - engine for particle effects. Proprietary, paid (free for the first game)
• Bass.dll - sounds and music. Proprietary, paid

I think it will be interesting to write a little about each library separately, because 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 working with him and knew what kind of animal it was and what it was eaten with.
Do not listen to shkolota, who says that such a framework is written in a month of work. This framework provides you with many amenities: a resource manager, loading resources in a separate stream, a system of widgets and controls, tracking memory leaks, a system for rendering bitmap fonts, packing multiple resources into one PAK file, an integrated XML parser, an integrated profiler, stack- trace, a simple and convenient API, the framework code takes into account many "special" situations and much, much more.
Of course, not everything in it is perfect. To work with Russian characters, you will have to “patch and update” a little (© “Bo Shop”). The built-in parser has errors, they will also have to be fixed. Well, the worst part is that PopCap has stopped updating this framework. However, there is an unofficial version of the 1.34 framework.- it fixed some flaws (at least the parser and Russian characters). But the main drawback remains: the framework is written for DirectX 7, and Windows Vista / 7 has some features 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 generally impossible to play on ATI cards (a black screen was displayed), then, however, a normal driver came out. On NVidia, with some version of drivers (in Vista / 7), support for 3D ceased to be detected, so the game went in Software-mode and, accordingly, was very slow. Therefore, at the moment I am forced to state that it is no longer possible to develop on the PopCap Framework - the circle of problems unsolvable by the developer 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 that is a wrapper over the Kanji engine , called SexyKanji and has a similar 98% 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”. Information also appeared that the engine was sold to another company and now, an equal version in functionality, will cost $ 1000 already (in addition, this is only for one workplace).
There is also a version of the PopCap Framework, for working on platforms other than Windows - this is the TuxCap Framework , but so far there hasn’t been time to see it, if anyone has used it, describe your experience in the comments.

Possible free alternatives for game development:

• HGE - from the pros: DirectX8. Of the minuses: DirectX8 - there will be problems on Vista / 7, not cross-platform, too low-level (IMHO), it seems it has not been updated for a long time either, I don’t like it :)
• Playground SDK - from the pros: updated, cross-platform, sophisticated. Of the minuses, there is only one, but which one: the source code of the engine itself is closed and if you stumble upon some kind of bug in the engine, you just have to wait for the fix, you yourself can hardly solve the problem

STLPort

Replacing MS STL. What for? Then, which is faster, it consumes less memory. It is 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 a project on the PopCap Framework forum, a library was found to find the path: AStar Library .
Maybe my hands are crooked, but I could not get her to work normally. She found a way, but very much it was not optimal. It was decided to look for another "passfinder". That was Micropather . At first there were problems due to path caching, but maybe I forgot to drop the cache somewhere. But after disabling 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 of 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’m not sure that there aren’t any errors in it yet. Well, besides, PugiXML is one of the fastest parsers, and speed is good :)

Cpptweener

I did not find any analogues for twining parameters in C ++, so I used this tweener . I had to debug deeply several times to fix some errors, now it seems to work fine, but sometimes I want to rewrite its code in the right way.

Yasper

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

Bass.dll

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

Pyro effects

At first, for the effects, it was decided to screw the effects from another OpenSource framework - from HGE. The main motive is the existence of a third-party port of the effects engine on PopCap ( SexyHGEparticles ) and a 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 complicated in it. And the port of the effects engine does not work as it does in the editor, as a result of which the effects behaved in a strange way, as if their gravity in the game is weaker, but this could not be fixed right away.
This went on for some time. At some point, it was impossible to continue working without normal effects, so I began to study other libraries and effect editors for them. What we needed: simple integration in the PopCap Framework and the ability to create complex effects. Magic Particles
was first considered.. It seems like a powerful editor, a large database of samples with rather complex effects. I began to screw it. I don’t remember why I climbed to see how it loads images. But when I saw that when creating the effect, it first saves the image to disk, and only then loads it into memory (this is true for the PopCap Framework, with other engines everything can be different) ... I immediately refused this solution, well, I don’t trust such “Hacks,” and I had neither the strength nor the desire to write normal support. Although the editor looked interesting.
Next test subject Pyro. It turned out to be quite simple to screw the system of effects, especially since there was a small wrapper for the PopCap Framework. The editor is also quite imagined. But as a result of using 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 non-display of the effect in the game). Because there was no more time to mess around, and Pyro was more suitable for us than not, we decided to stay on it.

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

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

Instead of a conclusion

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

Well, a link to the game itself .