Introducing ‘The Developer’
Hi there fellow reader. You can call me Ilyas and I’m doing experimental research at Gameye, as the final part of my Bachelor Informatics study at the Hogeschool Rotterdam. I’ve worked a few months at Gameye before as a developer working on improving Gameye’s internal infrastructure. It’s rather convenient to be able to focus on your assignment from day one of your internship because you get to skip the introductions.
My thesis will be dedicated to solving an integration of popular game engines with our Gameye infrastructure. We’re initially a game session hosting company that wants to solve problems related to latency by taking over the responsibility of hosting of game servers for game studios, so that they can focus on doing what they do best; which is building games. Eventually as a company we do wish to move on to other domains as well (besides gaming). We’re building a piece of technology, that we believe will be just as effective for other domains as it will be for gaming. Games are in fact one of the most complex pieces of software to exist within the software engineering field, especially online multiplayer games. So if we’re able to solve a problem in gaming, we should be able to solve it in other domains as well.
So why Gameye?
I chose Gameye because they provide the kind of service that I like to work on; game session hosting. In my spare time, I like to develop online multiplayer games so we’re automatically a match.
My backstory
I started programming at the age of 13 (about 12–13 years ago), working on servers, taking apart existing open source software, mutilating them and putting them back together like Lego’s. Ranging from web servers to game servers, I’ve taken them all apart. I’m a server guy. I love designing and building distributed systems. It’s like you’re putting a brain together with many different nodes that store information and then you have to wire these nodes together. Similar to a nervous system or like, the universe (if you go down to the microscopic level, they all even look similar!). The topic of distributed systems goes further than just computer science. There is a lot of philosophy behind it. It also has a scent of neuroscience to it. You are building a system that in essence models the real world. It’s a very challenging field. All these nodes within a distributed system have to communicate with each other. Reaching consensus is a very important part of it. A lot of things may (and will!) fail. Network may fail. Applications may crash. Your physical server may run out of memory. There may be an application bottleneck. You may run out of bandwidth. Retries are necessary. And probably the hardest of all; when things crash, you have to think of a strategy to bring nodes back up without losing precious data. These are just problems related to the host. Let alone deciding how nodes will communicate, what protocol, what language etc. Distributed systems are so complicated and I love solving problems related to these kind of systems.
What technology do you like to work with?
I’m kind of a polyglot. I like functional programming a lot (Scala, Haskell) but another side of me loves writing many side effects in Go. As long as the language and runtime are modern, I’m fine with it! Concurrent programming is one of the things I also aim to specialize in. I don’t fear threads, threads fear me because I will abuse them and make them suffer (just kidding, or am I?).
What are you researching at Gameye?
As we are a startup that primarily focuses on hosting of game servers, we need a solution that automates the workflow of hosting a game session for our clients. What we want for our clients is to simplify the deployment process. They focus on building a good game in their favorite game engine, we’ll provide the interfacing to allow their game to be hosted on our infrastructure. My experimental research is dedicated to developing this automated workflow and interfacing by designing and building an initial prototype that allows us to do this. All the way from turning the game into a self-contained deployable bundle, to extracting and wrapping the bundle into a deployment unit. Internally, we make use of container technology to solve many of our problems and we’ll continue to do so for this new solution. We wish to eventually move to a universal build target such as WebAssembly that allows us to interop our internal services that are written in different languages and runtimes. We love Go, we love Rust and we love TypeScript and we think being able to switch between any of them depending on the use case, is very powerful because they can all compile to one universal inter-operable build target.
If you want to connect, you can find me on LinkedIn and if you want to see the code I write, you can find me on GitHub.
Buh-bye.
P.S: if you’re wondering what my ethnicity is, I have four different ones. I’ll give one away for free. I’m 50% Dutch.
