As we wrote a strategic clicker on the hackathon ReactRiot

Hey. Not so long ago, we with rjericho saw the article How I participated in the Angular Attack hackathon, and what came of it . We in Barnaul started hackathons just a year ago. At the same time, they were more focused on the quick start of an IT startup. Therefore, they could not get to enjoy the use of all sorts of cool hipster libraries, and had to cut the product in good old PHP or Java. However, we have long wanted to participate in some kind of fan event, where you can just cut down what your heart desires and not think up how to monetize it.

A hackathon was found from the same organizers as AngularAttack: ReactRiot . The fact that we knew about the reactor only from articles on Habré only added interest to this event.

One week before the hackathon

For a start it was necessary to learn more about the reactor itself. Habr, official docks and codesandbox.io helped with this. On this site there were some examples that helped determine the choice of core libraries.

MobX was selected for state management. Redux also looked interesting, but it seemed that it is not suitable for the hackathon, as it takes more time to think through the architecture and add actions, which is not very suitable for the hackathon format, when one day after the start you come up with a brilliant feature that doesn’t fit into the architecture .

For the styling of the components was taken glamorous and the glamor itself. I liked that all the code of one component can be in one file, and not scattered in the css and js folders and does not affect other components.

Two days before the hackathon

The hardest thing in the hackathon is the idea :). Since for us the goal of this hackathon was to study a new technology and get a fan, it was decided to make a game. And so that it also beautifully lay down in the principles of the reactor and mobx, i.e. it was possible to create a component and use it many times on the page, as well as when everything was reacted by the user, it was decided to do something like a clicker.

The initial idea was a simulator of a mining village with various types of miners, mines and auxiliary buildings that affect miners (such as increasing productivity, etc.). However, when I started doing mocap for this case, it turned out that it was very difficult to put this on one screen so that it was immediately clear what to do here. Therefore, the idea was completely redone.

The only thing left of the initial idea is that the population has a discontent indicator, with an increase in which they begin a riot (eng. Riot - a reference to the name of the hackathon).

In short:

• Different types of resources (wood, jewelry, money, food, electricity)
• Population:
  
  • Unemployed - you can teach the profession
  • Workers - extract a certain type of resources (miner, forester, farmer, hunter)
  • Criminals spoil resources a little
  • Rebellious - badly spoil resources
  • Prisoners - can not become criminals, they immediately extract all the resources
  • Soldiers - differ in strength (recruit, sergeant, officer, general). You can send to the war to seize resources or turn into police, so that criminals and rioters become prisoners
• Population parameters
  
  • Mortality - the probability of death for people tick. Strongly increases when there is not enough food.
  • Dissatisfaction - the higher it is, the more criminals, if the threshold is exceeded
• Buildings - during the construction they change other game parameters (electricity, number of unemployed, mortality, discontent)

A full description of the idea with which we started the hackathon can be found here . True, it differs from what eventually happened, as some features did not have enough time. Other features were remembered only in the middle of the hackathon, when it was already difficult to insert them.

And here there would be another problem for the team of two programmers - the graphic component of the project. However, following the example of stickytape, suitable icons for units, resources, and buildings were taken from the emoji twitter pack (except for the ax logo. It turns out that it is not in Unicode and, accordingly, in emoji. Therefore, an ax suitable for the style had to be found elsewhere).

An hour before the hackathon

An hour before the hackathon - it's time to start thinking about the architecture of the project :). However, they only managed to invent a folder structure.

The components contain the jsx components of the reactor. In logic - model - MobX states.
A static webpack bundle was assembled, third-party css, fonts and images were inserted.
In styles.js were some common styles that were used in several components, like this:

 import { css } from 'glamor' export const boldBorder = css({ border: '3px solid' }) 

Not sure about properly organized work with such styles. It would be nice if the comments suggested something about this.

First day

Development began with the creation of small information components. Components have been written to display information on one unit, building and resource.

After that, the main three-column view was made up and a couple more components were added. This is where the react-bootstrap and react-rangeslider libraries helped .

The result was this:

Then a component of displaying the grid of units and buildings was written and some icons were added.

Finally it is time to write logic. The first was written to increment resources for units and build new units. This is where the first wtf happened.

We update the game in ticks: the main ticks are in one second. Smaller learning tics were also introduced to more smoothly reflect learning progress. When a unit was clicked, the animation of its construction began, and if everything was still good with one unit, then at a click on several lags at once. Even not so - logs. Everything was starting to slow down so wildly that I already thought to just remove this animation. However, the time was later and, having decided that morning was wiser, we went to bed.

Second day

The morning of the second day began with the realization of our main mistake: we are preparing MobX incorrectly. Our minimal components that display the basic information are not observers, but stupidly receive information about what to show through props. And this is fundamentally contrary to the method of operation of MobX.

It was:

 <Unit key={i} trainingAvailable={this.props.canBuy(unit)} trainingProgress={unit.queueProgress} queueSize={unit.queueLength} name={unit.name} cost={unit.costStr} description={unit.description} imgSrc={unit.imgSrc} onTrain={() => this.props.onTrain(unit)} /> 

After correcting this error, the application speed has stabilized.

It became:

 <Unit key={i} unit={unit} trainingAvailable={this.props.canBuy(unit)} onTrain={() => this.props.onTrain(unit)} /> 

Also in the process of correcting this miscalculation, it was discovered that dynamically using glamor.css inside render() is not very good. For each change in style used in the animation, he created a new rule in the style sheet, which perhaps also sagged performance.

After the correction of yesterday’s jambs, a grid of buildings was added

Then there was completed the logic of mortality of the population and the accumulation of discontent, sending soldiers to the war, and also added zero speed of the game to create a pause.

After that, it was time to balance all the coefficients, prices and effects of buildings so that it was impossible to play just poking at everything, but also so that it was not too hardcore. It was probably the most fun part. Because of the mortality formula invented by the bald, it was interesting to observe how the lumberjacks who were taking turns turning down one tree and immediately died, because of the high crime rate, the newly trained farmers immediately became criminals, ate all stocks and started to rebel from hunger. However, if the death rate was balanced still fairly easily, then while calibrating crime, we could not find such a balance for a long time, so that with a small starting number of people they would not immediately become criminals. As a result, we had to introduce a mechanism for turning the criminals back into the unemployed, also with a certain coefficient.

After adjusting the balance, it was necessary to add notifications of riot and random events (migrations and floods), as well as add a voting plate from the organizers. Moreover, they made this plate 6 hours before the end of the hackathon and when it was added, we had to transfer one block from the right side of the interface to the left one, so that everything would fit in height.

Results

In the process of the hackathon, the reactor and MobX were studied, although at the initial level. Some rakes were tried on their own :). One of our main conclusions: the architecture is better to think about it a bit beforehand. So, of course, it turns out more roflov, but on the second day the code changed color to brown and some things were done with awful crutches. The code can be found here . You can poke the game itself at town.surge.sh