Recently we had our second hackathon this year. We met in person at our office and had fun working in two teams. Check out what we were doing during those two days:
Nussknacker plays Starcraft 2
Authors: Wojciech Decker, Rafał Solarski, Michał Trzaskowski, Filip Michalski
Here at TouK we are dynamically developing Nussknacker (NU): a visual tool to run real-time business logic. Spending so much time with this technology puts the craziest ideas into our heads on how we can adopt NU in various fields. At each hackathon at least one team tries to build something on/with NU. Last time it was Natural language processing (NLP); this time it was something totally different – let Nussknacker manage and make decisions about Starcraft 2 strategies.
Starting from the beginning, we came across the Python-sc2 library, which allows communication with SC2 through the available API and adds a lot of high-level auxiliary methods (e.g. build base expansions) and collections (e.g. zap all visible enemy buildings on the map) on the basis of which complete bots can be created more conveniently. In our team, we had several experienced SC2 players who exploded with joy at being able to implement their strategies acquired through years of practice.
First to be implemented were all sorts of “cheese” tactics, such as so-called rushes (cannon rush, voidray rush, proxy gate), but so as not to make things too easy, we also tried to implement “deeper strategies” that first build a proper economy, conduct reconnaissance, put up defences… and destroy everything with a cloud of Carriers ;)
We noticed that some of the parameters and variables appearing in Python strategies scripts affect the specific behaviour of the bot. This was the signal for NU to step in, as it handles such cases best. So we ran the containerised Nussknacker in request-response mode and added Starcraft-specific components.
We transferred character IDs, buildings, factions so that we could start creating scenarios to manage our strategies. We selected key parameters from the created strategies and started building scenarios that returned information about how the bot should behave.
In addition, part of the team worked in parallel on a chatbot that was supposed to react to incoming chat messages during the game. For this, we used a trained ML Detoxify model, which was able to determine the toxicity of the message sent. Based on this, a scenario was created in NU to react to both negative and positive comments. In combination with the API, upon receiving a compliment or a diss, we returned an appropriate response to the nice or not-so-nice player.
The whole thing went great because we achieved our goal and had a lot of fun in the process. NU took the decision-making capabilities of the SC2 bot to the next level – and the strategies written during the hackathon posed quite a problem for the brave players who dared to face it. During the final demonstration, despite a fierce battle, the bot defeated its creator :)
Pimp my (TouK) 3D Printer
Authors: Patryk Majkrzak, Adrian Misztal, Marcin Lesiński, Kamil Trysiński
In our office is an ancient (2014!) 3D printer, which hardly anybody knew how to use. Since it is quite advanced for its age, we decided to spend this TouKathon on giving it a new lease of life. We gathered some opinions from our colleagues and concluded that there are two main reasons why it is so user-unfriendly:
- People do not know how to properly level a printer bed, which results in failed prints, frustration and ultimately abandoning the idea of getting into 3D printing altogether.
- The slicer software the printer came with was massively outdated and had a steep learning curve.
However minor these things may seem for 3D printing enthusiasts, the barrier of entry they posed made people wanting to get into the hobby quickly go from “I want to try this” to “This is an absolute nightmare, a rabbit hole of frustration”. We decided to resolve the issue once and for all.
Before TouKathon we created a list of things we wanted to change, so that the user experience would improve:
- We needed a bed levelling sensor, so that after slicing the printing process would become more or less fire-and-forget
- We needed updated printer firmware to support the sensor
- We needed to have centralised printing profiles for a popular up-to-date slicing software (we chose Cura)
- We wanted to have an Octoprint server, so we could print over WiFi. This was optional and ultimately we ran out of time to do it, so stay tuned for the next TouKathon.
First of all, we found a suitable spot on a carriage to mount our sensor. We then designed a mount for it in CAD. After a few iterations we had a pretty good-looking mount that fitted the sensor perfectly and we moved on to the next step: namely, flashing a new firmware. Since the original firmware settings were long gone, we had to start from scratch and reverse engineer most of them. Fortunately this was not too hard. However, we did think a few times we’d bricked the thing, because we selected the wrong display driver for an LCD and it stopped responding after uploading the firmware.
Finished model and sensor mounted to printing carriage.
We are in the process of doing test prints and making our printing profile database as comprehensive as possible. Some of our colleagues have already reached out to us for guidance on how to get started and were positively surprised by how much better it is now compared to eight years ago. We are excited to see this machine working once again after all this time.
See the post about the previous edition of hackathon here.
