Economic Strategy “Sakhalin Colony”

Sakhalin colony is an economic strategy whose goal is to survive. The player is given a standard or randomly generated playing field divided into cells.
Each cell represents a specific resource, or a clean field. At the beginning of the game, the player is given the administration building and 2 plots of land on which he can build resource-extracting structures. All buildings collapse over time and require repair - for the money earned from the sale of resources. The administration building is the main one - the impossibility of its repair leads to the end of the game.
It is not easy to get a plus in income, and a rare, but expensive repair of the administration often breaks beautifully built plans.





Once upon a time, I really liked the economic strategy of Sakhalin Colony by Grigory Zhmulevsky. Now it was from her that I decided to write my first game brought to the end, and at the same time study various aspects of C #. Having received from the author a concise "Of course" to the question about copying his game, I set to work.
C ++ sources are available on the author’s website, and I turned to them to copy these objects - the cost, how much the object lives in, in which situations it is destroyed more or less, etc. Otherwise, I tried to rely only on myself.
Together with chrome, the size of the original is 640x480. I chose the same application sizes, but without chrome. Due to this, as well as more optimal use of space, it was possible to increase the size of the map cell by 2 pixels. A little, but also good.
The internal logic of the game is preserved almost completely. Added brief help.

Brief information on the development progress.

General It
was decided to make the game on XNA in particular because for him I already had gui know-how.
For implementation, a rather simple architecture was chosen:
Game classes without using specific XNA classes, for simplicity of a possible port to another engine in the future:
  • Game class with map link
  • Map class with reference to an array of cells
  • Cell with its data and a link to the building
  • Build with your data and cell index
  • A static class containing all immutable data, including transfers.

Xna class Game:
  • In update () - open / close dialog forms, call update controls.
  • In draw () - rendering game elements, calling draw controls.

Class event_handlers:
  • Interlayer class between Game and game classes. The call of game methods is carried out only through it. Again, for simplicity, a possible port to another engine. In it, work with threads.

Xml class:
  • Work on saving, reading data.


Serialization
Serialization in theory could help to abandon the cumbersome data storage / read class using XmlDocument.
However, in practice, when implementing the serialization functionality, I came across a number of tasks without which it could not work.
In particular, I had to make most of the static classes public. The result is a static top-level class containing a link to the public class of the game. This approach allowed on the one hand to preserve the simplicity of accessing the necessary data, on the other hand, to use serialization. During programming and intermediate tests, I encountered a strange behavior of the program when opening and saving data - everything worked on the development computer, but on the other the game crashed all the time to serialization. Adding try catch constructions to the game, we managed to obtain and output information about errors to a file. It turned out that the serializer (only!) On the client computer could not parse some static classes. It turned out that the problem is in the fields - enumerations that are declared in the auxiliary static class. After a long search, I was advised to exclude them from serialization using the [XmlIgnore] attribute. Nevertheless, these fields are necessary in the logic, so it was decided to duplicate them into string fields, and after reading xml immediately parse the string representation into the corresponding enumeration. It worked.

Content
At first I planned to fill the game with images marked free from the Internet, as He himself never knew how to draw, but the search for suitable pictures was
surprisingly difficult. As a result, having tried to draw the icons myself, I saw what works fine (in my opinion), and is faster in time than looking for them on the Internet. At the moment, the game has only three pictures from the Internet - money, food, gold. The rest are painted in points. Post-processing in a more serious editor is quite small. All the icons of land and buildings in fact are twice as many as are displayed in the game - so it was easier to draw them. In addition, icons of this size will be easier to use in the future. Reducing is easier than increasing.



Texture maps
Initially, all the graphic content was broken - each button has one file. Moreover, the built-in XNA content mechanism was not used - all textures were loaded into the game in the standard way for C # and then converted to Texture2d via Stream. Textures were stored in a named array. A large number of files and difficulties with publishing made us think about texture maps. Having collected (almost) all the
textures in the cards, it was possible to reduce the memory consumption of the application by almost 10 megabytes (the value of the “allocated memory” column in the manager decreased from 69 to 60 mb). The named array has also been replaced with n separate variables.

Interface
Unfortunately, XNA does not have its own GUI. Connecting win form or wpf imposes its limitations. Because one of the goals of the project is to teach programming in C # in general and specifically in the gaming environment, it was decided to recall the relatively old bike - gui under XNA.
Initially, this gooey was conceived as a very powerful mechanism - an interface designer. Its power turned in huge blocks of code with hard-to-find errors and slow operation. I had to cut a lot of code, simplify the work, reduce the number of calls to auxiliary functions in update.
The edit control was also written - accepting only numbers, decimal point, plus and minus signs (excluding plus and minus on the additional keyboard - I did not find them in the list of XNA keys). With the help of gui, if necessary, additional textures are created - pressing, hovering, inaccessible state. It turned out to be a small but quite working gui.



Streams The
application uses windows, incl. modal. Question windows, messages, as well as a form of trading, must send some information to the program that will be processed.
In the course of work, the following solution was found: when the window is activated in a separate stream, the target method is called, for example, repair of the building. The repair cost is being calculated, the window activation flag and the text of the question itself are passed to the static question class.
The method of repairing the structure (called flow) enters the cycle by the flag - a sign of receiving a user response. Parallel to the execution of this cycle, in the Update method (main thread), a window - a dialog is opened, gui is executed, when the user presses the yes or no key, the corresponding flags are set in the static question class. The child stream exits the cycle, and continues to execute the building repair method, focusing on the user's response.
In order not to generate a lot of parallel threads and to screen other possible problems, all game buttons are blocked when the question is activated. System buttons are not blocked, in particular because they use standard windows dialogs, which completely block the application.

application
Written under win 7, requires installed XNA components, .net 4.0 framework - everything you need is downloaded automatically during the installation process.
XNA components can be downloaded separately www.microsoft.com/en-us/download/details.aspx?id=27598

Exe: rusfolder.com/35736586

Setup: rusfolder.com/35736588

Only registered users can participate in the survey. Please come in.

Are you interested in games of this genre?

  • 42.2% Yes 229
  • 28.7% Rather Yes 156
  • 24.3% By mood 132
  • 9.4% Rather Not 51
  • 10.7% No 58

Are you interested in the possibility of developing a published game?

  • 67.6% Yes 310
  • 35.5% No 163

Also popular now: