Snaketris post-mortem
Well, enough time have passed since a submission, so I think it's post-mortem time (it's gonna be a long post)!
First of all I want to thank GameDevNSK team for local event they organized for developers to take part of LD and even to stay and code all the night. You made Ludum Dare a 500% more fun!
It was the second my LD (the first was 36th and I didn't manage to finish my game) and the first one with a team. Our team consisted of three linuxoid students with almost no game development background (@komnotmr and I once made a clone of Nidhogg with Phaser.js for our web-dev university course, but it was a one single bug of a game, so doesn't count). However, I was sure we will make it right to the end and here is what we got.
Day 1
When a theme was announced, two of us were on our way to a place (the event took place in a wonderful building of Technopark, see a picture below), so we started to brainstorm in the car. Throwing away all the rubbish, we ended up with four acceptable ideas. Most of them needed tricky sprites to be drawn so, as no-one of us were an artist, we decided to pick the idea that challenges our programming skills and don't require much graphics. Here is where Snaketris begins.

We presented our idea to other 7 teams (6 of them have published their games, check here) and started to code. We agreed to use Phaser as two of us were somewhat familiar with it and also not to care too much about architecture, modularity and stuff like that. So, architecture was pure and simple: a tile field, input handling in 'update', two classes (for snake and for tetrimino) and one 'tick' function in a loop that handles all the mechanics.

When @dolorosso came we were already locked and loaded. First of all we occupied a comfortable couch, created a GitHub repo and set up Phaser. Then we split up: @komnotmr was busy with snake (and created the best falling animation ever. So inspiring!), @dolorosso was learning JS and making tetris work properly, I was busy with rendering and connecting two games in one. By 1:00 a.m. we had an image.

When this sprites was drawn we came up with an idea to make it look kinda Chineese-styled with golden dragon and a bamboo, but, as I mentioned before, there were no artists to help us. As for a code, things were runnding pretty smoothly, yet independently. There were lots of things to link, features to add and, of course, bugs to fix. Most of people around have already went to sleep, Aleksey was playing Super Mario 64 on his Orange PI when we were coding and merging like Pepsi-powered robots. By 5 a. m. we finally fallen asleep in our bean bags.
Day 2
The day begun with breakfast and a quick game of go. Feeling fresh and charged then we continued our development. Long story short, we made our game playable right in time to introduce it to the other participants. The only problem we encountered was a difficult merge gone wrong, turning a game into a black screen (lesson #1: never put everything in one function), but we addressed that problem. By the time of presentation, we had a game with gameplay, fancy squares and even some sounds to present.

After a presentation we had some time to play each other's games and to get some feedback. Some people said that the game was too difficult, but everyone who tried to play it team said it was fun! After a while the event was over and we went home satisfied and inspired.
Day 3: polishing
We really didn't want to spend one more day on this game, but dammit, we didn't want to publish unfinished job either! So, the next day began with a massive bug genocide (well, it appeared to be more like an assasination rather then genocide because there were only four of them and they were hidden very well). By two p. m. I met @komnotmr and we decided to put a little more effort into our game to make it look finished. He made all the pictures for tutorial screen and also added particle effects while I was busy with logo, game over screen and HTML-layers above our game's canvas. The game was published at 3 a. m. the next morning.
Conclusion
Ludum Dare 40 was so much fun to participate! I definitly want more and will be here for LD42 (yeah, seems like I'm skipping the next one). Here are some things I learned from our work:
- As someone already said in his post-mortem, making games is hard. Teamwork is even more harder because you need to explain your point, make compromises and just read someone else's code. But together you can do far more work and achive something you can hardly achive solo.
- It's better to share a room with your teammates rather than work remotely on voice chat.
- Multiplayer games are rated less often because less people can play it.
- Graphics and sound are soul and spirit of jam games. The better they are, the more people plays your game. Ironically, this two aspects are the weaknesses of our game. =)
Thank you for reaching this point. =) Leave your feedback, play Snaketris, make your own games. Hope to see you on oncoming jams. Here's wumpa-shower for you!
