Hi. I'm Marek Daniluk.
I'm a software engineer based in Bytom, Poland. Over the years, I've gained experience in a variety of fields, including embedded software development, IoT, and mobile applications, but my true passion lies in game development.
Currently, I work at People Can Fly, where I create tool applications. I'm dedicated to delivering easy-to-use solutions, which is why I love working closely with the people who use them.
That's how I got the task of implementing telemetry. The system had been in a prototype stage for a while, and no one really looked after it since the people responsible for it had already left the company. A few months before the release, an analyst became interested in the data to track player activity and prepare reports. The idea was to use this data to improve game balance and plan future events or challenges.
I didn't know much about telemetry. I knew what it was and how to integrate it because I had worked with ready-made solutions in mobile projects at previous jobs. But I had never been responsible for both integrating and implementing such a system. Luckily, the previous programmers left some documentation, and I could ask how telemetry worked in the first Dying Light, which helped me create a simple but stable solution. I focused on stability because I didn't have much time with the fast-approaching game release.
I also managed to add a few features I'm proud of. One of them was remote configuration, which was a huge plus. It allowed us to turn data collection on and off, change how often it was logged, and control when it was sent to the server, all without needing to rebuild the game. This was useful for reducing the amount of data collected since data transfer costs money. An interesting side note is that the config scripts were text-based, so modders quickly figured out how to edit them and turn off the system.
After the launch, I did some maintenance and had ideas for system's development, but then I moved to the tools team. A new person took over telemetry, and I think he did a great job improving what I had started. Still, I'm proud that I was able to jump into the project quickly and deliver a working solution despite the pressure.
Flashout 3D was my gateway into the gaming industry, and I was thrown straight into the deep end. I had no experience with C#, Unity 3D, or mobile games. It's a miracle I got the job, though I prefer to think it was due to my determination. I was given a test task: make a clone of Space Invaders in technologies I had never used before. I studied around the clock, even neglecting my university work a bit, but I made it in time. That's when I fell in love with Unity 3D and thought making games with pre-built engines was a piece of cake.
Jujubee offered me the job, and I was over the moon. However, the honeymoon phase didn't last long. I quickly learned about optimization, GPU and CPU bounding, the tedious work of implementing UI, testing code, and many other things you don't consider when you're outside the industry. As usual, I had more luck than sense. The company was very friendly, the people kind and helpful. I wanted to prove I wasn't a bad hire, so I continued learning after hours at home. It was a valuable life lesson in humility. We released the project on multiple platforms, including OUYA, which I'm sure not many people even remember now.
At the start, I mentioned I can't bear to look at Flashout 3D anymore, but it wasn't a bad project by mobile standards. It looked great (not my doing, just to be clear), and it was fun to play. Of course, all I can see now is the poorly interpolated movement of the racers, but when I tried solutions involving physics, weaker devices couldn't handle it. That's also when I created my first ever tool, checkpoint placer that automatically mapped out paths for AI. In fact, I wrote about 90% of the game's code.
I really enjoyed working at Jujubee and was supposed to continue development on the Flashout 2. However, I received an offer from a bigger company and thought I could become a better programmer there. The team in Katowice was young, and we made up for experience with enthusiasm. It was a tough decision, as it also meant moving, but looking back, I think I made the right choice.
My fiancee introduced me to her colleague at a party. The conversation smoothly shifted to what he was working on after hours. A game in a retro future setting. Comic-style graphics. The atmosphere thick and immersive, like in Blade Runner. All he was missing was someone who could code. We hit it off so well, and the project seemed so great that I didn't even mind that my partner had clearly arranged the whole thing.
Retro Synthesis was developed in our free time by two graphic designers using Unreal Engine. I didn't know the engine back then, so I asked if switching to Unity 3D would be a problem. It wasn't. I set up a repository, wrote the first scripts, and the project started to gain momentum. I proposed a dialogue system partially based on iconography, which they liked, so I started implementing it. Before I knew it, I was thinking about Retro Synthesis all day long and couldn't wait to write the next script or pitch the next idea.
We began meeting regularly and started talking more seriously about our aspirations — getting a publisher, starting our own studio. At that time, it didn't take much to attract investors, and we had a half-hour demo! All the feedback we got was overwhelmingly positive, our ambitions grew, and it seemed like nothing could stop us. We signed an initial agreement with a publisher who set out strict conditions. We were set to launch a Kickstarter campaign, so we prepared as best as we could and... then came our first reality check. Failure. A counteroffer from the publisher. Resignation and the project's surrender.
Does it sound sad? Looking back, I think we were lucky. Today, we could've been another struggling gamedev company laying off people. One potential investor asked us, "Do you want to finish the project or start a company?" and I admit, we didn't have a good answer. Now I know — it was about the project. Sometimes we get together over a glass of whiskey, sigh deeply, and think back to that crazy project. And even though we speak of it in the past tense, I feel like we're all just waiting for that one question: "So, should we finish what we started after all?"
BrixAR came about spontaneously, riding the wave of ARKit's popularity after Apple's presentation. I quickly added a basic Augmented Reality integration to Unity 3D, and my boss at LabLike played around with different demos, brainstorming how we could use this tech. I immediately fell in love with BrixAR's idea.
The scope of work was crazy because it also included a network layer with elements of economy and user interactions. We planned that players would unlock different types of blocks and create their own structures. They could then share their designs with others for feedback and downloads. I was responsible for figuring out what we needed and implementing the client side, which involved communicating via REST API and handling the building scene. Interestingly, the second part was harder, even though I had more experience with it. My boss was very detail-oriented, making sure users would have fun stacking the blocks. He had a great sense for these things. Today, we'd call his feedback the work of an user experience designer.
I mentioned the scope was crazy, but we only realized that when one-third of the team left (read: one person). We scrapped the network features, but they were already deeply rooted in BrixAR, and at that point, completely redesigning the gameplay wasn't an option. The project shrank and had a few rough edges, but I still think it was a charming app with a fun, relaxing vibe.
Today, I don't think you can play BrixAR anymore – I haven't seen it in the app store. There's also not much info about it online. Looking back, it's clear the mobile market was starting to close off to smaller studios around that time, and without solid marketing, even a great product couldn't break through. Maybe I'm just being sentimental, but I like to believe that BrixAR was an undiscovered gem.
I remember that it was probably the only project that was so well-planned from start to finish. My supervisor presented the idea, and then we broke it down into the smallest possible tasks and estimated how long each would take. The planning process took quite a while, but it was really effective and accurate. This plan turned out to be a huge asset when it came to getting a publisher on board. Not even my naive, youthful honesty got in the way.
After my supervisor's great presentation, the publisher asked some technical questions to check our experience and skills. That's when I got to speak, and I think I was doing pretty well until the last question. Mr.io was being developed on Photon, and the publisher wanted to know more about our experience with this framework. I answered that we had none. "So what tools have you used before for online games?" I replied that we had never made any online games before and were completely new to it. I saw the panic in my colleagues' eyes, but it turned out to be unnecessary — the publisher signed the deal with us anyway.
Photon was actually pretty user-friendly, and we quickly got the online gameplay working. We had a lot of fun with it because mr.io was shaping up to be a good game. Now, don't get me wrong — it was still a clone of slither.io with the skin of the most popular plumber in the world, but a few ideas made the game more interesting and intense. During development, I was also in charge of stress testing, where many bot instances connected so I could optimize the remote call procedures. Interestingly, the stress-test bots later evolved into AI, and I wrote a small system based on behavior trees. I even thought about developing it as a side project, but I never had enough time for it.
Today, you can't play mr.io, just like BrixAR. The name, which was supposed to help attract players, now works against it — it's hard to find any information about the game. The project came and went without much attention, but in some way, it stood out from other similar clones due to its quality.
I hadn't been on the tools team long when we were tasked to create Developer Tools — a simplified version of the editor for modders. The decision to make Dev Tools wasn't surprising since the first Dying Light had them too.
The real challenge (since "problem" is an outdated word these days) came with one of the requirements: making it possible to run mods on consoles. This isn't common because consoles are closed systems, and game mods don't fit well with that. Still, it can be done. There are solutions, like mod.io, that make adding mod support on consoles easier, and we ended up using it. Thanks to gods of the source code, I didn't have to handle the integration, but my tasks weren't much easier.
We quickly realized the biggest challenge was with resource paths. Techland's technology used different types of paths depending on where each resource came from. It could be part of the project, the engine (shared between projects), or external. In theory, virtual paths should handle this, but if a developer specified the exact location of a resource, the file system would look in a concrete spot for it. In Dev Tools mode, there were no engine files, so we had to find all the paths pointing to unavailable locations and fix them.
I had plenty of other tasks, like fixing icons and the UI, but what I'll never forget is moving files to the right places and fixing hardcoded paths in the code. I felt like a total commander with a personality, but the effort was worth it. When the Developer Tools launched, I felt even prouder than I did at the end of Dying Light 2. I still see the release as a big achievement for our tools team, though we had help from colleagues in other departments. In the end, we, the tools team, were in charge of this small launch from start to finish. It was our moment of glory and our very own product for gamers.
Everything is a matter of scale and planning. I used to be able to spend a lot of time working through brute force, but that didn't necessarily mean I was any closer to achieving my goals. Today, I'm a little wiser and can break tasks down into smaller parts, which themselves turn out to have its own added value. That's exactly the case with kra_imp, a library that, in the future, is meant to become a component of a larger whole.
Instead of creating a frame-by-frame animation editor from scratch, I decided to use an existing one and simply import files in the native format. Krita seemed like a solid choice. I discovered that the .kra file format didn't have an importer that could handle this use case. The format didn't look overly complicated, and I thought others might benefit from such a tool as well. That's when the idea shifted from solving a personal problem to contributing something back to the open-source community.
The library only supports a small piece of the .kra format, but it does the one thing no other library can: it imports animations. It took a few evenings of coding, and since I wanted to share it with the world, I made sure to do it right. I designed an API that's easy to extend, added CMake scripts for painless integration, wrote unit tests that helped catch some bugs, and set up GitHub Actions. There's not a lot of code overall, most of the effort went into planning and designing it properly. And yes, there's documentation (my personal weak spot). The library is not perfect, but it's decent, especially for a first release.
This project won't change the world, but it feels good to build something not just for work or personal use, but for others too. After so many years of using open-source code, it was time to give something back. Even if no one else ever uses kra_imp, I can say one thing with confidence — I've contributed.
I used to work on many Unity 3D side projects, but I lost interest in most of them. I also had no problem showing my prototypes to others, and sometimes I even had someone help me. I'm not sure how it happened, but a small team of three came together for The Merchants (codename for my mobile game), and we started meeting regularly to work on it. It wasn't an exceptionally promising project, so I think we treated making the game as more of an excuse to hang out.
If you checked the authors, you will notice four names. The last member joined later, but had the greatest influence on the current form of the game. It was his suggestion that pushed us to create paper prototypes of the game mechanics. One day he came and said: "I don't think you will agree, but I have to show you something." We saw cards instead of a huge board with hexes, tokens and complicated mathematical formulas. We immediately liked it.
It hit us that this version was much better suited for a board game. We started taking production more seriously, even attending board game development meetups at the Warsaw University of Technology, where we tested our ideas with strangers. We also held our own playtests in local bars. By the time we found a publisher, the mechanics were already polished. That didn't mean the work was over. Hexy Studio came up with a new name, refined the setting, and added a visual "overlay" to the bare mechanics. They launched a successful crowdfunding campaign and released our game to the world.
Slyville is a fun party game, and I'm not just saying that because I co-created it. It has simple rules, is well-balanced, and generates a lot of laughs during gameplay. It's not how I originally imagined the project, but it exceeded my expectations in the end. If I had stuck to my first idea, I wouldn't have met so many interesting people, and the game itself probably would've ended up scrapped. But now I can proudly add it to my portfolio, even though I never planned to make it in the first place.
That was roughly the feedback I received from the narrative designer when I was presenting my ideas for solving some issues with the story and dialogue tools. It hit me. It hit me hard. As a tools programmer, I often hear, to put it mildly, a lack of enthusiasm toward my first proposals. It's normal and understandable. That's why I prototype and iterate ideas directly with users. Every meeting brings us a step closer to a satisfying solution. The feedback had always been about the ideas, but this time it was personal.
I did some research on writing. I started reading about screenwriting, listened to podcasts about writing books, and even read Save the Cat!, the bible of storytelling. It didn't really help much with designing tools, but it gave me a new perspective on literature. Just like in programming, a good story has to follow certain rules, and learning that opened new doors in my mind but, more importantly, created new needs. I knew I had to push myself and introduce the most crucial element of learning any new field — practice.
The process of coming up with stories turned out to be... relaxing. I started making up bedtime stories for my kids and ended up writing short novels. I don't have aspirations to become the greatest writer of our time, but I won't deny I was curious how I was doing. To find it out, I entered a contest organized by the fantasy club Ad Astra, and I did it! My story made it into the anthology Fantazje Zielonogórskie XIV. I hope this success will motivate me to keep developing, while still allowing writing to stay a simple and enjoyable hobby.
Someone might try to draw a moral from this story, that I turned a bad experience into something positive. There's definitely some truth to that. About how it's sometimes worth stepping out of your comfort zone and being pleasantly surprised. Also true. About searching for a solution and finding it in an unexpected way. Absolutely. For me, though, it's mostly another exercise, where I try to write a concise story in four short paragraphs.