Remake Race Into Space: how to improve the gameplay and interface?

The idea to celebrate Cosmonautics Day 2012 by watching films on this topic led to the fact that I was seriously interested in the history of cosmonautics. And here was the place to the game, which I knew, but was not interested enough to become familiar. She came out in 1993 and was then called Buzz Aldrin's Race Into Space. Legendary astronaut Buzz Aldrin was involved in its development as a technical consultant. In 2005, the developers bought the rights and re-released the game under the GPL license, removing the name Aldrin. The game is very interesting and is strongly recommended for familiarization, however, after a while, the moments in which the game can be improved became obvious to me. This is how the Open Source project Space Race: The Game appeared. I also want to share with you a story about him and the improvements that are planned, under the cat.

Brief description of the game

The original Race Into Space is an economic step-by-step strategy in which the player manages the USSR / US space program. Investigating launch vehicles, unmanned and manned spacecraft, controlling a cosmonaut corps, the player launches space missions, gaining prestige points depending on their result and degree of primacy. The rarity and value of gameplay is that:

1. In the absence of time constraints on the decision (the game is turn-based)
2. The player assesses the degree of risk of their elementary actions (makes decisions on the start / cancellation of the mission, wanting to beat the opponent)
3. Implementing a long-term strategic program (the end of the game is a manned lunar mission, to which there are many steps)

A detailed review is contained here . The review will be useful to those who want to learn more about the original game.

The original game is available on the official website.

Decision making on remake development

Noticing the aspects of the game, which, in my opinion, it is possible to improve, I decided to start a project to develop a remake of this game. The option of joining the original project and adding improvements there did not suit me for the following reasons:

1. The game of 1993 development contains a very old code in C / C ++, languages ​​that I do not know, and, for sure, teems with restrictions stemming from the lack of resources of the then computers. In short, irrational and do not want to delve into it.
2. Some changes are so fundamental that it is easier to re-do than to redo what is already there.

')

Project Characteristics

1. Development language: Java as one of the most popular, and I like it irrationally.
2. Development Model: Open Source. The game, in addition to the main goal of pleasure, should give knowledge about the history of space exploration and arouse interest in this subject. This, firstly, should not be paid, and, secondly, should be able to develop beyond my efforts.

So, after the introductory part, I offer for your consideration a description of the improvements I have conceived, with explanations why I want to do just that.

Part one. Gameplay improvements

1. Concealment of reliability

In the original game, the reliability of the component (launch vehicle or spacecraft) is shown explicitly. Accordingly, the player knows exactly when it makes no sense to investigate, for example, the launch vehicle and it is time to start the launches. A mathematically savvy player can calculate the reliability of a mission by multiplying the reliability of its elements. It seemed to me wrong, so in the remake the reliability of the components is hidden from the player. In fact, Korolev decided to start up “Vostok” with a man only after two successive starts with dogs, no one showed him any probability of success. Accordingly, in the remake, the components have the time of their research, for which they gain reliability with some random deviation, and then the player can “refine” these components if his reliability does not suit him.

2. Increasing the number of unmanned missions

In the original game, unmanned missions are very few: a simple satellite, flying missions of the Moon and five planets, unmanned landing on the moon. This seems to me an unnecessary simplification, since it does not convey intrigue, for example, taking photographs of the far side of the Moon, or does not show the importance of the Lunokhod or Luna-16. Also, in terms of gameplay, I want to give an unmanned alternative to landing a man on the moon. Those. a player who has developed very successfully at the beginning of the game may try not to risk people (or get weak funding because of his success, like the USSR in real life) and win the game on points, sending machine guns to the Moon, and doing, for example, orbital stations ( approximately what the USSR did in real history). In the remake, the main missions of automata with a small alternative component - the transfer of Voyagers, Veg and rovers to the past have already been realized.

3. Introduction to the game component delivery time

In BARIS, the component was bought and delivered to the spaceport instantly. This is extremely unrealistic and deprives the player of the intrigue of random events "the production of component N is delayed." Despite the risk of making the game less interesting, I hope this item will add strategic depth and the need for planning player actions.

4. Reducing the duration of the course in game time

The original move was half a year of playing time. Accordingly, the game could have lasted from ~ 22 moves (landing on the moon in 1968) to ~ 50 moves (the time limit worked). This led to the fact that random events were too strong, for example, quite often blocked the possibility of buying components or launching any missions. With such an importance of a move, bad luck or mistake had too much significance, which was sometimes very annoying. In the remake, one move takes 1 month of playing time.

5. Adding flexibility to winning conditions

In the original game, the condition for victory was the landing of a man on the moon. In the remake, a flexible system for choosing the rules for ending the game is planned, with batches of different lengths and an optional end of the game by landing a person on the Moon.

6. Complicating Government Relations

The government gives tasks and finances. In the real history of the USSR, he lost the moon race due to the fact that they did not give money, despite all the successes before that. Also, this item should replace positive feedback (success - more money - more success - even more money - ...) with negative (success - the need to improve professionalism, since they will not give money, since you already have it all).

7. Replacement of the “hinged accelerators” module with modifications of launch vehicles

In the original game there is a module "mounted accelerators", which can be added to some launch vehicles, increasing their payload. In reality, only the PH “Titan-III” had something similar, while the more common option was to add or modify the upper stage (the “E” and “I” blocks of the USSR on the R-7, “Agena” and “Centaur” in USA on the "Atlas"). To enhance the realism (and the separation of the reliability of various modifications), it was decided to present one type of launch vehicle with several modifications.

8. Replacing accelerators with planetary coefficients

There are three types of accelerators in BARIS - A, B, C. They are needed for lunar missions, but without a manual you can not figure out which one is needed. To simplify the situation, it was decided to introduce mass increase factors (for example, the Moon - x3, Mars / Venus - x10, etc.). Accordingly, the Soyuz can be raised to a low near-earth orbit with the PH “R-7 -“ I ”block”, but in order to send it to the Moon, you will need the “Proton-K”.

9. Prohibition of flying to the moon for second-generation vehicles (Sunrise, Gemini)

In the original game, manned missions to the Moon are possible up to landing on second-generation vehicles (Sunrise, Gemini). Despite the fact that there were some prerequisites for such a solution, there were plans to modify Gemini for lunar missions, from the point of view of real design, very serious improvements were needed, and from the point of view of gameplay, the third generation devices (Soyuz, Apollo) they become de facto unnecessary, since nothing new is given to the player.

10. Preservation of some decisions made for balance

In the original game, the Voskhod crew was reduced to two people, but in return it was given the opportunity to dock, which was not possible in reality. The decision was made out of obvious balance considerations - the ships of the second generation in the game are designed to practice extravehicular activity and docking.

11. Transferring the reliability of VCD from research to testing

There is a very good idea in BARIS - it is impossible to “study” the docking. It is necessary to send missions that, with both successes and failures, increase the reliability of the docking. And this is despite the fact that the United States had no particular problems with docking. But with extra-shipping activity - they were. The astronauts were terribly tired, they could not carry out complete work plans. It seemed to me that, for the sake of historicity and interest, it would be good to extend the mechanism of “working out” the docking to WCD.

12. Obvious improvements

Multilingual support (now Russian / English, new languages ​​can be added without problems), normal multiplayer - all this was not in the original game.

Part two. Interface enhancement

First of all, it must be said that improving such an old interface may seem like a trivial task. But I will try to give explanations for my actions, I hope someone describing my train of thought will help in designing my own interfaces.



1. Main window







Nicely, animated, but in terms of functionality is a graphical menu that allows you to open the exploration window, assemble components of the mission, various cosmonauts training windows, and slows down the interface, at the same time increasing the complexity of learning (what are these buildings, and which menu contains which important item initially poorly understood). Proceeding from the desire to increase the speed of interaction with the interface, this window is removed, and in its place are interface elements of paramount importance - an element of interaction with components and astronauts, a warehouse, a waiting list and a planning sheet and the “end move” button. Buttons "end of turn" and "new mission", expectedly the most frequently used, are moved to corners according to Fitts theorem. The obvious advantage - it has become more convenient. The obvious minus - it became boring.

A curious question came up when designing logic. In the original game, it was impossible to go into negative finances, since the money for research or purchase was allocated each time at the touch of a button, and, if there was a shortage of finance, the button was simply not pressed. However, in the new interface, buttons with the state of “we investigate / do not investigate” have been introduced, and, in a situation where a long study was switched on and the money ran out, something must be done. In the current implementation, the “end move” button is blocked, and a text warning about a shortage of money for research / revision is issued in the “errors” field, prompting the player to turn off the least important (or all if necessary) studies. There is also an alternative option - to automatically turn off all active research (to switch off partially, making a decision for the player, we cannot). Which option is better, I think, it will become clear only after more or less serious operation of the application.



2. Study and purchase windows







Immediately visible interface error. Perhaps it was due to architectural or systemic constraints, I say not condemnation, but improvement for the sake of. The purchase window is located in two mouse clicks (“Administration” - “purchase”) from the main window, the study window in one (the building on the playing field). Before you investigate a component, you must buy at least one copy. That is, in reality, user actions fall into the following sequence: “playing field” - “research window” - “purchase window” - “component purchase” - “research window” - “start component research”. This is a long time. Therefore, it was decided to bring the information, purchase, revision, order component and the formation of crews for manned spacecraft to the upper level of the main window.



3. The window of the new mission.







Here you can very clearly show the following aspects of the problems of interface design:

• access speed Placing one of the most frequently called windows in three clicks from the main window is an obvious mistake. I do not know why it was made, it was possible to draw a building for designing a mission, or to use painted launch sites (you can cancel the mission there, but you cannot plan a new one).
• interaction speed. The implementation of the new mission planning interface is made in the style of a wizard (several windows with a small number of components). Here it is clear why such a decision was made - because of the small screen resolution. And, in my opinion, here one window with a large number of components looks better, which was implemented.
• problems using pictograms. Icons save space, but you have to pay for this by increasing the complexity of mastering the interface. For example, try to determine what the icon means with a spacesuit and two yellow sectors out of six. For a while, I thought it was the number of people in the crew. But no, it turns out, this is the duration of the mission. I decided not to save space, but to write directly with text.
• filters, clamps, rewind. Icons are indicators of the signs of the mission. When you click a small square in the lower right corner of the icon, the indicator becomes a filter and allows you to show only missions with this indicator state. However, to go to the list of filtered missions, you must click the "up" or "down" buttons and rewind the resulting list with them. No information about the length or components of the list can be obtained without rewinding. When designing a new window, it was decided to keep the filters as convenient, but to replace them with the corresponding elements - lists, radio buttons, checkboxes - which is better suited. And a list of suitable missions to show in full.
• interface state problem. The “Continue” button in window number 3 has two states that are not displayed on it at all. If the “no mission” mission is selected, the button is used to close the window. If any other mission is selected, the button is used to move further along the master of the new mission. Naturally, if the user changed his mind (or ran into problems when planning a mission), he forgets to consciously press "Reset" and only then "Continue", which is quite annoying. In the remake, put the usual buttons "OK" and "Cancel."
• show missions. The list of missions is collected only from possible missions. For example, if there is only one launch complex, it will be impossible to even see joint missions or multi-launch missions. In my project, the reverse approach is used - all possible missions are shown, which allows the player to be informed about what is possible to do at all. But when you try to choose such a mission, the required steps are shown that were not taken.
• removed two screens. Before launching the mission, the player had to go into the installation and test complex screen and assemble the rocket (it is now just a list of suitable carriers in the new mission window) and determine the launch month (this is generally removed, the mission is planned for the next month).

4. Mission display window







To illustrate the passage of the stages of the mission, thematic pictures and video are used. The choice of video is clear, but, alas, in my opinion, the disadvantages of this method outweigh. Space video is quite small, and once again watching the separation of the first and second stages of the Apollo 6, which appears even when launching a Soviet missile (we don’t have a similar video, really) gets bored quickly. Or, for example, in the above picture, the Soviet lunar module accelerates to the Moon, and shows the entrance of Gemini into the dense layers of the atmosphere. The video quickly becomes boring and starts to click. Ideally, it seems to me, it is necessary to make a full-fledged synthesized picture, and show various types of faults with the appropriate behavior of the device. I hope someday it will be, but for now the text report generation algorithm has been done. Each step has several spelling variants, if a malfunction occurs, it can be placed in any suitable place (for example, engine failure can occur at the tenth and hundredth second of the flight). Thus, I hope, the mission report was made more interesting, and for those to whom it gets bored, the options for the speed of showing the result of the mission were introduced - a full report right away, a step-by-step report, or textual imitation of reports that would sound in real PCUs.



The project is in the alpha version stage, version 1.0 is expected in one to two years. If you are interested in its current state, you can familiarize yourself with it on GitHub, I will be glad to receive feedback.



Used materials:

1. The space race chart is taken from Wikipedia.
2. BARIS screenshots are taken from Open Source version 1.0.0