Party hard programmatically, or as we wrote ClojureCup 2014
Last weekend, the Clojure-community was experiencing ... Oh, so last year's post began with a report on the past ClojureCup 2013.
ClojureCup is a 48-hour online hackathon, which is required to write applications in Clojure / ClojureScript languages. This year, about 50 teams participated in the hackathon (1-4 people each), which made many cool applications .
Applications are evaluated by both the jury (people known in the Clojure-community) and regular users: you can go on twitter and vote for the applications you like on the applications page.
')
And you can try what we have here .
Caution: under the cut a lot of pictures.
The idea to participate in ClojureCup came to me quite a long time ago, but laziness did its job, and I realized it was only three days before the hackathon began to gather (it turned out that two days before the hackathon needed to form teams). However, this world was not without programmers who want to lose their weekend, in order to write something in a strange language with brackets. Here it is necessary to additionally mention that none of us have ever written anything seriously on lojure, and two have not written at all. And yes, all four were programmers.
Initially, as a project, there was a desire to do strange things for static sites (one of the teams did something a bit similar in the end), but there were big questions about the usefulness of the result.
As a result, we formed the criteria for choosing an idea: something clear at once for a simple user.
From such criteria, we quickly came up with the idea of ​​making some kind of toy. And then I remembered the wonderful Puzzle Bobble :
This is a puzzle with a very mischievous P2P mode: the larger the piece of balls you knock off with a group, the more of these balls will come to the enemy. So we focused on finding a game to which it would be possible to fasten the mechanic “to make the enemy unpleasant”.
They thought about Tetris and 2048, but then they remembered Rocket Mania!
So, at night, two days before the start, the idea of ​​the application was born: two players will play a simplified version of Rocket Mania !, but the number of missiles will be limited and they will fly away to the enemy, and for the game to just end, they will have fuel , which decreases with each flight, and at the end of the rocket will fly into space for eternity.
At that time, the game should have been with cool graphics and the ability to play over the network, but when we started working on the idea on Friday night, two changes were made: we decided to throw the game over the network and only support the hotseat mode (remember, this was in the heroes when player at one computer), and also use flat design, because it's easier, and among us there are only programmers =)
These were very correct decisions : you need to choose goals for what you can really achieve. Simplify, simplify, simplify.
Like Clojure, we didn’t have experience in the functional programming style. But here we decided to take the functional paradigm in full: every observation of the world is immutable , the functions are clean, etc. etc. As a result, in our architecture there was one “atom of the world”, the state of which unequivocally set what was on the screen, and the change of which the world changed. We also decided to use react.js (it was a very correct decision) and a quiescent wrapper over it (which is wrong, but tolerable). Now it seems to me that it was necessary to look at the phaser , but then such a thought did not arise. By the way, at the phaser the other team made a funny game with the cats !
Meanwhile, time came to 4 in the morning, ClojureCup started, and we went to bed. One of the team members (who lives in another time zone) at this time raised the server and launched the stub with the Elon Musk rocket there:
The application is very well divided into parts: someone sawed a purely game logic, someone displayed the playing field, someone was engaged in processing the keyboard. For some reason, we didn’t have any active use of the terminal REPL, but figwheel , the solution for automatically recompiling ClojureScript code from hot reload code in the browser, was very useful and made our lives very, very simple. There is another interesting point to note here: the state of the world was stored in a non-reloading atom, so even after recompiling, the application remained in the same state as it was before. Of the minuses it can be noted that the incremental compilation flew from time to time, we had to do a full rebuild.
Initially, we stored the generated code in the repository, so we got magic numbers of tens of thousands of modified lines of code , with a total size of the order of 1K lines of code.
Of the unpleasant zapar we have two:
During the implementation of the game logic, we were faced with the task of a large-scale deep change in the immutable state of the world. As a result, a solution was invented, as it turned out, up to a signature that matches the solution from the standard library =) Moral : study at least a little of the tools that you will use. And before you do something your own, look: hasn't someone else done it?
And we didn’t know how to make a changeable state in Clojure (functionally unwillingly), this gave rise to the following monologue:
As a result, we have not learned to use the changeable state, but have used the loop.
At the end of the first day, we already had something showing the version of the application, and 3 hours before the end of the hackathon was a more or less full-fledged working version of the game. In the last 3 hours, we added sounds to the game (here we had to give up the functional paradigm and methods like play appeared!) And polished the UI very much.
In 2 hours before the end, the server fell down, and it turned out that the game was distributed by the built-in python server out of the box. Quickly picked up nginx and were happy.
Half an hour before the end, I opened the application in Safari, and it turned out that it was not working there at all (the turn of the blocks did not work).
15 minutes before the end, we didn’t want to work the sound for the victory (apparently, there was again a problem with the ClojureScript compiler), this all added adrenaline noticeably.
So even having a more or less working version in 3 hours, we spent the last minutes in steaming.
And this is the very moment when we started the release version and got three green check marks, which means that we did everything necessary =)
We succeeded, I would like to believe, a fun game for two . And even if it did not work out - we got a huge amount of fun and no less amount of experience. Here you can watch the source of the project, and then if you want to vote.
A list of projects sorted by current position in public voting can be found here and here . I advise you to look at these lists: among the projects there are very, very decent, funny and useful.
For this year, you can already read the reports of Alexander Solovyov (you may know him from this wonderful presentation about FRP and Clojure), the team of the Funstructor project, as well as Milestones .
Separately, I want to say thanks to Alexander Solovyov ingspree and Nikita Prokopov tonsky for maintaining interest in Clojure at a high level, as well as to Dmitry Groshev si14 , Nikolai Ryzhikov and Mikhail Lapshin for the workshop on clojure at JetBrains .
Also many thanks to Julia Belyaeva juliette , Seryozha Serebryakov, megaserg and Andrey Siunov fandes for the excellent company on this hackathon. Hackaton in a beautiful company - great!
ClojureCup is a 48-hour online hackathon, which is required to write applications in Clojure / ClojureScript languages. This year, about 50 teams participated in the hackathon (1-4 people each), which made many cool applications .
Applications are evaluated by both the jury (people known in the Clojure-community) and regular users: you can go on twitter and vote for the applications you like on the applications page.
')
And you can try what we have here .
Caution: under the cut a lot of pictures.
Idea
The idea to participate in ClojureCup came to me quite a long time ago, but laziness did its job, and I realized it was only three days before the hackathon began to gather (it turned out that two days before the hackathon needed to form teams). However, this world was not without programmers who want to lose their weekend, in order to write something in a strange language with brackets. Here it is necessary to additionally mention that none of us have ever written anything seriously on lojure, and two have not written at all. And yes, all four were programmers.
Initially, as a project, there was a desire to do strange things for static sites (one of the teams did something a bit similar in the end), but there were big questions about the usefulness of the result.
As a result, we formed the criteria for choosing an idea: something clear at once for a simple user.
From such criteria, we quickly came up with the idea of ​​making some kind of toy. And then I remembered the wonderful Puzzle Bobble :
This is a puzzle with a very mischievous P2P mode: the larger the piece of balls you knock off with a group, the more of these balls will come to the enemy. So we focused on finding a game to which it would be possible to fasten the mechanic “to make the enemy unpleasant”.
They thought about Tetris and 2048, but then they remembered Rocket Mania!
So, at night, two days before the start, the idea of ​​the application was born: two players will play a simplified version of Rocket Mania !, but the number of missiles will be limited and they will fly away to the enemy, and for the game to just end, they will have fuel , which decreases with each flight, and at the end of the rocket will fly into space for eternity.
At that time, the game should have been with cool graphics and the ability to play over the network, but when we started working on the idea on Friday night, two changes were made: we decided to throw the game over the network and only support the hotseat mode (remember, this was in the heroes when player at one computer), and also use flat design, because it's easier, and among us there are only programmers =)
These were very correct decisions : you need to choose goals for what you can really achieve. Simplify, simplify, simplify.
Like Clojure, we didn’t have experience in the functional programming style. But here we decided to take the functional paradigm in full: every observation of the world is immutable , the functions are clean, etc. etc. As a result, in our architecture there was one “atom of the world”, the state of which unequivocally set what was on the screen, and the change of which the world changed. We also decided to use react.js (it was a very correct decision) and a quiescent wrapper over it (which is wrong, but tolerable). Now it seems to me that it was necessary to look at the phaser , but then such a thought did not arise. By the way, at the phaser the other team made a funny game with the cats !
Meanwhile, time came to 4 in the morning, ClojureCup started, and we went to bed. One of the team members (who lives in another time zone) at this time raised the server and launched the stub with the Elon Musk rocket there:
Implementation
The application is very well divided into parts: someone sawed a purely game logic, someone displayed the playing field, someone was engaged in processing the keyboard. For some reason, we didn’t have any active use of the terminal REPL, but figwheel , the solution for automatically recompiling ClojureScript code from hot reload code in the browser, was very useful and made our lives very, very simple. There is another interesting point to note here: the state of the world was stored in a non-reloading atom, so even after recompiling, the application remained in the same state as it was before. Of the minuses it can be noted that the incremental compilation flew from time to time, we had to do a full rebuild.
Initially, we stored the generated code in the repository, so we got magic numbers of tens of thousands of modified lines of code , with a total size of the order of 1K lines of code.
Of the unpleasant zapar we have two:
- The first one was related to the fact that quiescent very strangely decided which parts of the page needed to be updated and which did not; at that moment I learned how to insert debug output into the generated JS code, and even understand what's up there,
- the second was apparently a bug of the ClojureScript compiler: the correct code was compiled, but then it did not work.
During the implementation of the game logic, we were faced with the task of a large-scale deep change in the immutable state of the world. As a result, a solution was invented, as it turned out, up to a signature that matches the solution from the standard library =) Moral : study at least a little of the tools that you will use. And before you do something your own, look: hasn't someone else done it?
And we didn’t know how to make a changeable state in Clojure (functionally unwillingly), this gave rise to the following monologue:
the klozhur terribly enrages me, so that I once again code on it; why do we need this language if it is impossible to read it, but in order to write something normal, you still have to go out of the concepts of the language.
As a result, we have not learned to use the changeable state, but have used the loop.
At the end of the first day, we already had something showing the version of the application, and 3 hours before the end of the hackathon was a more or less full-fledged working version of the game. In the last 3 hours, we added sounds to the game (here we had to give up the functional paradigm and methods like play appeared!) And polished the UI very much.
In 2 hours before the end, the server fell down, and it turned out that the game was distributed by the built-in python server out of the box. Quickly picked up nginx and were happy.
Half an hour before the end, I opened the application in Safari, and it turned out that it was not working there at all (the turn of the blocks did not work).
15 minutes before the end, we didn’t want to work the sound for the victory (apparently, there was again a problem with the ClojureScript compiler), this all added adrenaline noticeably.
So even having a more or less working version in 3 hours, we spent the last minutes in steaming.
And this is the very moment when we started the release version and got three green check marks, which means that we did everything necessary =)
Instead of conclusion
We succeeded, I would like to believe, a fun game for two . And even if it did not work out - we got a huge amount of fun and no less amount of experience. Here you can watch the source of the project, and then if you want to vote.
A list of projects sorted by current position in public voting can be found here and here . I advise you to look at these lists: among the projects there are very, very decent, funny and useful.
For this year, you can already read the reports of Alexander Solovyov (you may know him from this wonderful presentation about FRP and Clojure), the team of the Funstructor project, as well as Milestones .
Separately, I want to say thanks to Alexander Solovyov ingspree and Nikita Prokopov tonsky for maintaining interest in Clojure at a high level, as well as to Dmitry Groshev si14 , Nikolai Ryzhikov and Mikhail Lapshin for the workshop on clojure at JetBrains .
Also many thanks to Julia Belyaeva juliette , Seryozha Serebryakov, megaserg and Andrey Siunov fandes for the excellent company on this hackathon. Hackaton in a beautiful company - great!
Source: https://habr.com/ru/post/238845/
All Articles