Economic strategy "Sakhalin colony"
Sakhalin colony - an economic strategy whose goal is to survive. The player is given a typical or randomly generated playing field divided into cells.
Each cell represents a specific resource, or a blank field. At the beginning of the game, the player is given an administration building and 2 plots of land on which he can build resource-extraction structures. All buildings are destroyed over time and need to be repaired - for money gained from the sale of resources. The administration building is the main one - the impossibility of its repair leads to the end of the game.
To get a plus on income is not easy, and a rare, but expensive administration repair often breaks up beautifully constructed plans.
')
Once upon a time, I really liked the economic strategy of the “Sakhalin colony” of Grigory Zhmulevsky. Now it was from her that I decided to write my first completed game, and at the same time explore various aspects of C #. Having received a concise “Of course” from the author on the question of copying his game, I set to work.
Sources in C ++ are available on the author’s website, and I turned to them to copy these objects — the cost, how much the object lives, in what situations it is destroyed more or less, and so on. For the rest, I tried to rely only on myself.
Together with chrome, the size of the original is 640480. I chose the same dimensions of the application, 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. Little, but also good.
The internal logic of the game is almost completely preserved. Added brief reference.
Summary of development.
General
It was decided to make the game on XNA in particular because for him I already had some gui work.
A fairly simple architecture was chosen for implementation:
Game classes without using specific XNA classes, for the simplicity of a possible port to another engine in the future:
Xna class Game:
Class event_handlers:
Xml class:
Serialization
Serialization could in theory help to discard the cumbersome data storage / reading class using an XmlDocument.
However, in practice, when introducing the serialization functionality, I was faced with a number of tasks without which it could not work.
In particular, most of the static classes had to be made public. The result was 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 - 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 took off all the time for serialization. Adding try catch constructs to the game was able to get and display error information in 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 the serialization attribute [XmlIgnore]. However, these fields are necessary in 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, because he himself was never able to draw, but the search for suitable pictures
turned out to be surprisingly difficult. In the end, having tried to draw the icons myself, I saw what was going on normally (in my opinion), and it’s faster in time than searching for them on the Internet. At the moment there are only three pictures in the game from the Internet - money, food, gold. The rest are drawn in paint. Post-processing in a more serious editor is quite small. All the icons of land and buildings are in fact twice as large as those 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 Cards
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 the named array. A large number of files and difficulties with publishing made us think about texture maps. Gathering (almost) all
textures in maps managed to reduce the memory consumption of the application by almost 10 megabytes (the value of the “allocated memory” column in the controller decreased from 69 to 60 MB). The named array was also replaced with n separate variables.
Interface
Unfortunately, XNA does not have its own graphical interface. Connecting win form or wpf imposes its limitations. Since One of the goals of the project is to teach programming in C # as a whole and specifically in the gaming environment, it was decided to recall a relatively old bike - Gui under XNA.
Initially, this gui was conceived as a very powerful mechanism - an interface constructor. His power turned into huge blocks of code with hard-to-find errors and slow work. I had to cut a lot of code, simplify the work, reduce the number of auxiliary function calls to update.
The edit control was also written - accepting only numbers, decimal point, plus and minus signs (excluding plus and minus on the additional keyboard - did not find them in the XNA key list). Means gui, if necessary, create additional textures - pressing, pointing, inaccessible state. It turned out a small, but quite working gui.
Streams
The application uses windows, incl. modal. Windows-questions, messages, as well as a form of trade, should send some information to the program that will be processed.
During the work, the following solution was found: when the window is activated in a separate stream, the target method is invoked, for example, building repair. The cost of repair is being calculated, the activation flag of the window, the text of the question itself is transferred to the static question class.
The method of building repair (called flow) enters the loop by a flag — a sign that the user has received a response. Parallel to the execution of this cycle, in the Update method (main thread) a window is opened - the dialogue, gui execution, by pressing the yes key by the user yes or no, the corresponding flags are set in the static class of the question. The child thread goes out of the cycle, and continues the execution of the structure repair method based on the user’s response received.
In order not to generate many parallel threads and to screen other possible problems, all the game buttons are blocked when the question is activated. System buttons are not blocked, in particular because they use standard windows dialogs, which already 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
Each cell represents a specific resource, or a blank field. At the beginning of the game, the player is given an administration building and 2 plots of land on which he can build resource-extraction structures. All buildings are destroyed over time and need to be repaired - for money gained from the sale of resources. The administration building is the main one - the impossibility of its repair leads to the end of the game.
To get a plus on income is not easy, and a rare, but expensive administration repair often breaks up beautifully constructed plans.
')
Once upon a time, I really liked the economic strategy of the “Sakhalin colony” of Grigory Zhmulevsky. Now it was from her that I decided to write my first completed game, and at the same time explore various aspects of C #. Having received a concise “Of course” from the author on the question of copying his game, I set to work.
Sources in C ++ are available on the author’s website, and I turned to them to copy these objects — the cost, how much the object lives, in what situations it is destroyed more or less, and so on. For the rest, I tried to rely only on myself.
Together with chrome, the size of the original is 640480. I chose the same dimensions of the application, 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. Little, but also good.
The internal logic of the game is almost completely preserved. Added brief reference.
Summary of development.
General
It was decided to make the game on XNA in particular because for him I already had some gui work.
A fairly simple architecture was chosen for implementation:
Game classes without using specific XNA classes, for the simplicity of a possible port to another engine in the future:
- Class game with reference to the map
- Map class with reference to cell array
- Cell with your data and link to the building
- Building with your own data and cell index
- A static class containing all immutable data, incl. transfers.
Xna class Game:
- In update (), open / close dialog forms, call update controls.
- In draw () - drawing game elements, call draw controls.
Class event_handlers:
- Class-layer between the Game and game classes. The call of game methods is carried out only through it. Again, for the simplicity of a possible port to another engine. In it - work with flows.
Xml class:
- Work on the preservation, reading data.
Serialization
Serialization could in theory help to discard the cumbersome data storage / reading class using an XmlDocument.
However, in practice, when introducing the serialization functionality, I was faced with a number of tasks without which it could not work.
In particular, most of the static classes had to be made public. The result was 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 - 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 took off all the time for serialization. Adding try catch constructs to the game was able to get and display error information in 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 the serialization attribute [XmlIgnore]. However, these fields are necessary in 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, because he himself was never able to draw, but the search for suitable pictures
turned out to be surprisingly difficult. In the end, having tried to draw the icons myself, I saw what was going on normally (in my opinion), and it’s faster in time than searching for them on the Internet. At the moment there are only three pictures in the game from the Internet - money, food, gold. The rest are drawn in paint. Post-processing in a more serious editor is quite small. All the icons of land and buildings are in fact twice as large as those 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 Cards
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 the named array. A large number of files and difficulties with publishing made us think about texture maps. Gathering (almost) all
textures in maps managed to reduce the memory consumption of the application by almost 10 megabytes (the value of the “allocated memory” column in the controller decreased from 69 to 60 MB). The named array was also replaced with n separate variables.
Interface
Unfortunately, XNA does not have its own graphical interface. Connecting win form or wpf imposes its limitations. Since One of the goals of the project is to teach programming in C # as a whole and specifically in the gaming environment, it was decided to recall a relatively old bike - Gui under XNA.
Initially, this gui was conceived as a very powerful mechanism - an interface constructor. His power turned into huge blocks of code with hard-to-find errors and slow work. I had to cut a lot of code, simplify the work, reduce the number of auxiliary function calls to update.
The edit control was also written - accepting only numbers, decimal point, plus and minus signs (excluding plus and minus on the additional keyboard - did not find them in the XNA key list). Means gui, if necessary, create additional textures - pressing, pointing, inaccessible state. It turned out a small, but quite working gui.
Streams
The application uses windows, incl. modal. Windows-questions, messages, as well as a form of trade, should send some information to the program that will be processed.
During the work, the following solution was found: when the window is activated in a separate stream, the target method is invoked, for example, building repair. The cost of repair is being calculated, the activation flag of the window, the text of the question itself is transferred to the static question class.
The method of building repair (called flow) enters the loop by a flag — a sign that the user has received a response. Parallel to the execution of this cycle, in the Update method (main thread) a window is opened - the dialogue, gui execution, by pressing the yes key by the user yes or no, the corresponding flags are set in the static class of the question. The child thread goes out of the cycle, and continues the execution of the structure repair method based on the user’s response received.
In order not to generate many parallel threads and to screen other possible problems, all the game buttons are blocked when the question is activated. System buttons are not blocked, in particular because they use standard windows dialogs, which already 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
Source: https://habr.com/ru/post/174349/
All Articles