This is the list of games (and expansions) I have developed for yucata.de. To be precise, since my wife and me share this BGG account, with "I" I mean Adi, not San. San has often helped me prepare the images.
I took over the project because the previous developers didn't have time to finish the game. All images were already processed, and the UI layout existed, but I reworked the layout a bit and implemented all the logic.
This was the first game I developed completely myself. I had fun with trying to pack the game state as tightly as possible. My idea was to store the location where a card is placed relative to another covered card. This means I would only need to remember the rotation of the card (4 possibilities), the card which was covered by the leftmost upper symbol (where the card was identified as the index into the list of cards that the player had placed so far) and which of the 6 fields of the covered card the symbol was placed on. Not the easiest way for processing it, but it saved space in the database.
The next game I chose was quite a step up compared to the games I had implemented before. Implementing the logic for the helpers was both quite a lot of work and contained special cases that needed to be clarified with the publisher. I left out the Foreman helper because it would not be suitable for the asynchronous games played at yucata. This game used a new client-side yucata framework developed by another developer that allowed to undo/redo actions during a turn. Previous games had only allowed to undo the whole turn, which would have been quite bad for this game as the number of actions per turn can be quite high. Also I adjusted the framework so I could implement the history view by stepping through the selected actions of a player one by one. This was also quite new, because other games had to use custom logic for showing information what had happened in the whole turn.
After finishing university and starting with my first real job, I took a break from developing games for yucata, because my free time was more limited than before. But after a while I really got the desire to develop another game. Initially I wanted to develop Ebbe & Flut, Morels or Pastiche, but we either didn't get the license or it was unlikely that we would get the license. The publisher Pegasus suggested Port Royal, and after reading the rules I was convinced that it was suitable. After I finished a playable version, some of the playtesters already told me they were hooked by the game, and I also bought the game and played it offline quite often. When the game was finally released, it became the favorite game of the month November 2014, the first (and so far only) game to beat Can't Stop which had been the number one game since its release in 2011 (and also retook the top spot one month later). Even the author Alexander Pfister started playing the game on yucata, although he had certainly already played the game a lot during his playtesting. So far, the game has stabilized on the second place in the monthly most played statistic. So everyone who likes playing this game on yucata, you can thank the publisher Pegasus for pointing us to the game. We might have missed out on a great game otherwise.
The next game I chose to implement was La Isla. Initially I wanted to implement Splendor, but we didn't get the license. I had tried La Isla on the Spielwiesn fair in Munich, and immediately liked it and bought a copy. Developing the game took nearly a year, mostly because we also worked on a new yucata framework which moved the game logic to the server side and also had other improvements. My contribution to the new framework was a State Machine which used Reflection to gather the methods implementing the logic of a game. Games would just specify an enum of Actions, an enum of States, a list of valid transitions, and the State Machine would take care of calling the corresponding methods for each action (one verification method, one method to perform the action, and one method to generate valid action parameters). La Isla was also the first game where I worked with percentage based positioning. I also spent quite some time optimizing the image usage, building for example card images from parts so that common image areas could be shared and were more likely to be in the browser cache.
Alexander Pfister had contacted me if I also wanted to implement the expansion, and I agreed. Pegasus also gave us their ok, so I went ahead and implemented the expansion in 1 month. I think that was relatively quick But I used 1 week of my vacation time. When the expansion was released on yucata, the game got a small popularity boost, which was also necessary to defend the second place. Castles of Burgundy had almost overtaken Port Royal.
The next game I wanted to implement was Jockey, because I had fond memories of the game when I played it as a child; I used to almost always win 2-player games, and then nobody wanted to play it with me anymore. Because it was unclear who to contact regarding the license, we decided to create our own version of the game. I simplified the game and got rid of betting money on the horses, instead always selecting two equal bets (favorites) and playing only one round instead of 3. I scaled the numbers on the cards such that the strongest cards became slightly weaker to reduce luck a bit, and tried to use a scoring system that did take into account how many players have selected the same favorite, thus giving the player with the single favorite a chance to at least tie with the other players. I have learned by now that many people are extremely unhappy with ties, but in my opinion this outcome is much fairer than in the original game. Also the game now ends when three horses/knonsters have reached the goal, and it is possible to draw new cards towards the end of the game. The images for the game were created by San, and she also suggested the theme and the name of the Knonsters (Monsters made of plasticine = Knete-Monster in german). We used svg images which scale nicely. However it was a bit tricky to get it to work correctly on Internet Explorer, and I stumbled onto some weird browser bugs. Overall I am happy with the result and like playing the game especially in a two-player setting. The game is probably not that good with more than two players, and I also didn't really play-test it with more than 2.
For this game, the development took about three months. I had a playable version of the introduction game after 1 month, but it had only very basic UI. It took another month to finish the UI and the gamelog. And the last month I spent implementing the normal game and the "fight for survival" variant, creating the rules and some polishing. For this game I had to think about how to display the abilities with icons, because the text on the cards would have been not readable on smaller screens. Fortunately I got the card images of the cards from the publisher also without the text, so I did not have to first remove the text from every image (which also allowed me to display English labels on the cards).
Hacienda is one of my favorite games on Yucata. However the old implementation by Sparhawk from 2006 didn't have a game history display, which makes it more difficult to guess what the other player(s) are up to. So I decided that I want to reimplement the game using our new framework. Stonecrusher agreed to do the UI part, which is the part of the development of a game that I dislike. I started developing the logic when Stonecrusher was still busy developing the game Lemminge. Because I had no UI for testing the logic, I wrote several unit tests. By the time when Lemminge was finished the logic for Hacienda was also finished. Of course it still had bugs which we found when the UI was far enough to play test games. Stonecrusher even found a bug in the old map encoding for the Asymmetric map which I had reused for the new implementation (it had an extra meadow field in the lower right corner). For the new version of Hacienda I also wanted to support custom maps created with the Hacienda map generator. So first I needed to figure out how to read the data format used by the generator. I did this by changing a custom map in the editor, saving it and then comparing what has changed in the file. Fortunately the editor uses text/numbers instead of binary output so that it was reasonably easy to figure out what was going on and what map encoding was used. Also, I had never used the upload functionality of HTML before, so I needed to learn how it works. Interestingly the upload button uses the language setting from the browser, and it would be tricky to make it use the same language as the yucata UI. So it could happen that you see it in your native language while the rest of the page is in english or german (depending on your chosen yucata language). I also fixed a few client framework issues that Stonecrusher found while developing the UI. Overall this was a huge project, and especially the UI was a lot of work. So many thanks to Stonecrusher for doing the UI
This was again a case where a previous developer had abandoned the project after realising he would not have enough free time to work on the game. When I took this project over, the game state was already initialized and it was possible to use the barge action, and the UI showed the cathedral area and allowed to place a tile there. This means essentially almost all work was still left to do. This time I decided to track how much time I spent on different parts of the game: - Reading through rule clarifications on BGG and thinking about additional edge cases: 1h - Prepare images: 12.1 h (here I got help by my wife Sandra) - Finishing data structures and game setup: 3 h - Server-side game logic: 27.4 h - User interface: 48.45 h - Fix various bugs found with playtesting: 4.1 h - Implement animations for some actions: 2.25 h - Write the hints for handling section: 2.5 h - Various smaller improvements: 5.35 h Overall: 106.15 h
In addition to that, zzrxes prepared the HTML rules for the game, which certainly took at least another day of work.
Another technical challenge was the action panel. My wife had the idea that we could use the scroll image as background. Now we needed to find a way so that it scales according to the amount of content within. For that, we split the image into three parts: the upper and lower parts are always the same, the middle part scales with the content. To make it look somewhat ok, the middle part needs to be an image that can be repeated arbitrarily many times. There is a nice trick for that: extract some part of the original image, then attach to that a vertically mirrored copy. Then, it can be repeated vertically and still you can't easily tell where one part starts and one part ends.
I had played this game on the Spielwiesn fair in Munich and liked it. My feeling was that it should be a good fit for Yucata, because the rules are relatively simple and it plays well with 2 players. I developed this on a few weekends. Compared to my previous development project Ulm, this game was a lot less work. However I challenged myself to try to save database space. E.g. the relative order of the action strips never changes, so you can calculate which one is on top (and whether it’s front or back side is used) based on the round number, and only store the original order once. And the round number can be calculated by the number of cards remaining in deck 1. The decks themselves are shuffled on demand, it is only stored if cards are somewhere else than in the draw deck (all cards that are not stored must therefore be in the draw deck). When drawing a card we need to check first whether it is a card anyone has looked at before (although these cards are put at the bottom of the deck, at some point they can become the topmost card). If not, we draw a card at random from the cards which could theoretically be on top.